The project is to receive and decode a 345 MHz signal from a door sensor. It would probably connect to a Raspberry Pi.

The transmitter is https://www.alarmgrid.com/documents/honeywell-5800-series-wireless-technical-specifications.

This chip looks like it would work: http://www.mouser.com/ds/2/302/SA615-842911.pdf, but looks pretty difficult to use. It is also a SMD.

I am trying to gauge:

• How difficult it is to use this chip?
• Are there alternative, easier-to-use chips?
• Would a board like http://2gig.com/products/radios-antennas/319345-mhz-dual-receiver/ be easy to interface to Raspberry Pi?

Any advice on approach would be appreciated.

 

Hello -

I had been trying the same for a while, and took a bunch of routes over the last couple of days.

I won't bore you with the trial and error of what I went through. I spent a couple of days and eventually what I ended up with is quite simple! I was able to get the following setup to work:

1. Get an RTL SDR for your Raspberry Pi. I used https://www.amazon.com/gp/product/B018PUYPCA/ref=oh_aui_detailpage_o07_s00?ie=UTF8&psc=1, pretty much anything else would do to.

2. Install RTLSDR on your RPi, look at the "Setting up RTL-SDR" in https://www.rs-online.com/designspark/taking-the-raspberry-pi-2-for-a-test-drive-with-gnu-radio-2

3. Grab rtl_433 off https://github.com/merbanan/rtl_433 and build it

4. After building rtl_433, from commandline run "rtl_433 -f 344975000 -R 69"

rtl_433 already knows how to decode Honeywell sensors (that's what -R 69 is for). -f is the frequency. I just got this to work half an hour ago.

Hope this works for you too.

I'll try to hack rtl_433 to hook it up to https://ifttt.com/maker such that I can receive notifications on my phone and what not.

Happy hacking.
Thanks.

 

Thanks for this.

For 3 sensors in my home, an RPi with rtl_433 processed signals with mixed results:

• A side door sensor has the same binary code for open and close.
• A side window sensor has different binary codes for open and close, but thinks they are both open.
• A far window sensor's binary code varied from run to run. (Might be a range issue as it was far, but code did have correct start bits.)

I was able to decode the codes on a PC by recording with SDR#, and processing it with GNURadio. This allows verification that the side door sensor does in fact have a different close code.

However, when trying to record and process with GNU Radio, some signals were not received. (probably due to my inexperience with the application.)

I should probably take a look at the rtl_433 source to see if it is fixable as it did receive all signals without using much CPU.

 

Yea, I bought a new sensor which was having some challenges with rtl_433. So I tried https://github.com/jhaines0/HoneywellSecurity/ which seems to work with all door sensors and motion sensors.

Very few lines of code, it even generates json which can be used to trigger a service. This is what I'm trying right now.

 

HoneywellSecurity is solid. It did give some false readings (invalid device id) from a far sensor when the antenna was not tightly connected. Not sure how it passed the crc. A list of known devices would solve this. Code is well written and did not use much cpu. Developer must work in the industry.

I'll take a look at ifttt. It would be nice to not need a server.

 

Great! with IFTTT Maker you don't need a server. It gives you a URL to post to, you can then do whatever you want with it.

I'm trying to hook this up to Node Red. its basically an IoT friendly service that allows you to create flows, it's based on Node.JS. It's already part of Raspbian. So I'm POSTing JSON to a server locally hosted in Node Red and writing flows to create a webpage with the status of every sensor and now thinking of IFTTT and what not.

 

While IFTTT can be made to work to some degree, NODE-Red server seems more appropriate. I've got partial solution working with NODE-Red (hosted on FRED). A Python tkinter app acts as the console.The Python app's Arm Button calls NODE-Red via curl. NODE-Red still uses IFTTT to send me email, because it seemed easier than setting up email on the RPi.

I have not figured out Android support. I was hoping to use some customizable app or NODE-Red extension, but may build an app for maximum flexibility. Ideally, Android console would allow arming and showing current status. This is complicated by delays before arming and alarming to allow disarming. Ideally the console will display a count down clock and beep during the delay before arming or alarming. Push notifications like MQTT is probably needed.

 

Didn't realize NODE-Red had a gui. Will look at that.

 

im posting the JSON to a node-red hosted flow from HoneywellSecurity via curl, then wiring it to a Facebook bot. Also have the UI dashboard working, ran into some bugs with the UI dashboard and the chatbot nodered npm. Have it wired up, need to work on limiting what messages that need to be sent. Have a look at chatbot, setting it up was a breeze.

 

I've got my gui working with OpenRemote. Still needs some cleanup. For one, I'll have to install a DNS service (to push the RPi's semistatic IP to a DNS name) and open the port on my router. If you go with chatbot, is the interface like:
Alarm is disabled. Arm? y
Alarm armed in 10s. Disarm?
Alarm armed in 5s. Disarm?
Alarm armed. Disarm?

Originally, I was thinking of an app, but this seems fine.