In theory, theory and practice are the same, but...

Most of this week was spent doing other things, but I did find the time to actually build an "alarm panel", and today I took the plunge to install it at home in place of the Honeywell Galaxy system.

It is made using a RIO PSU box, the size of an alarm panel with a RIO and power supply, and includes battery charger, with lots of space. I added a second RIO as I'll need more than 8 inputs in total. And I added the DC supply and PI. Simples.

It has taken me all day, and I still have more sensors to connect up now, but that should be the easy bit! However there were a few pitfalls, which is why it has taken all day.

No space

First off, as you can see, where I wanted to put it, and sort of had to put it because of where cables would reach, I had no space. In fact there was a second battery box there originally which I don't really need.

Power off

I turned off the extra battery box, and was going to use the lead for the panel. I realised it had lights on, well it would, it has a battery, but I disconnected the battery and it was still lit up. To my surprise the power switch did not work and it was all live. OK time to turn off the circuit, remove that switch, and sort it out - my daughter's partner was here, and is a sparky, so he lent a hand to do it pukka. Thanks Jim.

Resistance is futile!

As you would expect - when I installed the panel in the first place I fitted the proper RS485 termination resistors to the buses.

When fitted they simple do not work with the FTDI USB serial I have. It even had a termination resistor in it to use on two leads, but fitting those breaks it. I had to actually remove them?!?

Are you positive?

The first thing I connected was the existing doors, well, one of them. That was simple, but something was not right. It took me a moment, but the lock was locking when you wanted to open the door and unlocking when it was closed. It seems I had misunderstood the polarity of the bits in my testing somehow. It is good to have a working existing installation as otherwise I'd have assumed it was meant to work like this and wired up accordingly. As it happens the locks I use here need a relay board anyway as they expect a reversed polarity. Apart from fixing my bug I also added a feature to allow the control to be inverted for cases like the locks I am using. This will allow me to remove the relay boards.

Beeping hell

If you have ever used the "Max reader" you will know it beeps. If the installer has not included the door open sensor, it beeps for as long as the door open time is. It is a tad loud. With the sensor it beeps until the doors open. Most of them have blu tack in the beeper to quieten it.

However, here, the locks are motorised so you can hear it is open without the need for a beep. So, as I have full control, I have made the beep on open optional. It still beeps for error cases, but these can be a lot louder now with no blu tack. Well done James for suggesting it.

Too quick for me

We had one door in service, and in use and a lot of coming and going. I was working on the other door, but we quickly realised that the door we had would sometimes come up door forced. Given the work I had put in to avoid this I was rather puzzled.

It only happened if you basically lent on the door and hit the open button, and fell through it, sort of. Opening the instant it was possible. Turns out the window was up to 100ms.

Well, the doors work on a state and if the door is found open in closed state, that is forced. It expects to go from closed to opening and then find it is open in that state so as to move to open state. The problem is the door release was quick enough that the state machine in a different thread was not spotting the state change for unlocking the door and hence seeing the door open in the closed state and so decided it was forced. The fix was simple, if we released the door, then that is allowed.

And still too quick

A bit later we realised the door was not locking. It would be opened and thne closed, but not locked. The issue is my above fix actually stopped the door going to forced state but did not in fact move the door to open state, it sort of got stuck in a rather inconsistent state of closed state but the door open. OK, that was easily fixed by actually moving to the open state.

And still too quick

Later in the day it happened again and I was cursing. I think I finally have it sorted now. The state machine was actually looking for change from opening to any other state as the trigger to stop the lock opening - e.g. engage mag-lock, etc. So it was staying dis-engaged and then the door was closed with the door lock set to open so the it promptly decided it was opening state again.

Some days I like state machines, and most days I do not. This is why the play house would have been a good idea for testing.

Why no fireworks?

Anyway, with lots of things working, including the lock engaged inputs on the doors, I decided to try and sort battery errors. I fitted the battery, and I tested. I turned off the mains and it all died?!?!

I was cursing, and it took me a while to spot a red spade clip on a black terminal and a black spade clip on a red terminal. I am impressed that the RIO, which not only runs from a battery, but charges it, managed to safely do nothing. Having swapped, I can battery and mains error reports and voltage information. Yay!

Can't spell, tutt tutt...

I wasted ages with debug trying to work out why outputs were not working, until I realised, eventually, that I spelt it outut instead. The XML config is currently ignoring any extra objects or attributes to allow for higher levels to hold data on things like images and locations on a map and so on, and so it was ignoring my config link completely. I plan to have a check against an xsd or some such at a higher level, later.

Next step

Connect all of the rest of the PIRs, and a lot of testing. It already texts me for events, and will be added to nagios to tell if it fails. This should provide a pretty good alarm system for home.

Is a PI going to be OK?

This is a good point - they are hardly "industrial". However, it boots very quickly, probably as fast as the Galaxy. It seems to just work. Even so, Andrew at the office had a bright idea I may purse...

Dual redundant PIs! They could easily see if the bus is in use, and wait, stepping in if the first PI dies. RS485 is very nice for that sort of thing. One to consider if I do run in to any reliability issues.

Open source

Still not released, and even if I do, it won't be until I am really happy with it. I may allow some people to test though.