Alarm State Machine / Group Zones Example

Just to update of gateway configuration page,  I've created a state machine diagram showing arm/disarm cycle.Also here is an example of my own groups (Garage, House) and zones (PIR, reed) setting for ground floor. You can see here how authentication unit is attached to particular zone. Only these zone is then set up with authentication delay. That is, when someone trips these zones there is time allowed for the person to authenticate. All other zones in house group trigger the alarm state immediately. You can read more about it in zone's setting.

 

Remote unit demo

I have shot a short video that show how the authentication works on the remote unit. As you can see there is red and green LED in the probe that helps to show current state, and piezo that is mounted inside. Slow green flashes without sound means that group/zone is disarmed. After touching the probe with a valid iButton, the group is being set to arm state with the configurable delay, as shown red flashes with sound. When the delay passes it switches to arm state, slow red flashes without sound. Then tripping a zone, here opening front door, shows another state awaiting authorization. The delay of wait state is configurable in 3 to 0 times of authentication delay time, which is configurable in seconds as well. Every such wait state is represented by faster LED flashes and also faster sound.

As you can see in the video I have the unit mounted next to switches, directly in the wall. I found it very fast and easy to arm/disarm the group. My 5 year old daughter still finds it funny after 3 months of use and she ask for my keys to do it.

Web interface - authentication

Authentication units have their own configuration page as shown on the right. On the top, again, is a summary of authentication units connected to system. The units can be connected by wire(RS485) or wireless(RFM12B). It is shown in the address field. "W" stands for wired and "R" for Radio. Address range is the decision maker here. Units in range 1-14 are wired and 17-143 are connected wireless. Address and type of the authentication unit is defined in remote unit itself. The few options to set is turn the unit On or Off, other is to attach them to certain group.

Remote units are dynamically added to the system at any time by process called registration. This process is activated by service thread few seconds after the system starts, or when you power up any remote units it will issue call for registration. If the unit is present already the system will re-reregister it with new parameters. The actions taken are presented in the log. You can for example see following messages:

If you miss any unit that should be there you can push "Reregister" button and the system will issue registration call.

Going little more in detail, the all the settings are permanently stored in remote units in-chip EEPROM. By default the units register with their defaults, that is not enabled and belonging to group 16. And you have to set them on first. The other settings like functions they provide is dependent on the hardware and is coded in the registration message they sent to main board. Any remote unit can provide more then one function, as you can see on picture above. Unit 1 is iButton authentication unit and also provide ambient temperature.

Web interface - keys

Another configuration page is about iButton keys. You can see the page on the right. Settings here are rather simple on the top you can see the table of assigned keys. There are name and and 8 byte address of iButton key. There is currently space to store up to 8 keys, but can be expanded. Bellow that is a pull down selection to work with single key.  There is not much to say about that except of last key value that is set to 55's. This value hold the last unauthorized key address. That can be used either to see address of key that is not yours. Or better when you have new key, you can just touch authorization unit. The system recognize unknown key, issue a warning message in the system log, and store the address value here. Next thing is to copy paste the value to some empty slot and give it a name, and press "Save all" to update the EEPROM. Well there is also laser printed address on every iButton, but in reverse order and it is bit tiny.

The system uses just ROM address of iButton, that mean you can use any iButton as a key even temperature probes and such. Now this bring another thought about security. First I consider iButton secure, but they can be read and copied, so can be RFID tags. Also touching probe with iButton is more convenient than to type 16 hex digit on keypad. But it can be surely improved. For example if you stay with iButton there is NVRAM version like DS1992. It gives you 1Kb of non volatile RAM you can use for floating code that can be generated every time you touch authorization unit. This makes coping much more complicated.

There is also possibility here to use other means of authorization, like NFC found on many phones. Or a simple keypad, but I have small children and prefer ROM iButton for its price and durability. Maxim states "Thanks to sealed stainless steel, you can drop it, step on it, or scratch it. The iButton is wear-tested for 10-year durability and a million hot contacts."