As with many systems there are a lot of layers involved, and I have been working my way up the layers (which is how I usually do things). I usually get bored by the time we are talking about what colour the icon for a PIR is on the web page :-)
The low level layers are all about the RS485 bus, and the reverse engineering of a normal Holywell Galaxy alarm panel. That has gone well, but even today I was revisiting a few bits like control of the backlight on the keypad. Over the weekend I have slept on the design and as I expected re-done several parts of the low level library to handle the bus and "door state machine" logic.
One of the main reasons for a re-work like this is that things are never quite the same when you come to using a library. I made my initial design, but when using it I found I was having to make messy code, which is always a bad sign, so I went back and made changes. The result is something I am a lot happier with.
I have now started the higher level design of an alarm panel. I had to pick a name. I have started with a name of SolarSystem, as it is a lot smaller than a whole Galaxy. That said, it is likely to be a lot more powerful to be honest. This also meant a lot of documentation and more sleeping on things and a lot of changing my mind as I started to code things.
The nuts and bolts of an alarm panel are damn simple - you configure shit, which is not that hard, and you have a lot of inputs which set an "alarm" state if triggered when the alarm is "set". You make bells ring, and you send text messages and so on. OK, that is simplified a bit, but not rocket science.
This is where we get to another part of coding, and especially for embedded systems, you need a shit load of error checking, and you need ways to report errors without simply aborting. For most code in a typical environment, using errx(...) is fine - aborts the programme and tells the user what went wrong. For an alarm panel that means the doors stop working and you are locked in or locked out of your office. So you need to take a lot more creative approaches to error handling.
The other big issue, even at this stage, is "user interface". For the most part I am working on the actual operation. However, even that has the keypads, and they represent a user interface. So I have to have a way to use them sensibly - modes and states and partial inputs of data - all good fun.
So, in summary - I have the low level RS485 handling for RIO, MAX, and Keypad all working. I have a design for the alarm panel operation. I have a start on the code for the alarm panel operation.
What next - well, lots of work at this stage still, and a lot of testing. I decided the alarm panel code runs from a config file, which can be re-loaded, and is XML (or JSON). So the actual config is to be done later - perhaps a nice web interface or mysql database, whatever. I said I get bored at the high levels, but I have people that will code that all if I want. For now I am using vim on an XML file :-)
I also need to start using this in practice, which means setting up better bench tests than I have now. Ideally a board with some doors on it (small ones) with lock release and buttons and reed switches and max readers, and a keypad, and something to simulate PIRs and a bell and so on. Make a dummy system and try out the logic, and also to demo the way it works and use in videos!
One small step to that which I may do is fit door entry and alarm to this :-
It is nearly finished (thanks to all my family who have worked hard on this), but has a door, and so could be set up with a full alarm system - why not. Indeed, I suspect my grandsons will love it if the door needs a key fob and will take great delight showing their friends and locking them out even.
Changing my house is also a key step. I have a Galaxy panel now, but will change to a new system. I need a key switch so I can cut power to the fail safe door on my office here at home for when early versions do manage to crash in some way. Even I am not brave enough to lock myself, yet.
Them the next big step will be changing the office over. I expect that is weeks away, but when we do it, it will allow a lot of new features.
One of the key things we can do a lot better is door management, which I have already coded. Actually being able to use "lock engaged" inputs, and allowing secondary deadlock on a door, and handling door forced events way better as well as door propped.
It is probably worth explaining slightly. When the certified alarm installers did the office, they did not connect the door open sensors to the Max readers. Why? Because it causes door forced events. Grab a door as it is closing, or bounce a door shut then open (depends on type of lock), or even just pull hard enough on a mag locked door to trip the reed switch, and you have a door forced alarm. So they, as a matter of policy, don't enable the sensor as way fewer support calls. Bear in mind, for a lot of systems, this sort of issue may mean calling the installer to have them reset it.
We were robbed, and there was a complex sequence of errors on our part, but one of them is that we would have seen door forced and come running if those sensors were fitted.
Now they are - but we have a false alarm on this once a day at least and it is annoying. We have the system so we can reset the alarm, but still it is annoying people.
So simple things can be changed. One is a short timer on the input for the "tugged the door hard", though, to be honest, on the outer doors I would rather know someone is doing that. Actually, D'Oh, I need that only during the day when alarm not set. When alarm set I want that to trip instantly. /me makes note. This means we eliminate a lot of the errors.
The other is a door closing timer and integration with lock engaged inputs where available. This would allow door open just after closed without being a door forced.
Just those simple little things would stop the staff cursing the Galaxy system every day!
Another issue is door propped events. The Galaxy does this - a door left open too long is considered propped. A useful alert.... Except sometimes you want to prop a door. Hence we have it disabled. My design allows a propped alert to be cancelled (and to record who did it) by someone allowed to cancel propped alerts using a key fob on the Max for that door. That way we can prop doors if we want, and record who did it, but a door that has not quite closed for other unconfirmed reasons raises an alert.
By creating a door object as a concept and not restricting ourselves to what the Max does, we can allow all sorts of new things. One of which is air-lock door sets. I.e. two doors where one must never be open if the other is open. This is a requirement in many places, and indeed, one of the doors does not even need a Max reader at all, just buttons and sensors.
Another is cases of max reader both sides, which doubles as a time recording system for staff. My design allows these with ease.
All good fun. I'll post more on this next week I expect. Still considering the best way to open source the project.
This sounds excellent Adrian. I have a G3 panel at home, and up at the workshop, and I'd love to change them for something a bit more reliable and easier to work with - are you aiming for a Pi Powered solution?
ReplyDeletePi is the obvious one, but may not be reliable enough. It may depend on my code and if it wears out the SD card, obviously. I am planning on using a Pi for my dev/test and maybe later this week we can work on something. RS485 USB leads are really easy to get. I am using FTDI ones but some are like £1 each or something, which is mental.
DeleteLet me know if you want to play with the code.
DeleteMy first attempt used a Pi but I diteched it for two reasons - one was needing a USB power supply which was hard to hook into the battery backed power supply of the existing panel (I suspect this is fixable, but it looked like more cost). The second was boot time.. a Pi can take many seconds to boot so all you have to do to defeat the alarm is somehow cause a reboot event - which it was vulnerable to due to the supply issue.
DeleteI settled on a arduino with a wifi shield for feedback. As a bonus I got compatibility with the 9 bit serial interface the keypad used, which was a source of pain on the Pi. It boots nearly instantly and takes a range of voltages so was easy to step down the 12v from the alarm supply.
Also an advantage of the arduino is open collector outputs so could cope with the alarm box triggers that were pulled up to 12v.
If I were to re-do the project today I'd probably use the something like a NodeMCU it's crazy value as £8 with inbuilt wifi.
You lost my interest when you said the config file is XML. It is one of the most god awful overly complex file formats ever invented. It has needless complexity on top of more needless complexity. If I'd known the Firebrick uses XML files for config I would never have bought one. It remains unused more than a year after I bought it, because I can't get my head round the configuration. I write software for a living, embedded C and 8051 assembler. I'm not a novice at either tech in general or IP in particular, yet XML defeats me.
ReplyDeleteI'm a tad surprised at that. Yes XML is a bit cumbersome, and what I am coding will happily work using JSON. What is your view on that. As for FireBrick - there is a web interface which hides all the XML behind the scenes.
DeleteWith the FireBrick, is it the XML (which, as RevK says, can be ignored completely in favour of the web UI), or the seeming complexity of its configuration?
DeleteI, like you, held off using mine for a while, as I was worried it was going to be too complex, but then I found that the out-of-the-box config got me online with basic settings. After that, I think the challenge I had was working out how to do port forwards / NAT rules, and Jamie helped me with the (actually really obvious after the event) rules.
Now, I tend to use the manual and web UI to work out what I want / need to do first time, and then copy and edit the XML config to replicate things if needed (e.g. firewall rules, user creation).
If you haven't already, give it a try — it may not be as bad as you are fearing!
I typed in a lengthy reply explaining the entire sorry saga. But blogspot seems to hate the iPad and threw it away, and I don't have the will to type it in again. I bought the FB2700 15 months ago, and I still can't get my head round how to configure it. The way the config works for it is totally counter intuitive, I wish I'd never bought it. I can't even get three network ports to work on the same subnet, never mind local DNS server and NAT port mappings. All I want is a home router where the IPv6 actually works, unlike the Zyxel VMG (which is otherwise a fine home router). The Firebrick was a waste of money for me.
DeleteMaybe someone from support needs to chat. If you use an A&A line you connect port 4 to whatever does PPPoE (bridging modem) plug network in to port 1 and you are on line with IPv6, NAT IPv4, DNS, and all working. Putting ports 123 in one port group means config - you just set first portgroip to be "1 2 3" and delete second and third Port group. But support can help.
DeleteLord knows why you'd ask me rather than A&A support, but I've got local DNS and NAT port mappings working, so happy to help / share some config, if you wish,
DeleteI've not tried to get three ports on the same subnet.
They also seem to do pretty well on eBay etc., if that's a better outcome for you!
This sounds brilliant. I also wouldn't mind a play with the code, if you're willing to share. Have been thinking about doing something similar for a while though never seem to find the time to play with it.
ReplyDeleteI wonder if it's worth looking at ACL systems such as those by Paxton, HID, etc - a lot of the functionality you're looking to build and integrate can be seen in those products. Whilst I know you're going to build a better and obviously customised solution, it may be worth looking at how they're doing things to crib some ideas and so on. I mention this as Paxton's Net2 product has some great work around sign in/out, timesheets, fire alarm integration and so on. If you want more info on that (Net2), hit me up - I'm using it in anger on a site with around 60 odd readers and a couple of hundred staff.
ReplyDeleteNet2 is great, until you have to push firmware updates out and find it is still basically RS485 over ethernet...
DeleteReally interesting project. I use Texecom Elite systems across our sites all using either WiFi or Ethernet for reporting and control. Texecom are great but there are quite a few things that pee me off with them. They too use a bus (not explored if it's just RS485) but you've got me thinking of investigating further.
ReplyDeleteAs has already been said above, the Pi would probably not be ideal but devices like arduino, ESP8266 (you can get ESP8266 for a couple of quid now!) are great for this sort of thing. They are quite simple and versatile.
It would mean porting your code across, however that shouldn't be too difficult.