I'm totally new to electronic/hardware/interfaces/GPIO sort of thing, but I have a project in mind. My house has an alarm system, which can be unlocked by key, with buttons. The alarm system gives a 'beep' sound, when I lock/unlock it. I can interact with the alarm system using the key, within 1 meter (the maximum distance I can hear the 'beep'), any distance further I will be unsure if the alarm system received the signal.

I have a Pi, connect to wireless router via Ethernet, and the router is connect to WAN. My project is to be able to do the same thing (locking/unlocking), using the Pi.

My questions:

  1. How the key transmit the signal? Note that there is a door between the alarm system and the key, so probably not Infrared?
  2. How to reproduce the signal, combining hardware(push buttons, GPIO, etc) and software(libraries, programming, etc)?
  3. Can I remote(SSH) into the Pi, transmit the signal without pushing the button?

Leave aside security concerns such as sniffing my network or breaking into my house etc.

  • The key probably uses RF to transmit the signal. Can you include the make and model of the alarm panel, and the model of the remote key?
    – TomG
    Dec 31 '12 at 21:53
  • Sadly, I can't find any information on the model or name, not even on the product's website itself. Jan 7 '13 at 5:59
  • Could you mark an answer or answer your own question please.
    – Piotr Kula
    May 7 '15 at 16:26

The most easy and straightforward way is to just emulate the pushing of the button. That way you don't need to know anything about how the transmitter does it's work!

Meaning you use a (spare) transmitter for your alarm system and use a relay to act like the push button. You connect this relay (the contacts that get activated by the relay, common and normally open) parallel with the original push button on the transmitter. You connect the coil of the relay to a GPIO pin on the RPi using one of the many examples on this site or something like described here, and you're done with the hardware. Write a simple script or program that activates the GPIO pin/relay for a moment and you're done....

As to contact bouncing:

In an ideal world the relay closes the contact and that is it, as does the button on your remote. But in reality both contacts bounce (make and break contact repeatedly in a very short period of time). For normal buttons (manually operated) this problem is normally a bit severe and happens over a longer period of time, because your hand/finger does not push the button in a constant way everytime. So when your remote operates by hand in a stable manner, we can safely assume that there are hardware and/or software solutions to this problem already in the remote, thus the relay (which is faster and more constant in closing it's contacts every time) will not have a problem operating the remote in a stable way. If for some reason the alarm switches on and off in a very short period of time (while you know the relay contact did not change state), you experience contact bouncing and you need to address that. You can solve that in multiple ways, the easiest is just adding a capacitor and resistor (effectively making an RC filter), if that does not solve it, you can add a Schmitt trigger. But before overflowing you with scenarios that probably are not be needed (because there already must be a form of debouncing used in the remote), try the plain solution first (locally not debounced) and if the bouncing problem appears, open a question about it and you'll get all the info needed.

You can use this over SSH, you could make some 'server' application with a client for your cell phone and turn the alarm on and off from your cell phone, the sky is the limit.

Reproducing the signal from scratch is a bigger challenge ofcourse, but you need to have a lot of info about the system, or you need to spend a lot of time trying to figure out how that thing does what it does...

  • You should mention about de bounce. It could be a problem?
    – Piotr Kula
    Jan 17 '13 at 10:55
  • 1
    I guess I should, we don't want his alarm to be switched on and off again because of that, thank you @ppumkin for reminding me.
    – ikku
    Jan 17 '13 at 11:15

The remote probably uses the public band of 315mhz,433mhz or possibly 800mhz. These frequencies are popular with allot of commercial wireless devices like, remote controlled garden switches, power meters, door bells, garage doors, etc.

  • One of the benefits of the 433MHz frequency is that is can transmit allot of text data over a long distance (up to kilometers with the right device and licenses but remote controls using within meters to 10 meters)

  • The other benefit is isolation. What that means is that you can have a hundred devices in your home transmitting at the same time and there will be no interference between them or your neighbour. That is great- but not for you. Why?

Did you ever hear about car thieves that used receivers to capture your car keys immobilizer code then re transmit it to open your car. Well any body can scan these frequencies with inexpensive gadgets, capture the data, re transmit it to do various things. If you knew what you are doing off course. Vendors do not supply what packets do what and allot of data is reverse engineered. That only applies for un encrypted data.

Now- If your security remote is made by a responsible company it wont just transmit some kind of packet saying "turn off" or "turn on" that any remote can send. Car thieve story all over again! Remote are paired to your system where they exchange private keys that are used in DES but hopefully AES encryptor. Making it very difficult to crack.

So with all that said using a 433Mhz transmitter attached to a Pi's UART is OUT of the question.

I would go with ikku's answer and do not even try to follow re transmitting route unless you have allot of time on your hands.

  • Ahhh, a very good explanation when coupled with @ikku answer, I will give up in finding way to re-transmit the signal. Jan 29 '13 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.