Honeywell ActivLink Doorbell (868 Mhz) #652
Comments
|
Test driver: https://github.com/Jc2k/rtl_433/blob/master/src/devices/honeywell_activlink.c Have tried with short_limit, long_limit and reset_limit exactly as in output and increasing and reducing them as well. Large reset_limit avoids lots of small empty events, but instead yields large (number of rows) empty events. |
|
Samples added here: merbanan/rtl_433_tests#201 |
|
PWM (ternary) looks right. Also looks like the sample data. The symbols are 480 us (120 samples @250K) long, Perhaps try the that's which works well. If you try which is OOK_PULSE_PWM_TERNARY with it doesn't work so well. |
|
Though i.e. |
|
I would like to buy this device as my doorbell for my home automation... do you think it’s will be add to the master branch ? |
|
Just use the |
|
I got a regular Honeywell doorbell. I don't think the signal can ben demodulate. It's is possiblie trap the signal ? I just want to trigger my home assistant. I am confuse about short, long, reset limit... can you help me. The doorbell have 3 type of rings (set with a tiny selector switch)... this is ring #2. |
|
The doorbell detailed by @Jc2k seems to be very similar to the North American 916.8 MHz model variants I've been playing with. The only difference seems to be the frequency used. I have a GitHub project started for the Honeywell Wireless Doorbell. Please let me know if you'd like to help with this effort! |
|
@klohner Looking promising! I don't have much (any!) spare time right now but you want me to check anything out with my devices let me know and i'll see what i can do. |
|
Great work on the decoding! Just to clarify: a "doorbell-style" device to me means a (very) dumb device, usually built on some x1527 variant chip with a fixed 24-bit "payload". |
|
@Jc2k @zuckschwerdt Thanks so much for the replies. Yes, these devices aren't really that "dumb" and I think a proper decoder for them would be useful. I've put together a quick form to submit signals at https://goo.gl/forms/SuxA3qgVRivXmNMf1 if anyone would like to help with my efforts. |
|
#898 adds support for this. @zuckschwerdt can you review the code? All samples decode fine. |
|
Support for this merged. Closing issue. |
I'm trying to add support for Honeywell Actilink doorbells.
I'm running rtl_433 with:
I'm expecting up to 2 packets from the doorbell - i believe the receiver potentially replies (the marketing material talks about a 'confidence LED' to indicate the button is working - the marketing doesn't make it clear whether it confirms the receiver got it or not. It might also be "forwarding" the event (again marketing material talks about range extending - 'Link two doorbells together to boost your range up to 400m.').
The analysis device picks out the following parameters:
So I took those parameters and added a new device. My callback just pretty prints the contents of the bitbuffer. Weirdly though instead of getting the same data as the auto-analysis pretty printed my callback seems to get called multiple times with bitbuffers that have 2 empty rows. If i increase the the reset_limit it can batch the packets together - and i'll get 2 lots of 25 rows that are empty.
I'm at a bit of a loss as to why the parameters detected automatically don't seem to work when plugged in manually.
Below is the full report it from the auto-analysis.
The text was updated successfully, but these errors were encountered: