Imagine that you’re starting a project where you need to measure temperature and humidity. That sounds easy in the abstract, but choosing a real device out of many involves digging into seemingly infinite details and trade-offs that come with them. If it’s a low-stakes monitoring project, picking the first sensor that comes to mind might suffice. But when the project aims to control an AC system in an office of temperature-sensitive coders, it pays to take a hard look at the source of all information: the sensor.

Continuing a previous article I would like to use that same BMaC project from that article as a way to illustrate how even a couple of greenhorns can figure out how to pick everything from environmental sensors to various actuators, integrating it into a coherent system that in the end actually does what it should.

Popularity Isn’t a Good Indicator

A major issue when it comes to figuring out which components one needs is that there are a lot of (online) articles, forum posts and other commentary out there by people who are using the same sensors and actuators without ever really questioning why they are using those devices and not others. A good example of this are the DHT11, DHT22, and AM2302 temperature and hygrometer sensors. While very popular and used by everyone and their dog, they come with a whole range of potential issues.

This sensor and a number of others were recently compared in a comprehensive test. The findings of that test showed that across six different sensor devices (specifically the DHT22, BME280, SHT71, AM2320, HTU21D and Si7021), the DHT22 performed the worst, with three out of six sensors outright dying over the course of two years.

They also showed issues with variability between individual sensors and a lack of long-term stability and reliability. Long-term stability cannot be expected, self-heating is an issue, and there’s no reliable way to detect strong heating or cooling as compared to a failing sensor.

Another issue that makes this range of sensors so annoying to work with is that they use their own, proprietary interface and protocol. This protocol is somewhat similar to the 1-wire protocol as invented by Dallas Semiconductor, but uses its own timing system and without the bus-mastering additions. With only its from Chinese translated datasheet to base a library on, one has to raise serious questions about the reliability of any system that includes one of these sensors.

In the BMaC project we initially started out with these DHT22 sensors as well. They were cheap and plentiful, and at first glance they seemed to be just fine. Unfortunately the breakout boards we had did not include the proper resistors on the breakout board, so humidity measurements were off by a few percent RH, as we found out later. These sensors, especially including the breakout boards, are rather bulky as well, making them hard to integrate into projects.

At some point we came across this MEMS sensor from Bosch, the BME280. It was similar to the BMP180, another quite popular MEMS temperature and relative humidity sensor. The BME280 does pretty much the same, only a bit more accurately, and also adds air pressure measurements. Even better, these sensors on a nifty little breakout board cost little more than the DHT22 boards we’d been using until that point.

These Bosch sensors all use either an I2C or SPI bus. This means that one can hook multiple of these sensors to a single I2C bus and communicate with them using an industry-standard protocol. This massively simplifies the sensor code, as it only has to concern itself with reading out the appropriate registers, instead of also the timing and interpretation of the received bits.

So in short, these BME280 sensors turned out to be the superior choice for the project. They are much smaller and more accurate, use a standard interface, and make it easy to chain multiple sensors to a single microcontroller and gaining air pressure readings in the process.

Devil is in the Details

With hygrometers, self-heating can lead to inaccurate results. The act of measuring the temperature simply causes the device itself to heat up. While working on the initial BMaC project, we struggled trying to determine the accuracy of our thermometers, both DHT22s and BME280s, in the absence of some absolute reference sensor.

There are plenty of forum and mailing list threads where people note that their BME280 sensor is measuring two degrees higher than it should, or their DHT22’s measurements are completely out of whack. While the latter we unfortunately found out ourselves to be the case for certain breakout boards, the former issue with the BME280 was harder to pin down as being true.

Since that time, people including the very same who did the aforementioned hygrometer shootout also did an absolute temperature test of the BME280 and DS18B20 sensors, with the conclusion that there’s no sign of self-heating apparent. Possibly one could induce some level of self-heating in the case of rapid and sustained measurements, but then one would have to wonder about what kind of environment would have a temperature that changes so quickly that one-second temperature updates are necessary.

For the BMaC project we used a measuring interval of 30 seconds, which was more than sufficient for general room temperature measurement. Even when we moved to using the BME280 sensors as inputs for the air conditioning control system, we got nice and tight feedback loops between the AC and the temperature response, as can be seen in this image:

The blue graph (MemoryLeak) is the temperature reported from the ceiling-mounted BME280 sensor in a meeting room with two AC units, whereas the other two squiggly lines (Großraum 3) were from the same type of sensor setup in the center of a line of three AC units in an open-plan office.  Finally, the sensor readings post-fixed with my name were DHT22-based setups on my desk in that same open-plan office.

The sensor setup in the open plan office was also controlling the AC unit’s fan coil unit (FCU) while measuring the temperature in the same space. The difference between the meeting room and general room readings show how different both systems are configured and measure. The original AC controller with a wall-mounted sensor and aggressive heating pattern ramped up the fan quickly, easing off when the target temperature got reached.

In comparison, my ceiling-mounted sensor and controller took a more gradual approach, preferring to slowly ramp up the fan speeds in small increments and constantly adjust using the temperature readings from the nearby BME280 sensor. Obviously, for critter comfort, it’s important that such systems are non-obtrusive and – above all – accurate.

Time to Actuate Serious Business

While playing around with temperature is fine and everything, the real fun starts when one starts manipulating the water valves and other toys that are hidden in the suspended ceilings of office buildings. Changing the fan speed of the FCUs was easy enough – using a 0-10 V DC signal into a header on the original FCU controller board – the valves controlling the flow of hot and cold water (as described in the aforementioned previous article) required a few bits of custom hardware.

The valves near the FCUs are usually the linear thermoelectric actuator type, whereby a material inside the valve is heated through resistive heating in order to cause a linear motion. This motion in turns either opens or closes the valve. The ones we came across were made by Honeywell, with the 24 VAC version installed. These look similar to these:

This was high stakes hacking. There was every potential that by using the valves in the wrong way, leaving them open for too long, or drawing too much current we could irreparably damage something, or worse: disable the AC system in the entire building. That’s the kind of scenario where you wish that you had paid more attention to a robust system for the actuators.

The system that we ended up implementing for the air conditioning valves either used the standard control signal via a relay for whole-floor-section switches, or the 24 VAC supply that was already present on the original valve control line for the FCUs, bypassing the original relay. For the latter we used an industrial Phoenix Contact SPST relay, driven by a Darlington array from an MCP23008  I2C-based GPIO expander.

The advantage of this system is that it uses off-the-shelf components that are meant to be used in an industrial setting. By ensuring that especially the mechanical (relay) parts are rated for the conditions in which they are meant to be used (mounted in a stuffy, hot space above a suspended ceiling), failure over time should be unlikely.

When One Can Afford to Learn Lessons

As the BMaC project (or ‘playing with IoT stuff’ as it was still known back then) kicked off, there was nothing crucial about anything we did. Using DHT22 sensors, only to find out that they weren’t that good was therefore totally okay. As the project escalated from merely making measurements to controlling parts of the building’s systems, it soon became clear that the stakes had risen dramatically.

In any project that uses sensors and/or actuators, the need to validate sensor and actuator accuracy and reliability over time is directly linked with the consequences if any of them were to fail. Having inaccurate room temperature measurements displayed on a Grafana dashboard is embarrassing, having a dodgy coffee machine is annoying, having a non-functioning air conditioning system can cost the company thousands of Euros in lost productivity, or worse.

This leads to the take-away message of this article; the most essential part of any serious project is to know what the cost of failure is, and how to hard to try to avoid this by picking the right system components.