This project is a mashup of different experimentations. I wanted to try the SHT21 sensors and I was looking for a CO2 sensor at the same time accurate and not too expensive.
CO2 Sensor
Until recently, gaz sensors were either analogue (and totally uncalibrated) or relatively expensive (when not both at the same time). Then came the MH-Z14 which is a affordable "Non-Dispersive InfraRed" sensor, in theory quite selective.
The MH-Z19 from the same company can be found for ~ $25. The main issue is the partial documentation. Some commands are still a bit obscure.
A great source of information is the wiki https://revspace.nl/MHZ19 and there a quite a few examples on github to get started.
At first experimentations were a bit frustrating but after a while things started to stabilise a bit and sensor's readings from the past few month seem to make sense. The solution was to reject sub-standard readings and to average valid ones over a period of 5 minutes.
One quite annoying thing a bit this module when using breadboard or prototype PCB is that it has weird dimensions (not a multiple of 2.54mm) and won't fit nicely.
Calibration
Calibration can also be an issue, specially because of the ABC calibration every 24h. The system would be great if it spanned over let's say a week which would give you several chances to open the window but as it is (i.e. using the minimum value of previous day as base), reading were becoming strange day after day. It turns out that it works a lot better without ABC and a manual calibration from time to time.
Then manual calibration can be triggered by software or using the hardware pin. To avoid trying to fit a switch on the enclosure, the solution retained was to use a reed switch inside and to press a neodymium magnet on the cover once the air of the room has been well recycled.
Wemos D1 mini
Although I initially planned to use nodemcu modules, I decided to try Wemos D1 mini which are smaller, cheaper and able to cope with higher speed communication via USB so firmware upload is twice as fast.
Besides this, there really behave like any other ESP8266 solution. Wemos offers a good selection of shields (power, relay, LED, sensor, ...) which I haven't tried as well as modules based on the more powerful ESP32.
It is probably best to use their official online shop as there seems to be quite a lot of fake modules around, and not necessarily cheaper.
I2C Oled
Having used a 0.96" Oled screen for the time bomb, I really thought that using a 0.91" 128x32 I2C SSD1306 screen would be trivial. As it turns out, library for the former is not compatible with the latter because they lack of a proper framebuffer. After digging around, I found that the Adafruit library was working (one parameter is of a different value) even if the hardware looks quite different (more pins).
To be perfectly honest, if I was to make another sensor, I would give up the screen and use coloured Led shinning through (the plastic is slightly translucent) as the physical fitting was probably the most challenging part of this project (even if simple by DIY standard).
A sprinkle of MQTT
Communication with base is, of course, via MQTT, nothing new or complicated here. There is a sampling every minute for the CO2. The average value as well as the current values of temperature and relative humidity are sent every 5 minutes.
Wifi off (really?)
Since this new sensor is installed in our bedroom, I wanted to switch the Wifi on only when needed MQTT communication to send the values. I basically used the dedicated function for this. Is is really switching off "radiations"? Who knows... as I discovered with the electricity meter project, electric consumption is not lowered by it.
Powering the sensor
I knew from the start that using battery would be a challenge and I didn't even bother. Between the screen, MH-Z19 and the Wifi, it is probably around 200mA anyway. The USB port of the Wemos D1 mini is plugged directly on a small power adapter. The usb cable can also be used to upgrade the firmware as no OTA was implemented on this project.
All in a "sensor box"
Like almost everything else, directly from China, I found an enclosure designed for sensors (or thermostat?) which was the right size to fit everything. The USB power adapter is external, the ESP8266 at the top and the thermometer at the bottom, by the vents in order to stay as accurate as possible. Despite this, the temperature appears 1.5°C higher than without cover. The offset can be corrected in software.
Code
As usual the code and schematics are available (AS IS) on github.
It includes a SHT library and MH-Z19 library.
Back after a hiatus of a few months. The main reason can easily be guessed from the previous post! :-)
This time I will be talking about so-called "Smart meters" since both my antiquated electricity meter and gas meter were recently replaced.
Linky
Linky is the name for the French electricity smart meter. They are manufactured by different companies but all have exactly the same flashy green colour!
Linky is highly controversial but not for the right reasons IMHO. Opponents seem to concentrate on false and bizarre statements about radiations when they don't assert the meter embarks a camera!
Long term loss of job (meter reading people) and above all the risk of privacy breach (it is technically possible to know how much electricity is used in real time hence to know what are people's daily routine and/or if they are on holiday, etc...) could have been causes worth a battle. But honestly opponents only managed to discredit themselves and look like a bunch of lunatics!
Let's not forget that the original reason behind the arrival of smart meters is (by extension with smart grids) to be able to better handle the production of electricity by "green" means (wind, solar, ...) which are highly unpredictable and require to collect real time usage to try to balance production and consumption.
The fact you can now be charged with real amount rather than estimates and you don't have to be home any more to open the door is a real bonus too. Note that in France, contrary to some countries like the UK, you don't have a "smart energy monitor" in standard. This kind of display with the current consumption in currency seems to be given only to the poorest families. AFAIK there isn't any similar solution sold yet.
There is a slot for the emitter module ("ERL") and "Teleinfo" is available! Hurrah!
So my first task was to create a MQTT/Wifi module to transmit the real time data. I'll give all the information about it soon.
The smart gas meter is called Gazpar and is controversial too (obviously!). The transmission of information is slightly different. First it is only one-way and for reading: Nothing can be done remotely. Reading are transmitted by FM then mobile network twice a day.
It is like a old "dumb" meter clad in an bright orange cuirass.
For me the main issue is the loss of the magnetic pulse reading. I actually suspect that is is used internally by the Gazpar electronics but it is no longer available for personal use.
There is a "socket" but I can't find much information about how to use it (dry contact? Not so sure specially that the battery should last 20 years and in theory the fact that something is plugged in is sent to gas provider) and I am rather shy to try anything. If someone has any information about it... Please contact me.
Le compteur gazpar est équipé d'une prise. Cependant quasiment aucune information à ce sujet n'est disponible. Cela pourrait être un contact sec mais j'ai du mal à croire qu'il s'agisse d'un relais (avec une pile qui doit durer 20 ans et du fait que l'utilisation/occupation de la prise semble faire partie des informations remontées). Je suis preneur de toute information à ce sujet... Merci d'avance.
EDIT (16/12/2018):
The cable is for sale on (at least) two online shops. By the time you add VAT and postage, it's almost 20€ or 24€ (horrendous for what it is) but let's hope the price will go down with time.
Regarding how it is connected internally, I still haven't been able to find any documents but my best guess is that there are 2 reed switches bundled together, one used for the internal counter, the other one directly connected to the socket.
One of the humidity sensor currently in use, on the Home Automation Project, is the ubiquitous DHT22 also known as AM2302 which came with the AirPi board I installed.
I don't particularly like it as it has a very specific protocol which need a special C-compiled software to communicate. Second problem, it sometimes crashes. And lastly, I am starting to have serious doubts about its accuracy (specially on the humidity side).
I discovered an alternative known as SHT21 or HTU21D (depending on the manufacturer) which seems quite appealing as this one use the perfectly standard I²C protocol.
That said, the chip is so tiny, the only way to use it is mounted on a breakout board (like the GY-21): For around 4€, you get the sensor, the power regulator as well as a level shifter. Which means that it can safely be used with 3.3V or 5V.
More information and datasheets
Datasheets and examples in C can be found on the manufacturers' websites:
Basically, it works by sending a Read (humidity or temperature) command, wait (hold mode) or poll (no hold mode) for the answer and apply a mathematical formula to get the actual value.
There is a precision setting but the only effect is to reduce the measurement time and since on the default/highest setting it takes less than 50 ms, there is little need to change it.
Using it with Arduino
As I wanted to experiment with the ESP8266, I (temporarily) diverted the chip from its initial goal (i.e. replacing the DHT22) and decided to use it on the Arduino plateform. There are librairies available from Adafruit or Sparkfun but I created my own version to include soft reset as well as serial number reading.
I'll publish it as an example at some point in the future.
Later, using this chip on the Rasberry Pi with python should be trivial.
First impressions
So far, the only small drawback I found with this kind of chip is the fixed I²C address (0x40) which mean there can only be one sensor per bus. But in practice, there is little need for more than one anyway.
The Digispark is a Atmel Attiny85 based microcontroller development board similar to the Arduino line but cheaper and smaller. They had an extremely successful Kickstarter campaign 2 years ago and clones are available on ebay a few euros.
They seem to now have their own ecosystem and can emulate a USB device. The USB is also used to programme the microcontroller, the same way it is done on Arduino.
Wiki pages quickref and basics have some information about pins, differences from the Arduino and limitations.
Here I need only two pins for the project : 1 for the RF receiver and the other one for the serial connection to to Raspberry Pi.
I decided to go serial instead of I²C mainly because of the asynchronous nature of the signal and to avoid polling from the I²C master (Raspberry Pi in my case). Here the digispark will simply send its data as soon as it decodes something from the RF receiver.
So PIN 0 will be the RF receiver IN while PIN 2 (default for Serial Debug) will be used for the Serial Communication. 38400 bit/s seems to be the recommended value. Fair enough.
In order to allow serial communication, the serial port has to be freed from any usage as a console. Once it is done (and the Raspberry rebooted), minicom can be used to check if everything is alright.
minicom -b 38400 -o -D /dev/ttyAMA0
Note that the port is /dev/ttyAMA0 while the one for the Z-Wave static controller is /dev/ttyACM0.
Storing values
Same as the values from the airpi sensors, these ones can be stored in RRD databases:
