If you have a DSC (Digital Security Controls) home security system, with wireless sensors such as door / window contacts, glass break detectors, smoke, CO2, heat, and water detectors, you can now monitor them with rtl_433. The code is now in the mainline Merbanan github repo.
Only the 433 Mhz security sensors/contacts devices are currently supported. I will be working on other devices soon. I have almost all of the status bits worked out. I will be submitting a pull request soon.
DSC alarm systems are also sold under other brands such as ADT Pulse, and a number of cable/telephone company's home automation systems, such as Time Warner Intelligent Home. DSC is a division of Tyco, so you will also see DSC products listed as Tyco Security, though Tyco has a whole list of security brands.
These are fairly inexpensive wireless devices that can also be useful for a variety of home automation projects.
The DSC WS4945 - Wireless Door and Window contact
can be used as a magnetic contact or used with any sort of sensor that provides a normally closed output. If you are using it for home automation without a security system, it doesn't matter if it is normally closed or normally open. It will transmit at any state change. The device also sends a heartbeat with the current state every 64 minutes.The Vanishing door/window contact, EV-DW4975 is quite thin and small if you don't need the screw terminals for wiring up some other type of sensor. It will barely be noticed on most doors and windows.
If you are interested in decoding DSC's wireless protocols, or have any information to share, please contact me, I could certainly use someone to collaborate with.
** UPDATE For status bit decoding see rtl_433 DSC Status Bit Decoding **
17 comments:
IS this just capturing the open close status? I have been looking for a way to monitor the battery levels as well.
Currently in rtl_433 it is printing the whole 8 bit status byte without interpreting the bits. I have another script that parses the output, maps the ESN to the sensor label, etc.
The status byte has a bit for low battery that gets flipped on at 2.4 Vdc. So you don't get a level, you just know whether it is OK, or low.
My first interest in parsing with rtl_433 was getting a better sense of reliability of the RF environment. Most of the sensors send a heartbeat every 60-64 minutes. The recessed door sensor is every 84 minutes.
I've been meaning to post the decoded bits for the sensors/contacts I've worked with.
Hi, I'm in the process of building a decoder for my DSC wireless sensors and wanted to say that your work here is much appreciated! One thing you mentioned but didn't post (that I could find) are the decoded status bits. Is there any way you could post them somewhere? Thanks!
Hi Greg -
Sorry I let this slip. I'll get this written up and posted.
Also, I'm long overdue for converting the rtl_433 output to JSON and breaking out the bits into individual flags. So if you are using rtl_433 it will get done for you.
I'd certainly like to hear more about what you are implementing.
About a year ago I added an Envisalink EVL-4 to my panel. I've been using Juggie's alarm server from github. One of the thinks I'd like to do is combine the output, so I can get a consolidated view of both environments including things like heartbeats that I can't see from the panel until there have been too many missed.
I also have an Envisalink on my panel. I use it to integrate with OpenHAB and it actually works really well.
Since I can never seem to leave well enough alone, I was thinking about attempting to pair a 433mhz receiver with an ESP32 to replace the Envisalink and DSC panel with my own creation. I'm going to attempt to build a proof of concept; and if it works out I'll have some boards manufactured in China. It would be an open source alarm panel that is able to use DSC sensors.
As my wife says, things generally end up being 10x more difficult than I envision, so we'll see how it works out. :)
Hi rct, any chance you could post the decoded status bits you mentioned earlier? Similar to Greg I'm working on building a decoder.
For reference my door sensors return "A1" (1010 0001) when closed and "A3" (1010 0011) when open. So it seems like the second bit flips when the sensor is triggered.
You mentioned "The status byte has a bit for low battery that gets flipped on at 2.4 Vdc.". I would love to know what bit it is that gets flipped for low battery.
I also haven't had the chance to decode the heartbeat yet so any info about that would be much appreciated.
Reading what I posted again I realise I made a mistake it is the other way around. The sensors return "A1" when triggered (door opened) and "A3" when closed.
Ok after some more experimentation I have managed to work out that.
0x01 = Tamper
0x02 = Open/Closed/Alarm triggered
0x04 = Heartbeat
Still not sure what the low battery bit is. Would love some help with that one.
Sorry for not getting this published earlier. Here are my notes, which are still in need of some review:
* 0x80 = ?? always on, possible sync bit
* 0x40 = Heartbeat Message (off for an open/close event)
* 0x20 = For 4945, indicates contact activity/actual open/close message? (not set for case/tamper), also seen for motion sensor tripped
* 0x10 = Tamper message, case open or closed
* 0x08 = Battery Low
* 0x04 = ?? (never seen)
* 0x02 = Closed
* 0x01 = Tamper Ok/case closed,
Some notes:
* Open / Closed is probably more accurate with the "alarm terminology" of "Restored/Faulted" or "OK/Tripped". Normally Open sensors like the water/flood sensor report OK with bit 0x02 set just like normally closed sensors.
* Some of the sensors, EV-*, those built by SWI (Secure Wireless Inc) instead of DSC, set 0x20 in the next heartbeat message if there was any activity since the heartbeat. So a Normal heartbeat would be 0xC3, then an 0xE3 after an open/close event. It's a minor detail that could be useful to detect missed messages.
Some examples, hopefully I haven't made any transcription errors in describing the bits:
* Test Vanishing EV-DW4975
* 0x81 = 10000001 - Open, Normal (Case closed no tamper)
* 0x83 = 10000011 - Closed, Normal (Case closed no tamper)
* 0xC1 = 11000001 - Open, Repeat/Heartbeat, Normal (no tamper)
* 0xC3 = 11000011 - Closed, Repeat/Heartbeat, Normal (no tamper)
* 0xE1 = 11100001 - Open, Repeat/Heartbeat, Activity since last heartbeat?, Normal (no tamper)
* 0XE3 = 11100011 - Closed, Repeat/Heartbeat, Activity since last heartbeat?, Normal (no tamper)
* 0x80 = 10000000 - Open/powering up
Glass Break Sensor
* 0x81 = 10000001 - Open, Glass Break sensor Open/Tripped,
* 0x82 = 10000010 - Closed, Glass Break sensor Closed & Tampered.
* 0x83 = 10000011 - Closed, Glass Break sensor, tamper cleared.
* 0xC3 = 11000011 - Closed, Heartbeat/Repeat, Closed, OK/no tamper.
* 0xCB = 11001011 - Closed, Heartbeat/Repeat, Closed, OK/no tamper. Low Battery
* 0x8A = 10001010 - closed, Event (Not heartbeat), Tamper, Low Battery
* 0x8B = 10001011 - Closed, Event (Not heatbeart), Ok/no tamper, Low battery
* 0x80 - 10000000 - ? Power up,
* 0x83 = 10000011 - Closed, Event, OK/no tamper, Battery OK (all normal again)
WS4985 - Flood Detector
* (generally send C3 (closed, even though actually N.O., just like N.C. devices)
* 0xC2 = 11000010 - (regular heartbeat, but no 1 - OK bit, because no wired sensor with EOL resistor, so tampered)
* 0xC1 = 11000001 - Heartbeat when tripped w. wired sensor.
* 0xA1 = 10100001 - Tripped/wet
* 0xA3 - 10100011 - Closed (after drying out)
* 0x92 = 10010010 - Open/OK AND closing case?
* 0xD2 = 11010010 - Closed, (Powering up)?
Thanks so much for posting this info.
I have some WS4904P movement sensors and WS4945 door sensors. I'll post what I'm getting from those sensors later today.
The WS4904P behaves much like the W49445 and others. Status code is 0xA1 when tripped. Heartbeat with all ok is 0xC3.
Looks like mine are basically the same as yours. I've provided my notes below in case you are interested.
WS4904P - Motion Sensor
Only trips once every 3 mins (due to 3 min cooldown).
* 0xA1 = 10100001 - Tripped
* 0x92 = 10010010 - Tamper (removed from cradle)
* 0x93 = 10010011 - Tamper (returned to cradle)
* 0xC3 = 11000011 - Heartbeat
------------------------
WS4945 - Door Sensor
* 0xA1 = 10100001 - Open/Tripped
* 0xC1 = 11000001 - Open, Heartbeat
* 0xA3 = 10100011 - Closed
* 0xC3 = 11000011 - Closed, Heartbeat
Yes those match my notes. There are some slight variations between different families of sensors. (Possibly due to different implementations by different firmware autohrs?)
The use of the 0x20 bit is a little unclear. I believe all of the sensors set 0x40 for a heartbeat message and clear it for an actual event. The 4945, 4904, set 0x20 for actual events which is somewhat redundant, but the vanishing sensors and the other EV-WS sensor I have that are made by Secure Wireless Inc, don't sent it on an event. Rather as I posted above, for a heartbeat when there has been recent activity they set both 0x40 and 0x20. My guess is the panel (really the RF receiver on the keybus) probably ignores 0x020.
I currently process my status codes in a script that consumes rtl_433 output. So the raw output from rtl_433 has been fine with me. Now that you're motivating me again, I'll see if I can submit a PR to parse the output into structured (ie. JSON) data this weekend.
BTW, if you want to get in touch with my directly, my email address is in the AUTHORS file.
Hi
I have a lot of generic 433Mhz door sensors. I want to move to a Honeywell panel but I dont want to loose the old sensors. I have a DSC - Honeywell translator. I want to build a translator from my generic 433Mhz sensors to DSC signaling, Doyou think there's a better way ?
Post a Comment