Honeywell Ademco alarm panel via AD2USB

[mchias13]

gustavo,
can you explain what the RFX Sensor and the "loops" are for more?  I'm interested in testing CptJack's work once my house is complete, but not sure on what you have added.

[gustavo]

gustavo,
can you explain what the RFX Sensor and the "loops" are for more?  I'm interested in testing CptJack's work once my house is complete, but not sure on what you have added.

The sensors I've written are a different way to represent the state of ademco wireless device sensors than what CtpJack has done.  Both ways have advantages and disadvantages.  CptJack's code represents these sensors by looking at the fault codes / messages that are sent to the alarm keypad.  So for example "FAULT 20 Upper Back Door" gets mapped a virtual sensor using CtpJack's code.  These come across the ad2usb like this:

[0001000110000000----],003,[f700000d1003000028020000000000],"FAULT 03 HALL   MOTION          "

The string "FAULT 03 HALL" is configured a s fault code for the motion sensor.  To know that the motion sensor has cleared, Jack's code looks for the "READY TO ARM" message:

[1001000110000000----],008,[f700000d1008001c28020000000000]," DISARMED CHIME   Ready to Arm  "

Here's where the fault message method is advantageous:  devices that are wired directly into the alarm panel show up as fault messages, but they do not show up as !RFX messages.  The !RFX message type is only for wireless devices.  In other words, if you're house is all wired, and wired directly to the panel (instead of via an expander) then the RFXSensor method does not work for you.

An RFX message looks like this:

!RFX:0103377,04

Dissecting it, you see the RFX message header ("!RFX") a colon delimiter, the serial number, comma delimiter for status.  While wired devices have only one of two state possibilities wireless devices have multiple.  The different states are represented as "loops" and you configure them this way when you enroll them in the alarm panel.  A wireless device can have upto 4 loops, plus a battery code (e.g. is its battery good or bad) and a supervision bit.  Take into consideration the Ademco 5816.  This device has 3 loops that I know of.

Loop1:  Is a wireable loop.  You can connect it to a wired reed switch, or contact switch.
Loop2:  Is the internal reed switch.  Loop2 is probably what 99% of people use the 5816 for.
Loop3/4:  I'm not sure which one (I'd have to check which means setting off the alarm and pissing the wife off) but one of those loops is for the builtin "tamper" switch - which is a contact switch that gets flipped when you pull the sensor open...

The RFXSensor thus allows you to monitor all four of the loops on a wireless device, plus its battery status.  Because these are represented as a DoorWindow device, which can be used as part of HGs builtin alarm system, I've allowed you to configure which loops should trigger the DoorWindow device to open/close.  E.g. Loop2 and Loop4 (I think) on the 5816 would trigger the DoorWindow device.  You'd exclude loop1 because it's always open, unless you've wired it to another switch (which is very useful if you have say two windows right next to eachother, you use a single wireless device where the device itself is monitoring one window using its builtin reed switch, and monitoring another via the remotely wired reed switch).

So the RFXSensor is *only* for wireless devices - whereas CtpJack's setup is for wired / wireless.

Additionally, the RFXSensor can monitor devices that are not enrolled / configured for your alarm system.  A blessing, and kind of creepy.  Where I live, the RFXSensor has picked more than 50 wireless sensors - though I only personally have 4 of them.  What this means though, is you can setup ademco wireless sensors as automation sensors, but not necessarily alarm sensors.  E.g. for interior sensing, or using their hardened devices - like their commercial series wireless smoke alarms.

Additionally, RFXSensors are updated regardless of the Alarm Panel's status.  This is probably the biggest difference.  When the Alarm Panel is armed, you do not get Fault Message updates.  You only see "ARMED" status.  So even if ARM your alarm panel as stay (e.g. only exterior entry points trip the alarm) you won't be able to use the motion sensor in the hall way to automatically turn on lights at night - because you'll never get a fault message for it.

If the motion sensor in the hallway is wireless, however, it'll generate an !RFX message regardless of whether or not the panel is armed - so you'll be able to use it for automation purposes as an RFXSensor.

Finally, it should be noted that the same thing that RFXSensor does for wireless devices can also worked for wired devices, if those devices are wired into a zone expander.  That's because the zone expander sends the messages across the bus similarly to how the radio receiver does.  I haven't coded it up, but it would be quick and easy to have an EXPSensor (much more so than RFXSensor, since there's no mapping of serial numbers, multiple loops, battery status, etc).

Again, these are different ways to skin the cat.  They have advantages and disadvantages.  For me, there are wireless sensors in my house that I want to monitor with homegenie, even when my alarm panel is armed.  RFXSensor allows that.  It does not allow me to monitor my wired sensors.  I will probably buy an expander board, and move the wired sensors to that (and write EXPSensor as a result) down the road.

[mchias13]

thanks.  got it now.  good explanation.

[CptJack]

Based on Gustavo's posts, I've updated the first post with new code. The alarm panel will now pass RFX messages to the sensors, and the sensors can now use either a panel string or an RFX ID to receive updates. Loop status is reflected in RFX.Status. The RFXSensor code is not used here - I instead chose to allow one sensor module to handle both types of updates. That way, the IDs are stored in the modules instead of the program itself, plus there's a lot less code to maintain/debug.

[gustavo]

Thanks Jack.  Looking at it, I think there are a couple of missing features in the way you incorporated it - maybe these can be improved on?

1) The sensor you have now is a generic sensor.  Wouldn't it be best if they were Door/Window so that they can be used by the built-in alarm system?  E.g. with what I have now, I can map RFX Sensor loops to the main Door / Window (based on the appropriate loop) and have those trigger HGs alarm code in addition to being used by the ademco.  Perhaps a normal sensor can be used for this purpose, in which case disregard this concern.

2) It looks like you're not actually using bit-wise logic, but rather you're evaluating the sensor status as strings.  My RFX code used bit-wise logic, because often times (actually more often than not!) you'll have more than a single loop.  Take an example of the 5816.  If you use it as a single sensor using the builtin reed switch (the most popular configuration) it'll always have the wired loop set as tripped.  In that case, none of the options you've listed actually works.  That's why my code runs through bitwise logic to determine exactly what loops (including if the message includes multiple loops, or is a supervision update - most of them are supervision updates as opposed to initial trips) are tripped, and allows the user to specify /which/ tripped loops trip the sensor.  The way you've re-coded this, a 5816 being used in the normal way will /never/ become untripped.

I know my code is long and complicated and I can see the desire to simplify it, but that's the nature of the beast.  You can't treat these as simple strings because they are not.  Further, because of multiple loops on a single sensor, you really need to be able to configure which loops actually matter and which do not.

[enterprised]

Sounds like a great opportunity for CptJack and gustavo to work together to make this a killer app within HomeGenie.

If this works and word gets out HG becomes very attractive for many Honeywell/Ademco owners who want remote monitoring and integration of their security system without having to pay an arm and a leg to a security company.

[CptJack]

Based on your description, I see the need for the bitwise code, and the sensor type, as well, but I'm not fond of things like having another program, having lots of blocks of nearly identical code, storing strings in the program instead of the module, etc. which I have to update before I can do another release, plus I've found a couple of things in my own code which need to be changed/fixed.

I'll take a look at it again after a while - I don't have the extra loops to test, and since I write code all day, I don't have a huge desire to write more code in my off time.