I bought a new house last Summer and, of course, the first thing I did was start automating things! My house came with an ADT security system installed, but not active. I have no interest in using the control panel or professional monitoring, but I figured there should be a way to use the sensors that came with the house. Specifically, I have Honeywell/Ademco contact sensors/motion detector from the early 2000’s which operate on 345 MHz.
It turns out that these devices use a proprietary wireless protocol, but that was only a bump in the road. After much hacking, researching, and experimenting, I have integrated these sensors with ST by way of a raspberry pi with an SDR dongle listening to the sensors. It’s not 100% reliable due to SNR issues, but its plenty good to use the sensors for some typical automation (turn on lights when the door opens, etc). It’s especially satisfying that I got six contact sensors and one motion detector for ~$60 ($35 for the RPi, $25 for the SDR dongle).
I think this approach could be especially interesting to anyone who would like to keep their ADT panel active, monitored, and un-tinkered-with. Nothing has to change with respect to the ADT hardware, since it just listens to the existing signals.
SO, I have some code for the RPi, a smart app, and a couple of device handlers, which I’d be happy to share. I just wanted to test the waters and see if anyone is interested in trying this for themselves before I go to the work of documenting and publishing my project.
My approach was rather very simple. My goal was to read the state of the zones (whether they are open or close). I directly tapped into the respective zones and read the state of the zone by assessing the voltage drop when its open vs closed. It works great!..
Just found this thread and am interested in your Raspberry Pi + SDR solution. I have a similar situation (345 MHz sensors in a 2Gig system) and wanted to see if what you’ve already done would work for my needs.
Did you happen to put your code on Github? If so, could you post the link?
@aliby, the code for the ST side is available here but I’ll have to upload the raspberry pi side of the code this weekend. As a point of interest, since making this project I have been gradually swapping out the honeywell sensors with zwave sensors. I found that the ADT sensors were too laggy to trigger lights as I walk through a door.
@jh0 Thanks for the ST code. Would still be interested in getting the Raspberry Pi side of the code.
Appreciate the feedback about swapping out your sensors. I have a 2Gig system with an alarm provider and want to keep that, but also want to add the sensors into SmartThings for additional flexibility/functionality.
If you get a chance and can upload the RasPi code and post a link, I’d appreciate it!
@aliby, I’ve finally gotten around to uploading the raspberry pi software. You can find it here.
I’ll apologize in advance for the lack of instructions, you will have to experiment a bit to get the raspberry pi set up appropriately. My vague memory tells me this is about what you will need to do:
Install a newish version of g++
Install an apache webserver
Install the rtlsdr driver
Change the code to point it at the correct ST endpoint. I put in placeholder values and a #warning in digitalDecoder.cpp
@jh0 Thank you for the link to the software. Got everything running on the RPI side. Just went to install the SmartApp, but I’m not quite sure what I need to enter for:
Server URI is the address of the RPi on your LAN. In my case it is “192.168.109.2” (no quotes).
Desired Serial Numbers is a list of the sensor serial numbers you’d like to incorporate into ST. In my case I have “119354,548732,473729” (no quotes) in that setting.
The serial numbers may be on a sticker on/in the sensor. Otherwise you can run the program on the raspberry pi, open and close some doors/windows, then go to your version of http://192.168.109.2/deviceState.json in a browser. It will list all of the sensors the server has detected since it started. I found that my radio occasionally got messages from other sensors outside my house, so this field is necessary to filter the sensors down to the ones you actually care about.
Thanks again! Another issue that’s come up - When I go to trip different sensors (door/windows), I’m getting the following error:
1/1 packets failed CRC
This continues up to different numbers (12/12, 20/20, etc.).
Any ideas why this might be or what I could do to fix it? I’m guessing I may need to modify your code a bit to work with my sensors as mine are not technically Honeywell, they’re 2GIG ones.
Interesting… It does sound like your sensors use a slightly different message format than mine do. You’ll probably have to do some experimentation to see if you can figure out your format. Try opening one of the sensors to look for the FCC ID. You can look it up on the FCC website and you might find some more info about the specific message format.
You can also put your detective hat on and just print out a few messages to see which bits change when you open/close the door and which bits look like the serial number.
Tried uncommenting your “Print Packet” statement in digitalDecoder.cpp. When I do and recompile, the app crashes (returns me to a bash prompt) when I trigger a sensor.
From the same Defcon paper, I found this related to the 2GIG protocol/packets in relation to the Honeywell ones. Regarding 2GIG: “No changes were made to the SIGINT implementations. While the modulation, line coding, and packet sizes were all the same as the Honeywell equipment, the contents of the packets diverged slightly.”
That sounds like a good plan, sorry a bug has derailed you at the first step! I think the problem is the formatting for 64-bit print… I’ve updated that small block on github, so copy in the new chunk and see if it works better for you. I haven’t tested it, but hopefully should get your sleuthing back on track.
Just wanted to update this thread with the outcome of some debugging I helped @aliby with over DM.
We ended up determining that the 2GIG sensors use a different CRC algorithm than the sensors I have. To correct this, the polynomial in the RPi code (line 128 of digitalDecoder.cpp) needed to be changed to 0x18050.
Also, I wrote up the following instructions for manually setting up the OAuth tokens required for the RPi to push events directly into the ST cloud:
Go to the My SmartApps section of the API, and click the edit properties button on Honeywell Security Sensor Discovery. Put smartthings.com in the field for redirect URI. Find your client ID and client secret and remember where they are for a later step.
Select your location and click authorize. It will re-direct to a Not Found page, but look at the URL and note where it says code= Write down the code, this is your authorization code.
You should substitute your authorization code and your client id/secret (that you found above) In the URL.
If all goes well, you will get back an access token.
The access token goes in the RPi program in the Authorization: Bearer portion.
Getting close!
Now on the raspberry pi (or any other linux computer with curl installed) run:
curl -H “Authorization: Bearer YOUR_ACCESS_TOKEN” -X GET “https://graph.api.smartthings.com/api/smartapps/endpoints” (don’t forget to copy in your access token)
Find the installation ID in the “uri” field of the response, and copy-paste it into the URL in the RPi program. This is also on the same line as you modified above.
Now you can recompile the program and restart it. If all went well, you will start to get ST events!
@aliby, were you able to get your 2gig sensors to report to ST? I have a functioning 2gig system that I want to keep but would love to be able to link the sensors into ST.
@jh0… This project is really appealing to me. I have a DCS Impassa system that is 100% wireless and the other hacks don’t work on it. Listening to the sensors to report back open/closed states of the sensors are exactly what I’m looking for.
Do you have any updates or suggestions after using this for a couple of years?
Lastly, I’ve only done a couple of projects on the Rpi and was hoping someone could walk me through the install steps.
Hi @JohnnyBoyGee. I’m sorry to say, but I don’t think my project will work for your system. The Impassa system looks to be much newer and use a different wireless frequency/protocol than the system I have. I have gradually swapped out the Honeywell door/window sensors in my house for Zigbee units, as I was never intending to use the sensors with a security system beyond the ST built-in security, so I’ve stopped working on this project. I definitely invite you (or anyone else) to fork the repo and improve! Good luck!