ID ends up as part of CMD with Chuango devices

[LuccoJ]

Two Chuango door/window (reed) sensors I have appear, when they trigger, to show up in rtr_433 as ID 16bit = 0xFC5C CMD 8bit = 0xC7 instead of the proper ID 16bit = 0xFC5CC CMD 8bit = 0x7 and ID 16bit = 0xC731 CMD 8bit = 0x1A instead of ID 16bit = 0xC7311 CMD 8bit = 0xA

The central station and another sensor I have don't seem to have this problem, their IDs being 0x764CE and 0x01F00 respectively. The sensors exhibiting the problem also output TRISTATE = 1110FF1010F1 which I don't really know the meaning of.

[merbanan]

I'm not totally sure what your issue is can you elaborate a little bit ? Ie explain why your sensors have 20bit id instead of 16bit.

[LuccoJ]

Uh, well, I'm not sure, but that's what Chuango sensors have, and your program seems to know that, going by src/devices/chuango.c But I guess maybe it simply doesn't realize that some of these are Chuango sensors, while it knows about some others?

[merbanan]

Ok, now I know what you are talking about. The issue here is that this is a family with chips that output the same bitstream. For these bitstreams we have 2 decoders, generic_remote.c and chuango.c. For some reason chuango does not pick up the sensors you have. Most likely this is caused by the signalling rate of the sensors. If you open the sensor that works and set the same rate for the non working sensors. Things will probably work as you wanted.

[LuccoJ]

I'm not aware of any jumpers that set the signalling rate inside the sensors. Could it not be based on ID? Like, some ID being known as belonging to Chuango? I've had a look at the source but I'm unable to understand how the program determines which device callback to use. The Chuango alarm's control panel certainly had no trouble recognizing those sensors, so if they aren't signalling using Chuango standards, they must at least be very close...

[merbanan]

if ((bits == 25)
 && (b[3] && 0x7F)  // Last bit is always 0
 && (b[0] != 0x00) && (b[1] != 0x00) && (b[2] != 0x00)  // Reduce false positives. ID 0x00000 not supported

This is all what is used to identify both type of sensors. So only the signal properties differs.

[merbanan]

Can you open the sensors and look ?

https://github.com/merbanan/rtl_433_tests/blob/master/tests/PT2262/01/IMG_20150830_155716.jpg

That is what one of my pirs look inside. The 4.7 3.3 1.5 jumpers control the rate.

[LuccoJ]

These are reed sensors. The PIR is actually the one that works okay.

I've put pictures of the front and back at http://imgur.com/a/H08Mu The four D0-D3 jumpers are to decide whether the sensor is in the normal, home, 24h or single zone.

[LuccoJ]

I also got a Chuango smoke sensor today, and it also misacts. Its reported ID is 0x5D2F and rtl_433 says it sends the command 0xAB, while the ID should be 0x5D2FA, and 0xB is the command for "24h mode" sensors. So, to sum it up, so far only the control panel and the PIR sensor are correctly recognized as Chuango devices.

[merbanan]

The design of the PT2260/PT2262 SC2260/SC2262 EV1527 chips causes this. Chuango can use sensors and remotes not specifically designed for their system. It all depends on how you configure tehm. rtl_433 needs the same kind of configuration to be able to work the same way as Chuango. And currently there is no support for that.

[LuccoJ]

I'm not sure I get it; are you saying that some of my Chuango sensors (the misbehaving ones) use a more generic chip that uses non-Chuango signalling, but then my Chuango control panel can decode it anyway, and it just interprets it as a 20bit ID + 4bit CMD instead of 16bit ID + 8bit CMD?

And you say about configuring non-Chuango sensors... are those usually more configurable than Chuango ones? (yours definitely does look like it has a ton of jumpers that mine lack)

Just a thought: maybe rtl_433 could be changed so that, when I specify "-R 29" (i.e. filter for Chuango commands only), it will also consider generic_remote commands, but output them as 20+4 instead of 16+8?

[merbanan]

All chips use the same signalling. And rtl_433 has 2 decoders for one type of signals. And no decoder is more right then any other,

[LuccoJ]

Then I still don't get it, sorry for being thick, but why is one decoder picked for some of my sensor and the other decoder for the other sensors, if everything is the same? Keep in mind that if I use "-R 29", the sensors that normally get decoded by generic_remote.c simply stop being decoded at all, and do not show up.

[merbanan]

They differ a little bit. In the signal detection values.

[merbanan]

.short_limit    = 142,  // Pulse: Short 142, Long 426 
.long_limit     = 426,  // Gaps:  Short 142, Long 424
.reset_limit    = 450,  // Intermessage Gap 4300 (individually for now)

vs

.short_limit    = 116,
.long_limit     = 351,
.reset_limit    = 450,

[LuccoJ]

Okay, I've made a generic_chuango.c device that behaves like chuango.c but uses the detection values of generic_remote.c. This works for my system if I specify "-R 29 -R 33" (33 is the number of the new generic_chuango.c device), although it segfaults as soon as a sensor fires if I give no arguments (probably because then rtl_433 tries to decode using both decoders?).

The changes are at https://github.com/LuccoJ/rtl_433

[merbanan]

I think the way to solve this in a maintainable way is to add a load hook for the chuango protocol that reads a file with id's that you can register as valid sensors to the chuango system. There is no way to detect this automatically. You have to add it manually. If someone implements that I will merge it anything else will be rejected. Anyway I hope this answers your issue.