Vivint DW11 and some 2gig motions.

[clsferguson]

So I have been trying to get some vivint DW11 sensors workings, they are basically DW10 sensors from my understanding. But the present build of rtl_433 does not see them functioning under protocol 70.

My googlefu lead me to #746

I found this comment

With that I can see the door sensors and the motion sensor send things. but i have no idea how to decipher it. That is beyond me.

just a snippet from a door sensor {"time" : "2020-01-11 13:52:17", "model" : "2gigdw10-re208", "count" : 1, "num_rows" : 1, "rows" : [{"len" : 80, "data" : "7a029518012bd3fb5fd3"}], "codes" : ["{80}7a029518012bd3fb5fd3"]} A motion. {"time" : "2020-01-11 13:10:45", "model" : "2gigdw10-re208", "count" : 1, "num_rows" : 1, "rows" : [{"len" : 48, "data" : "447d9100b060"}], "codes" : ["{48}447d9100b060"]}

I ran this in powershell, could have probably changed the model name though .\rtl_433_64bit_static.exe -M newmodels -f 344985000 -g 25 -p 14 -F json -R 0 -X '2gigdw10-re208:OOK_MC_ZEROBIT:150:150:300,invert,preamble=ffe' -v

am I just missing something maybe?

[zuckschwerdt]

The compatible timing is a good sign that it's something like the existing Honeywell protocol. Packet length is different, the preamble seems to fit though. It's best if you record some samples (-S all), verify a clean signal with http://triq.net/iqs and upload here as zip. We can then take a look what's in there.

[zuckschwerdt]

Current decoder code for reference: https://github.com/merbanan/rtl_433/blob/master/src/devices/honeywell.c

[clsferguson]

vivint-dw11+2gig-pir1.zip

[zuckschwerdt]

The samples look good. I've enhanced the 2Gig support with 9c23ceb. For the DW11 we need to figure out the payload and checksum. You can get the output with -vv -R 70. Just collect lots of codes, annotate them and share a BitBench link.

[clsferguson]

Do I need to build a new version of rtl_433 first? Or will the current version work?

[zuckschwerdt]

I've just triggered a new build. It's available now on https://bintray.com/chzu/dist/rtl_433

[clsferguson]

dw11.zip

I attached the annotated output. i opened and closed the sensor 5 times, then did the tamper 5 times. The bitbench link was too long it said. I probably could have edited the output down, but I'm not exactly sure if you need the duplicates or not. it's just a text file in there.

[zuckschwerdt]

It's good to know there are identical duplicates. That way we can assume the codes are valid. Not needed for the BitBench, compact is better. It looks like the first changing bytes are just counting up. I don't see any correlation to tamper/open. The last changing bytes could be a checksum or encrypted data, not sure. This is not going to be easy to make sense of.

[clsferguson]

I wonder if the vivint system is like a handshake or something.

[zuckschwerdt]

I'd say vivint and 2Gig are just resellers. The product is the DW11. In a home security product you really don't want other people to know if you just opened or closed something. It's a good idea to encrypt the status payload. That could be happening here. If you have the patience to record really many messages then chances are good that we can understand the protocol. We are looking for pattern and collisions, thus we need at least 100 or more messages, maybe a few 1000.

If I was debugging this: Put the sensor on a slow rotating motor so it goes open and close every 2 seconds or so. Then run that over night and record 10.000 messages easy ;) But it would be important to know which messages are "open" and which are "close" -- so the setup needs to be robust ;) Perhaps rig it so open stays 2 seconds and close 3 seconds, then you can see the state in the timings.

[clsferguson]

ok. this is something I will work on. I have to go to work today and will be out of town for a bit. but when i get a chance I will try and build something for this.

side note/qurestion; I'm using the home assistant 433 add on,trying to put all my sensors in it. But my system is a mixed bag of GE and 2gig. they operate on two different frequencies. I have a RE124 translator for the alarm panel. But the translator doesn't see the DW11 sensors I just picked up (for cheap). Or I would be trying to learn the translator as well, lol. So my solution is to use the hop function with the 433 software. But the fastest it can hop by the looks of it if 1 second. Do you think you could make it hop faster then that? like 0.5 seconds? It seems 1 second is just a tad to slow to catch every event. It's a good thing most my sensors seem to pulse signals for up to almost 1 second, lol.

thanks for this software by the way.

[zuckschwerdt]

Which frequencies are that? Hoping generally is not a good solution for important (security!) sensors. It's better for e.g. weather sensors.

