Weather-Station-WH31E Parser

[ghost]

Just circled back to this parser we wrote last year using rtf_433, forgot to send along info. Might be interesting to see how we decoded it, still needed horrible hacks to the lovely rtf_433 bitbuffer.c Posting here incase folks have the same - it should really be pulled into the main code as this thing is hacky as anything, but we needed something fast to stand up for our tenants while they were away.

https://github.com/jamesdotcuff/Weather-Station-WH31E

The parser does bit shifts on the raw binary data once you allow all data to be dumped:

https://github.com/jamesdotcuff/Weather-Station-WH31E/blob/master/src/parse_WH31E.py

Hope this helps.

[merbanan]

We need sample signals to be able to implement support for it. Instructions on how to do that are on the rtl_433 page.

[zuckschwerdt]

Very interesting read and exciting unique approach with the sequence analysis. I'll have a look through the code and see if this fits with the existing Ambient Weather device (or maybe Fine Offset, they use WHxx model names).

[ghost]

Sorry for missing the cu8 files. Added results of rtl_433 -f 915000000 -a -t

https://github.com/jamesdotcuff/Weather-Station-WH31E/tree/master/cu8_data

Parsed strings look like this below. Channel, temp, humidity. Basically all it does is parse the bitbuffer generated by rtl_433. Again, sorry we did this so messily.

bitbuffer:: Number of rows: 1 [00] {1031} ff ff ff c0 00 00 00 05 55 55 55 55 55 51 6e a1 82 24 90 d1 ca d5 98 3a 28 22 f8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3f ff ff ff f0 00 00 00 00 aa aa aa aa aa aa 2d d4 30 44 92 1a 39 5a b3 07 45 04 5f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 BITS : 11111111 11111111 11111111 11000000 00000000 00000000 00000000 00000101 01010101 01010101 01010101 01010101 01010101 01010001 01101110 10100001 10000010 00100100 10010000 11010001 11001010 11010101 10011000 00111010 00101000 00100010 11111000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00111111 11111111 11111111 11111111 11110000 00000000 00000000 00000000 00000000 10101010 10101010 10101010 10101010 10101010 10101010 00101101 11010100 00110000 01000100 10010010 00011010 00111001 01011010 10110011 00000111 01000101 00000100 01011111 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000001

Into this:

[jcair:~/Weather-Station-WH31E/cu8_data] jcuff% rtl_433 -f 915000000 -A | & python ../src/parse_WH31E.py

2018-10-23 15:13:57.062114 4 57.4 57

{"humiditybin": "00111001", "tempstr": "541", "temperature": 57.4, "tempbin": "001000011101", "nib": "1011", "timestamp": "2018-10-23 15:13:57.062114", "id": "00101011", "pos": 62, "channel": "4", "humidity": "57"}

[zuckschwerdt]

No worries, it's good prototyping work. With the recent addition of the flex device it should be easier to do things like this without too much hacking.

rtl_433 -q -F json -R 0 -X 'Weather-Station-WH31E:FSK_PCM:56:56:1800:2500' -r g001_915M_250k.cu8

will give the raw data. (PCM 56µs bit length with a preamble of 1336 µs pulse, 1996 µs gap, 48 bit flips (0xaaaaaaaaaaaa):

{57}7fffff800000000
{183}aaaaaaaaaaaa2dd430c3820a5edfbc0756a7ae00000000

The Sigrok Pulseview shows this better:

Matching the preamble will align and strip the preamble (and sync word here)

rtl_433 -q -F json -R 0 -X 'Weather-Station-WH31E:FSK_PCM:56:56:1800:2500,preamble=0xaa2dd4' -r g001_915M_250k.cu8

results

{119}30c3820a5edfbc0756a7ae00000000

[zuckschwerdt]

Btw. the leading long pulse and gap (rather mark and space with FSK) are a warm up, the 0xaa… pattern is a preamble (a training pattern to sync the clock) and 0x2dd4 is a very common sync-word.

[merbanan]

@zuckschwerdt how about to hook that up to the analyzer ?

[zuckschwerdt]

Yes, I need to get around to do that someday. The analyzer should suggest a -X spec.

[ghost]

Rock on team! Glad it helped, y’all are super gurus. One less janky python script for the win. I’ll link my little GitHub page back here to thread as an example of how folks should really be doing it.

[zuckschwerdt]

I copied the sample data to https://github.com/merbanan/rtl_433_tests/tree/master/tests/ambient_weather/04 And I'll add the device code in the next few days.

[ghost]

Christian, you are a true and dedicated scholar - thank you so much, this is such a fun project. Can't wait to test on the core after you work your magic on the device code. Hope everyone gets to learn from you and Benjamin on how to run a high quality and yet inordinately complicated public project. Thanks again team for putting up with our half finished idea - looking forward to monitoring the house this year without our random bits of python. Let me know if you need anything else, but it looks like y'all got this.

[zuckschwerdt]

Here is a branch for testing this: https://github.com/zuckschwerdt/rtl_433/tree/feat-wh31e I.e. this file https://github.com/zuckschwerdt/rtl_433/blob/feat-wh31e/src/devices/ambientweather_wh31e.c I had only two samples to test with but there seems to be a CRC in the last byte (Interestingly reflected, i.e. LSB first). That is 10 data bytes. Accounting for msg code, channel, temp, and hum this leaves 5 bytes uninterpreted. The output show those as extra, perhaps take a look if something correlates. Also the battery flag might be flipped (or completly wrong).

[zuckschwerdt]

If you have a variable voltage power supply, a threshold voltage for battery low would be great. Otherwise use an mostly run-down pair of batteries to check for the battery low flag. Also could you post some output lines with corresponding read-out from the head-unit? Does the channel output match x+1, i.e. 0-7 in the output is setting 1-8? Some of the extra data (2 bytes?) is perhaps a pressure reading.

[ghost]

Absolutely amazing work! We are so close, but I must have snagged some cu8 data from something that wasn't us that was also on 915 in the neighborhood, we spotted this before with electric meters, the range is nuts on those things. Anyway, I double checked my work and your parser works perfectly with the files I had uploaded, but they must clearly be the wrong ones, someone must have another weather station nearby is my only guess! Doh!

I've gone ahead and uploaded new cu8 files that definitely parse - I used the -r to test them and knocked up a script "run.sh" you can find here:

https://github.com/jamesdotcuff/Weather-Station-WH31E/tree/master/cu8_data/newdata

I left the old cu8 files in the old directory, the "newdata" are the ones we want.

Also as requested uploaded an image with the actual readouts that also correspond to the parsed channels and gave you lots more data.

https://github.com/jamesdotcuff/Weather-Station-WH31E/blob/master/images/IMG_1151.jpg

Maps to:

https://github.com/jamesdotcuff/Weather-Station-WH31E/blob/master/cu8_data/newdata/out.log

Still not sure what on earth happened with those first set of cu8 files, I should have double checked them. Hope this is more to go on, we are inches away.

[zuckschwerdt]

The two usable samples in the first batch match this new captures. Only the CRC was a fluke.

2dd4 30 c3 8 20a 5e dfbc 0756 a7ae <- old
2dd4 30 44 9 21a 39 5ab3 0745 045f <- old
2dd4 30 c3 8 1d5 5c 2acf 0835 442c
2dd4 30 35 c 22f 3c 0fa1 0752 299f
2dd4 30 35 c 22e 3c fb8c 0752 299f
2dd4 30 c9 a 21e 40 0c05 0734 c6b1
2dd4 30 2b b 214 3d 94f2 0853 78e6
2dd4 30 c9 a 21f 40 f8f2 0734 c6b1
2dd4 30 44 9 213 3e 0e65 0745 045f
2dd4 30 44 9 215 3d 075f 0745 045f
2dd4 30 c3 8 1d6 5b 9035 0835 442c

result in

g002_915M_250k.cu8 {"temperature_C": "6.9", "flag": "1", "id": "195", "channel": "1", "humidity": "92"}
g003_915M_250k.cu8 {"temperature_C": "15.9", "flag": "1", "id": "53", "channel": "5", "humidity": "60"}
g005_915M_250k.cu8 {"temperature_C": "15.8", "flag": "1", "id": "53", "channel": "5", "humidity": "60"}
g006_915M_250k.cu8 {"temperature_C": "14.2", "flag": "1", "id": "201", "channel": "3", "humidity": "64"}
g008_915M_250k.cu8 {"temperature_C": "13.2", "flag": "1", "id": "43", "channel": "4", "humidity": "61"}
g009_915M_250k.cu8 {"temperature_C": "14.3", "flag": "1", "id": "201", "channel": "3", "humidity": "64"}
g039_915M_250k.cu8 {"temperature_C": "13.1", "flag": "1", "id": "68", "channel": "2", "humidity": "62"}
g049_915M_250k.cu8 {"temperature_C": "13.3", "flag": "1", "id": "68", "channel": "2", "humidity": "61"}
g051_915M_250k.cu8 {"temperature_C": "7.0", "flag": "1", "id": "195", "channel": "1", "humidity": "91"}
g053_915M_250k.cu8 {"temperature_C": "13.2", "flag": "1", "id": "43", "channel": "4", "humidity": "61"}

like in your out file.

From the unknown last 6 bytes the first is actually a CRC for the preceeding bytes. Of the remaining 5 the second and third look like a sensible number, but I don't know what. The other three vary too much.

I update the code for the new CRC. You need to reset the branch before a pull or best download the whole thing again.

[ghost]

Nailed it! Channel number is off by one, (0 order vs starting at 1) but that's all!!

Channel 1 is outside, and it is raining and cold, perfect.

Live data right off the detector:

Registering protocol [111] "Ambient Weather WH31E Thermo-Hygrometer Sensor" Registered 111 out of 111 device decoding protocols Found 1 device(s)

trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001 Found Rafael Micro R820T tuner Using device 0: Generic RTL2832U OEM Exact sample rate is: 250000.000414 Hz [R82XX] PLL not locked! Sample rate set to 250000. Bit detection level set to 0 (Auto). Tuner gain set to Auto. Reading samples in async mode... Tuned to 915.000MHz.

2018-10-24 13:40:53 : AmbientWeather-WH31E : 195 Channel: 0 Msg Type: 48 Battery: LOW Temperature: 6.9 C Humidity: 97 % Extra Data: 4d0835442c Integrity: CRC 2018-10-24 13:40:53 : AmbientWeather-WH31E : 195 Channel: 0 Msg Type: 48 Battery: LOW Temperature: 6.9 C Humidity: 97 % Extra Data: 4d0835442c Integrity: CRC 2018-10-24 13:41:33 : AmbientWeather-WH31E : 43 Channel: 3 Msg Type: 48 Battery: LOW Temperature: 16.6 C Humidity: 56 % Extra Data: df085378e6 Integrity: CRC 2018-10-24 13:41:33 : AmbientWeather-WH31E : 43 Channel: 3 Msg Type: 48 Battery: LOW Temperature: 16.6 C Humidity: 56 % Extra Data: df085378e6 Integrity: CRC 2018-10-24 13:41:38 : AmbientWeather-WH31E : 68 Channel: 1 Msg Type: 48 Battery: LOW Temperature: 13.1 C Humidity: 60 % Extra Data: c10745045f Integrity: CRC 2018-10-24 13:41:38 : AmbientWeather-WH31E : 68 Channel: 1 Msg Type: 48 Battery: LOW Temperature: 13.1 C Humidity: 60 % Extra Data: c10745045f Integrity: CRC 2018-10-24 13:41:39 : AmbientWeather-WH31E : 201 Channel: 2 Msg Type: 48 Battery: LOW Temperature: 13.8 C Humidity: 64 % Extra Data: 840734c6b1 Integrity: CRC 2018-10-24 13:41:39 : AmbientWeather-WH31E : 201 Channel: 2 Msg Type: 48 Battery: LOW Temperature: 13.8 C Humidity: 64 % Extra Data: 840734c6b1 Integrity: CRC 2018-10-24 13:41:43 : AmbientWeather-WH31E : 53 Channel: 4 Msg Type: 48 Battery: LOW Temperature: 16.4 C Humidity: 61 % Extra Data: e20752299f Integrity: CRC 2018-10-24 13:41:43 : AmbientWeather-WH31E : 53 Channel: 4 Msg Type: 48 Battery: LOW Temperature: 16.4 C Humidity: 61 % Extra Data: e20752299f Integrity: CRC

[zuckschwerdt]

@jamesdotcuff your idea with the genome sequence analysis resparked an idea I had sometime ago: I always wanted a simple editor where I dump hex codes and then align and dissect them interactively. There is now a quick example I hacked, it sure needs polish but is working

http://triq.net/bitbench

It comes preloaded with your example data :)

