Home environment monitor

Firmware is slowly coming together for ESP32 module based version of Dwalin (thermostat). 

Working features:

• OTA update
• Rotary encoder pushbutton to cycle through info screesn
• Rotary encoder to adjust set-temp
• Furnace relay responding to any time set-temp is higher than average temp
• Actual & Network Average stubbed out to just unchanging '68' degrees
• Refresh rate on OLED at 0.5s for full update
• Light sensor turning on/off onboard LED as placeholder for NeoPixel control

Pending work:

• Enclosure
• BME680 integration
• MQTT (or other) control & cell app
• MQTT (or other) logging
• MQTT (or other) input of other temp sensors to build up NetAvg temp
• Wire into furnace

I'm still undecided on enclosure - I've got several, but basically I have a handful that might just barely fit everything and one that's huge and would be relatively empty. The smaller ones look better, and I'd prefer to have the finished product not have a 'hacked together DIY' look. The X and Y axis space will be tight but should fit - my concern is the Z axis as I need to attach the OLED and rotary encoder to the cover and leave enough clearance behind them so they don't contact anything on the  main prototype board. 

Status update since last log entry

After getting power handling resolved in last log entry, I started to really think how amazing the existing Honeywell thermostat was. It's been years since the last time I changed AA batteries in that thing and it's still chugging merrily along. I "knew" that it was only a 2-wire hookup, but I started to doubt myself - wondering if perhaps it's actually pulling power from the furnace. As a simple diagnostic, I shut off the furnace switch - and the Honeywell is still displaying. I also double checked and sure enough, only two wires are connected. It is still possible that the Honeywell is drawing phantom power normally (the way some smart thermostats can) and storing it in a supercap - or it could just be a very efficient design that can run an LCD years from a pair of AA batteries. While I was checking this, I noticed that I can actually send 24V AC from the furnace, and frankly that makes the thermostat requirements much simpler (no need to run when the furnace has no power, so no need for multiday standalone backup power). 

Redesign

Now that I don't need to run for multiple days without power, I am thinking that the space and complexity of two units within the thermostat housing is a poor tradeoff, so I'm switching from a Pi Zero W serial linked to a Feather to an ESP32 module (NodeMCU from HiLetgo specifically). I also picked up a cheap buck regulator for power. Feeding it from the 24V AC line through a bridge rectifier. The whole circuit is a lot more compact now. 

I am finding the ESP32 IDF environment a lot more complex than programming the Feather in the Arduino IDE. 

