SHT21/HTU21D Humidity and Temperature Sensor

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

GY-21

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.

    Lacrosse TX2/TX3 Sensors and Digispark

    Digispark

    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.

    Digispark

    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.

    For reference, here is the schematic of digispark.

    Pins

    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.

    Code is available on github :https://github.com/guillier/la_crosse_sensors

    Raspberry Pi

    Serial communication

    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:

    rrdtool create temperature_device33.rrd --step 300 \
    DS:temperature:GAUGE:600:0:U \
    RRA:AVERAGE:0.9:1:24 \
    RRA:AVERAGE:0.9:6:35064 \
    RRA:MIN:0.9:288:1826 \
    RRA:AVERAGE:0.9:288:1826 \
    RRA:MAX:0.9:288:1826
    

    Lacrosse TX2/TX3 Sensors

    La Crosse WS7014

    I have owned a La Crosse Weather Station WS7014 for quite a long time (I would say it is around 15 years old or so) and if one of the sensor (TX2) can't be used outdoor because it is no longer waterproof, the base station is still going strong. The newer (but at least 7 years old) sensor is a TX3-P.

    WS7014 + TX2 + TX3-P

    Receiver

    XY-MK-5V + FS1000A

    Found on ebay a 433Mhz RF transmitter and receiver kit for 1 € (inc. pp)! It turned out to be a FS1000A + XY-MK-5V.

    I'm not too much bothered about the transmitter but if the receiver can do the trick (at this price), why not?

    Note that some projects seem to rely heavily on Aurel's modules which are in the 30€ range.

    Decoding

    All these sensors communicate the 433Mhz band and it would be nice to be able to intercept the signal. Fortunately some people have already decoded it.

    Based on this page http://www.f6fbb.org/domo/sensors/tx3_th.php and this one http://www.f6fbb.org/domo/sensors/tx_signals.php for starters and on this arduino forum as well the decoding should have been easy.

    But after several hours, nothing was showing up on the arduino serial console.

    Using the code posted on one of the messages it turned out that all the timings were off by 25-30%. Ajusting the ranges helped and some values from the nearest sensor appeared within minutes.

    If the code in the PDF document (for Funksensor TFA 30.3120.90) is handly, I really think that Mr ROUBELAT is right when he considers a short pulse as bit 1 and a long one as bit 0 and not the other way around.

    Another observation is that as far as I can tell the parity bit is always correct from the TX3 but not so from the TX2. So I decided not to rely on it but on the CRC and on the redundancy instead.

    At night

    During the day I can't receive anything from the outdoor sensor but in the evening, it appears as well. Maybe the dead cheap receiver it not completely up to task to cope with the distance and several concrete walls.

    Replacing the Arduino

    Due to the asynchronous nature of the transmission and on the timings (a few hundred µS), using the Raspberry Pi directly won't do. Using a full size Arduino for this is certainly a waste. Maybe a ATtiny would do but I have no experience in programming them so I went for something in the middle: A digispark.

    To be continued...

    Page 1 / 1