[clsferguson]

ge 319500000 and 2gig 344985000

This is more for automations then security. my monitored alarm panel handles the security.

[zuckschwerdt]

Oh, ok. Those are really too far apart for sample rate ;) Maybe you can grab a second receiver, the cheap ones cost less than a single sensor. Just run rtl_433 twice then.

[clsferguson]

think i could run the two instances of the addon in hassio on a pi?

[zuckschwerdt]

Performance wise? On a Raspberry Pi 3 an instance of rtl_433 uses 35% of a core. Should allow to run 12 instances then ;)

[clsferguson]

No I just mean like can the addon itself launch two. I know it's not your thing, but i think i would have to try and modify the addon code to recognize 2 devices. Got some learning to do, lol.

[zuckschwerdt]

Sorry, don't know anything about an addon. I run a couple of rtl_433 with MQTT output and my HASS picks up messages from MQTT. E.g.

   - platform: mqtt
     state_topic: 'sensor/rtl_433/Bresser_3CH_sensor/1/temperature'
     name: 'Bresser 1 Temperature'
     unit_of_measurement: '°C'
     value_template: "{{ value | round(1) }}"
   - platform: mqtt
     state_topic: 'sensor/rtl_433/Bresser_3CH_sensor/1/humidity'
     name: 'Bresser 1 Humidity'
     unit_of_measurement: '%'
     icon: mdi:weather-rainy

[zuckschwerdt]

The DW11 has an external input for a contact, see https://fccid.io/2AAAS-DW02/User-Manual/Users-Manual-2437221 No need to build a contraption, just switch it with a Relay, maybe MOSFET or Open-Collector (needs check beforehand).

[clsferguson]

Okay. I set it up on a timed relay. the file is 700mb in a zip. it will be located here on my onedrive.

the relay was open for 25 seconds. then closed for 5 seconds. It seemed to store 2 files every time it closed and then another 2 files every time it opened.

[clsferguson]

Okay the file is finally available.

[zuckschwerdt]

It still shows "The folder is empty" for me. Do I need to sign in?

[clsferguson]

You shouldn't need to. Maybe. Let me see what I can figure out.

[clsferguson]

try this one?

[zuckschwerdt]

Very clean data, thanks. I've collected, parsed, and cleaned the data. Now to make deductions…

vivint_dw11_6080_state.zip

[clsferguson]

Alright here is my first deduction.

there is a minor slip in the parse code I think. So I also think my deduction is not invalid because of that.

edit 1: That pattern holds up through out the file. some of the open/closed things get flipped but still, looking at the timestamps you can tell that.

edit 2: looking at the last text file that we did with a few samples it looks the odd/even is way it tells the door is open or closed.

I used this to tell what is odd or even in the hex. http://hextodecimal.com/index.php

edit 3: Well maybe not.. The flipping the tamper button in the last text file that hex still counts up.

[zuckschwerdt]

A guess would be that the second and third byte form a 16-bit counter, going up for each message sent. That counter could be used to derive a crypto key, the fourth byte then would be encrypted with that key and should contain the state. The last two bytes should be a checksum (CRC-16, as with other Honeywell sensors), but it could be that it's only the last byte.

[clsferguson]

So I tried this. But I have no clue what i'm doing lol. it kinda decoded it.

[zuckschwerdt]

I don't think AES is used, deriving a key (and perhaps also IV) is too weak. I would rather guess it's a CRC over the counter that provides an XOR key.

[merbanan]

7a 5e de [08] 01 2e 5b 30 db bc OPENED

Only 2 bits are set in this low nibble (bits 2 and 3). 0,4,8 and C.

That speaks against it being an XOR of the previous counter. The high nibble has full range.

[zuckschwerdt]

I noticed that oddity too, effectivly the range there is only 6 (upper) bits.

[merbanan]

But the previous observation seems to hold a bit.

7a 58 [00]  18  01 2e 5b 30 7f 45  CLOSED
7a 58 [72]  18  01 2e 5b 30 49 4c  CLOSED
7a 58 [84]  18  01 2e 5b 30 8c 4a  CLOSED
7a 58 [c6]  18  01 2e 5b 30 c9 5c  CLOSED
7a 58 [df]  18  01 2e 5b 30 ea e2  OPENED
7a 58 [e6]  18  01 2e 5b 30 fd d7  CLOSED

When the low counter byte is even the state is closed and when it is odd it is open.

7a 55 40  00  01 2e 5b 30 b3 61  CLOSED
7a 55 41  00  01 2e 5b 30 06 a1  OPENED

So while I don't think the real state is the counter low byte lsb it just follow the state in lock step. But here we can see that the counter cancels out what we assume is the state. If we make the guess that the open/closed state is the lsb (bit 0) of the low nibble and bit 1 for some reason always is 0 we are back to XOR of the counter.

To verify this we need to increase the counter from 5 -> 6 and observe if the pattern changes. So can we get ca 300 more switches? That should trip the counter and it would confirm the hypothesis. Not everything adds up but it would be interesting to see what happens at least.

[clsferguson]

Yeah I can run the thing again

Thanks, Cory

[merbanan]

I tried to brute force the last 2 bytes, did not work.

[clsferguson]

edit: I have it recording into a csv file.

Is there a better command line to run to record this data? Straight to text file?

[zuckschwerdt]

rtl_433 -vv -R 70

should print only the code. But it's missing the timestamp :/ Perhaps insert a small section above https://github.com/merbanan/rtl_433/blob/master/src/devices/honeywell.c#L82

    decoder_output_data(decoder, data_make(
            "model",        "", DATA_STRING, "Honeywell-DW11", NULL));

[clsferguson]

more dw11.zip

more samples in json

[merbanan]

My guess did not hold. The "state" byte still only use 6 bits. But now you actually can look at the counter lsb to figure out if the sensor is open or closed.

[merbanan]

I am out of ideas. You probably need to look at the sender/receiver firmware.

[zuckschwerdt]

It will take time to try, but there are still options. I'd like to have a go at the checksum first. If the checksum is over the unencrypted bytes (doesn't seem to be over the encrypted ones), then we can brute force the unencrypted payload :)

[Sleepybear]

Has there been any update on this? I am trying to connect to a DW11 device as well as using the 2GIGTAKE 345 takeover device which also broadcasts on the same signal (it seems to also send the honeywell but for some reason is not sending me the closed signals on some of the sensors on the honeywell protocol)

[NorthernMan54]

Just to add to the conversation I recently acquired a bunch of v-dw11-345 contact sensors and spent a little bit time looking into the technology and protocol. I looked at the FCC internal pictures and am thinking the onboard controller is from the TI MSP430G2x5 series, this was based on the chip package and markings - 'g2452' and TI.

After playing with my SDR for a bit, I had recorded some signal samples with this command line

rtl_433 -f 344988000 -vv -R 70

7a a3 18 c8 01 05 72 36 98 63 
7a a3 18 ec 01 05 72 36 94 b4 

7a a3 19 9c 01 05 72 36 bb 25 
7a a3 19 bc 01 05 72 36 b3 ea 

7a a3 1a 7c 01 05 72 36 49 c2 
7a a3 1a 58 01 05 72 36 45 15 

7a a3 1b d4 01 05 72 36 7c cd 
7a a3 1b f0 01 05 72 36 70 1a 

7a a3 1c 18 01 05 72 36 e2 0b 
7a a3 1c 38 01 05 72 36 ea c4 

7a a3 1d d8 01 05 72 36 bf 20 
7a a3 1d f8 01 05 72 36 b7 ef 

7a a3 1e b4 01 05 72 36 88 5c 
7a a3 1e 94 01 05 72 36 80 93 

7a a3 1f 08 01 05 72 36 e0 ce 
7a a3 1f 28 01 05 72 36 e8 01 

7a a3 20 48 01 05 72 36 c3 85 
7a a3 20 68 01 05 72 36 cb 4a 

7a a3 21 d4 01 05 72 36 28 db 
7a a3 21 f0 01 05 72 36 24 0c 

7a a3 22 50 01 05 72 36 2d 50 
7a a3 22 74 01 05 72 36 21 87 
7a a3 23 d0 01 05 72 36 8b c0 
7a a3 23 f4 01 05 72 36 87 17 

7a a3 24 44 01 05 72 36 7d 88 
7a a3 24 60 01 05 72 36 71 5f 
7a a3 25 28 01 05 72 36 ed f7 
7a a3 25 08 01 05 72 36 e5 38 
7a a3 26 a8 01 05 72 36 f4 07 
7a a3 26 8c 01 05 72 36 f8 d0 

