DIO remotes interpreted only as Nexa and Proove devices (not newkaku)

[apaneiro]

I've been testing rtl_433 with some DIO remotes but they are all interpreted only as Nexa and Proove devices (not newkaku) that have similar structure but interpreted differently. Some of these remotes have multiple buttons and the mqtt state messages allways send the same "channel" although they have different "unit" as we can see in the mqtt events messages. We need the "unit" to be present in the "state" messages so that we can configure separate devices in HA.

The 3 devices I have tested have the following ids:
0x01455A52
0x01BFF092
0x01C41472

MQTT messages received for one of these devices (2 buttons):

Mensagem 879 recebida em rtl_433/9b13b3f4-rtl433/devices/Nexa-Security/3/29356178/state às 11:02 :
ON
QoS: 0 - Retain: false
Mensagem 878 recebida em rtl_433/9b13b3f4-rtl433/events às 11:02 :
{"time":"2023-05-22T11:02:41.008220+0100","model":"Nexa-Security","id":29356178,"channel":3,"state":"ON","unit":3,"group":0}
QoS: 0 - Retain: false

Mensagem 967 recebida em rtl_433/9b13b3f4-rtl433/devices/Nexa-Security/3/29356178/state às 11:07 : <<<<< same channel
ON
QoS: 0 - Retain: false
Mensagem 966 recebida em rtl_433/9b13b3f4-rtl433/events às 11:07 :
{"time":"2023-05-22T11:07:05.844556+0100","model":"Nexa-Security","id":29356178,"channel":3,"state":"ON","unit":2,"group":0}
QoS: 0 - Retain: false

Lines 26/27 of:
https://github.com/merbanan/rtl_433/blob/master/src/devices/newkaku.c
reject any id with first byte different from 0x65 or 0x59 but the ids of my test devices start with 0x51, 0x6F and 0x71

** Remove first byte check **

[zuckschwerdt]

reject any id with first byte different from 0x65 or 0x59 but the ids of my test devices start with 0x51, 0x6F and 0x71

The check is not for ID but the raw coding of ID. But otherwise you are correct.

Your IDs

0x01455A52
0x01BFF092
0x01C41472

left aligned to the 26 bit ID length are

51... = 0101... -> encoded this is 0110 0110 = 0x66
6f... = 1111... -> encoded this is 1010 1010 = 0xaa
71... = 0000... -> encoded this is 0101 0101 = 0x55

where we before only have seen 0x65 or 0x59.

I also don't believe that check is sensible. It has always been there, strange.

Unless someone has a good explanation why we only want those two ID ranges I'll merge this.

[zuckschwerdt]

S.a. #2508