HomeGenie Forum
Automation Program Plugins and Wizard Scripting => APP Contributions => Topic started by: CptJack on February 16, 2015, 06:16:24 PM
-
It's my experience that alarm sensors (door/window and motion) are more reliable and less expensive than their HA counterparts. Also, if the HA system fails, the alarm panel will still do its job as an alarm. With that in mind, I've been using my Honeywell Ademco Vista 20P alarm panel and wireless sensors as HA sensors in my previous HA setup, and wanted to do it again with HG.
The AD2USB (http://amzn.to/1EDZEBs) connects to lots of different kinds of alarm panels, but my experience is only with the Vista 20P. It wires in as a keypad using the four-wire interface, and provides a USB connection to your computer. It creates a virtual serial port which can be used to get information from the panel, and to provide commands to the panel. I'm on Windows, but it should work fine on Mac and Linux, as well, as there are drivers available.
Update 5/1/2015: You can now interact with the system using the plugin. Six quick-access buttons (Disarm, Max, Stay, Instant, Away and Chime) plus the 12-key keypad are available for use.
Update 6/7/2015: The panel/sensor combo will now monitor both the panel and wireless sensors directly. You can add the RFX ID of your sensor to the Alarm Sensor module instead of a panel string to match. The RFX.Status field on the sensor is updated with loop/battery/supervision information.
The files provided will get you started. The AlarmPanel folder should be placed in /HomeGenie/html/pages/control/widgets, and then import the HGX files. The Alarm Panel program will provide the interface to the alarm panel itself, and the Alarm Sensor will provide the virtual sensors which feed off of the data from the Alarm Panel. There's a place to enter the string which the alarm panel sends when a zone is faulted - such as "FAULT 1 FRONT DOOR". These strings are set by the installer at the panel, and are what show up on the keypads when a zone is faulted. If you don't know all the strings, you can look at the Alarm Panel device that you create, and it will display them as they're faulted. Just copy and paste that text into the textbox. You can alternately use the RFX ID of the wireless sensor you want to monitor directly.
If you have any questions, post them and I'll see what I can do to help out!
-
Nice job, can't wait to try the final product.
I've got the Alarm Panel working with an AD2USB connected to a Raspberry Pi B+
Still struggling a bit with the virtual sensors, either i'm entering the wrong string or something is not configured correctly in my Vista 10P.
-
The first thing to check would be the alarm panel module. It should have the last received status in the title area (which, for a 10P, should be ****DISARMED**** Ready to Arm or a fault). If you don't have that, the virtual sensors won't work.
-
Sometimes the solution to the problem is so simple that you wonder why didn't I think of this before.
Since I'm using this on a Raspberry Pi, all I had to do was re-compile the Alarm Sensor plugin.
I also made a small tweak to the HTML and JS files to make the alarm panel picture show up properly.
Fantastic option to have lights switch on/off using the Alarm Sensors and some Macro's when opening the front door or garage door.
-
I'm glad it was easy to get working! I'm still working on it, but the panel shows up fine for me - what did you have to change? I wonder if it's the difference in the platforms, or something I did wrong.
-
While playing around with HG I had the following thought. The widget used for "BasicThermostat" looks like a good choice for this program. The main widget can act as display, and the secondary control widget can become the keypad.
I made a small change to your panel code to make it re-connect after the connection to the AD2USB is lost, see attachment.
I also started writing an add-on that will speak a user defined text when a sensor is activated. The wife realy wanted the alarm system to speak voice commands if a perimeter door was opened, even if the Ademco alarm system is not activated.
You can define the text in the widget settings under Features/Options there is a new option "Speak Sensor Status". If you add text in this field HG will speak the text when the sensor is activated. Also, see attachment. Will work for all sensors, is not locked-in to alarm system only.
-
I like the idea of the speech. I hadn't posted it, but I'd also written a connected status check, but I did mine a little differently. I'm not sure if one way is better than the other, but this has been working very reliably for me:
while (Program.IsEnabled){
if(!SerialPort.IsConnected){
SerialPort
.WithName(Program.InputField("Port").Value)
.OnStatusChanged(HandleStatusChanged)
.OnMessageReceived(HandleMessageReceived)
.OnStringReceived(HandleStringReceived)
.Connect(115200);
}
Pause(30);
}
Now that I'm a little more familiar with HG, I might actually go back and re-write the whole thing to integrate the two programs, plus also auto-generate the modules for the sensors. I also need to add the arm/disarm capabilities.
-
Was trying to make the sensors app to only look for "FAULT ##" (## is related group number) instead of the full name given the alarm config.
I tried the following change to your code, but does not seem to work. Any idea what I'm doing wrong?
I just learned a bit of C# playing around with HG.
//value coming from alarm system
var panelValue = new System.Text.RegularExpressions.Regex(@"[^a-zA-Z0-9-]", System.Text.RegularExpressions.RegexOptions.None).Replace(parameter.Value, @"").ToString();
//only look for fault code i.e. "FAULT 01"
panelValue = panelValue.Substring(0,8);
Modules.InDomain("HomeAutomation.AlarmPanel.Sensor").Each((sensor) => {
//parameter entered in sensor setup window
var stringMatch = new System.Text.RegularExpressions.Regex(@"[^a-zA-Z0-9-]", System.Text.RegularExpressions.RegexOptions.None).Replace(sensor.Parameter("StringMatch").Value, @"").ToString();
//only look for fault code i.e. "FAULT 01"
stringMatch = stringMatch.Substring(0,8)
-
I've found that the whitespace that comes in from the panel is unpredictable (e.g. "FAULT 10 KITCHEN MOTION" could be received as "FAULT 10 KITCHENMOTION" or "FAULT 10 KITCHEN MOTION"), so I 've stripped out all the whitespace from the strings before I do a comparison. So, you'll want substring(0,7) to match "FAULT01" instead of "FAULT 01".
-
CptJack,
Did you do further development to this app?
-
I have a couple of small fixes I need to package up. I haven't done any of the setting of the panel yet - maybe I'll work on it this week.
-
I've updated the first post with a new zip and picture of the plugin. I want to do some work on notifications next, and if there's anything you can think of, I'll work on it, too.
-
The new alarm panel program and widget are working great.
The sensor program however did not work with my Vista 10PSIA, I had to revert to the old version and now all works fine.
-
I've made some updates to your app. Specifically, AlarmPanel will now raise events for the !RFX messages, which will be processed by a new Sensor Type RFX Sensor. The current app maps the fault codes to virtual sensors which works great. By mapping to RFX sensors, you get a couple of advantages:
1) You can monitor wireless sensors that are not specifically enrolled in the alarm panel.
The !RFX messages come across for any wireless sensor in range. This is useful for debugging before enrolling, or just for monitoring sensors that aren't part of your alarm network. :P
2) You can monitor all of the loops on a specific sensor.
For example, the wireless sensors in my house all have three loops. There's a loop for the builtin reed sensor, as well as a loop for wired devices (e.g. you can wire a device into the sensor itself). Thus each one of my wireless sensors can serve dual zones. Additionally, the sensors I have at my house have a loop for tamper. Additionally, my smoke alarm has a freeze sensor builtin on a separate loop. The caveat for loops is right now, a trigger for any loop triggers the DoorWindow. I plan to allow a configurable mapping of loops which trigger the Door/Window for the specific sensor.
3) You can monitor sensors even when the system is armed.
This is useful for interior monitoring and automation that doesn't necessarily need to trip the alarm. Again, this is only for "wireless" sensors. As far as I can tell there's no real way to monitor "wired" devices that are wired directly into the alarm panel, while the panel is armed. Note I said directly attached. I plan on writing the same sort of thing for wired expanders unless someone else gets to it first.
Note that you have to configure the serial number of your device as sensorsn (it's a 7 digit serial number). I'm not sure if this is a 1:1 map of the actual device SN or not. Right now the RFX Sensor is spamming the user with notifications for sensors that it doesn't know about - so you should be able to trigger your wireless devices, and see the notifications, thus grabbing the serial number. When you're done, just comment out this line:
Program.Notify("RFXSensor: " + sensorSN, "Sensor unknown, state: " + sensorState);
-
I've made an updated version of my RFXSensor mod for AlarmPanel. In this version the loops are configurable. E.g. if you have a sensor with SN 1234567 and you only want to trigger the DoorWindow based on loop2, you'd configure 1234567:2
This is useful for a sesnor like the 5816 where loop1 is 'wired' and loop2 is the reed switch. If you to utilize loop 1,2, or 4 to trigger the DoorWindow, use 1234567:1,2,4
Keep in mind that you need to use the updated AlarmPanel from my previous post, as the official doesn't won't convert the !RFX messages into events that are handled by the RFX Sensor. Maybe that can get merged in?
-
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,
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.
-
thanks. got it now. good explanation.
-
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.
-
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.
-
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.
-
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.