Digoo Outdoor Humidity Sensor sniffing help.

[robmarkoski]

Information

Digoo DG-R8H Outdoor Humidity Sensor

Sniffed data

21:01:26 MQT: HA/RF_Bridge/RESULT = {"RfRaw":{"Data":"AA B1 03 0226 073A 0726 28180808 55"}} 21:01:26 MQT: HA/RF_Bridge/RESULT = {"RfRaw":{"Data":"AA B1 04 0212 037A 074E 0EF6 38181818281818182828181828181818182828281828281828282828281818281818181818 55"}} 21:01:27 MQT: HA/RF_Bridge/RESULT = {"RfRaw":{"Data":"AA B1 04 021C 0744 0370 0744 38182828 55"}} 21:01:30 MQT: HA/RF_Bridge/RESULT = {"RfRaw":{"Data":"AA B1 02 03F2 05C8 90808080 55"}}

Query

So the sensor produces the above at a semi-regular interval. The second line i have been able to decode, and is the actual data. But not sure what the other lines are. Sometimes I get four-five short hits in a row like so:

23:26:02 MQT: HA/RF_Bridge/RESULT = {"RfRaw":{"Data":"AA B1 03 01F4 0780 062C 281818 55"}} 23:26:02 MQT: HA/RF_Bridge/RESULT = {"RfRaw":{"Data":"AA B1 04 0208 0758 0384 0780 38182828 55"}} 23:26:02 MQT: HA/RF_Bridge/RESULT = {"RfRaw":{"Data":"AA B1 03 021C 0370 074E 281818 55"}} 23:26:02 MQT: HA/RF_Bridge/RESULT = {"RfRaw":{"Data":"AA B1 04 0226 074E 037A 0744 38182828 55"}} 23:26:02 MQT: HA/RF_Bridge/RESULT = {"RfRaw":{"Data":"AA B1 03 021C 074E 0762 281818 55"}

Then othertimes I get 6 bucket sets like this:

{"Data":"AA B1 06 023A 06A4 0064 0136 038E 0ED8 5808080818080808181808081808080808181A38080818080818181818180C08180808484818 55"}}

Apologies if these are basic questions, this is my first time messing around with rf.

[Portisch]

Try this new firmware: https://github.com/Portisch/RF-Bridge-EFM8BB1/blob/DG-R8H/Keil%208051%20v9.53%20-%20Release/RF-Bridge-EFM8BB1.hex And use advanced sniffing 0xA6

For more information take a look at #87

[robmarkoski]

Hey mate, just uploaded firmware.

Receiving data:

HA/RF_Bridge/RESULT = {"RfRaw":{"Data":"AAA606011190E6F1C055"}}

However doesnt seem correct.

The total data length should be 36bits in total. If I am understanding the Above correctly Preamble: AA A6 06 01 Data: 1190E6F1C0 End: 55

Converting Data to Binary I get 1000110010000111001101111000111000000 which is 37bits but could be a trailing zero which i can deal with. However according to the specification, bits 25-28 must be all 1111.

Edit: More details on the spec here.

[Portisch]

I do not know the protocol. The decoding seems right. 1190E6F1C0 -> right shift 4 bits (8*5 - 36) = 0x1190E6F1C Bin: 0001 00011001 00001110 01101111 00011100

Your example from

AA B1 04 0212 037A 074E 0EF6 38181818281818182828181828181818182828281828281828282828281818281818181818 55

gives me: 0001 00011001 00001110 11011111 00100000 This is 0x1190EDF20 which looks almost the same as 0x1190E6F1C.

Your spec is talking about a different sensor!?

[robmarkoski]

That works great! The sensor uses that same specification for data transfer. Last 8 Bits are humidity and in your one that equates to 32% Also bits 13-24 are the temperature (237 in decimal but require to divide by 10)

Can I ask why we need to shift 4 bits to the right?

[Portisch]

36 bits are used. UART can only transport 8 bits packets. So the last 4 bits are unused. That's why a shift right is needed. Maybe I will implement a shift right already at the transfer.

[Portisch]

Please try this new version and post a 0xA6 sniffed result: https://github.com/Portisch/RF-Bridge-EFM8BB1/blob/DG-R8H/Keil%208051%20v9.53%20-%20Release/RF-Bridge-EFM8BB1.hex This release should shift the data automatically.

[robmarkoski]

hey sorry didnt reply. looks like i bricked the bridge when trying the upgrade. rf led on constantly, and beeping like hell! will need to order new one i guess

[Portisch]

Yes, when it beeps the whole time after flashing it's broken. Did you use the tasmota to flash the efm8? I broke 2 with this method. Now I use a extra hw connection and flasher without any problems.

[robmarkoski]

Yeah used Tasmota.

How do you do it? Dont want to break another one!

[Portisch]

I use this software and a Arduino: https://github.com/Portisch/RF-Bridge-EFM8BB1/wiki/Hardware

[robmarkoski]

Awesome. MIght need to grab an Arduino now... I wonder if I can port to a pi?

Anyway thanks again, will let you know when I am back up and running!

[jensweimann]

Hi, I installed the new version and sniffed the data:

14:28:16 MQT: tele/sonoffRf1/RESULT = {"RfRaw":{"Data":"AAA606012208AE2F0B55"}} 14:29:13 MQT: tele/sonoffRf1/RESULT = {"RfRaw":{"Data":"AAA606012208AE2F0B55"}} 14:30:10 MQT: tele/sonoffRf1/RESULT = {"RfRaw":{"Data":"AAA606012208AE2F0B55"}} 14:31:07 MQT: tele/sonoffRf1/RESULT = {"RfRaw":{"Data":"AAA606012208AE2F0B55"}}

Edit: This would be 27,86 for temp and 38,51 for humidity correct? Temp is a little high, I have another sensor in the room that show 23,6°C

Edit2: I used this for interpreting: https://github.com/dgomes/homeGW/blob/master/digoo.cpp

[Portisch]

This is not correct. You have 36 bits. 40 bits are 5 bytes - 4 bits. So 4.5 bytes. And the number should start with a leading 0. I will check what is wrong...

[jensweimann]

Per this cpp file the packet size should be 37 Bits: https://github.com/dgomes/homeGW/blob/master/digoo.cpp

[jensweimann]

This is not correct. You have 36 bits. 40 bits are 5 bytes - 4 bits. So 4.5 bytes. And the number should start with a leading 0. I will check what is wrong...

Hi Portisch, any news about this topic? Kind regards.

[robmarkoski]

finally got a new unit! going to try get back onto working on this. I see previous version isnt working?

[jensweimann]

finally got a new unit! going to try get back onto working on this. I see previous version isnt working?

Hi robmarkoski, did you managed to achieve any progress?

[gabrielklein]

Hi, I have success using https://github.com/merbanan/rtl_433

My Digoo is detected as a Nexus Temperature. (Yes the -20°c is normal :) in my freezer since a few months and send an alert if temperature is bigger than -15°c.)

time : 2019-10-08 16:12:55 model : Nexus Temperature/Humidity House Code: 105 Channel : 2 Battery : OK Temperature: -19.50 C Humidity : 31 %

time : 2019-10-08 16:13:01 model : Nexus Temperature/Humidity House Code: 182 Channel : 2 Battery : OK Temperature: 20.30 C Humidity : 57 %

[aefo]

I flashed the firmware from https://github.com/Portisch/RF-Bridge-EFM8BB1/blob/DG-R8H/Keil%208051%20v9.53%20-%20Release/RF-Bridge-EFM8BB1.hex ( f04658a on Jun 6 ) and a RfRaw 166 race is below.

10:13:48 MQT: tele/sonoff/RESULT = {"Time":"2019-10-29T10:13:48","RfRaw":{"Data":"AAA60601ED0A1C3F0E55"}} 10:15:07 MQT: tele/sonoff/RESULT = {"Time":"2019-10-29T10:15:07","RfRaw":{"Data":"AAA60601ED0A1C3F0E55"}} 10:16:26 MQT: tele/sonoff/RESULT = {"Time":"2019-10-29T10:16:26","RfRaw":{"Data":"AAA60601ED0A1C3F0E55"}} 10:17:45 MQT: tele/sonoff/RESULT = {"Time":"2019-10-29T10:17:45","RfRaw":{"Data":"AAA60601ED0A1C3F0E55"}} 10:19:04 MQT: tele/sonoff/RESULT = {"Time":"2019-10-29T10:19:04","RfRaw":{"Data":"AAA60601ED0A1C3F0E55"}} 10:20:23 MQT: tele/sonoff/RESULT = {"Time":"2019-10-29T10:20:23","RfRaw":{"Data":"AAA60601ED0A1C3F0E55"}} 10:21:42 MQT: tele/sonoff/RESULT = {"Time":"2019-10-29T10:21:42","RfRaw":{"Data":"AAA60601ED0A1C3F0E55"}} 10:23:01 MQT: tele/sonoff/RESULT = {"Time":"2019-10-29T10:23:01","RfRaw":{"Data":"AAA60601ED0A1C3F0E55"}} 10:24:20 MQT: tele/sonoff/RESULT = {"Time":"2019-10-29T10:24:20","RfRaw":{"Data":"AAA60601ED0A1C3F0E55"}} 10:25:39 MQT: tele/sonoff/RESULT = {"Time":"2019-10-29T10:25:39","RfRaw":{"Data":"AAA60601ED0A0C3F0E55"}} 10:26:58 MQT: tele/sonoff/RESULT = {"Time":"2019-10-29T10:26:58","RfRaw":{"Data":"AAA60601ED0A0C3F0E55"}} 10:28:17 MQT: tele/sonoff/RESULT = {"Time":"2019-10-29T10:28:17","RfRaw":{"Data":"AAA60601ED0A0C3F0E55"}} 10:29:36 MQT: tele/sonoff/RESULT = {"Time":"2019-10-29T10:29:35","RfRaw":{"Data":"AAA60601ED0A0C3F0E55"}}

The Digoo sensor is next to different sensor that is reading the temperature as 18.8 degrees C.

I tried parsing the data using the functions from https://github.com/dgomes/homeGW/blob/master/digoo.cpp but the results don't match what I expected

See https://repl.it/repls/MindlessInstructiveCommand for code / tests

For AAA60601ED0A0C3F0E55:

    Parsing Digoo data
    data: 1018091486990
    id: 208
    channel: 3
    temp: -7.700000
    battery: 1

Am I parsing / processing the data incorrectly? Thanks

[aleksey2000]

Hi! Could you plz, help me to recognise data from my digoo temp & humidity. I'm seriously stacked with this(

RfRaw 166 {"Time":"2019-11-01T02:08:18","RfRaw":{"Data":"AAA6060124083E1F0955"}}

RfRaw 177 {"Time":"2019-11-01T02:10:26","RfRaw":{"Data":"AA B1 04 0212 0370 0744 0EEC 38182818181818281828181818181818182828281818182818282828281818182828181828 55"}} {"Time":"2019-11-01T02:10:26","RfRaw":{"Data":"AA B1 04 0212 0370 0744 0744 38182828 55"}}

Thanks.

[rcampbellbassac]

Just to add to this, I have a Digoo DG-TH8380, and it seems to have the same protocol for data. Here are my notes as I worked through my own data. I don't fully understand everything involved, but this is where I am at. Are there plans to add the protocol support to a newer firmware?

AA - start
B1 - binary 1
04 - 4 buckets
0230 - 560µs
0384 - 900µs
0758 - 1880µs
0F00 - 3840µs

01010202020102010201010101010102010101010202010202020202010102020202020203

55 end

“Header : 650ms high and 8000ms low
Body : a set of 36 bits
bit 0 : 650ms high and 2000ms low
bit 1 : 650ms high and 4000ms low

bit 0-13 : id (seems different for each sensor. When you press test, id send id+1. When you reset power, id can be different)
bit 14-15 : channel-1 (select)
bit 16-27 : temperature in degre (must be divide by 10. for exemple 298 = 29.8)
bit 28-35 : humidity (assume 10 seems = LL from panel)”

0

unit id (0-13)
10
10
20
20
20
10
20
10
20
10
10
10
10
10

00111010100000 → 3744 or EA0

channel (14-15)
10
20

01 → channel 1

temp (16-27)
10
10
10
10
20
20
10
20
20
20
20
20

000011011111 → 223 /10 = 22.3C

humidity (28-35)
10
10
20
20
20
20
20
20

00111111 → 63%

3

[Montreal666]

Did anyone manage to extract Temp/humidity data from the Digoo DG-R8S/H with a Sonoff Bridge (Tasmota/Portisch) ? I do get the Raw data but wondering how I can get to the actual values via MQTT. Plan B seems to be OMG or This: https://1technophile.blogspot.com/2019/04/sonoff-rf-bridge-pilight-or-how-to.html. will have to do further testing . thx

EDIT just completed the hack. Works perfectly.

[simonteran]

@aefo I run into same problem. Looks like data ordering is bit off: lower 4bits and higher 8 bits are swapped in byte. Here my simple python code that produce correct output:

data= "AAA60601ED0A0C3F0E55"

id_s    = data[9]+data[8]
flag_s  = data[11]

temp_s  = data[10]+data[13]+data[12]
const_s = data[15]
hum_s   = data[14]+data[12]

id      = int(id_s, 16)
flag    = int(flag_s, 16)
battery = flag>>3
channel = (flag&0x3)+1
const   = int(const_s, 16)
temp    = int(temp_s   , 16)/10.
hum     = int(hum_s    , 16)

print "data    %s" % (data)
print "id      %x" % (id)
print "flag    %x" % (flag)
print "battery %d" % (battery)
print "channel %d" % (channel)
print "cons    %x" % (const)
print "temp    %.1f" % (temp)
print "hum     %d" % (hum)

Here is printed output:

data    AAA60601ED0A0C3F0E55
id      de
flag    a
batery  1
channel 3
cons    f
temp    19.2
hum     48

[aefo]

Thanks for sharing. I posted it to https://repl.it/repls/CapitalWeeklyRelationalmodel and also tried it with data from @jensweimann and it gives a value of 23.4 which is pretty close to the 23.6 he was expecting!

14:28:16 MQT: tele/sonoffRf1/RESULT = {"RfRaw":{"Data":"AAA606012208AE2F0B55"}} Temp is a little high, I have another sensor in the room that show 23,6°C

[mikezs]

I've been having a play around with a Digoo DG-R8S and @Portisch's firmware.

I've got the firmware flashed: https://github.com/Portisch/RF-Bridge-EFM8BB1/blob/DG-R8H/Keil%208051%20v9.53%20-%20Release/RF-Bridge-EFM8BB1.hex

But when I try and do the A6 raw sniffing I don't get anything. I've done the B1 sniffing and get the messages successfully:

09:52:15 MQT: /home/tele/rfbridge/RESULT = {"RfRaw":{"Data":"AA B1 04 02A8 0FDC 07D0 0FC8 38181828181828282828 55"}}
09:52:16 MQT: /home/tele/rfbridge/RESULT = {"RfRaw":{"Data":"AA B1 04 02C6 0FBE 07B2 230A 3818282818182818281828182828282828282828281818182818182828282818182818281828 55"}}
09:52:16 MQT: /home/tele/rfbridge/RESULT = {"RfRaw":{"Data":"AA B1 04 02D0 0FB4 07B2 0FB4 3818281828 55"}}

This leads me to think there's a slight variation in protocol for this device, but I'm out of my depth for decoding the buckets into something meaningful to add my own protocol to the firmware. Also my end goal is to get it to spit out temp/humidity in an RfReceived message rather than RfRaw. I already have a few door sensors that I want to use in conjunction with a few of these devices.

Can anyone point me in the right direction to achieve this? I'm a programmer, so the implementation doesn't daunt me, I just need some pointers in the right direction.

[Montreal666]

Hi @mikezs you didn't mention which RF bridge you are using but I have the same units and managed to get the appropriate data by installing Pilight/OMG;

See this thread :

https://community.openmqttgateway.com/t/digoo-dg-r8s-433mhz-battery-operated-temperature-and-humidity-sensor-with-embedded-display/287

and this one if you use the Sonoff bridge:

https://1technophile.blogspot.com/2019/04/sonoff-rf-bridge-pilight-or-how-to.html

BTW, do your units seem to report accurate humidity levels? Mine are so off that humidity levels are essentially usueless. Temperature is OK.

[mikezs]

Hi @mikezs you didn't mention which RF bridge you are using but I have the same units and managed to get the appropriate data by installing Pilight/OMG;

I'm using the SONOFF Bridge V2 2.0 hardware revision

See this thread :

https://community.openmqttgateway.com/t/digoo-dg-r8s-433mhz-battery-operated-temperature-and-humidity-sensor-with-embedded-display/287

and this one if you use the Sonoff bridge:

https://1technophile.blogspot.com/2019/04/sonoff-rf-bridge-pilight-or-how-to.html

I have seen that thread, it requires modification to the bridge that will cause my existing sensors to stop working, so I'd rather contribute to this firmware. Backup plan is to get another bridge for the Pilight protocols

BTW, do your units seem to report accurate humidity levels? Mine are so off that humidity levels are essentially usueless. Temperature is OK.

The humidity levels on mine seem pretty accurate. Have you only got 1 unit to compare to each other?

[Montreal666]

That's exactly what I did, Sonoff bridges are so cheap, I bought a second one; One is on Portisch, the other one on Pilight.

Also, the added benefit of pilight is that all data can be parsed easily via MQTT on separate topics

TEMP_SENSOR|OpenMQTTGateway_SRFB_TEMP1|PilighttoMQTT:message:message:id-63:humidity  

TEMP_SENSOR|OpenMQTTGateway_SRFB_TEMP1|PilighttoMQTT:message:message:id-63:temperature   . With Portisch all data goes under the same topic which makes it cumbersome to manage.

tele/SONOFF_RFBRIDGE_PORTISCH/RESULT:RfReceived:Data

The Portisch has proven useful though because some motion sensors are not decoded via Pilight.

Some devices are decoded by both units which is a good way to add redundancy to your mix.

hope this helps.

PS: the hack involves some fine soldering but fairly easy to achieve.

[Montreal666]

I have 3 R8S and they all have the same issue; normal humidity levels return minimum level (10% or error) when raised over 60% then the sensor starts returning values over 10% it's essentially off by -30%/40% and it's not related to decoding as you can see values directly on the units. I have ordered a separate humidity sensor to test/replace the existing ones, we'll see if it works. the small board inside is quite basic and the sensor is easily replacable (2 pins)

[mikezs]

Does anyone else know how to add their own protocols by decoding the buckets?

[mikezs]

Just as an update, I've updated this firmware and Tasmota to properly parse the data. I've now got the DG-R8S logging to MQTT:

14:55:22 MQT: /home/tele/rfbridge/RESULT = {"Time":"2020-06-19T14:55:22","RfReceived":{"Temperature":22.3,"Humidity":49,"Battery":"High","Button":"Off","Channel":1,"Id":"9AC"}}
14:56:12 MQT: /home/tele/rfbridge/RESULT = {"Time":"2020-06-19T14:56:12","RfReceived":{"Temperature":22.3,"Humidity":49,"Battery":"High","Button":"Off","Channel":1,"Id":"9AC"}}
14:57:02 MQT: /home/tele/rfbridge/RESULT = {"Time":"2020-06-19T14:57:02","RfReceived":{"Temperature":22.4,"Humidity":49,"Battery":"High","Button":"Off","Channel":1,"Id":"9AC"}}
14:57:52 MQT: /home/tele/rfbridge/RESULT = {"Time":"2020-06-19T14:57:52","RfReceived":{"Temperature":22.3,"Humidity":49,"Battery":"High","Button":"Off","Channel":1,"Id":"9AC"}}`

Final step is to make it work with the default protocol for my door/window sensors and i'll post back here with the 2 firmwares to upload and get this working.

[Montreal666]

Great. Let me know once you are done. I'll be glad to test here. Cheers

[Montreal666]

Hi Mikezs, were you able to get this working? Thanks!

[mikezs]

Hi Mikezs, were you able to get this working? Thanks!

Yes, I've got it all working, but it requires a custom Tasmota build plus a custom Portish firmware to get working. I'm planning to release them both as a fork on my github once I get more units to test with, but won't be doing a pull request for either because I need to change the functionality of both of them which is a breaking change.

[finwes]

@mikezs Would you be kind to share your firmwares to test on my hardware? I have the exact same hardware that you do I would love to get the DG-R8S working with my old sensors. Thank you for you work!

[mikezs]

@mikezs Would you be kind to share your firmwares to test on my hardware? I have the exact same hardware that you do I would love to get the DG-R8S working with my old sensors. Thank you for you work!

I've actually found an issue where the door/window sensors are only working some of the time and they're being "batched" up and sent in one go, so there's still an issue with my firmware before I share it.

Once it's sorted (it's not high priority for me though) I'll post back here with the firmwares and source code

[finwes]

Just to add to this, I have a Digoo DG-TH8380, and it seems to have the same protocol for data. Here are my notes as I worked through my own data. I don't fully understand everything involved, but this is where I am at. Are there plans to add the protocol support to a newer firmware?

AA - start
B1 - binary 1
04 - 4 buckets
0230 - 560µs
0384 - 900µs
0758 - 1880µs
0F00 - 3840µs

01010202020102010201010101010102010101010202010202020202010102020202020203

55 end

“Header : 650ms high and 8000ms low
Body : a set of 36 bits
bit 0 : 650ms high and 2000ms low
bit 1 : 650ms high and 4000ms low

bit 0-13 : id (seems different for each sensor. When you press test, id send id+1. When you reset power, id can be different)
bit 14-15 : channel-1 (select)
bit 16-27 : temperature in degre (must be divide by 10. for exemple 298 = 29.8)
bit 28-35 : humidity (assume 10 seems = LL from panel)”

0

unit id (0-13)
10
10
20
20
20
10
20
10
20
10
10
10
10
10

00111010100000 → 3744 or EA0

channel (14-15)
10
20

01 → channel 1

temp (16-27)
10
10
10
10
20
20
10
20
20
20
20
20

000011011111 → 223 /10 = 22.3C

humidity (28-35)
10
10
20
20
20
20
20
20

00111111 → 63%

3

@rober42539 How do you parse your data?

Cannot understand how you go from 10 10 10 10 20 20 10 20 20 20 20 20

to 000011011111 → 223 /10 = 22.3C

For instance, how would you parse this from my sensor:

AA B1 04 02D0 0FA0 079E 22F6 3818282818182818281828281828282828282828182828181828181818282818282828281828 55

Thank you in advance!

[finwes]

@mikezs Thank you! Thats awesome! In the meanwhile any help to understand the protocol of the R8S would be great so I could implement a parser.

This is what the sensor would send with fraw 177 (as you said before 166 won't work):

AA B1 04 02D0 0FBE 07A8 22EC 3818282818182818281828281828282828282828182828181818181828282818282818181828 55

Thank you so much in advance.

[mikezs]

I've already implemented a parser for this sensor, and it's not trivial! I'll release it when it's ready because currently it's not perfect.

Your explanation is also not complete, and there is more data like button pressed and low battery warning You decode the long string by converting 18 -> 0 and 28 -> 1 (or similar) get a binary/hex value and then use the rules above to get the data.

Here's my python decoding with comments: https://repl.it/repls/YouthfulThankfulSearchservice so you can hopefully understand and then an implementation I wrote in C that I used for modifying the Portisch firmware: https://cplayground.com/?p=manis-partridge-eel

You can decode yourself and plug the numbers into the data and see if it gives you the results you expect.

[finwes]

Thank you @mikezs! That would do! Really appreciate it! Thank you again for your work!

[rcampbellbassac]

Just to add to this, I have a Digoo DG-TH8380, and it seems to have the same protocol for data. Here are my notes as I worked through my own data. I don't fully understand everything involved, but this is where I am at. Are there plans to add the protocol support to a newer firmware?

AA - start
B1 - binary 1
04 - 4 buckets
0230 - 560µs
0384 - 900µs
0758 - 1880µs
0F00 - 3840µs

01010202020102010201010101010102010101010202010202020202010102020202020203

55 end

“Header : 650ms high and 8000ms low
Body : a set of 36 bits
bit 0 : 650ms high and 2000ms low
bit 1 : 650ms high and 4000ms low

bit 0-13 : id (seems different for each sensor. When you press test, id send id+1. When you reset power, id can be different)
bit 14-15 : channel-1 (select)
bit 16-27 : temperature in degre (must be divide by 10. for exemple 298 = 29.8)
bit 28-35 : humidity (assume 10 seems = LL from panel)”

0

unit id (0-13)
10
10
20
20
20
10
20
10
20
10
10
10
10
10

00111010100000 → 3744 or EA0

channel (14-15)
10
20

01 → channel 1

temp (16-27)
10
10
10
10
20
20
10
20
20
20
20
20

000011011111 → 223 /10 = 22.3C

humidity (28-35)
10
10
20
20
20
20
20
20

00111111 → 63%

3

@rober42539 How do you parse your data?

Cannot understand how you go from 10 10 10 10 20 20 10 20 20 20 20 20

to 000011011111 → 223 /10 = 22.3C

For instance, how would you parse this from my sensor:

AA B1 04 02D0 0FA0 079E 22F6 3818282818182818281828281828282828282828182828181828181818282818282828281828 55

Thank you in advance!

I haven't touched this in months, and gave up on it because of how complicated it is. I just wasn't getting consistent results. So, I'm not really able to answer your question. I'd simply recommend finding a different device that is already tested to work. Those notes were just what I found working through limited amounts of data, but the comments above show that there is much more involved, and it's all a bit over my head.

[finwes]

Thanks to @mikezs 's examples I have managed to decode the raw frames of the R8S digoo. I have implemented a python script that decodes both the frames of the temperature sensor and all the sonoff sensors that I have (PIR, different buttons, and such). The script implements an MQTT client and subscribes to the topic of the sonoff RF Bridge, parses and decodes the raw messages and publishes a fully decoded MQTT message on different topic. These messages are already very easy to use in HassIO and other similar systems. I have installed the script as a daemon on the raspberry pi where I have the HassIO so the system is quite integrated. It may be an easy and quick solution, but it does the job. I look forward to @mikezs 's work which will be a much better solution to the same problem. In the meantime, if anyone needs the script I have no problem sending it to them.

Thanks again for the help @mikezs !

[kostya4000]

@finwes Share your script.

[TimDowker]

Thanks to @mikezs 's examples I have managed to decode the raw frames of the R8S digoo. I have implemented a python script that decodes both the frames of the temperature sensor and all the sonoff sensors that I have (PIR, different buttons, and such). The script implements an MQTT client and subscribes to the topic of the sonoff RF Bridge, parses and decodes the raw messages and publishes a fully decoded MQTT message on different topic. These messages are already very easy to use in HassIO and other similar systems. I have installed the script as a daemon on the raspberry pi where I have the HassIO so the system is quite integrated. It may be an easy and quick solution, but it does the job. I look forward to @mikezs 's work which will be a much better solution to the same problem. In the meantime, if anyone needs the script I have no problem sending it to them.

Thanks again for the help @mikezs !

Yes, please share your script.

[kostya4000]

@aefo I run into same problem. Looks like data ordering is bit off: lower 4bits and higher 8 bits are swapped in byte. Here my simple python code that produce correct output:

data= "AAA60601ED0A0C3F0E55"

id_s    = data[9]+data[8]
flag_s  = data[11]

temp_s  = data[10]+data[13]+data[12]
const_s = data[15]
hum_s   = data[14]+data[12]

id      = int(id_s, 16)
flag    = int(flag_s, 16)
battery = flag>>3
channel = (flag&0x3)+1
const   = int(const_s, 16)
temp    = int(temp_s   , 16)/10.
hum     = int(hum_s    , 16)

print "data    %s" % (data)
print "id      %x" % (id)
print "flag    %x" % (flag)
print "battery %d" % (battery)
print "channel %d" % (channel)
print "cons    %x" % (const)
print "temp    %.1f" % (temp)
print "hum     %d" % (hum)

Here is printed output:

data    AAA60601ED0A0C3F0E55
id      de
flag    a
batery  1
channel 3
cons    f
temp    19.2
hum     48

I am using this script, but it does not display negative temperatures correctly.

[rummager]

@aefo I run into same problem. Looks like data ordering is bit off: lower 4bits and higher 8 bits are swapped in byte. Here my simple python code that produce correct output:

data= "AAA60601ED0A0C3F0E55"

id_s    = data[9]+data[8]
flag_s  = data[11]

temp_s  = data[10]+data[13]+data[12]
const_s = data[15]
hum_s   = data[14]+data[12]

id      = int(id_s, 16)
flag    = int(flag_s, 16)
battery = flag>>3
channel = (flag&0x3)+1
const   = int(const_s, 16)
temp    = int(temp_s   , 16)/10.
hum     = int(hum_s    , 16)

print "data    %s" % (data)
print "id      %x" % (id)
print "flag    %x" % (flag)
print "battery %d" % (battery)
print "channel %d" % (channel)
print "cons    %x" % (const)
print "temp    %.1f" % (temp)
print "hum     %d" % (hum)

Here is printed output:

data    AAA60601ED0A0C3F0E55
id      de
flag    a
batery  1
channel 3
cons    f
temp    19.2
hum     48

I am using this script, but it does not display negative temperatures correctly.

Hi, If the temperature is negative, is the value greater than 511? Before dividing by 10.

[Laces]

I know it's an old thread, but still not trivial how to decode the data sent by DIGOO R8S. I got this with rfraw 177 using Tasmota and Portisch:

AA B1 04 02D0 0FBE 07BC 2288 3818282818182828182818182828282828282828182828182818282818282818281818282828 55

and I have changed the 18 to 0 and the 28 to 1: 380110011010011111111011010110110100111 and according to the comments above the last 8 should be the humidity: 10100111 and the 8 before that 10101101 should be the temperature, but the reading on the display says 44%humidity and 29.5°C but if I convert the binary to decimal I got 16.7%humidity and 17.3°C. Can you point out what I'm doing wrong?

[rummager]

Hello Laces, A bit late but I think I know how to analyze this data.

1. The correct temperature is 29.7 C, not 29.5 C and the humidity is 44%.
2. Sometime my sensor sends data in reverse. When I change the battery for example.
3. Let's try to reverse them: Convert 18 to 1 and 28 to 0. Result: 381001100101100000000100101001001011000
4. We remove the last 0 and we have 38100110010110000000010010100100101100
5. The last 8 digits are 00101100 after the conversion is 44. The next 9 (I don't know why) is 100101001 after the conversion is 297 divided by 10 is 29.7
6. At negative temperatures, this value may exceed 511. Then it should be minus 1024. We will then obtain a negative temperature.

Maybe I helped. My sensor works differently and I had to look for values ​​elsewhere.

[BacchusIX]

Using the 18 and 28 thing, my readings don't seem to make sense. I get: AA B0 2F 04 08 0226 074E 037A 0EF6 38182818182828281828282828282828281828182818282818181818182818282818181828 55. 18= 1 and 28=0 gives me: 38101100010000000010101001111101001110 the last 8 gives me 78 which can't be right (furnace, and a 2 other meters all say it's about 55% humidity. the 9 before that gives me 15.9 ( which is close actually) next i get: AA B0 2F 04 08 0208 0776 03A2 0F0A 38182818182828281818282828282828281818282828282828181818182828181818182828 55 or: 38101100011000000011000000111100111100 last 8 gives me 60 for humidity and 15 for temp ( which I turned the heat up for this one so the value should have increased.

and I had another that gave me 65 for humidity and 35 for temp.