Paradox Security Systems DGP/EVO Alarm Plugin

Folks,
I’ve released the source code for the first version of the Alarm Panel/Luup interface for a Paradox Security Systems alarm Panel.

You can find the basic details here, including where to download the codebase:
http://wiki.micasaverde.com/index.php/Paradox_Alarm_Plugin

This code only works with the Paradox Security Systems “EVO” Alarm Panels, but can likely be adapted to other Panels if you’re feeling creative, and have the relevant documentation.

I’ll use this thread to take any feedback on the code, functionality (etc), and then fold the necessary changes into the Wiki page, or the Alarm Panel’s codebase.

It has some rough edges, mostly in error handling, but will suffice for folks to take a peek. I’ve been running the various evolutions of this code “live” against my house-alarm Panel for a few months now to get most of the kinks out.

This version was built using the 1.0.979 release.

Many thanks to all of the MCV Team members who’ve helped along the way (from the early days of stabilizing the IO Communications, through to the more recent UI Changes to support Status and Scene-Events)

Great work! Thanks for all your effort!

I personally will not benefit from this directly in the near future, but I would definitely use the code as a reference and as a reminder of what can be achieved… :slight_smile:

I will be putting the alarm control panel in my new home in about 2 months. I have lots
of flexibility on picking a panel and the security company tells me paradox systems are
good. Can you recommend the model that works with the software you wrote.

Frank

Hey Frank,
I have the Paradox Digiplex DGP-848, but it’s really the Printer/Home Automation module (PRT3 or APR-PRT3) that the code is interfacing with. It’s then bridging the events and commands onto Paradox’s COMBUS interface (some sort of 4 wire serial)

I believe the DGP-848 is replaced by the Paradox EVO Series (48,96 or 192 zones depending upon model) but the PRT3 interface board works with all of them.

The code is set to work with all of them since it senses the number of Partitions/Area and the number of Zones during startup.
I have keyfob remotes via it’s ‘Magellan’ interface, which can also be used for wireless sensors - all of mine are wired though.

Mine has 24 total zones and the bits are listed on the wiki. Apparently the lower end Spectra series would also work but I wouldn’t go there.

I’ve updated the Wiki just now to include Version 1.1 of the codebase, with the following key additions:

[ul][li]StayArm, Arm and Disarm of the Alarm Area now supported via Scene Actions[/li]
[li]InstantArm, InstantStayArm for “PIN-Less” Alarm activations[/li]
[li]StayArm/Arm/Disarm Features need to be enabled via Parameters prior to use[/li]
[li]Support for “Levels” of Enabling (Disabled, Stay-only, Stay+Arm, Stay+Arm+Disarm)
[/li][li]Added Prototype code to support the Alarm Panel’s 16 Virtual Inputs via Scene Actions[/li][/ul]

I’ll update the Documentation over the coming weeks with more details, but the Arming/Disarming work only if Enabled via “special” parameter values. These are disabled by default.

Once enabled, you can use them as Action-targets in scene events (as shown in the Wiki page)

The Virtual Input support for the Alarm Panel is a prototype, and may change since I only knocked it up today. It lets you setup Scenes in Vera that set inputs back in the Alarm Panel. In turn, these can be used to trigger Alarm Panel events (etc). This allows you to tie ZWave “Events” (Lights on, ZWave motion events, Bad PIN Code on Schlage etc) into things that can trigger an Alarm in the Panel.

Enjoy!

PS: There appear to be a few problems in the Vera UI Renditions for “Advanced” Scenes. Not all of the labeling and parameter validation I’ve described in [tt]D_AlarmPartition1.xml[/tt] is rendering for users creating Scenes.

This mostly impacts anyone trying to use the Virtual Inputs, so shouldn’t be a problem for now.

That is one very impressive work. I would be very interested to learn about the environment and methodology you certainly developed while working on such a massive Luup project. I suppose it’s still Eclipse, but what Lua-related components or libraries have you used? How did you deal with the fact Vera-specific APIs aren’t available on PC?

Feel free to move this into a separate topic if you will…

@325xi, thanks! Hopefully I’ll clean up the rough edges shortly.

I still use Eclipse, but mostly for it’s Editor… which is a little defeated by the .XML format of the Device files.

The best way to describe how it was built is “baby steps”.

All debugging was done “in place” in Vera, which takes time. There are times that a 2nd Vera, or an emulator, would save time, but in the grand scheme of things it’s work-able.

I started very small, and just kept adding to it. Every now and again, I’d run into a new Lua “thing” I needed to learn, and I used a free-standing Lua interpreter to try these out (such as string output formatting and parsing)

You also end up “tailing” the LuaUPnP.log file until you’re blue in the face. Watching all sorts of crazy errors going by and trying to work out what change you made that caused it. Actually that part’s a lot of fun, it reminds me of programming assembler when I was younger.

Yesterday, I left the “function” keyword out from a new method I’d written, and it took me 20 minutes to work out what was missing as the [Vera] Log message was obscure (“ expected after end”).

All along, I found myself referencing the source files of the other [built in] Plugins, in order to find examples (View/Source) of how Vera features were exposed. The Alarm Plugin pretty-much contains a Frankenstein of declarations and components from the other plugins (Actions defns, Scene Actions, Scene Events, etc, etc)

On more than a number of occasions in the early development, MCV + Team would help either diagnose some odd behavior, fix a bug (completely replacing serproxy with ser2net, Source-code length limits), or add a feature of two (CR-only delimiters, Images/Icons for Arming modes).

Oh, yeah, the initial interaction with the Alarm Panel I worked out with the Alarm reference manual along with a [Windows] Terminal emulator. I’d type textual commands and see how it responded. There’s only so much the manual describes before you need to jump to the wire protocol to see more “semantic” parts of it.

Don’t forget “backup” regularly. :slight_smile:

The Panasonic TV Plugin I have was a LOT simpler to write given the experiences of above.

@guessed, thanks for the insights! very helpful.

Will this interface continue to work and be compatible with the new GUI?

Hi,

Yes, it will. Is that right guessed? You will allow little changes to your plugin if necessary? Thank you!

Yes, it’ll continue to work. If there are material changes in any of the API’s then I’ll change/branch my code to suit, but I’m not hearing of any in the 1.1.x build series.

All of my code is really “backend” interfaces to the Alarm system, glueing standard Vera “components” (MotionSensor1 etc) atop to provide the visualizations.

There was only 1 UI Component that was added for me, and that related to Visualizing the Armed/Stay/Disarmed/Breach status. That’s in the 1.0.9xx series builds for everyone so I’m assuming an equivalent of that will be maintained, or the newer Plugin-specific .json files hinted at by the DCS Alarm stubb, will allow me to do something similarly flexible.

I also plan to see if we can get the SquareConnect folks to add more native support in a “post initial release” version of their iPhone application. Hence the interest in ensuring that all the Alarm panels are built to a standard set of interfaces… ones that the Control Pad authors (iPhone, Android, Flex etc) can all write to as well.

Great to hear that! Thank you!

ok, so I’m going to have to eat my words here. It doesn’t work on the 1.1.x series of platform.

Unfortunately I have only one Vera and I’m taking it back to 1.0.994 to get stability back into my system.

Not sure why it’s not working (the Alarm Panel, and Alarm Area devices dont show in Scene control) but I’ll sort it out in a few months once that codeline is stabilized.

For now, if you want to use it, please dont upgrade to the 1.1.x codeline. I’ll update the Wiki pages shortly to indicate the same.

Hey Guessed,

As mentioned in my PM, I have the PRT-3 module installed, and setup with Vera. At first glance it all looked good. I was able to activate the ability to arm/disarm, and it works quite well.

