Tuesday, 4 July 2017


Obviously, in most cases, proper "hacking", as in breaking in to someone's system without permission, is illegal.

However, it is quite fun to be able to do some "hacking" in the sense of working out how something works, and breaking in to it and doing things it was not designed to do. It is also fun to document how it works, even when it is using a protocol from the last millennium. In fact, in some ways, that is what makes it extra fun as it is nostalgic too...

So, today, I am playing with the Honeywell Galaxy alarm system. You see them everywhere - a very popular system. We use them, and slightly hate them to be honest. Even with full installer access they are impossible to make do some thing sensibly, even though they are actually very flexible. They have some really annoying quirks - like you can disarm the alarm using a key fob (good), but that does not also open the door, you have to use the key fob again to open the door. You can also set the alarm using the key fob (holding it to reader), but that also unlocks the door whilst doing it which may not catch (depending on type of lock). Little things like that just make it that extra bit annoying.

However, the actual bits that go with a Galaxy system are not bad - there is the keypad (as per picture) with display, the Max readers which work a door entry system, and RIOs which provide a range on input / output for sensors like reed switches and PIRs. They all sit on an alarm bus which is typically untwisted screened wire carrying 0V/12V power and A/B of an RS485 bus. Different panels have different number of busses and allow different number of devices.

My hacking today is understanding the protocol on that bus, and it has taken me most of the day. The main delay was many hours trying to work out how to make the RS485 USB lead switch to transmit and drive the bus. My mistake was assuming that I needed a a separate control like using RTS/CTS or some such (as some devices do). What I did not realise is the UART itself had a TXDEN output which does the driving and in fact I had a faulty cable - arrrrg. Change to different cable and you literally just write bytes to the port (from linux) and it enables the transmission side and sends them on the bus cleanly. Obviously that was the first thing I tried, but, faulty cable. It could not be simpler.

The nostalgia really has started to kick in though - I remember busses like this from, well, the 90s maybe, perhaps even earlier. We are talking standard serial protocol, 8n2 at 9600. The messages have no length indicator, just using timing to find end of message. There is a simple 1's compliment sum on the message for checking. No sequence numbers or acknowledgement or retransmission - it seems to use a state based logic, so sending the same message repeatedly until something needs to change. A really noddy and really old fashioned protocol. I suspect the "legacy" is strong with this one.

There are a few lovely quirks, like the keypad codes "0" to "9" as 0x40 to 0x49, but codes key "A" and 0x4B and key "B" as 0x4A, LOL.

Anyway, I have not only been able to work out the protocol but also send messages, even ones I should not be able to - like sneaking a status from a Max reader saying that someone has pressed the door exit button during the 10ms turn around time before the reader actually responds! Hence making a door open. Also sneaking in some messages to the keypad/display for fun, or changing the LEDs on the max reader. Basically, if you get access to a bus on one of these systems you can do all sorts.

OK, so why?

Well, I am thinking of making some open source linux code to work with the Honeywell / galaxy kit. Allow an open source alarm panel to be made, even. I suspect the protocol documentation and low level tools are what we would release, and maybe we make a high level panel and sell that as a solution, or maybe we make that open source, or like asterisk - a community designed alarm panel. Linux based would allow use of small industrial computer boards that could fit in a box with a PSU, battery and RIO. USB to RS485 allows plenty of busses with no problems. If you wanted to do something on the cheap you could even use a Raspberry Pi, but they tend to be less reliable than you would want for an alarm panel.

Of course this could allow a panel with modern config, using a web based interface.
It could allow integration with IT systems, like allowing SNMP of status feeding in to Nagios.
It could allow alarm state reporting by SMS, and email, even tweet DMs.

I suspect that getting insurers to be happy is a trick. We decided long ago that, at the office, contents insurance was more expensive that making the place secure. This applied even though we did have a burglary with several expensive machines stolen. So we do not have an insurance company breathing down our neck if we want a more custom alarm system. At home, the insurance company said the premium is no different, so they did not care if this was a custom alarm system or not. I suspect, even without insurance endorsed alarm system, there are plenty of opportunities for a system like this, and if it does get at all good and popular they may well endorse such a system. After all, the components are all proper off-the-shelf parts, standard RIO and PIRs and so on.

Of course, there are many other non alarm systems, such as purely door entry systems or time recording systems, which could use these same components.

What can I say? watch this space and we'll see what we can do.

First step is probably publishing the protocol.

It is fun.


  1. Texecom already has IP connectivity on their panels, easy to do quite a lot of what you're suggesting with one of those, just saying ;)

    1. The Texecom IP connectivity is awful. It's just a board with one of the standard serial <-> ethernet modules on it, and it only supports a single connection - if the unit is sending communication out, or someone else is connected, you're locked out. (Worse than that, they suggest exposing this port to the internet, so a DoS is trivial.) They mobile apps are (at best) naive and the notifications from their panel to email & mobile app notifications are ridiculously unreliable, something like 25% at least get 'lost' which is 'definitely not their fault'.

      Texecom are doing their connect system ( http://www.texe.com/uk/technology/connect/ ) which has been "coming soon" for years now, which should improve things a bit.

      In general, the Texecom hardware is better than the Honeywell (eg. they have a great range of style in their keypads that are IMHO nicer looking), and they have a nice mesh based wireless system (though for me it performs awfully, I'm fairly certain that's something 'odd' about my house). They also give good support to anyone (whereas honeywell support is relatively useless even if you're one of their approved installers).

      I'd be interested to potentially collaborate on something like this; the whole idea fascinates me and having all the alarm sensors available to trigger other behaviour would be a massive benefit. Things that are really pretty simple concepts ("if it's dark and I open the front door switch on all 3 outside lights") are ridiculously difficult to achieve right now.

    2. I have some really silly things like - if the door is closed (door close reed switch) but after 3 seconds the "lock engaged" input is not active then alert on the max reader with LED and beep so someone knows they have not quite shut the door properly, and text me if not sorted in one minute.

  2. You might think RS485 is 'legacy', but even today it doesn't have much competition for low-rate connections once you get to any reasonable length (i.e. past the copper Ethernet length limitations). Hard to think of a better alternative for commercial alarm systems, really.

    1. Indeed, very versatile. I was having fun with RS485 years ago with PIC 16C84 using an HDLC style bit stuffing frame with CRC - same physical characteristics but much nicer message packet format.

  3. Have you thought about using a ESP8266 for the central control and wifi connectivity etc...
    You can get SIM900 modules to add GPRS/GSM connectivity and RS485 modules fairly easily. I don't know how many RS485 modules you could run on one though.
    You could easily have more of them or Arduino's acting as an interface to multiple RS485 sets.

  4. You’ve probably already come across https://www.selfmon.co.uk/SelfMon/cpanel/ allows voice / sms / email / iOS notifications

  5. Basically, re-inventing the wheel is my thing :-) And fun.

  6. I have a couple of G2/G3 panels, loads of RIO's and some keypads if you need some to play with Adrian.

  7. Do you plan the release any code or details of the protocol, you've worked out? I have a G2 panel which I'd like to link to a home automation system (https://home-assistant.io/). I've tapped into the RS485 bus, with a USB adaptor, but can't work out the protocol. I had hoped it was using OSDP, as this is well documented, but as far as I can tell it's not.