(also with your output above -F json is much prefered, the default KW output is just too verbose. And you might want -C customary to get Fahrenheit)

[ghost]

Love the bitbench idea, that is fabulous. Almost heading towards a "decode bench" for protocol analysis.

My current project is to simplify rtl_433, and these other two decoders:

https://github.com/andresol/Efergy-E2-linux https://github.com/bemasher/rtlamr

Into a unified scanner so that there aren't like 5 languages from GoLang, python, C and bash all trying to bounce around the frequency spectrum in the house to get energy and consumption data from electric, gas meter and water meters and temperature gauges. Yesterday's hilarity was rediscovering that we used to have a different voltage in the UK. Hehe!

https://twitter.com/jamesdotcuff/status/1055167981255319552

Probably going with one of those new fangled databases to then do some integrated graphing. Every project is a real labor of love based on single use cases, this community is amazing to me but kinda needs the one scanner and protocol unpacker that can rule them all while being able to bounce around 433MHz and 915's etc... Things like https://www.home-assistant.io help, but are more oauth/web token based on existing "cloud" systems plus I'm too cheap to do all that fancy IoT lightbulb stuff. :-)

Thanks again for all your help getting another tricky decoder into the tool chain, I've learned a lot from you as to how the decoders now work inside your framework, very cool stuff!

[zuckschwerdt]

The Efergy E2 should already be supported. If not just supply some samples and we'll update the device driver. https://github.com/merbanan/rtl_433/blob/master/src/devices/efergy_e2_classic.c

Adding the ERT support would be nice. I guess some of the existing protocols can be reused, but I haven't looked into it and how it compares to e.g. mBus.

I hope rtl_433 can be universal enough to provide the Ash nazg durbatulûk bridge from radio to backends like MQTT (home assistant) and TSDBs like InfluxDB or Graphite. I use an MQTT and Graphite bridge script to feed rtl_433's data to e.g. HA and Influx. http://triq.net/articles/rtl-433-networking

[ghost]

Oh look at that! Efergy E2 works just perfectly. Rats, never even thought to look.

jcair-6:Efergy-E2-linux jcuff$ ~/rtl_433/build/src/rtl_433 -f 433550000 -G -F json 2> /dev/null
{"time" : "2018-10-25 14:10:45", "model" : "Efergy e2 CT", "id" : 8655, "current" : 2.620, "interval" : 6, "battery" : "OK", "learn" : "NO", "mic" : "CHECKSUM"}
{"time" : "2018-10-25 14:10:56", "model" : "Efergy e2 CT", "id" : 8655, "current" : 2.630, "interval" : 6, "battery" : "OK", "learn" : "NO", "mic" : "CHECKSUM"}

My next challenge is to look at ERT. This is fab.

[ghost]

Ok, so this is simply awesome, the channel hopping is perfect, add both freqs and a -H and off to the races. Y'all are one step ahead of me. 60 seconds of each is enough to capture all the data with one device. Once I hook this up to your MQTT/Graphite bridge idea, I'm basically done.

Ash nazg durbatulûk status achieved :-)

jcair:src jcuff$ ./rtl_433 -f 433550000 -f 915000000 -H 60 -G -F json 2> /dev/null

{"time" : "2018-10-25 14:24:26", "model" : "Efergy e2 CT", "id" : 8655, "current" : 2.380, "interval" : 6, "battery" : "OK", "learn" : "NO", "mic" : "CHECKSUM"}
{"time" : "2018-10-25 14:24:36", "model" : "Efergy e2 CT", "id" : 8655, "current" : 2.360, "interval" : 6, "battery" : "OK", "learn" : "NO", "mic" : "CHECKSUM"}
{"time" : "2018-10-25 14:24:46", "model" : "Efergy e2 CT", "id" : 8655, "current" : 2.290, "interval" : 6, "battery" : "OK", "learn" : "NO", "mic" : "CHECKSUM"}
{"time" : "2018-10-25 14:24:56", "model" : "Efergy e2 CT", "id" : 8655, "current" : 2.280, "interval" : 6, "battery" : "OK", "learn" : "NO", "mic" : "CHECKSUM"}
{"time" : "2018-10-25 14:25:05", "model" : "Efergy e2 CT", "id" : 8655, "current" : 2.290, "interval" : 6, "battery" : "OK", "learn" : "NO", "mic" : "CHECKSUM"}
{"time" : "2018-10-25 14:25:15", "model" : "Efergy e2 CT", "id" : 8655, "current" : 2.300, "interval" : 6, "battery" : "OK", "learn" : "NO", "mic" : "CHECKSUM"}
{"time" : "2018-10-25 14:25:19", "model" : "AmbientWeather-WH31E", "id" : 201, "channel" : 2, "msg" : 48, "battery" : "LOW", "temperature_C" : 14.500, "humidity" : 65, "data" : "130734c6b1", "mic" : "CRC"}
{"time" : "2018-10-25 14:25:19", "model" : "AmbientWeather-WH31E", "id" : 201, "channel" : 2, "msg" : 48, "battery" : "LOW", "temperature_C" : 14.500, "humidity" : 65, "data" : "130734c6b1", "mic" : "CRC"}
{"time" : "2018-10-25 14:25:31", "model" : "AmbientWeather-WH31E", "id" : 68, "channel" : 1, "msg" : 48, "battery" : "LOW", "temperature_C" : 13.900, "humidity" : 56, "data" : "f8039a5289", "mic" : "CRC"}
{"time" : "2018-10-25 14:25:31", "model" : "AmbientWeather-WH31E", "id" : 68, "channel" : 1, "msg" : 48, "battery" : "LOW", "temperature_C" : 13.900, "humidity" : 56, "data" : "f8039a5289", "mic" : "CRC"}
{"time" : "2018-10-25 14:25:53", "model" : "AmbientWeather-WH31E", "id" : 53, "channel" : 4, "msg" : 48, "battery" : "LOW", "temperature_C" : 15.800, "humidity" : 60, "data" : "8c0737fc58", "mic" : "CRC"}
{"time" : "2018-10-25 14:25:53", "model" : "AmbientWeather-WH31E", "id" : 53, "channel" : 4, "msg" : 48, "battery" : "LOW", "temperature_C" : 15.800, "humidity" : 60, "data" : "8c0737fc2c", "mic" : "CRC"}
{"time" : "2018-10-25 14:26:13", "model" : "AmbientWeather-WH31E", "id" : 43, "channel" : 3, "msg" : 48, "battery" : "LOW", "temperature_C" : 13.500, "humidity" : 58, "data" : "8c08395db8", "mic" : "CRC"}
{"time" : "2018-10-25 14:26:13", "model" : "AmbientWeather-WH31E", "id" : 43, "channel" : 3, "msg" : 48, "battery" : "LOW", "temperature_C" : 13.500, "humidity" : 58, "data" : "8c08395db8", "mic" : "CRC"}
{"time" : "2018-10-25 14:26:17", "model" : "AmbientWeather-WH31E", "id" : 195, "channel" : 0, "msg" : 48, "battery" : "LOW", "temperature_C" : 7.900, "humidity" : 60, "data" : "0e0712571c", "mic" : "CRC"}
{"time" : "2018-10-25 14:26:17", "model" : "AmbientWeather-WH31E", "id" : 195, "channel" : 0, "msg" : 48, "battery" : "LOW", "temperature_C" : 7.900, "humidity" : 60, "data" : "0e0712571c", "mic" : "CRC"}
{"time" : "2018-10-25 14:26:26", "model" : "Efergy e2 CT", "id" : 8655, "current" : 2.300, "interval" : 6, "battery" : "OK", "learn" : "NO", "mic" : "CHECKSUM"}
{"time" : "2018-10-25 14:26:36", "model" : "Efergy e2 CT", "id" : 8655, "current" : 2.290, "interval" : 6, "battery" : "OK", "learn" : "NO", "mic" : "CHECKSUM"}
{"time" : "2018-10-25 14:26:46", "model" : "Efergy e2 CT", "id" : 8655, "current" : 2.290, "interval" : 6, "battery" : "OK", "learn" : "NO", "mic" : "CHECKSUM"}
{"time" : "2018-10-25 14:26:56", "model" : "Efergy e2 CT", "id" : 8655, "current" : 2.370, "interval" : 6, "battery" : "OK", "learn" : "NO", "mic" : "CHECKSUM"}
{"time" : "2018-10-25 14:27:06", "model" : "Efergy e2 CT", "id" : 8655, "current" : 2.730, "interval" : 6, "battery" : "OK", "learn" : "NO", "mic" : "CHECKSUM"}
{"time" : "2018-10-25 14:27:16", "model" : "Efergy e2 CT", "id" : 8655, "current" : 2.670, "interval" : 6, "battery" : "OK", "learn" : "NO", "mic" : "CHECKSUM"}
{"time" : "2018-10-25 14:27:22", "model" : "AmbientWeather-WH31E", "id" : 43, "channel" : 3, "msg" : 48, "battery" : "LOW", "temperature_C" : 13.600, "humidity" : 58, "data" : "1608395db8", "mic" : "CRC"}
{"time" : "2018-10-25 14:27:22", "model" : "AmbientWeather-WH31E", "id" : 43, "channel" : 3, "msg" : 48, "battery" : "LOW", "temperature_C" : 13.600, "humidity" : 58, "data" : "1608395db8", "mic" : "CRC"}
{"time" : "2018-10-25 14:27:25", "model" : "AmbientWeather-WH31E", "id" : 201, "channel" : 2, "msg" : 48, "battery" : "LOW", "temperature_C" : 14.500, "humidity" : 65, "data" : "130734c6b1", "mic" : "CRC"}
{"time" : "2018-10-25 14:27:25", "model" : "AmbientWeather-WH31E", "id" : 201, "channel" : 2, "msg" : 48, "battery" : "LOW", "temperature_C" : 14.500, "humidity" : 65, "data" : "130734c6b1", "mic" : "CRC"}
{"time" : "2018-10-25 14:27:35", "model" : "AmbientWeather-WH31E", "id" : 68, "channel" : 1, "msg" : 48, "battery" : "LOW", "temperature_C" : 13.900, "humidity" : 56, "data" : "f8039a5289", "mic" : "CRC"}
{"time" : "2018-10-25 14:27:35", "model" : "AmbientWeather-WH31E", "id" : 68, "channel" : 1, "msg" : 48, "battery" : "LOW", "temperature_C" : 13.900, "humidity" : 56, "data" : "f8039a5289", "mic" : "CRC"}

[merbanan]

@zuckschwerdt my MQTT code is almost ready for testing.

[ghost]

That's fabulous - will be using that for sure. In the meantime the ERT doesn't look to bad. I'm not posting examples as I can collect most of the meters in my area eek, and they have they all have meter IDs encoded inside of them, which isn't a good thing to put on the internet.

I've already got rtl_433 to pick up the 96 byte OOK's that hang out on 912600155 Hz though.

https://en.wikipedia.org/wiki/Encoder_receiver_transmitter

Matches exactly with:

https://github.com/bemasher/rtlamr/blob/master/scm/scm.go

cfg: protocol.PacketConfig{
            Protocol:        "scm",
            CenterFreq:      912600155,
            DataRate:        32768,
            ChipLength:      chipLength,
            PreambleSymbols: 21,
            PacketSymbols:   96,
            Preamble:        "111110010101001100000",
        },

func NewSCM(data protocol.Data) (scm SCM) {
    ertid, _ := strconv.ParseUint(data.Bits[21:23]+data.Bits[56:80], 2, 26)
    erttype, _ := strconv.ParseUint(data.Bits[26:30], 2, 4)
    tamperphy, _ := strconv.ParseUint(data.Bits[24:26], 2, 2)
    tamperenc, _ := strconv.ParseUint(data.Bits[30:32], 2, 2)
    consumption, _ := strconv.ParseUint(data.Bits[32:56], 2, 24)
    checksum, _ := strconv.ParseUint(data.Bits[80:96], 2, 16)

So I should be able to use your template from this weather code and with some good luck and a following wind to unpick it and present you with a new device driver (I think, although my C is rusty as all hell, way too many years in management).

[zuckschwerdt]

@merbanan there is working MQTT code in the feat-mqtt branch ;) But I guess you ment the value mapping then.

[merbanan]

@zuckschwerdt I pushed a smdl branch, it is quite messy still but this I'd like to go forward with a native MQTT protocol implementation.

[zuckschwerdt]

@merbanan Ok, now I get it. Yes, feat-mqtt is based on PAHO.

[zuckschwerdt]

@jamesdotcuff I have a suspicion about the extra data. If you sort by channel or device id the last 32 bit are constant for each device (at least in the few samples I have). BitBench showing this I guess the value after the CRC is a counter and then a 32 bit device UUID? Can you look through your long list of samples and confirm that?

[zuckschwerdt]

@jamesdotcuff could you verify that there is a device-unique ID in the extra data and maybe a counter? Otherwise mail me a list of output (50-100 lines) if possible and I'll dig through that ;)

[ghost]

Hi @zuckschwerdt so very sorry for the delay - we've been out of the country for a week, and then distracted. I've uploaded a file for you:

https://github.com/jamesdotcuff/Weather-Station-WH31E/tree/master/dat

This is from your code now running mostly full time. Michele is writing a viewer to merge all the gas, electric and temperature generated from your lovely Ambient code.

https://github.com/jamesdotcuff/Weather-Station-WH31E/tree/master/monitor

I pulled this this epic and dodgy shell script because I couldn't get the SCM stuff to fly inside the main code base, please look away, it's ugly as all hell, but does get realtime data from 5 temperature, gas meter, electric meter and the Efergy code from rtl433 you put me onto earlier.

https://github.com/jamesdotcuff/Weather-Station-WH31E/blob/master/monitor/monitor.sh

[zuckschwerdt]

Well, the extra data reveals no apparent structure. It's not constant per device and seems to change even for the same measured temp/hum sometimes.

I guess we'll leave it at that for now and I'm going to merge the WH31E support as-is. I've flipped the battery bit from LOW to OK assuming all your devices have a good battery currently.

The ERT meter support should perhaps be added to rtl_433 so you don't have to share the receiver and call two programs alternating. I need to check if it fits with the existing m_bus decoder.

Do we already have samples from your ERT meters, or can you supply some?

[zuckschwerdt]

If you want to record ERT samples, send them to me by mail so we don't leak private serial numbers and such.

[merbanan]

Can this be closed?