But now that I’m setting up some scenes, using the motion detectors to turn on lights, I’m running into a few issues. Mainly, I can’t seem to get it working. I’d really like to use the detector without having to set its “Arm” state, and I see that option when setting up my event, but regardless of the combination of settings, I can’t seem to get the light to turn on. (well it has happened, once, but then only once.) So then as I started tailing (tail -f) the Vera log to ensure that it was receiving the events I noticed something a little funny that I wanted to mention. I would open a window, and the log entry wouldn’t show immediately… a few seconds later, 5 - 10 or so I would move in front of the motion sensor a few times, and then suddenly all those events would show… almost like they were buffered, and not received until that buffer was flushed. Have you seen this happen?

If you could give me a quick example of getting the events working, I’d love to try them out and see if I’m just doing something wrong, or need to adjust some settings to get it working.

Thanks for any advice you can lend - stoked about getting this running!

Jamie

A few quick questions:

a) What Vera version are you on?
I’m running 1.0.988. I tried UI3 back on 1.1.228 (?) and it was having a bunch of problems so I reverted to 1.0.988 until UI3 stabilized.

b) Do the Vera Dashboard lights show motion when you move and/or Open a Window or Door (with the alarm disarmed, of course)?

c) Do you have a screenshot of your Vera’s Scene setup so I can validate it?

BTW: Vera’s notion of a MotionSensor has two different “states” that can be set or reset.

The states are Tripped and Armed

Only the Tripped state is set, or reset, as Motion (Alarm Motion Sensor), Open/Close (Window/Door) states occur within the Alarm Panel. This behavior is consistent with a ZWave Motion sensor, where only the Tripped state changes as Motion is sensed.

The Armed state of the individual Motion sensors that the Plugin creates is never set/reset. Again, this is consistent with a ZWave Motion sensor, leaving the Armed state/flag alone so that folks can do creative things with it (you’ll see what I mean once you’ve had it for a while)

The Alarm Panel Device itself supports the overall notion of Armed, Disarmed, Breach, Stay-Armed (etc), with the associated Events for scene scripting (which is what I use most, to SMS notify me)

oh, and one other thing. In 1.0.988 (UI2) the logs are buffered somewhat (which is appropriate).

If you switch on Verbose logging (temp) you’ll see a general background noise of logging that’ll help flush out the logs for the Alarm stuff. If you don’t do that, the event still occurs at the same time, but the log output will appear “delayed” (in tail -f) due to this buffering. You’ll also start to see Debug logging from the Alarm Panel code that’ll tell you (more or less) whether the raw events are working correctly… like this:

[tt]06 03/08/10 17:41:22.923 Device_Variable::m_szValue_set device: 46 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 0 now: 1 #hooks: 0 upnp: 1 v:0x83edc0/NONE duplicate:0 <0x3c10>

01 03/08/10 17:41:22.927 luup_log:35: 001:Zone is Open, 010:Bedroom #2 (Zone 10), 001:Area 1 <0x3c10>
[/tt]

Hi Guessed,

A). running 1.0.979 - any changes between this and 1.0.988 you developed against that would mandate my upgrade?

B). They do, a little slow compared to the immediate update at the alarm keypad, but I imagine it’s the web interface causing the slight delay of a few seconds.

C). attached.

PS - thanks for the buffering info, I’ll give that a shot tonight.

Thanks,

Jamie

@jamie,
on 979 vs 988…
For what you’re doing there’s no material difference. I was just checking you weren’t running UI3 (1.1.2xx) since I had a bunch of problems getting it to run there.

on Keypad…
I’ve set one of my keypads to “beep” when a Zone is opened. This allows me to debug remotely from my office by opening/closing a window (etc). The Keypad beeps so I know when the Alarm Panel itself has recognized the event as occurring.

There’s usually a 1-2 second delay between that beep and the log being written (assuming verbose logging and the flush) so it’s fairly quick. Note that I’ve configured to use 57600 Baud transfer rate on the APR-PRT3, not the default (which I think is 9600baud), just in case that’s introducing extra delays. There’s a note about that in the Wiki.

The beep action can be set directly on each keypad (it’s a preference, like the backlighting etc) and is handy for trialing this stuff.

on Event defns…
It looks correct. Let me try it tonight just to see if I broke something recently. I tend to use notifications (email/SMS) on the Primary Alarm Events, and not too much on the discrete sensors).

