rtl_433
rtl_433 copied to clipboard
merbanan
Device support for Kidde RF-SM-DC smoke detector
Kidde makes these smoke detectors which use 433MHz.
I have been trying to decode the signal, but do not see anything that looks obvious when doing the -S unknown so I tried button triggering the device while sampling for 15 sec:
kidde_RF-SM-DC_15s.zip
The signal captured has my two temperature sensors Acurite-986 and Acurite-606, but a "Megacode-Remote" shows up that I do not have and have never seen before, but the time it shows up is later than expected.
My best guess is the signal @1.947876s is the one I am after:
Detected OOK package @1.947876s
Analyzing pulses...
Total count: 130, width: 481.68 ms (120421 S)
Pulse width distribution:
[ 0] count: 98, width: 544 us [444;592] ( 136 S)
[ 1] count: 13, width: 372 us [300;420] ( 93 S)
[ 2] count: 8, width: 176 us [148;212] ( 44 S)
[ 3] count: 2, width: 76 us [76;80] ( 19 S)
[ 4] count: 6, width: 260 us [236;288] ( 65 S)
[ 5] count: 1, width: 48 us [48;48] ( 12 S)
[ 6] count: 1, width: 136 us [136;136] ( 34 S)
[ 7] count: 1, width: 108 us [108;108] ( 27 S)
Gap width distribution:
[ 0] count: 56, width: 4164 us [4052;4756] (1041 S)
[ 1] count: 67, width: 2096 us [2012;2496] ( 524 S)
[ 2] count: 4, width: 9116 us [8968;9364] (2279 S)
[ 3] count: 1, width: 6672 us [6672;6672] (1668 S)
[ 4] count: 1, width: 2760 us [2760;2760] ( 690 S)
Pulse period distribution:
[ 0] count: 56, width: 4636 us [4336;5176] (1159 S)
[ 1] count: 68, width: 2580 us [2112;2928] ( 645 S)
[ 2] count: 4, width: 9664 us [9512;9908] (2416 S)
[ 3] count: 1, width: 7208 us [7208;7208] (1802 S)
Pulse timing distribution:
[ 0] count: 98, width: 544 us [444;592] ( 136 S)
[ 1] count: 13, width: 372 us [300;420] ( 93 S)
[ 2] count: 8, width: 176 us [148;212] ( 44 S)
[ 3] count: 2, width: 76 us [76;80] ( 19 S)
[ 4] count: 6, width: 260 us [236;288] ( 65 S)
[ 5] count: 1, width: 48 us [48;48] ( 12 S)
[ 6] count: 1, width: 136 us [136;136] ( 34 S)
[ 7] count: 1, width: 108 us [108;108] ( 27 S)
[ 8] count: 56, width: 4164 us [4052;4756] (1041 S)
[ 9] count: 67, width: 2096 us [2012;2496] ( 524 S)
[10] count: 5, width: 9296 us [8968;10004] (2324 S)
[11] count: 1, width: 6672 us [6672;6672] (1668 S)
[12] count: 1, width: 2760 us [2760;2760] ( 690 S)
Level estimates [high, low]: 15974, 74
RSSI: -0.1 dB SNR: 23.3 dB Noise: -23.5 dB
Frequency offsets [F1, F2]: 4788, 0 (+18.3 kHz, +0.0 kHz)
Guessing modulation: No clue...
Googling I have found:
https://github.com/tofurky/kidde_cc1101
But looks like a different device from the same manufacturer.
Any suggestion for what to try next? Thanks!
All three signals look like Acurite weather sensors and not the typical alarm-thingie.
You would need to capture a clean sample. Remove the antenna to limit reception and put the device near.
Also use -s 1024k to widen the band, the smoke alarm might not be at exactly 433.92k.
But we already have a Kidde RF-SM ACDC sample here: https://github.com/merbanan/rtl_433_tests/tree/master/tests/KIDDE_RF-SM-ACDC
it's the typcial pattern: lots of repeats with just ~24 bit fixed ID in them.
This should work: rtl_433 -X 'n=name,m=OOK_PWM,s=400,l=800,r=2000'
Thanks for the pointers! I managed to find the signal at 434.37MHz. Looks similar to the sample you already had in the tests folder - I didn't see that earlier.
Doing rtl_433 -X 'n=name,m=OOK_PWM,s=400,l=800,r=2000' gives the repeating data:
ff90e0 [ID 8bit switch is 11110000] = 11111111 10010000 11100000
f9f0bc [value from rtl_433_test file] = 11111001 11110000 10111100
Not much there... My capture file: g001_434M_1024k.zip
Interesting about the switches. If you flip one at a time and compare we might get insight about the mapping.
But really you just want to set any pattern, then capture the code and on reception recognize that. Or e.g. add ,match={22}ff90e0 to just receive your code.
So the bit count seems a bit weird. Trying to figure out decoding because I think the message will change depending on whether test, alarm, battery, etc.
I get the following when doing rtl_433 -X 'n=kidde,m=OOK_PWM,s=400,l=800,r=2000' on the cap file (repeated ~every 50ms) [id setting on device]:
[11110000] {21}ff90e0 [from above]
[11111111] {18}f8420
[00000000] {25}fffc3f8
[10000000] {24}fff43f
It isn't actually PWM, it's DMC. There is a sync, then the ID and finally more data bits, see this BitBench.
The OOK looks like this, note the (de-)sync in front.
btw. why did you record at 256k rate? The default of 250k would be much more common.
Thanks! The 256k was power of 2… old habit from ADCs/fft and trying to get a better sample. If it makes a difference, I can resample.
On Sun, Nov 20, 2022 at 10:34 AM Christian W. Zuckschwerdt < @.***> wrote:
btw. why did you record at 256k rate? The default of 250k would be much more common.
— Reply to this email directly, view it on GitHub https://github.com/merbanan/rtl_433/issues/2240#issuecomment-1321176453, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH2SKOZACN4UL3RRTREI43WJJHHRANCNFSM6AAAAAASFOPRC4 . You are receiving this because you authored the thread.Message ID: @.***>
Incidentally I just today added DMC decoding for flex (#2241). So this will work to get the decoded data:
rtl_433 -R 0 -X 'n=name,m=OOK_PCM,s=400,l=400,g=1000,r=2000,decode_dm'
Awesome! Thanks. I just pulled your DMC decoding and now get the following [device ID setting]:
[11110000] {4}1,{25}07bfc78
[11111111] {4}1,{25}7fbfbf8
[00000000] {4}1,{25}003fc00
[10000000] {4}1,{25}00bfc08
I guess there is an extra bit (25 vs. 24).
I guess there is an extra bit (25 vs. 24).
Ah, yes. Remove the first bit, then bytes line up nicely. Being DMC that first bit can have data in it, but I guess they choose to use it as start-bit only.
I am just learning your amazing tools at triq.org, thanks for this! (did not realize I could zoom on the pulse train for the details!)
Looking at the pulse, I see the output of the DMC decoder adds 4 bits at the end 1000:
For example using the bitbench SYNC:4h ?b ID:8b ?8b ?7b ?4b:
[11111111] 07fbfbf8 = SYNC:0 ?0 ID:11111111 ?01111111 ?0111111 ?1000
vs.:
Similarly,
[00000000] 0003fc00 = SYNC:0 ?0 ID:00000000 ?01111111 ?1000000 ?0000
vs.
I can ignore them, but thought it should be consistent. Of course, it is very likely I am missing something, like the OOK settings (using rtl_433 -R 0 -X 'n=name,m=OOK_PCM,s=400,l=400,g=1000,r=2000,decode_dm').
That's a representation problem when using nibbles (for every four bits), i.e. the length will always be a multiple of 4 (or 8 even when printing full bytes).
For BitBench a 07fbfbf8 is seen as {32}07fbfbf8 to clearly exclude the phantom bits at the end use {29}07fbfbf8
Just curious if there has been any more success on this? I just got the RF-SM-AC and a couple RF-SM-DC units to expand coverage in our finished basement where we had a (thankfully false-alarm) non-interlinked one fail (and couldn't hear it upstairs in bedrooms)
I see Kidde claims its 434.3 MHz, and I know there's somehow "coded" the 8-bit "channel/system ID" so it won't go off when adjacent houses have the same alarms. https://www.kidde.com/home-safety/en/us/support/help-center/browse-articles/articles/how_wireless_smoke_alarms_work.html
My guess is 434.3 is near enough to 433.92 that one SDR could "hear" both...and I would be slightly curious to see this working so that I could pull the data into Home Assistant.
I didn't successfully get a capture of the first two I installed but when the 3rd arrives I will give it another try...but I don't want to torture the dogs TOO much with the house beeping and screaming at them. EDIT: Still no success capturing a signal with the last one I installed and tested...but open to ideas for tips maybe another day I could give another try if needed.
./rtl_433 -R 0 -X 'n=name,m=OOK_PCM,s=400,l=400,g=1000,r=2000,decode_dm' -f 434300000
I successfully got a capture of my real alarms: smokes_cap_code_00111011.txt
Also captured some working (replay sets off alarms on set channel) RF samples with a Flipper Zero if that helps with the reverse-engineering of the signal allowing others to generate a known-working alarm signal in the most obvious (to me) patterns: https://github.com/mmiller7/flipper/tree/main/subghz/Kidde%20RM-SM-DC%20Smoke%20Alarm
Code 00000000: smokes_cap_00000000.txt
Code 00001111: smokes_cap_00001111.txt
Code 11111111: smokes_cap_11111111.txt
I'm guessing the 'data' field that repeats the most frequently may be the actual correct payload for each?
Using this command to "weed" some of the invalid looking one-character and only-happened-infrequently data payloads
grep data filename.txt | egrep -v ': [0-9a-z](, )?$' | sort | uniq -c | egrep -v '^[ ]+[0-9] data'
00000000:
352 data : 003fc00 <-- I think this is the real data payload?
14 data : 007f80
13 data : 02
14 data : fc00
00001111:
12 data : 07f70
23 data : 0fee0
423 data : 783fb80 <-- I think this is the real data payload?
12 data : c1fdc0
25 data : f07f70
15 data : fb80
11111111:
340 data : 7fbfbf8 <-- I think this is the real data payload?
11 data : bf8
20 data : dfdfc
19 data : fbf8
11 data : fefe
14 data : ff7f7f
00111011:
213 data : 6e3fae0 <-- I think this is the real data payload?
90 data : 88,
@loopy321 @mmiller7 Where are we on this? Does it work better with current git master? What has to happen to close the issue as solved? Do one of you want to make a PR?
@loopy321 @mmiller7 Where are we on this? Does it work better with current git master? What has to happen to close the issue as solved? Do one of you want to make a PR?
Not quite ready for a PR. Will try to take another look this weekend.
I don't currently understand enough of how this works to write a fix myself, but I could run a test build to test one.