Search facility

Friday 18 November 2022 00:00 | General

A search facility page has been added to the blog.

The link is available from all the pages (side panel on the left) and uses the fantastic Pagefind library. If you run a static site, I really invite you to check it out!

    Fridge Sensor

    The rain gauge receiver's code, described last time was running happily on a ESP8266 + antenna RXB6 when the next challenge came up:

    While shopping for a Zigbee receiver (more about it another time), I spotted a fridge sensor Telldus (312716) looking exactly like my F007TH sensors but with a cable and measuring temperature only.

    Telldus thermometer for indoor/outdoor

    Protocol?

    Honestly, the information gathered on different sources about these was totally unclear but I decided to buy one for my chest freezer.

    And... obviously, the casing is identical BUT the protocol (F007TP here) is absolutely not compatible with the F007TH. To be clear: they have nothing in common!

    Yet, this new sensor was recognised by my RTL-SDR adapter running rtl_433 (but with the wrong temperature -- according to the source code there may be a conflit bitween WH2 & WH5 which are part of the same family).

    Decoding

    It appears that the protocol was described more than 10 years ago by Luc Small on his blog, so at least the heavy lifting was done. I only had to use the decoding and CRC calculation in my own code.

    Hosting

    As I didn't want to requisition a specific ESP8266 just for one sensor and because it was in the same area as the rain gauge, I decided to merge the decoding functions even if there is very little in common between these 2 applications.

    It is unfortunate that the WH2/F007TP protocol doesn't have an easy synchronisation preamble but at least the rain gauge do, so the main loop now checks if there are a number of ~500ns pulses followed by one ~1500ns or if it detects one ~7500ns pulse.

    If it's the latter, then it records 64 pulses then calls the rain gauge decoder. If it's the former, then it records 40 pulses then calls the F007TP decoder.

    Overall, the routing mechanism is similar to the solution used for 433Mhz remote sockets.

    Code

    The code is available online (Plateform.IO format this time).

    Ecosystem as a diagram

    This now brings the ecosystem to:

    Ecosystem

    Rain Gauge

    Having bought a Wireless Rain Gauge from Pearl Diffusion, and since they looked alike, I was hoping that even if the model number was different, its protocol would be similar to the TFA DROP 47.3005 which is implemented/documented by rtl_433.

    It turns out that they are similarities (they might come from the same factory) and also quite a few differences.

    • For reference, here is the inFactory FWS-275 (aka NX-6331-675):

    FWS-275

    • And here the TFA 47.3005 (aka TFA 30.3233.01):

    TFA 47.3005

    Looking for the data

    Signal

    I decoded several protocols in the past, mainly using dumps of timing on Arduino serial port. Here, the author of the TFA device's code (helped by one of the maintainers of rtl_433) gives a few clues in how to proceed rapidly in the issue associated.

    rtl_433 -A
    

    manages to collect the format of the signal and a way to display some formated information:

    rtl_433 -X 'n=rain,m=OOK_PWM,s=996,l=2700,r=2684,g=0,t=0,y=7352'
    

    The signal seems to be composed of 2700µS and 970µS pulses with 7340µS synchronisation pulses. One suprising thing is that it doesn't seem to be regular (for example long HIGH + short LOW or the opposite). It is a mix of long HIGH + short/long LOW or short HIGH + short/long LOW). But it we take into account only the HIGH side, it doesn't matter much.

    Data

    When decoded (PWM slicer), the first chunk is always different (values divided by 2), probably due to a shifted bit. The second and the third are almost identical, except the last byte. Best is to ignore it and see.

    bitbench is another handy tool to carry on with the decoding.

    Protocol

    One (obvious) difference between the two gauges mentionned above is that the one I own also a outdoors temperature display, so the protocol has to transmit the value.

    The 2 first bytes never change except after a change of batteries on the outdoor unit, so it is certainly a random ID.

    The third byte follows the pattern 00, 02, 04, 06, 08, 0a, 0c, 0e already found in the TFA unit. Like on the TFA, bit 7 is the battery indicator (tested using a variable power supply to lower the voltage) and bit 6 a reset indicator.

    The fourth and fifth bytes seem to be the counter of the bucket tips, using the same weird initial value (-10). More about it later

    The sixth and seventh values are the temperature. Since, they didn't really match the Celcius display, I switched the display to Farenheit and in this case a change of value is also a change of display. This mean the transmission is in Farenheit (like in the F007TH protocol) but the encoding is diffent. After toying a bit, it appeared that the format is 16 bits Little Endian and that the value is in tenth of degrees Farenheit with an offset of 900.

    Last but not least, the checksum... I was expecting something like on the TFA unit (it took me a while to understand zuckschwerdt's answers to be honnest) but after trying the referenced tools it turns out that the checksum is just that... a sum of the first 7 bytes!

    All was fine... except that the main reason of this apparatus is to mesure the amount of rain, and there was not an obvious link between the counter values and the display!

    Knowing that the base is 25.4mm (top of the tube on the display), it is almost certain that the mesurement is with imperial units too.

    After tiping the bucket (by hand) a few hundred times, it seems that the value is 1 tip = 0.0425 in of rain. Converted in metric, this gives 1 tip = 0.108 mm.

    How on earth did they managed to select this kind of value??? Well never mind...

    Thermometers

    What and why

    In order to complete and replace the old TX2/TX3 sensors, I found some new ones using a similar technology (still RF 433 Mhz). These are the TFA ref 30.3208.02 and can be bought with a very handy external housing (ref 98.1114.02):

    TFA thermometer and housing

    They also come in sets of 3 sensors + a "climate monitor".

    TFA thermometer and housing

    (Edit 27/07/2022: PEARL Diffusion's rebranded NX-6185-675 sensors (sold for Infactory FWS-1000 station) are fully compatible too).

    Technical info

    The sensors themselves measure and display the temperature as well as the relative humidity. Up to 8 sensors can be used at the same time and their address is set (thus fixed) using microswitches, which is a huge improvement over the previous models (either IDs changing at reboot or limited to 3).

    The communication protocol seems to be known as F007TH (from Ambient Weather) and presents 2 singular characteristics:

    • The temperature is transmitted in Fahrenheit
    • It uses a Manchester Encoding

    The protocol has been described at length in Weather-Sensor-RF-Protocols.pdf or in Weathermon / F007TH protocol for example.

    Various implementations exists and can be found on the Internet; last but not least my version, adaption of one of the different sources and for which I use on a ESP8266 as a gateway to the MQTT broker.

    My current ecosystem as a diagram

    So far the described ecosystem can be represented as:

    Ecosystem

    Other pieces of the puzzle to follow…

    Page 1 / 31 »