If you run it with Verbose, and capture the log for me, then I’ll take a look to see if there’s anything obvious. You can PM me with the location of that log (box.net etc) so it needn’t be published here.

PS: The Device Labels for each MotionSensor in Vera will follow those defined in the Alarm unit. If you use Mixed case there, then they’ll be mixed case in Vera. you can change them anytime, and just “restart” (Save, in Vera) and it’ll reload the labels :wink: I went through and manually mixed-case my labels after the installers left to make them read nicer in Vera.

Thanks, I’ll be interested to see if anything turns up with the discrete sensors/scenes… I believe the Primary Alarm Events are functioning just fine, but will run a few tests tonight just to see if I’m having bigger issues.

Oh, and yes, I set the PRT-3 and Vera to 57600, and actually have been using the beeps at the keypad as you are for testing.

Thanks for the heads up on the case of labels… it really doesn’t bug me too much, but nice to see that I’m not the only one with a lazy installer! :slight_smile:

Jamie

Here’s what I have so far…

If I attach a Scene defn similar to yours (except I dont put in the “after 10 mins” bit), then I can get it to fire once after opening the Window (to which the Virtual MotionSensor device is attached by my AlarmPanel code)

If I repeatedly Open and Close the Window, after a few attempts I will eventually cause Vera to emit a lock problem, and associated trace info which looks something like:

[tt]07 03/09/10 18:03:41.238 Event::Evaluate 21 Guest Window is true <0x3c10>
08 03/09/10 18:03:41.239 Scene::RunScene running 22 Guest Window <0x3c10>
08 03/09/10 18:03:41.240 JobHandler_LuaUPnP::HandleActionRequest device: 11 service: urn:upnp-org:serviceId:Dimming1 action: SetLoadLevelTarget <0x3c10>
08 03/09/10 18:03:41.240 JobHandler_LuaUPnP::HandleActionRequest argument newLoadlevelTarget=50 <0x3c10>
06 03/09/10 18:03:41.241 Device_Variable::m_szValue_set device: 11 service: urn:upnp-org:serviceId:Dimming1 variable: LoadLevelTarget was: 50 now: 50 #hooks: 0 upnp: 1 v:0x7945b0/NONE duplicate:1 <0x3c10>
01 03/09/10 18:04:11.008 Failed to get lock(0x6b6410) Variable: …/ZWave/ZWJob_SendData.cpp:130 last used luc.h:113 first used Device_LuaUPnP.cpp:348 thread: 0x3c10 (>4851) handler 0x4295cc bOkToFail 0 <0xc04>
02 03/09/10 18:04:11.015 Dumping 13 locks <0xc04>
02 03/09/10 18:04:11.016 finished check for exceptions <0xc04>
02 03/09/10 18:04:11.017 finished check for exceptions <0xc04>
02 03/09/10 18:04:11.017 finished check for exceptions <0xc04>
02 03/09/10 18:04:11.019 OL: (0x6b63a0) (>2445) ThreadedClass …/JobHandler/JobHandler.cpp l:389 time: 4:00:00p (1268186651 s) thread: 0x400 Rel: Y Got: Y <0xc04>
02 03/09/10 18:04:11.019 finished check for exceptions <0xc04>
02 03/09/10 18:04:11.020 OL: (0x6b63a0) (>4839) ThreadedClass Device_LuaUPnP.cpp l:329 time: 6:03:41p (30 s) thread: 0x3c10 Rel: Y Got: Y <0xc04>
02 03/09/10 18:04:11.021 finished check for exceptions <0xc04>
[/tt]

followed eventually by

[tt]01 03/09/10 18:04:11.067 Deadlock problem. going to reload and quit <0x3c10>
[/tt]

followed by the normal restart sequence of messages. I suspect your Vera is doing the same, which would definitely account for the “I got it to work once” comment.

MCV is currently helping someone else, so I’m going to submit a ticket with the details so it can be tracked here. Definitely a nasty bug.