Alarming based solely upon some set high or low reading has its value and place in the overall scheme of things.
It can alert you to the probable/possible complete failure of a sensor, or the wires connected to it.
For example, average background outdoors ambient CO2 in most places runs between 350 and 450 ppm. So it'd be pretty safe to say that an indicated reading of something like 250 ppm or lower on an indoors sensor indicates that you have a problem.
On the high side, things get a bit more problematic. Walk up to a wall mounted space CO2 sensor and breath on it a couple times. And watch the readings soar. You can cause the sucker to indicate 1300-1500 PPM without half trying in quick order. Just a couple exhalations will do it. Its one of the simple tests I do when commissioning a new installation, to ensure the device is working, and to verify that the sensor in question is indeed connected to the point I think it is. Or, if a networked, communicating device, that it's identified in the network correctly.
Its VERY unlikely that under any normal circumstance that you'll see 250 ppm or less on a space CO2 sensor. But it is quite possible that temporary high readings can be caused by such things as a teacher or student or occupant standing near a sensor for a bit, while chatting or whatever. I've seen this numerous times. Also have seen situation where in a grade school classroom teacher moved small work table very close to wall where sensor was located. And periodically a group of little, highly excited, heavily breathing urchins ... each trying to talk or squeal louder than the other ... sat virtually right under the sensor.
LOL ... I know about that one as I got a warranty call/complaint about it. Building maintenance guy, with brand new system ... so he was actually watching those screens with some regularity since the "new toy" effect had not worn off yet ... called me. Noted that between 4 nearly identical classrooms, with approximately same number of occupants, one kept indicating a reading that'd go high for a while. Much higher than the others. Driving outdoor intake high at the air handler. He couldn't figure out why, so thought sensor was bad.
I checked, classroom unoccupied, everything seemed fine. Sensor was checked. Seemed fine. Looked for the obvious, i.e. Things arranged so that it was possible someone periodically stood close beside sensor. Didn't look likely. Told maintenance guy I didn't know WTH. But I started a specific trend for that sensor. Checked a week later, sucker went high at approx the same time each school day. Talked to the teacher. When I mentioned the time of day, little bulb lit up in her head and she told me that was usually when she had this particular student activity, and as part of it, that table moved over by sensor, and yes it held a large group of little tykes.
Okay, mystery solved.
So if monitoring for a high alarm limit that'd signify to an operator that sensor is probably failed, you gotta watch that. Limit needs to be good and high, and should have some significant delay to it.
What becomes more difficult are those in between conditions. What's "normal", and what might indicate something like sensor drift over time?
Let's look a bottom line base levels, unoccupied. I stated that between 350 and 450 ppm is average for OA. But this varies. Plus the sensors we're discussing are inside the building envelop.
Some locations such as Los Angeles, New York City, Beijing, etc can have significantly higher ambient CO2 levels. More, given a single location, ambient CO2 levels can vary widely depending on the season, predominate weather pattern that day, etc. Heck, in the middle of a large, heavily forested area, far from the effects of human activity, windless conditions, ambient CO2 can vary as much as 100 ppm depending on the time of day. With a day time low caused by the plant life absorbing CO2, and a night time high caused by photosynthesis shutting down.
So how the heck do you go about doing something like detecting if a sensor or sensors are "drifting"?
i.e. In the example I spoke of in another thread, there were no "alarm" conditions occurring. What was happening was that some of the sensors, over time, were experiencing quite normal drift. "Zero" was moving.
Most modern CO2 sensors (and other gas sensors) are pretty darn good at linearity and repeatability. That is, expose to a gas in increasing concentrations, and if that last sample indicated 600 ppm, and you now expose them to a gas concentration 200 ppm higher, you'll probably get an indication of ~800 ppm. (Keep in mind the +/- 50 ppm or whatever the manufacturer lists for the sensor). Repeat test, you'll likely get the same results, close enough.
What tends to move, and which is not a sensor failure indicator, usually not, is the beginning point or ZERO starting point. Exactly why depends on the technology used, precise hardware of the sensor. But, for instance, a common scheme is the use of a light emitter which emits a very specific frequency of light which is just right to be absorbed by CO2 molecules. Light receiver at other ends of sampling chamber measures precisely the amount of light of that specific frequency which makes it through chamber, and electronics calculates ppm of CO2. Trouble si that over time, light emitter can age and lose a little power. Or chamber, which is reflective, can dull a little. And now a real ppm of 400 looks to the circuitry like 600 ppm.
So now, were at normal unoccupied times sensor dropped indicated readings to ~400 ppm. Now only drops to ~600 ppm. (This occurs pretty slow. I'm using a 200 ppm difference as an example. Normal drift only occurs a few ppm at a time.)
Next day, when occupied, occupants bump up CO2 maybe 400 ppm, as they always have. When sensor gave true reading, 400 plus 400 = 800 ppm, no problem. But now you've got 600 + 400 ppm = 1000 ppm.
And in the case of the example site I mentioned, OA is driving open a bit more than it used to, or needs to. That's a loss of condition air and a need to condition more air than really required.
Maintenance staff wasn't seeing any alarms. And in truth, they didn't really understand just a lot about how the system worked or what to expect for "normal" CO2 readings, etc. In fact all of them thought the CO2 thing was all about safety and protecting folks from a "hazardous gas". After all, CO2 is the boogie man these days. LOL ... they were somewhat surprised when I told em that the "hazardous gas" issue was a non-issue, really, unless you got to levels beyond anything those sensors could measure. This was a matter of air quality, not danger.
Anyway, took em some time before somebody finally paid attention, questioned what he was seeing in some cases, and wondered why spaces were taking in more OA than they used to ... all the time. He wasn't even sure if he was right, had a reason to be concerned, etc. But got up enough gumption to give me a call and ask me to take a look.
Anyway, I got them squared away, and things set right. Plus spent a couple hours educating them. Well, at least a few key characters. They'll probably remember long term, and actually act upon the info. The rest have probably forgotten by now. Or didn't care to start with. You know how that goes.
This site, the first, the one that called me in, was a High School. A BIG High School. Until recently, the biggest in the state. If you consider that they were probably averaging somewhere around 20% excess OA, that can add up. In some cases, particular air handlers were taking in more than that.
All without an alarm condition being met.
However, detecting such issues isn't a matter of just plucking some number and associating an alarm with it.
What number would you use?
Keeping in mind that the lowest number you might see (indicative of an unoccupied period) in a 24 hour period can vary considerably due to variations in ambient OA CO2 concentrations. And whats expected and normal can vary geographically.
Add that you might have areas never unoccupied, or other special case areas. Such as the smoking area you mention. Or in the case of several high schools I service, they have indoors greenhouses, welding shops, etc.
Exclude the special cases for this discussion.
For the ordinary use spaces, a possibly workable approach is to do a simple comparison if you have multiple similar use spaces. Record daily low readings. Arrive at an average. Toss out any numbers varying significantly from the others. Compare each sensor, daily, with that average on an individual basis. Pick a number, lets say 20%. If any one sensor has a daily low recorded which varies from the average by more than 20%. Flag it somehow for attention. Or show simple bar graph, one bar indicating average low, another indicating this particular unit's low with bold numbers indicating, for example "23% deviation". Or whatever. Something to catch operators eye.
Or pick any number of other schemes. i.e. If you have an OA CO2 sensor, show 3 bar graph with low for OA sensor, average low for all indoor ones, daily low for THIS one. Keeping in mind to compare similar usage spaces.
Whatever. But don't just show endless list of recorded numbers. Nobody looks at that stuff. At least not with any regularity. Usually not at all 2 years after the new installation.
In that last example, for instance, with the 3 bar graph, you can catch operators attention, but reduce nuisance alerts, by doing a test. If THIS sensor is 20% out as compared to the others, do a popup or whatever saying "Possible Maintenance Needed, Check Sensor Calibration". BUT ... make that percentage user adjustable. Give it a default, but let em be able to adjust it for removing nuisance alerts where a particular space might indeed, normally, have a higher low than the average of the others. Instruct operators than once alert is given, and sensor checked and verified to be correct, adjust the number.
You could add feature so that one or two times of being "out of bounds", show it, but don't alert. Third time, do the pop up. This would take care of a single abnormal condition which might not be an actual failure of sensor.
You get the idea, I'm sure. Nuisance pop-ups or alerts just get ignored, or disabled.
For SysInt. One of the problems with this kind of stuff, from my point of view is that it is extra work for the guys doing the installation. True, its not a LOT of work. But it is extra work.
Don't even mention that we could save effort by not showing the usual data we do. I know the answer to that from the vast majority of our customers. They're going to want to ALSO see the current CO2 readings. So that's not going away.
Might save on doing useless trends and endless lists of numbers. I have sites that have data of things like current CO2, or space temp, or whatever, readings every 15 minutes for the past 10 years. Nobody actually looks at that stuff. I don't even when trouble shooting. Too many friggin numbers, made meaningless over time. I just start fresh trend/data collection so I'm looking solely at numbers relevant to NOW. Current situation. Kill the trend when problem identified and resolved. The only currently running trends, graphs, etc any of my customers are running that are worth the time and effort that I know about are with customers renting/leasing office spaces. Who have us tracking customer energy use for billing purposes.
i.e. Have a customer who tracks energy consumption of fan motors on air handlers. Why? I sure don't know. Well, I do. The guy who designed their system, who spec'd what controls we were to do, specified this. <Shrug> Its just a numbers collection thing no one looks at.
Customer head of maintenance asked me what those numbers should mean to him. I shrugged and said that as it was done ... it meant nothing. It was what it was. Air handler energy consumption at any one point of time, was whatever it needed to be to satisfy demand. And that varied IAW OAT, occupancy, whatever space temp set points occupants decided they wanted that day or that week, what kind of reset he was electing to use on his heating water boilers lately (he varies it because at spec'd reset rates, system is slow to warm up spaces, people b*tch if its really cold outside, etc), or reset used on CHW, etc, etc, etc. Too many variables for those recorded energy usage numbers to mean much.
You'd have to know a dozen other related pieces of data to have any real idea of whether a particular energy usage number for those fans was unusual or not.
The thing is, a lot of what could be done better as concerns HMIs and employing your suggested types of techniques ... and your suggestions are good ... would require not only additional programming time but also some time spent collecting base data, so you have something to work with which might indicate the "health" of this or that system.
That later point would be the real time eater.