Not sure how to calculate what size actually needed correctly, but... I slapped a bigger capacitor (1000uF - why isn't it labelled as 1mF?) in and that appears to have resolved the Pi brownout problem.

I'm moving Dwalin from the breadboard stage to prototype in the enclosure. As part of this, I'm setting it up so that the Pi can turn off power to the Feather in order to run the Feather from the LiPo battery once a week. Unfortunately I've run into two problems: 

1. I didn't set it up so that I can either reach the LiPo JST connector when everything is mounted into the enclosure (even with the top off) nor so that I can reach either the reset button on the Feather or on the Latching Relay Wing. For now, until I get a reset button for the Feather accessible, I've just been using a jumper to manually reset after I get everything plugged in.
2. A bigger issue is around startup draw from the Feather, particularly in the context of the Pi disconnecting input power going to the Feather. If I have the LiPo plugged in, things are working correctly (the charge indicator on the Feather tells me that power is coming in or not and both Pi and Feather work as I expect through a power off/on cycle of the Feather initiated by the Pi). If I don't have the LiPo plugged in, when I command the Pi GPIO pin connected via transistor to the relay to open the +5V to the Feather the Feather will simply shut off as expected. When I command the Pi to return power to the Feather, the Feather starts (f.e. expected output to the OLED), but the Pi reboots at the same time. I think what's happening is that the startup of the Feather is briefly drawing enough current to trigger the brownout detection circuit on the Pi and so the Pi is halting/resetting.

I tried putting a 47uF cap between +5V and GND, but that wasn't sufficient to carry through the transition.

More fitting work, soldering up headers.

Stack from bottom to top:

1. Adafruit Feather M0 Express
2. Adafruit Latching Relay wing, Raspberry Pi Zero W
3. Adafruit Raspberry Pi Protosheild (I didn't do enough research on this - it's the older 26 pin header not the current 40 pin - fortunately the pHat I'm using works fine with only 26 pins)
4. Pomironi eInk pHat and power cutoff relay for Feather stack and SSD1327 OLED display and rotary encoder

Not on the stack:

• Neopixel stick
• Mcp9808 for feather
• Bme680 for pi
• Usb case connector

I purchased several different enclosure since I'm not sure of final packaging. The largest arrived (it is actually a somewhat chunky handheld enclosure rather than wall mount), two haven't shown up yet but from a 1:1 printout of the drawings I think the largest is going to work best anyway. 

Started mocking up layout of components in the enclosure. I'm going to perforate the battery door and use that space to house the temp and humidity sensors - away from heat generated by the electronics.

I did a bit of work with the sleep modes but didn't have much luck. Specifically, I had trouble getting interrupts to work during sleep.

In the meantime, I've added a rotary encoder instead of up/down buttons, just because I think as an interface for ordinary people a knob is pretty easy to know what to do. 

I also hooked up photo transistor and NeoPixel stick to use as a nightlight. 

I'm still waiting on an enclosure. 

OLED display runtime was 52.3hrs to hitting the wall of not dropping voltage, and 54.3hrs till last serial data. I'm not sure if the significance of it, but the OLED was still displaying the last image (meaning it was running fine when the Feather ARM processor brownout detector halted operation). Also measured OLED module consumption at 8.6mA (not including the Feather in this measurement) during the test with DMM. 

Calculating average usage:

For cell capacity of 1200mAh, for the run with eInk, at 85 hrs, if I was able to pull all the available capacity out of the battery, it would be 1200/85 = 14.11mA average and for the OLED test at 54.3hrs it would be 1200/54.3 = 22.1mA average. I suspect my calculation is somewhat high as the OLED still displaying an image tells me there was still some untapped capacity remaining in the battery. The eInk displaying an image after the end of the test means nothing, as it will hold the same image with no power applied.

Difference between eInk calculated average draw of 14.11 and OLED calculated average draw of 22.1mA is within 10% of the measured OLED module draw of 8.6mA. To see 72hrs on the 1200mAh means getting the total draw under 16.6mA - I'm not sure if it's possible to reduce the OLED, meaning I'd have to drop the average Feather consumption approximately 50%. I'll need to research how the sleep modes work. Other options are a bigger battery, accepting the need to charge from a battery pack during power outage exceeding 2 days or getting power to the thermostat from a circuit powered by the generator. I would prefer to run off alkaline so that  replacement is trivial in extended power fail situations or supercapacitor so that cycle life of the battery isn't a factor. 

OLED runtime test in progress. It's definitely going to have a shorter runtime than the eInk display did. Currently at 3.84v after 23.75 hours. The eInk run took 38.6 hours to drop from 4.2v to 3.84v. If the ratios hold this means 51.68 hours to stop of serial data and 49.8 hours to stop of meaningful battery voltage readings. We will see how accurate that prediction is.

First thermostat runtime test results

The good news is that with the eInk display, the Feather is able to run longer than the target goal of 72hrs.

From start of test, until approximately 81 hrs in, the measured voltage off the Feather appears to match the shape of what I would expect for a LiPo cell. However, from hr 81 to 85, the Feather continued to run and report approximately 3.5v, however this value didn't change (which seems unlikely) - I'm wondering if this is an artifact of the 3.3v regulator needing 0.2v drop to operate and the ARM processor measuring from Vin and assuming that was 3.3v (even when it was lower).

On plugging in USB power again and charging the LiPo cell, the Feather reported 3.14v as the first battery reading. 

Currently logging charge voltage curve.

Next test will be replacing the eInk module with an OLED module and performing the runtime test again.