I have been having fun, and yes, it is fun.There have been many set backs. Today I spend two hours assuming the damn Max Reader was being daft before finding a loose connector. Yesterday was an faulty RS485 lead.
I have discovered that the Max reader really does want around 10ms gap between messages on the bus else it gets confused and sulks. Shame, as keypad is happy with way less.
My code design has evolved - it now works as a library which creates a per bus thread to do the polling, and a separate "doorman" thread to handle logical "door" objects. By default these are created from new Max readers it finds.
My idea is that a "door" is a lot more than just what a Max reader can do. They are pretty simple, with two inputs (exit button and door open) and one output (door release relay).
I think a "door" needs more, so the design allows (optionally) a Max reader and then a number of inputs and outputs (which may be on that Max reader, or on a RIO), to make the door complete.
So you have the basics, a door exit button, and a door open sensor, as well as a lock control relay. But the logical door can have more. Indeed, those basic inputs do not need to be on the Max - its inputs and outputs can be for anything, just defaulting to their normal use.
Extra I/O for a "door" includes things like a door bell button input and a door bell output. Simple stuff. But also a door "lock engaged" input (which many locks can do), so you know you are not locked. This allows a "door ajar" state if door shows closed, by lock not engaged in a sensible time.
I also created the idea of a deadlock, so an output for that and a deadlock engaged input. This allows for doors to have extra locks when alarm set.
The system also allows for the notion that a closing door can take time to close, either for lock to engage or simply a time of a few seconds, and opening during that is NOT a door forced event! The source of so many texts I get from our Galaxy system. I will be really glad to kill the event!
The keypad code is fun - an event for key presses, but a simple memory mapped text area for display- sending new display text on next poll if changed. Makes for easy app coding.
At this stage my library has low level code for Max readers and keypads, and will soon have RIOs. It also has logical system management for doors.
Next step is "alarm panel" logic, and deploy on some Raspberry PIs, and RS485 USB cables, and sorted!
This is basically a complete alarm system coded in less that a week, I know! My plan is changing my house over this weekend.
The video blog of progress :-
A silly question. What is the code you have written running on in your demo? Is It code on your Mac / Pi / some other external machine which is doing these things, or code flashed to each of the various keypads and fob readers?
ReplyDeleteI'm guessing the former, but interesting that it is code on the Mac (or whatever) which determines whether the keypad beeps or not.
On a linux box. The keypad has key beeps, but there is a setting to turn off or make quiet. The Max reader automatically lights its top LED (key fob present) but the rest are all under remote control. I'm going to try a Pi soon.
DeleteHow are you getting on with this project?
ReplyDeleteI'm reverse engineering (i.e. doing the same as you) my Honeywell galaxy as I've came to the conclusion that Honeywell are stuck in 1990.
I think that a few RIO panels feeding back via an RS485 dongle to a raspberry pi could perhaps be more secure than anything currently out there on the market - particularly if opensource.
I'm getting sick of people suggesting that the obscurity of Honeywell - or any other manufacturers - system is critical to its security. When in fact we know that the obscurity is more likely to be hiding some awful security flaws.
Anyways I was mainly wondering how your getting on? May be worth setting up a github library as I've done a bit of work myself that I wouldn't mind contributing.
All open source on git hub, and working well. In use in several businesses and homes already.
Delete