For temperature measuring I selected a popular and cheap DHT22 sensor. The DHT22 contains temperature and humidity meter in a same package and it is packed to the plastic box that can be attached to the wall. The sensor is preatty cheap - price is about 10€. Adafruit provides ready to use Arduino library and tutorials to use the DHT22 sensor so taking sensors to use is relatively easy.
Summary
On my project the most difficult part was to manage the Feather board power consumption (actually the ESP8266 chip is the issue). This is an issue especially on battery powered setups since the board will run only couple weeks by the batteries. The TPL5110 breakout is an useful extension to solve this issue especially if the setup can be switch off periodically.
The Feather board itself works well and I didn't have any issues with the board.
The DHT22 sensors works well expect the issues to power up the circuit. I didn't find any good solution to solve that issue and ended up to manually hook the wires to get the sensors work.
In future I will replace the prototyping board with more solid solution. The prototyping board may cause some issues since it is very easy to accidentally loose the wires.
 |
| I have created a simple dashboard to the Adafruit IO cloud. |
The project
The setup contains Adafruit Huzzah board, four accu-batteries and two DHT22 sensors. Setup is assembled to the prototyping board.
On my home, the one DHT22 is placed in the living room and second is in the air conditioning pipe where fresh air flows into the room. Measurements are collected and sent to the cloud over the wifi in every 10 minutes.
My aim was to create a battery powered setup. I noticed immediately that the power consumption of the Feather board is relative high. For that reason I ended up to try couple different setups. First setup was using DeepSleep mode of the board to restrict the idle power consumption. That didn't give enough battery life so I made a second version that was using an additional TPL5110 circuit to control the power.
Version 1 with ESP8266 DeepSleep mode
The first version of the setup was using the Feather ESP8266 board DeepSleep mode to save the power. In a DeepSleep mode the Feather will shut down all functions expect the real time clock. On my project the Feather was put into the DeepSleep between the measurements. Practically the Feather was awake about 10 seconds that was required to send the data to the cloud and after that it was shut down to the DeepSleep for 10 minutes.
The DeepSleep mode is activated from the program code by simple command: ESP.deepSleep(milliseconds). After the given time, the board wakes up. Note that the wake up will reset the board.
The reliability of this setup was very good during the couple months when it was in use. Only issue was battery life that was about 10 days with the four accu-batteries.
I measured power consumption of the Feather. The board takes about 100mA current when connected to the Wifi. In the DeepSleep mode consumption is still 7mA. The DeepSleep consumption is the problem since it will eat the batteries empty even nothing is happening.
Charging accu-batteries in every 10 days was a bit frustrating so I started to search a better solution.
 |
| The version 1 circuit is very simple. Instead of the picture, I have four AA batteries. |
Version 2 with Adafruit TPL5110 Power timer breakout
The second version of the setup was using the Adafruit TPL5110 breakout to control the power.
Adafruit site says: "TPL5110 will take care of turning your project on/off using a built in timer that can vary from once every 100ms up to once every two hours. Basically, the TPL will turn on periodically, adjustable by potentiometer or resistor, and turn on your project's power. It will then wait until a signal is received from the project to tell the TPL that it can safely turn off the power."
The circuit:
1) After the Feather has sent data to the cloud it will switch the power OFF by rising the GPIO pin to HIGH. 2) The TPL will wait the time amount that is defined by the build in potentiometer. 3) After the time has passed the TPL will switch the power ON.
The TPL itself consumes very little power so the Idle power consumption is much less compared to the version 1.
I noticed that the Feather GPIO pins 4 and 5 are the only pins that can be used to control the TPL5110. Every other GPIO pin has a strange feature: there happen a small voltage peak when the power is switch ON to the Feather board. That peak is just enough to trigger the TPL to cut the power immediately OFF and the setup never start up properly. The voltage peak cannot be controlled from the program code so it must be related to the board build-in boot sequence.
The reliability of this setup has been excellent. The setup run 45 days before the accu-batteries were empty. That is 35 days more than without the TPL5110 brakeout.
After the first tests I realized that the DHT22 sensor is quite unstable. Often the sensor value can not be read after the power is switch on to the board. It doesn't matter whether the board is powered from the USB or battery. After some googleing I found that the issue is well known and reported on the discussion forums and blogs.
I found that quite often the sensor starts to work after manually loosing the sensor power wire and then instantly plugging it back. This must be done while the board is powered and reading the sensor.
I also tried to take the sensor power straight from the board IO pin. That way I was able to control the sensor power from the code by switching the IO pin HIGH and LOW. This also didn't give any real help.
My conclusion is that the sensor just is unstable. If the first reading is fine after the power is switch ON, then the sensor will probably work without any issues as long as the board is powered. If the first reading does't success, then it will not repair itself without actions. With the TPL5110 the sensors seems to work better.
- Power to the Feather is wired though the TPL breakout
- The Feather GPIO pin 5 is connected to the TPL "done pin"
1) After the Feather has sent data to the cloud it will switch the power OFF by rising the GPIO pin to HIGH. 2) The TPL will wait the time amount that is defined by the build in potentiometer. 3) After the time has passed the TPL will switch the power ON.
The TPL itself consumes very little power so the Idle power consumption is much less compared to the version 1.
I noticed that the Feather GPIO pins 4 and 5 are the only pins that can be used to control the TPL5110. Every other GPIO pin has a strange feature: there happen a small voltage peak when the power is switch ON to the Feather board. That peak is just enough to trigger the TPL to cut the power immediately OFF and the setup never start up properly. The voltage peak cannot be controlled from the program code so it must be related to the board build-in boot sequence.
The reliability of this setup has been excellent. The setup run 45 days before the accu-batteries were empty. That is 35 days more than without the TPL5110 brakeout.
Stability of the DHT22
After the first tests I realized that the DHT22 sensor is quite unstable. Often the sensor value can not be read after the power is switch on to the board. It doesn't matter whether the board is powered from the USB or battery. After some googleing I found that the issue is well known and reported on the discussion forums and blogs.
I found that quite often the sensor starts to work after manually loosing the sensor power wire and then instantly plugging it back. This must be done while the board is powered and reading the sensor.
I also tried to take the sensor power straight from the board IO pin. That way I was able to control the sensor power from the code by switching the IO pin HIGH and LOW. This also didn't give any real help.
My conclusion is that the sensor just is unstable. If the first reading is fine after the power is switch ON, then the sensor will probably work without any issues as long as the board is powered. If the first reading does't success, then it will not repair itself without actions. With the TPL5110 the sensors seems to work better.
