xoseperez / espurna

Home automation firmware for ESP8266-based devices
http://tinkerman.cat
GNU General Public License v3.0
3k stars 638 forks source link

Sonoff RF Bridge: Support identifying devices that send 1527 codes. #271

Closed xoseperez closed 6 years ago

xoseperez commented 7 years ago

Originally reported by: Mike Hole (Bitbucket: mikehole, GitHub: mikehole)


OK this isn't an issue so much but more of a plea for help. If I am using the wrong channel can you please point me in the right direction.

A little background: I have been looking for an inexpensive solution that will allow me to use 433 based PIR devices and Door sensors. The SONOFF RF Bridge looked like a great solution for this. I also didn't want to use the supplied firmware so ESPURNA looks like a great solution.

I purchased the devices that iTEAD sell to go with the bridge: https://www.itead.cc/sonoff-rf-bridge-433.html

The problem I am having is that the codes that the devices send codes that I can not easily distinguish between here is a sample from the PIR:

30 D4 01 04 C4 D1 0C 6E 6E

30 D4 01 04 C4 0C 6E 0C 6E

30 D4 01 A4 04 6E 6E 0C 6E

30 DE A4 04 C4 D1 0C 6E 6E

30 DE A4 04 C4 D1 0C 6E 6E

30 01 A4 04 0C 6E 41 3C 00

And the door sensor:

3A 48 01 F4 05 4A 41 4A AA

31 10 01 14 4A 41 41 4A AA

30 FC A4 BA 4A 41 AA A4 3B

3A F2 01 F4 05 4A 41 3C 00

From looking into this the codes follow the 1527 protocol and are supposed to roll but the devices do have a way of setting the 'key' that they send (the door sensor has a soldered bridge on a pad that has Key4 next to it).

Ho do I find the key from the data I have above?

xoseperez commented 6 years ago

Original comment by Phil Elson (Bitbucket: pelson, GitHub: pelson):


Just wanted to add another datapoint here. I have a remote that came with "Brennenstuhl RCS 1000 N Comfort remote control set, 3 remote control socket set (with remote control and child proof device)" (ref: https://www.amazon.co.uk/gp/product/B003BIFLSY/)

When I press the remote button C "on" I get some different codes:

25 58 01 36 03 98 54 55 5F
25 76 01 2C 03 A2 54 51 51
25 58 01 36 03 98 54 51 5F
25 4E 01 36 03 98 54 55 5F
25 9E 01 22 03 AC 54 51 51
25 6C 01 36 03 98 54 51 5F

With the trailing 3 bytes being:

54 55 5F
54 51 51
54 51 5F

For the record, I believe these are coming from "protocol A" (length 24) as discussed in the rc-switch library. The dip switches on this particular remote are set to "00010". I'm going to dig a little to figure out what is going on. Would be great to use this remote, as I now have a few of them lying around, and they seem to have a pretty decent range (when paired with a decent receiver, such as the one on the sonoff rf-bridge).

I used the rc-switch library's advanced receive example to get the following output for the button:

Decimal: 5592145 (24Bit) Binary: 010101010101010001010001 Tri-State: FFFFFFF0FF0F PulseLength: 308 microseconds Protocol: 1
Raw data: 9568,314,918,909,331,284,948,905,334,282,950,902,333,286,949,901,336,282,954,898,343,274,956,897,340,277,956,896,341,27
6,956,278,955,278,957,896,341,275,959,894,341,276,958,276,958,275,959,894,342,
xoseperez commented 6 years ago

Original comment by Biddster (Bitbucket: biddster, GitHub: biddster):


Good point. It's possible. I'll try to get to the bottom of it.

xoseperez commented 6 years ago

Could they be ON / OFF messages?

xoseperez commented 6 years ago

Original comment by Biddster (Bitbucket: biddster, GitHub: biddster):


I forgot to say. I have some 433 water sensors, one of those exhibits the same behaviour. Last digit of the code varies.

xoseperez commented 6 years ago

Original comment by Mike Hole (Bitbucket: mikehole, GitHub: mikehole):


Have you tried any other devices along with the pir?

xoseperez commented 6 years ago

Original comment by Biddster (Bitbucket: biddster, GitHub: biddster):


I see this too with my 433mhz pir.

I get mqtt messages with codes ending AB1310 and AB1319 when triggering the pir. That's easy enough to match though.

xoseperez commented 7 years ago

That's weird. You said they are supposed to work with the RF Bridge and the decoder is the same since that sits in the secondary microcontroller. ESPurna just listens to the codes it receives from the EFM8

xoseperez commented 7 years ago

Original comment by Mike Hole (Bitbucket: mikehole, GitHub: mikehole):


Yeah this is what I am getting from the MQTT packages from the RF bridge (using node red to show the codes). Open the door sensor and I get these codes from the door sensor.

snip_20171109094211.png

This is from the PIR once again totally inconsistent with the other codes.

xoseperez commented 7 years ago

These are codes intercepted by the RFBridge? These codes have 4 parts: 2 bytes sync length, 2 bytes low length, and 2 bytes high length. The final 3 bytes are the code itself and it should be unique for every button in the same remote (or for every device reporting a message, like the PIR). So my guess is that the PIR sends a 0C6E6E when movement detected and an 6E0C6E when stop detection (or the other way around). The door sensor is problably reporting 414AAA when it is triggered. But this should be further checked, some of the codes above are inconsistent (sync length should be aprox the same for every message from the same device).

xoseperez commented 6 years ago

ESPurna has to deal with what it receives from the EFM8. The only way to have more control or support different protocols is to change the firmware in the EFM8. Please refer to #386.