Is My Thermostat Lying? Designing a Low-Power Multi-Sensor Node (Series)

A Cruel Thermostat

I'm sure many of you can relate to the lies that our thermostats push to us every day, 68 degrees my foot. Jokes aside, it's well established that the temperature across the room is not constant, with variation from the floor to ceiling, as well as local hot-spots near heat generating equipment or personnel. This creates a need for localized heat monitoring to track and log these hot-spots.

Where There's One There's Another

Additionally, in spaces with large heat generation, specifically from additive manufacturing or soldering, there is a marked increase in VOC, NOx, and CO2 generating. This poses several risks to occupants, from CO2 accumulation, to long term health degradation from exposures to VOCs such as styrene.

Engineering a solution

To track and monitor these quantities, I began work on a small air quality monitoring project. The first version began as a DHT11 connected to a raspberry pi pico. But after its untimely destruction, and with the accuracy of the DHT11 having much to be desired, I set out to create a new unit.

Requirements

The system was designed with four primary constraints:

1. No daughterboards (fully integrated design)
2. High-accuracy sensors
3. On-board power (battery operation)
4. Compact footprint

Version 1

The first official version of my air quality sensor, dubbed the Air Sentry was based off of the ESP32. Unfortunately, I did not include a USB interface on the PCB, which made programming and powering difficult. Apart from that small oversight, it was powered off of an internal battery, and could take 5 different measurements:

1. Temperature via SHT45
2. Humidity via SHT45
3. CO2 via STCC4
4. VOC Index via SGP41
5. NOx Index via SGP41

The primary motivator behind the ESP32 was fourfold:

1. A large amount of computing power
2. Ease of hardware integration
3. Programming over the USB interface
4. Relatively inexpensive

The ability to program over USB, rather than with a dedicated debugger gave me the ability to quickly program on the fly, rather than finding where I put the programmer. The ease of integration allowed me to focus on the design of the sensors, rather than the complex RF integration that BLE requires.

Numerous electrical issues primarily related to power regulation prevented reliable operation, leading to a rapid redesign.

Version 2

Version 2 addressed the power delivery issues identified in the first design and improved overall board stability. It also included some LEDs but kept the same sensors. There were also numerous electrical fixes that were identified from the first version. Before I manufactured this board, however, I shifted towards a longer and less square layout requirement. This was to try turning it into a commercial product.

Version 4

Funny enough, I skipped version 3 accidentally, but nonetheless, version 4 was built with this new requirement. Again, based around the ESP32, it included a new BMP390 barometric pressure sensor, and removed most of the LEDS. This was the first version to be successfully constructed. And after some driver development with ESPHome, I had a fully functional sensor node to play around with. However, power management with ESPHome proved challenging. As the project shifted toward longer-term data collection, I needed the device to operate for at least a week on battery power, something the current architecture struggled to support.

Version 5

Version 5 of the Air Sentry introduced the first major architectural redesign of the device since its inception. Thus, past version 5, the name officially changed to the Air Sentry Neo. The Neo replaced the ESP32 with a nRF52810 MCU, and consolidated the battery charging and voltage regulation using the nPM1304 PMIC. The combination allows me to have full control over the power of the device, with a sleep current under 500 µA. This transition traded the simplicity of ESP32-based layout and integration for lower idle current and more granular control over power modes. The improved efficiency also enabled a smaller board footprint without introducing thermal drift issues in the temperature sensor. On the software side, the system transitioned to Zephyr RTOS, and initial bring-up was successful with reliable sensor readings.

Unfortunately, there were issues with the clock generation, which led to a kernel panic when the BLE systems were turned on. This leads to the current state of the project: Version 6, which is focused on stabilizing the clock system and finalizing the design.

Conclusion

What started as a simple attempt to verify a thermostat reading evolved into a full design of a low-power, multi-sensor environmental monitoring system.

Across multiple iterations, the project highlighted several key lessons:

• Power architecture is critical for battery-operated systems
• Rapid hardware iteration exposes design flaws early
• Platform choice (ESP32 vs nRF52) has a significant impact on power performance

With Version 5, the system reached a point of functional maturity, achieving reliable sensing and a substantial reduction in power consumption. However, challenges with clock stability and BLE integration remain.

Version 6 is currently in development and is focused on resolving these timing issues and finalizing the design for long-term deployment.

Ultimately, the goal is to use this system to generate and publish data on environmental conditions in additive manufacturing spaces—providing greater transparency into how these environments impact temperature and air quality.