7a a3 27 88 01 05 72 36 c2 0b 
7a a3 27 a8 01 05 72 36 ca c4 
7a a3 28 b0 01 05 72 36 c2 be 
7a a3 28 94 01 05 72 36 ce 69 
7a a3 29 a4 01 05 72 36 2a e3 
7a a3 29 84 01 05 72 36 22 2c 
7a a3 2a 98 01 05 72 36 65 42 
7a a3 2a bc 01 05 72 36 69 95 
7a a3 2b 38 01 05 72 36 b2 3e 
7a a3 2b 18 01 05 72 36 ba f1 
7a a3 2c 68 01 05 72 36 72 66 
7a a3 2c 48 01 05 72 36 7a a9 
7a a3 2d 8c 01 05 72 36 13 3a 
7a a3 2d ac 01 05 72 36 1b f5 
7a a3 2e a4 01 05 72 36 60 46 
7a a3 2e 84 01 05 72 36 68 89 
7a a3 2f f8 01 05 72 36 53 53 
7a a3 2f d8 01 05 72 36 5b 9c

When I recorded the signal, I was moving the magnet close to the device ie closed, then immediately moving it away ie open. What appears to happen is that the transmitted signal maintains the same counter, but updates the device status, which was an interesting finding. Within a single timestamp I was moving the magnet close than away.

Based on spending a few hours doing signal analysis, the second and third byte 'a3 2f' appears to be counter as previously reported, byte 4, a encoded status, bytes 5,6,7,8 appear to be a deviceid ( I played with two devices, and the difference in byte 8 between two devices aligned with the delta on the TX ID on the sticker, the numbers had a difference of 161 ). And Bytes 9 and 10 are likely a CRC check.

[zuckschwerdt]

Nice data! Could be that it's two different checksum fields: only the last byte has high entropy. Or it could be a large sum with MSB LSB bytes. You observed lots of bit flips in bit 26 and the second to last checksum always xor's by 0x08. For bit 23 (only one occurence) it's 0xbe.

[NorthernMan54]

I'm learning the bitbench tool, so please bear with me as I work thru this. This is a link to data from another device I have.

So far I have been using this pattern to analyze the data hh COUNT:16d STATUS:bb b bbb bb ID:32d CRC:hh CRC:hh

One thing I was able to figure out, is that if you add 143,222,784 to the ID ( bytes 5,6,7,8) you get the devices TX ID.

I do see what your seeing in bit 26, now to see if I can determine a pattern.

[NorthernMan54]

More data to share, spent time today looking at the data for the tamper and contact sensor, and they appear to be bit flips on bit 25 ( tamper ) and bit 24 ( contact ). And looking at work on the Honeywell contact sensor, the bit pattern aligns with my findings - honeywell.c

