Home environment monitor

Yet another wireless network of environmental sensors in a home

Similar projects worth following
Wirelss network of sensors for monitoring my home

Overall this is a collection of environmental sensors to monitor and control my house.

The following locations will be monitored:

  • Garage (temp, humidity, pressure tVOC) [possible expansion to monitor household current use as well as furnace oil tank level]
  • Yard (temp, humidity, pressure, solar panel output, supercapacitor bank voltage)
  • Back shed (temp, humidity, pressure)
  • Main thermostat location (temp, humidity, pressure, tVOC, battery backup voltage level, ambient light level, output demand output to furnace)
  • Master bedroom (temp, humidity)
  • Attic (ambient temp, domestic cold water pipe temp, domestic hot water pipe temp, baseboard heating return temp)
  • Office (temp, LoRa gateway)

Logging will be to Prometheus database with Grafana front end.

Control/update protocol yet to be determined

Nodes inside the house will use WiFi

Nodes outside and in back shed will use LoRa

Temp control of furnace will be a combination of inputs: user requested temp, average of interior measured temps, lower threshold for domestic water pipes. 

  • 2 × Raspberry Pi Zero W
  • 1 × Adafruit BME680 breakout
  • 1 × 3.3k Ohm resistor
  • 1 × 470 Ohm resistor
  • 1 × 1200 mAh Lithium Poly battery

View all 13 components

  • New direction for Dwalin (thermostat)

    Tundra2 days ago 0 comments

    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). 


    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. 

  • Power management issue resolved

    Tundra01/06/2019 at 23:10 0 comments

    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.

  • Dwalin: Power management problem

    Tundra01/06/2019 at 20:28 0 comments

      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.

  • Dwalin: More fitting work in the enclosure

    Tundra01/05/2019 at 22:19 0 comments

    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

  • Working out enclosure for Dwalin (thermostat)

    Tundra01/01/2019 at 22:37 0 comments

    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.

  • Dwalin (main thermostat) progress update

    Tundra12/29/2018 at 03:02 0 comments

    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 first runtime result

    Tundra12/20/2018 at 04:24 0 comments

    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

    Tundra12/18/2018 at 11:49 0 comments

    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 runtime results

    Tundra12/16/2018 at 18:55 0 comments

    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. 

  • Measuring dwalin Feather runtime (thermostat on LiPo)

    Tundra12/13/2018 at 12:49 0 comments

    For most modules, when the house doesn't have power, I'm not worried about the modules being offline. For the thermostat, however, I need it to run even without power, as it's controlling heat for the house. I have a generator that covers a few circuits, including the furnace, but the thermostat is located in the junction of bedrooms and office, not near the furnace, so it won't be covered by the generator. Since the longest power outage I've had in this house was 3 days, I'm targeting 72 hrs of run time for the thermostat without wall power. To achieve this, I'll need an internal power storage unit of some kind as well as a mechanism to use minimal power from that storage. So the thermostat consists of a Raspberry Pi Zero W for communication, which will be powered from the wall and not off internal power, as well as a Adafruit Feather which is what directly controls a relay to switch the furnace. The Feather will be running on either supercap or a rechargeable battery of some kind. 

    Last night I set up the Feather connected to the Zero with a serial line between them so the Zero can log what the Feather is outputting. The Feather has a sketch on it that allows up/down adjustment of set temp via two physical buttons, running an MCP9808 to measure temp and a eInk display to show current temp, set point, battery voltage and 'furnace commanded on' or 'furnace off' as well as reporting status out the serial port to the Zero. 

    For the first test, I'm running this off a 1.2Ah LiPo cell with the eInk to see how long it's able to run in that configuration. The only thing that's not currently part of the circuit is the relay (hence it isn't actually commanding the furnace) 

View all 11 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates