[thielj]

Hi,

I've a few temperature and humidity sensors of Chinese origin, sold under the DIGOO (DG-R8H, DG-R8S) or BALDR brand, e.g. search AliExpress for 32651878320, 32826519857 or 32852252178. On BangGood: 1139603 or 1178108 (sorry, can't post direct links).

They seem to be using the "Nexus sensor protocol" or "Rubicson protocol", as implemented in rtl_433 on github. I can't post direct links, but you'll find the source code in their repository under src/devices/(nexus|rubicson).c  

The 36 bits translate as follows:

Code:

  ID ID ID CC         8-bit ID, the two least significant might encode the channel
  BF CC               4 bits of flags:
                         B  =1 battery good
                         F  =1 forced transmission
                         CC =  channel, zero based
 TT TT TT TT TT TT   12 bits signed integer, temp in Celsius/10
 11 11               const / reserved
 HH HH HH HH         8 bits, either
                        - humidity (or 1111 xxxx if not available); or
                        - a CRC, e.g. Rubicson, algorithm in source code linked above

It would make sense to look at these two protocols as one and assume that a valid CRC or a humidity value > 100 means that the sensor is not transmitting humidity. The protocol is very similar to the other temperature and humidity sensor protocols (tfa, etc) and sometimes misdetected. The const 4-bit value can eventually be used to differentiate this protocol from others.
  
On the air, the BALDR sensor seems to transmit a different footer:

Code:

BALDR EXAMPLE (Temperature only)

data:
568 1892 524  928 532 1908 532  944 512 1932 532  924 524  952 508  944 
520 1932 524  948 508  944 512  956 500  964 504  968 520  952 492  968 
504 1912 536  940 512 1920 520 1904 544  940 536  928 520 1920 524 1924 
520 1904 544 1908 528 1912 512 1920 536 1900 520 1944 516 1912 524 1916 
544  920 532 1904 528  968 508  944 
footer:
516  468 484 3864 

data decoded:
10 10 10 00        ID
10 00              Battery OK, regular transmission, Channel 1 (00)
00 00 10 11 00 11  179 => 17.9`C
11 11              const
11 11 01 00        invalid or CRC?

Code:

DIGOO example 1

data:
428 1048 404 2024 408 2028 408 1072 388 1076 384 1076 388 1088 376 2056 
400 2032 404 1068 392 1076 388 2040 396 1076 388 1080 384 1084 376 1100 
364 2064 396 2040 392 1072 392 1076 388 1076 384 1084 380 1088 376 1084 
380 2060 396 2040 396 2036 400 2056 396 1076 384 1072 388 2056 384 2056 
396 1064 396 1312 388 1084 380 1088 
footer:
376 3988 

data decoded:
01 10 00 01        ID
10 01              Battery OK, regular transmission, Channel 2 (01)
00 00 11 00 00 00  192 => 19.2`C
11 11              const
00 11 00 00        48 => 48%        

---

DIGOO example 2

data:
404 2044 384 1096 364 1140 336 2064 368 1088 372 1092 360 2132 308 1096 
356 1128 364 1124 312 1128 332 1160 328 1132 308 1168 304 1180 288 1128 
344 2088 380 1092 360 2080 352 2112 340 2056 372 1116 332 1136 344 1112 
328 2140 344 2088 380 2056 352 2032 416 1096 348 2100 332 1096 384 1112 
328 1128 328 1196 296 1100 356 1116
footer:
372 4004
 
10 01 00 10        ID
00 00              Battery fail, regular transmission, Channel 1 (00)
00 00 10 11 10 00  184 => 18.4`C
11 11              const
01 00 00 00        64 => 64%

--

DIGOO example 3

data:
424 2000 428 1060 392 2036 416 1052 400 2048 392 1068 400 2036 408 1076 
392 1060 396 1064 396 2048 404 1064 392 1076 384 1076 396 1064 392 1080 
392 2044 396 1076 384 2044 408 2024 416 2036 400 2032 416 1064 392 1072 
396 2032 408 2040 400 2040 408 2024 416 1056 396 1068 400 2036 404 2048 
404 2032 408 1060 392 2048 404 1060
footer:
396 3984

data decoded: 
10 10 10 10        ID
00 10              Battery low, regular transmission, channel 3 (10)
00 00 10 11 11 00  188 => 18.8`C
11 11              const
00 11 10 10        58 => 58%

The transmission is repeated a few times

[ha_username]

I've successfully written the decoder for the Nexus temperature sensors (bought from pearl.de I think) and the main issue (for me) was that ESPiLight was using a hardcoded ESPiLight::mingaplen=5100 delay between repeats while Nexus specifies 4000. I've changed this to 3700 and my decoder worked without issues. I can post the nexus.c/.h code here for review and testing. Or should I try to create a PR?

[curlymo]

Please in a PR

[ha_username]

Please in a PR

I've spoken to the original ESPiLight author and he changed the the delay logic (gap length) so it's now precomputed from all the protocols.

I just need to check out the pilight branch and create a link (NTFS junction?) so that I can properly test it and create the PR.

[curlymo]

I would check one of the merged PR's on how they did the PR and check the contribution guide.