I think I see something interesting with the data this time ( or something I didn't notice before ), there is a couple of examples where the just a single bit changes.

This is series of flips on the tamper sensor, first is tamper closed, and second is tamper open - BitBench

[TAMPER - bit 25]
{80} 7a ac 56 e8 01 05 72 fa 01 25 [Closed]
{80} 7a ac 56 ac 01 05 72 fa 0c a6 [Open]

{80} 7a ac 57 24 01 05 72 fa 29 05 [???]
{80} 7a ac 57 a4 01 05 72 fa 22 36 

{80} 7a ac 58 fc 01 05 72 fa 23 d7 
{80} 7a ac 58 78 01 05 72 fa 2c fc 

{80} 7a ac 59 48 01 05 72 fa 43 75 
{80} 7a ac 59 cc 01 05 72 fa 4c 5e 

{80} 7a ac 5a c8 01 05 72 fa 13 06 [???]
{80} 7a ac 5a 48 01 05 72 fa 18 35 

{80} 7a ac 5b 18 01 05 72 fa 17 a8 
{80} 7a ac 5b 9c 01 05 72 fa 18 83 

{80} 7a ac 5c e4 01 05 72 fa 4b 44 [???]
{80} 7a ac 5c 64 01 05 72 fa 40 77 

{80} 7a ac 5d 1c 01 05 72 fa dc 75 
{80} 7a ac 5d 98 01 05 72 fa d3 5e 

{80} 7a ac 5e 18 01 05 72 fa 69 6e [???]
{80} 7a ac 5e 98 01 05 72 fa 62 5d 

{80} 7a ac 5f 4c 01 05 72 fa 2b 68 
{80} 7a ac 5f c8 01 05 72 fa 24 43 

{80} 7a ac 60 00 01 05 72 fa 8f 08 [???]
{80} 7a ac 60 80 01 05 72 fa 84 3b 

{80} 7a ac 61 dc 01 05 72 fa ce 0d [???]
{80} 7a ac 61 5c 01 05 72 fa c5 3e 

{80} 7a ac 62 38 01 05 72 fa ab 92 
{80} 7a ac 62 bc 01 05 72 fa a4 b9 

{80} 7a ac 63 88 01 05 72 fa b6 0b 
{80} 7a ac 63 0c 01 05 72 fa b9 20 

{80} 7a ac 64 ac 01 05 72 fa c0 d9 
{80} 7a ac 64 28 01 05 72 fa cf f2 

{80} 7a ac 65 cc 01 05 72 fa 25 ad [???]
{80} 7a ac 65 4c 01 05 72 fa 2e 9e 

{80} 7a ac 66 5c 01 05 72 fa 04 98 [???]
{80} 7a ac 66 dc 01 05 72 fa 0f ab 

{80} 7a ac 67 60 01 05 72 fa bd da 
{80} 7a ac 67 e4 01 05 72 fa b2 f1 

{80} 7a ac 68 68 01 05 72 fa c4 e6 
{80} 7a ac 68 ec 01 05 72 fa cb cd 

{80} 7a ac 69 a8 01 05 72 fa 99 cd [???]
{80} 7a ac 69 28 01 05 72 fa 92 fe 

{80} 7a ac 6a ec 01 05 72 fa 0d 8e [???]
{80} 7a ac 6a 6c 01 05 72 fa 06 bd

This is series of flips on the contact sensor, first is contact closed, and second is contact open -

[Contact - bit 24 ]
{80} 7a ac 57 24 01 05 72 fa 29 05 [??? Closed]
{80} 7a ac 57 a4 01 05 72 fa 22 36 [Open]

{80} 7a ac 58 fc 01 05 72 fa 23 d7 
{80} 7a ac 58 78 01 05 72 fa 2c fc 

{80} 7a ac 59 48 01 05 72 fa 43 75 
{80} 7a ac 59 cc 01 05 72 fa 4c 5e 

{80} 7a ac 5a c8 01 05 72 fa 13 06 [???]
{80} 7a ac 5a 48 01 05 72 fa 18 35 

{80} 7a ac 5b 18 01 05 72 fa 17 a8 
{80} 7a ac 5b 9c 01 05 72 fa 18 83 

{80} 7a ac 5c e4 01 05 72 fa 4b 44 [???]
{80} 7a ac 5c 64 01 05 72 fa 40 77 

{80} 7a ac 5d 1c 01 05 72 fa dc 75 
{80} 7a ac 5d 98 01 05 72 fa d3 5e 

{80} 7a ac 5e 18 01 05 72 fa 69 6e [???]
{80} 7a ac 5e 98 01 05 72 fa 62 5d 

{80} 7a ac 5f 4c 01 05 72 fa 2b 68 
{80} 7a ac 5f c8 01 05 72 fa 24 43 

{80} 7a ac 60 00 01 05 72 fa 8f 08 [???]
{80} 7a ac 60 80 01 05 72 fa 84 3b 

{80} 7a ac 61 dc 01 05 72 fa ce 0d [???]
{80} 7a ac 61 5c 01 05 72 fa c5 3e 

{80} 7a ac 62 38 01 05 72 fa ab 92 
{80} 7a ac 62 bc 01 05 72 fa a4 b9 

{80} 7a ac 63 88 01 05 72 fa b6 0b 
{80} 7a ac 63 0c 01 05 72 fa b9 20 

{80} 7a ac 64 ac 01 05 72 fa c0 d9 
{80} 7a ac 64 28 01 05 72 fa cf f2 

{80} 7a ac 65 cc 01 05 72 fa 25 ad [???]
{80} 7a ac 65 4c 01 05 72 fa 2e 9e 

{80} 7a ac 66 5c 01 05 72 fa 04 98 [???]
{80} 7a ac 66 dc 01 05 72 fa 0f ab 

{80} 7a ac 67 60 01 05 72 fa bd da 
{80} 7a ac 67 e4 01 05 72 fa b2 f1 

{80} 7a ac 68 68 01 05 72 fa c4 e6 
{80} 7a ac 68 ec 01 05 72 fa cb cd 

{80} 7a ac 69 a8 01 05 72 fa 99 cd [???]
{80} 7a ac 69 28 01 05 72 fa 92 fe 

{80} 7a ac 6a ec 01 05 72 fa 0d 8e [???]
{80} 7a ac 6a 6c 01 05 72 fa 06 bd 

[zuckschwerdt]

bitbrk from revdgst can quickly check for single bit changes ("if only a single bit changes between messages, what is the effect on the checksum?"). Omit the last byte to check the first checksum. Here is what we get:

18 : 7a ac 4a 6c 01 05 72 fa 32  ->  7a ac 6a 6c 01 05 72 fa 86  |  b4
19 : 7a ac 2a 10 01 05 72 fa b0  ->  7a ac 3a 10 01 05 72 fa e4  |  54
19 : 7a ac 42 54 01 05 72 fa 73  ->  7a ac 52 54 01 05 72 fa 9c  |  ef
19 : 7a ac 42 10 01 05 72 fa 7e  ->  7a ac 52 10 01 05 72 fa 91  |  ef
21 : 7a ac 2a 10 01 05 72 fa b0  ->  7a ac 2e 10 01 05 72 fa aa  |  1a
22 : 7a ac 41 40 01 05 72 fa 14  ->  7a ac 43 40 01 05 72 fa d9  |  cd
22 : 7a ac 41 00 01 05 72 fa 1d  ->  7a ac 43 00 01 05 72 fa d0  |  cd
22 : 7a ac 44 cc 01 05 72 fa 0c  ->  7a ac 46 cc 01 05 72 fa 7a  |  76
22 : 7a ac 44 8c 01 05 72 fa 05  ->  7a ac 46 8c 01 05 72 fa 73  |  76
22 : 7a ac 4d 78 01 05 72 fa 57  ->  7a ac 4f 78 01 05 72 fa e3  |  b4
22 : 7a ac 68 ec 01 05 72 fa cb  ->  7a ac 6a ec 01 05 72 fa 8d  |  46
23 : 7a a3 26 a8 01 05 72 36 f4  ->  7a a3 27 a8 01 05 72 36 4a  |  be
23 : 7a ac 3c 1c 01 05 72 fa fd  ->  7a ac 3d 1c 01 05 72 fa b1  |  4c
23 : 7a ac 3c 5c 01 05 72 fa f4  ->  7a ac 3d 5c 01 05 72 fa b8  |  4c

from here on the pattern looks sane, few examples only

24 : 7a ac 57 24 01 05 72 fa 29  ->  7a ac 57 a4 01 05 72 fa 22  |  0b
24 : 7a ac 5a c8 01 05 72 fa 93  ->  7a ac 5a 48 01 05 72 fa 98  |  0b
25 : 7a ac 2a 50 01 05 72 fa b9  ->  7a ac 2a 10 01 05 72 fa b0  |  09
25 : 7a ac 2b 80 01 05 72 fa 0d  ->  7a ac 2b c0 01 05 72 fa 04  |  09
26 : 7a a3 19 9c 01 05 72 36 bb  ->  7a a3 19 bc 01 05 72 36 b3  |  08
26 : 7a a3 1c 18 01 05 72 36 e2  ->  7a a3 1c 38 01 05 72 36 ea  |  08

[NorthernMan54]

Thinking about this further, bits 24 to 29 are likely the sensor status just obfuscated with a reversible bit flip like XOR. This is based on bit 26 consistently flipping in the reed sensor test. And based on the sensor being tested, we know the answer to the reversal. In this example, the value being transmitted was 11111000 which should represent a sensor value of 00100000 ( I wonder if open is zero or one ? )

7a a3 2f f8 01 05 72 36 53 53 | 11111000 | 00100000 | D8
7a a3 2f d8 01 05 72 36 5b 9c | 11011000 | 00000000 | D8

[mikedm139]

I have a couple several of these DW11 sensors (both all DW11 28-000002-001 REV-D circuit boards) that I would love to be able to read. I'm happy to contribute. What's the best way to jump in?

-ETA- I did a run of cycling the tamper switch on one of my DW11s and compiled the resulting generated codes with annotations into a gist. I hope to find time to do similar cycle testing with the open/close reed switch.

[NorthernMan54]

@mikedm139 I parked this a few months ago as I couldn't figure out how they were obfuscating the sensor status. I had played with a couple different things but hit a wall. I was 90% sure that bits 24 to 29 where the status bits, and that it matched this work https://github.com/merbanan/rtl_433/blob/4bb75b4cd25b965955ab8e9ca9dbca88e5d31252/src/devices/honeywell.c#L98. But what I could not figure out was the pattern/algorithm applied to the sensor values to obfuscate them.

[mikedm139]

@NorthernMan54 ok. So unless I (or someone else) can figure out their obfuscation, we're stuck.