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.

  8. Hi, great to see your work so far. You've gone down a path that I'd wanted to quite a few years ago when I started SelfMon - use all the low cost peripherals and drop or re-write the firmware in the Galaxy control panel.

    I didn't see you mentioning the Galaxy peripherals run with 3.5char gap mode with a 1ms gap at 9.6kbaud? I suppose it doesn't matter as much when you're the controlling master? Some of the releases of the peripherals are more relaxed than others, again easier to control when you are the master. When designing a slave device to be compatible with the Galaxy panel, if you get this timing wrong, or if your CPU gets tied up servicing some higher priority process, then the panel will supply you with a missing device tamper. Most of the security panels are running RTOS. My original thoughts for a drop in control panel board was a Beagle bone board, using the PRU's to take care of all the realtime bus transactions and then Linux running on the main CPU abstracted from the bus traffic. I suppose it's all about keeping the timing intact, while scaling devices and having other services taking CPU time with a non RTOS. Looking forward to seeing how this progresses and nice to see names of many who I've talked to in the past.

    1. My measurements seem to be 10ms gap in most cases. The Max readers can take 20ms to answer some times, and get upset if I make gaps too short before next poll.

  9. I'd need to dig out my notes from about several years ago when I had this hooked up on my TDS. I recall the timing is slightly different on the G2 series, so the devices have quite a bit of tolerance. I never really had to worry about the master timing, as I was only ever emulating a slave. So for me, it was the detection of the last byte that was most important and also providing the response packet / enabling and disabling the RS485 write line in time.

    The panel controller does a round robin on the slave addresses with a request. The slaves can acknowledge the request with or without a payload. Some of the devices like the Ethernet take time to process the request to generate the reply payload.

    My starting point was taking the E080-2 Ethernet module and rewriting the firmware to provide a web based virtualkeypad for remote control over the web. I did that, but the 8 bit Rabbit 2000 micro was not powerful enough to provide a decent user experience and the latency between web keypress and the output being returned on the display was too great. The Rabbit processor supports serial in gap mode and when I compiled their sample code, the device worked perfectly with the Galaxy bus.

    I then went on to look at the event reporting to the Ethernet module and created SelfMon to process large volumes of alarm reports for anyone who wanted to switch away from dial-up TAP. This basically runs itself and the customer payments cover the servers and distributed databases at Amazon. It was never going to me a money making machine anyway...

    After creating SelfMon, it was clear that at £200, the Ethernet module was too expensive for the domestic market. The firmware on the module also doesn't emulate a keypad when plugged into the lower end G2 panel and that meant very limited remote control over the system. So, that drove me to develop something to fill the gap. I hunted high and low for a low cost Ethernet connected CPU at less than £30 (that was actually quite difficult a few years back) and found the Wiznet W7100 CPU. They even had a serial to Ethernet version Wiz108SR that supported RS485. I re-wrote the serial to Ethernet code to provide the same functionality as the E080 modules and that's been successful over the last few years.

    In the meantime, Ethernet based hardware costs have dropped and cheap CPU's are much faster. So, I'm now working with the Tiva TM4C1294 and have the keypad and Ethernet module emulated on that in the office. The K3 from USRiot implements the same CPU inside an Ethernet connector like the Lantronix XPort, but much cheaper at ~£15. Roll on the £35 Ethernet module.

    1. As it happens I am just about to try a G2 panel, so will be interesting to see any differences.