Add support for Honeywell 5890PI

[fanlessfan]

I have honeywell 5890PI motion sensor not supported yet. I recorded the files and create a pull request in rtl_433_test, but I don't know how to upload the files.

http://library.ademconet.com/MWT/fs2/5890PI/5890PI-Data-Sheet.PDF

Could anyone give me some instructions?

thx

[zuckschwerdt]

Upload the files to a comment on that PR and I'll merge it.

[fanlessfan]

Hello, @zuckschwerdt, Thanks for your response. I am new to the github and cant find a way to upload files. Could you give me a clue? Anyway, the files in the link below. https://1drv.ms/f/s!AuO6KkRWpEjPgddwKT8BseEim-J8BQ

thx

[fanlessfan]

Hi @zuckschwerdt , I got the files attached to rtl_433_test PR. Please take a look. thx

[zuckschwerdt]

works, I'll test and merge this probably tomorrow.

[zuckschwerdt]

Could be related to #747 (but unlikely with the ASK).

Samples merged to https://github.com/merbanan/rtl_433_tests/tree/master/tests/honeywell_5890PI

Interestingly this signal is true ASK not OOK. Our demod currently does not handle this well. A good example to improve things!

[merbanan]

@zuckschwerdt I came to the conclusion that the signal was PSK modulated quite certainly. Can you take another look? I got small spikes in the fsk output while looking at the signals in sigrok. Those should be there in PSK modulated signals but not in ASK modulated signals. Unless the ASK is not continuous phase which I did not think about.

[zuckschwerdt]

Different issue/samples perhaps? I didn't merge the g001 and g006 which where plain Manchester, probably TPMS. The rest show two distinct A levels, about 30% and 100%, encoding is Manchester.

[zuckschwerdt]

The phase isn't continuous, but wouldn't assume that to be data.

[merbanan]

A min/max tracker should be able to make pulses of this. Maybe we need a complete overhaul of the processing path. To bad the signal detector in the research for a new fsk demod is performing poorly. Otherwise all modes OOK/ASK and FSK could be combined.

[merbanan]

Anyway with samples we could at least do something about it.

[pbendersky]

I have those sensors as well. I'd be glad to help, but I'm not sure how... If I can capture anything useful, let me know.

[klohner]

The FCC filing for this device has lots of useful data including the message format and this text in the Circuit Description:

"The data output is phase-encoded Manchester that has inherent 50% duty cycle and consists of 64 bits per word sent at a nominal data rate of 3.7 kb/s (3.2kb/s min to 4.2kb/s max)."

[klohner]

I took another look at these samples and made some headway. I think the signals are fine, it's just that these sample recordings are blown out.

Here's a view in URH cleaned up as best I could:

By specifying a -Y level=-1 detection level in `rtl_433', it'll pick up the symbols and decode successfully. I think this is likely a signal quality issue and not a rtl_433 issue.

$ rtl_433 -f 250k -r "g002_344.975M_250k.cu8" -Y level=-1 -X n=5890PI,m=OOK_MC_ZEROBIT,s=137,r=500,bits=64

time      : @0.206764s
model     : 5890PI       count     : 1             num_rows  : 1             rows      :
len       : 64           data      : 00017cceb59f7d51
codes     : {64}00017cceb59f7d51

time      : @0.206764s
model     : 5890PI       count     : 1             num_rows  : 1             rows      :
len       : 64           data      : 00017cceb59f7d51
codes     : {64}00017cceb59f7d51

time      : @0.206764s
model     : 5890PI       count     : 1             num_rows  : 1             rows      :
len       : 64           data      : 00017cceb59f7d51
codes     : {64}00017cceb59f7d51

time      : @0.206764s
model     : Honeywell-Security                     id        : 3314a
channel   : 8            event     : 60            state     : closed        alarm     : 2             tamper    : 1             battery_ok: 1             heartbeat : 0

time      : @0.206764s
model     : Honeywell-Security                     id        : 3314a
channel   : 8            event     : 60            state     : closed        alarm     : 2             tamper    : 1             battery_ok: 1             heartbeat : 0

time      : @0.740468s
model     : 5890PI       count     : 1             num_rows  : 1             rows      :
len       : 64           data      : 00017cceb59f7d51
codes     : {64}00017cceb59f7d51

time      : @0.740468s
model     : Honeywell-Security                     id        : 3314a
channel   : 8            event     : 60            state     : closed        alarm     : 2             tamper    : 1             battery_ok: 1             heartbeat : 0

$ rtl_433 -y "{64}00017cceb59f7d51"

time      : 2020-04-30 16:47:11
model     : Honeywell-Security                     id        : 3314a
channel   : 8            event     : 60            state     : closed        alarm     : 2             tamper    : 1             battery_ok: 1             heartbeat : 0

[merbanan]

Well as you see the amplitude never go down to 0. The current code does not handle that very well. I am quite sure you can tune the level parameter for one specific sensor. The problem is if you have many of them that needs different levels depending on distance from the receiver the battery or what ever. As always I do have some ideas on how to support this but I currently don't have the time to try to implement it.

[gdt]

@fanlessfan What's the status of this issue and path forward? Can you test with current git master? A lot has been improved.

[gdt]

@fanlessfan We are still awaiting updated test and status. I am marking this inactive.