Fail to fully decode of NEXA NBA-001 messages

[Janlars]

Hi I have been playing arround with rtl_433 and found that it does not fully decode messages fron his device. Inside it has a HIDEKI pcb and the device shows in rtl_433 as HIDEKI TS04 sensor The rtl_433 decode are missing a device ID.

2018-09-05 16:46:50 : HIDEKI TS04 sensor Rolling Code: 1 Channel: 1 Battery: OK Temperature: 23.1 C Humidity: 48 %

If I test the same device with a RFXcom RFXrec433E USB receive and the corrosponding RFX Manager. Here the Nexa (Hedeki) device is decoded like this:

05-09-2018 02:39:36:726 Packettype = TEMP_HUM subtype = TH7 - Cresta, TFA TS34C channel 1 Sequence nbr = 0 ID = 370E decimal:14094 Temperature = 25,2 °C Humidity = 46 Status = Comfortable Signal level = 7 -64dBm Battery = OK

As ther are no other way to tell which sensor is which, I would like that we can get atleast the ID in the rtl_433 decode ??

Regards Jan L

[zuckschwerdt]

Is rc (Rolling Code) really a proper RC, i.e. changing with every message? Does it correspond to the "sequence number"? Also you might want to dig around in https://github.com/merbanan/rtl_433/blob/master/src/devices/hideki.c and see if anything is amiss?

[Janlars]

Sorry, but I am not a porgrammer so I don't understand this hedeki.c I just thought that it might be possible to get the sensor ID in the decode, as RFCcom guys have...

[merbanan]

Submit a sample signal with rtl_433 output and RFXcom output. Then we can correlate it and maybe add the missing bits.

[Janlars]

This is my plan, but I am only able to find tools which gives me the decoded output I wrote in my first message

[merbanan]

You need to record a signal with rtl_433. Look into the documentation on how to do that.

[zuckschwerdt]

The ID might be in the byte 2 or 3, those are currently not decoded. Can you grab a packet with a known ID? I.e. let rtl_433 grab packets, watch the RFXcom output, stop when a packet is received?

[Janlars]

OK that I think I know how to...

I will give it a shot with these files rtl 433 Dump.zip

I havd this dump from RFXcom where the hedeki has ID = = 300E decimal:12302 05-09-2018 09:48:46:956 Packettype = TEMP_HUM subtype = TH7 - Cresta, TFA TS34C channel 1 Sequence nbr = 70 ID = 300E decimal:12302 Temperature = 23,3 °C Humidity = 55 Status = Comfortable Signal level = 8 -56dBm Battery = OK

As I have 2 of these sensore the other id is 05-09-2018 09:45:26:274 Packettype = TEMP_HUM subtype = TH7 - Cresta, TFA TS34C channel 1 Sequence nbr = 51 ID = 210E decimal:8462 Temperature = 23,4 °C Humidity = 53 Status = Comfortable Signal level = 7 -64dBm Battery = OK

[Janlars]

This is from the RFXcom log in Homeseer It is for ID 300E / 12302 Data should be rad from bottom up

sep-05 23:59:12 RFXCOM Battery = OK sep-05 23:59:12 RFXCOM Signal level = 7 sep-05 23:59:12 RFXCOM Status = Comfortable sep-05 23:59:12 RFXCOM Humidity = 48 sep-05 23:59:12 RFXCOM Temperature = 25,4 °C sep-05 23:59:12 RFXCOM ID = 12302 sep-05 23:59:12 RFXCOM Sequence nbr = 207 sep-05 23:59:12 RFXCOM subtype = TH7 - TFA TS34C sep-05 23:59:12 RFXCOM 36 (RecTRXChar) transceiver #1 packet: 0A5207CF300E00FE300179 sep-05 23:59:12 RFXCOM 36 (sockDataArrival) TCP 192.168.2.223,10001 data received: 0A5207CF300E00FE300179

As I read it 0A5 =(I dont know) 207 =(I dont know) CF = Sequence nbr 300E =ID in hex 00 FE = Temp 30 = Humidity 01 = Batt 7 = Signal level 9 =(I dont know)

/Jan L

[zuckschwerdt]

The three test samples decode to:

{90} 06 bd e3 10 a1 bd e1 56 01 80 72 40
{90} 06 bd e3 10 91 bd e1 56 01 81 e5 40
{81} 06 ff 33 31 b0 c8 be 67 84 3a 80

which after transformation (MSB-LSB reverse, flip bits) is

9f 37 ce de 47 c2 51 fc 0f 9a ff 00 00 00
9f 21 ce 9e 27 c2 55 ff 3e 96 ff 00 00 00
9f 80 cc 8e cf 17 66 7c 56 ff 00 00 00 00

I don't see the id's in there.

[Janlars]

Do you see any of the other data like Hum, Temp, Seq nbr, ?

I found this file, used by another Home automatisation system.. It is about RFXcom decode, maybe it can be helpfull.

https://github.com/contactless/domoticz/blob/master/main/RFXtrx.h#L638

[zuckschwerdt]

Add this line

    fprintf(stderr, "bytes 3,4,7,8,9 are: %02x %02x %02x %02x %02x\n", packet[2], packet[3], packet[7], packet[8], packet[9]);

after

if (sensortype == HIDEKI_TS04) {

in file src/devices/hideki.c before you compile and run. Look at the bytes (3 and 4 are good candidates, 7,8,9 are likely some checksum) and see if something correlates.

A quick test with existing data (see above) is possible with e.g.:

rtl_433 -q -F json -R 42 -y '{90} 06 bd e3 10 a1 bd e1 56 01 80 72 40'

(which gives "bytes 3,4,7,8,9 are: ce 5e ff fe d8" with no obvious id.)

[Janlars]

thanks alot for the suggestion.

I did a small modification to your code and changed into this: fprintf(stderr, "bytes 0,1,2,3,4,5,6,7,8,9 are: %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x\n", packet[0], packet[1], packet[2], packet[3], packet[4], packet[5], packet[6], packet[7], packet[8], packet[9]); This gave me this output from 2 different Sensors:

bytes 0,1,2,3,4,5,6,7,8,9 are: 9f 34 ce de 55 c2 48 f3 08 95 2018-09-06 19:15:18 : HIDEKI TS04 sensor Rolling Code: 4 Channel: 1 Battery: OK Temperature: 25.5 C Humidity: 48 % bytes 0,1,2,3,4,5,6,7,8,9 are: 9f 30 ce 5e 44 c2 49 ff 90 bb 2018-09-06 19:15:27 : HIDEKI TS04 sensor Rolling Code: 0 Channel: 1 Battery: OK Temperature: 24.4 C Humidity: 49 %

One has Rolling Code =0 and the other have Rolling Code =4

I found out that it is a real Rolling Code because I was also monitoring the devices in RFX Manager and saw that when I turned one sensor off and on that both the Rolling Code i rtl_433 and ID RFXManager changed..

I believe I have found out how RFCcom compose the ID... They take leading number of Rolling Code and Rolling Code and prefix it with 0E This means that the ID for the first Sensor will be 340E and for the second 300E which matches the values seen in RFCManager

Would it be possible to ADD an ID field, composed as above, to hideki.c ??

[zuckschwerdt]

Good work so far! There are some hints in the hideki.c on which fields are known. Like you say, for the 2nd byte the 0 (lower nibble) is the rc, the 3 (upper nibble) divided by 2 is the channel. Shouldn't the ID be constant? Using the RC is not good then.

[zuckschwerdt]

Usually an ID is determined when the device powers up. You could watch the device for some time, see which number are fixed. Then disconnect and reconnect the battery and see which of the fixed numbers change.

[Janlars]

The ID should be fixed, but apparently it is not in this Nexa/Hideki device. Answer to your last suggestion... This was exactly what I did :-) and I turns out the numbers that change in rtl_433 trace are also chancing in RFCcom manager trace !

[zuckschwerdt]

Please reopen if you find out how to decode extra fields. Thanks!