Paradox Security Systems DGP/EVO Alarm Plugin

Plugins & Plugin Development General Plugin Discussion
161

[quote=“93732, post:160, topic:165163”][quote=“guessed, post:159, topic:165163”]Can you grab a log file covering the period where it gets the error?
ie. Before, during and after[/quote]

Okay, I will work on getting you a verbose log. Is there a variable that I can monitor using PLEG so that I can be notified when the AL communications error occurs?[/quote]
They only happen at Vera startup/reload processing, so you could add something to your startup Lua (for Vera) that sends a notification… Or logs it etc, that would give you the boundary timeframe where it might have occurred, but there’s no quick/clean way to know that it actually did occur at that time.

162

Switched to a different USB 2.0 cable, 6 feet long. Plugin still crashes after about 24 hours – no error message until I restart the Luua. This is fixed with a soft reboot of the Vera. I have a verbose log, will parse through it this weekend. I also decided to buy a new VeraLite to test and see if it is a hardware issue.

163

Ok, cool.

It may also be worthwhile testing with a power USB hub in between Vera and the PRT3, esp as you’re running a Vera3. The FTDI on the PRT3 is already powered (by the Alarm Panel) but might as well exclude that as an issue. I’ve always run mine bus-powered, on a Vera2 and Vera3, but they’ve been backed by non-standard[sup]*[/sup] power supplies for most of their installed life, so current-supply has never been an issue (as is typically a problem with Vera3 and VeraLite units)

[sup]*[/sup]I run all my network gear from a central/custom 12v, battery-backed, PSU.

164

Guessed,

I actually have a VeraLite, not a Vera3 so there is only one USB port. In order to have verbose logging to a USB drive and have the PRT3 attached via USB, I need a USB hub. I went out and purchased a Belkin powered 4 port USB hub (model F4U040v). Unfortunately, the problem still arose.

To be clear, the problem starts when my motion/door sensors stop responding. However, I can still use the Vera to arm/disarm the panel. If I restart the Luua via the reload button at the top right, I get the AL0024 communication. If I reboot via the “Net & WiFi” tab, all is back to normal. Strange isn’t it?

Either way, I’ll get you the log soon.

165

Really odd, but the logs will really let me know what’s going on (and what’s causing the restart, that’s triggering this cycle in the first place)

BTW: I assume you mean [tt]AL002[/tt], not [tt]AL0024[/tt], and that you have the parameter maxAlarmPartitions with a value of “[tt]2[/tt]” (the default is “[tt]1[/tt]”)… This is the configuration I run with (“[tt]2[/tt]”), but it’s worth checking.

The Alarm Area (“Partition”) labels are the first thing that the Plugin fetches after it’s started, there are typically only 1, or 2, areas per system.

166

I am sorry, that was a big typo. The error code is AL001. I only use Partition 1 on my alarm.

167

The log lines are indicating that something is requesting to Arm Area “015”, which doesn’t exist.

You’ll see log lines similar to the following when this is happening:

50 03/29/14 1:07:55.328 luup_log:3: ParadoxSecurity: Unable to locate Alarm Area Device 015 <0x2d7ef680>

Unraveling this a bit, I make these calls internally when I get data from the Alarm Panel over COMBUS. For some reason though, all of the log data associated with calls from the Panel is missing from the log.

These would normally be log lines along the form of:

52 04/02/14 10:11:33.265 0x47 0x30 0x30 0x30 0x4e 0x30 0x31 0x35 0x41 0x30 0x30 0x31 (G000N015A001) <0x2fe0a680>

These lines start with “52”, and the rest is the data from the Panel (the above example is a motion sensor I just tripped in mine)

It’s possible that your logs aren’t configured to capture these log lines. You can check the [tt]LogLevels[/tt] parameter in [tt]/etc/cmh/cmh.conf[/tt], and see if it’s listing that entry (or the log line is commented out altogether, which is equivalent to “all”)

Anyhow, I’ll need those log entries to see what’s being sent over the Serial interface, to see where it’s getting the “015” Area definition from. DGP-848 Panels only have 8 Partition/Areas so it shouldn’t send anything like that.

Bottom line, I need the log lines 51 (data sent) and 52 (data recv) unfiltered so I can see how these match up with the processing performed by the plugin.

Also, while not published to apps.mios.com, there is newer code available at:
http://code.mios.com/trac/mios_paradox-alarm/export/68/trunk/I_ParadoxSecurityEVO.xml

whilst it won’t fix this issue, it has better logging (etc) and a few other fixes that would simplify the debugging process a little.

168

Thankyou for the additional logs.

Odd indeed. I fixed a minor problem where your browser was sending a value of “undefined” when you attempted to Stay Arm without a PIN Code. I’ve translated that situation into a valid value, so that shouldn’t error anymore. I normally rung Firefox, but I’m guessing you run another type of browser.

There were a few of these in the logs, followed by a correct Stay Arming request, so this checkin should address that issue.

This fix is here if you’d like to apply it:
http://code.mios.com/trac/mios_paradox-alarm/export/69/trunk/I_ParadoxSecurityEVO.xml

Tracing the logs there are two issues:
a) The PRT3 is returning “Area-015”:

52 04/02/14 21:56:17.850 0x47 0x30 0x36 0x35 0x4e 0x30 0x30 0x30 0x41 0x30 0x31 0x35 (G065N000A015) <0x2dec5680>
This will of course error out, since no Area 15 is ever possible in these Alarm Panels. I can fix the code so it doesn’t error out, but I have absolutely no idea why the PRT3 would ever return that value.

Typical values are 000 (All Areas), 001 (Area 1) and in my house 002 (Area 2) since I’ve split the sensors out.

Now, this breakage will only impact that specific request, and the code will carry on afterwards. It’s possible that some state is lost in that specific instance, since my code does attempt to respond to that data, but events are otherwise arriving correctly afterwards.

b) The Arming command you requested got Sent, but I get no confirmation from the PRT
I can see the failed stay-arming request that you sent, but each “send” is supposed to come with a corresponding acknowledgement. This would imply that some component between Vera and the PRT is not working correctly, and the data isn’t getting out, or not getting back. This is the root of the next step of analysis.

For (b), can you PM me a copy of the following:

a) Your [tt]NetworkMonitor.log[/tt] file?
I’d like to see if both [tt]ser2net[/tt] and [tt]serproxy[/tt] are running at the time of the incident.

b) Output from running [tt]logread[/tt]

c) Output from running [tt]dmesg[/tt]

My suspicion is that something is taking out Vera’s [tt]ser2net[/tt] process, or the serial port itself, at some point “past” the last valid data received from the PRT3. Scanning the above information will give me a sense for whether this is the case.

If that fails, then the next step would be to instrument the Plugin to periodically “poll” one of the Zones to determine more precisely when the middle component stops communications with the PRT3 (right now, there is a wide time range)

Thanks for taking the time to get this together. It’s an interesting problem since I’ve never seen anything like it (isn’t that always the way?)

169

Hello Guessed,

A quick question for you. I’d like to be able to be able to trigger the real PGM on the panel, as opposed to the virtual PGM. Custom Luup code would be sufficient, as I can’t find any means of doing so in the plugin. Looking through the ASCII API, I’m dubious as to the possibility, but I thought I’d ask.

Thanks again!

170

[quote=“Pestus, post:169, topic:165163”]Hello Guessed,

A quick question for you. I’d like to be able to be able to trigger the real PGM on the panel, as opposed to the virtual PGM. Custom Luup code would be sufficient, as I can’t find any means of doing so in the plugin. Looking through the ASCII API, I’m dubious as to the possibility, but I thought I’d ask.

Thanks again![/quote]
This area of the code is messy, since I really didn’t understand Virtual PGM’s and Virtual Inputs at the time I first wrote this code (4 1/2 yrs back) and even now it’s still a little hazy since I’ve not had to use them :wink:

At this time, you can interact with a Virtual Input via

luup.call_action("urn:micasaverde-com:serviceId:AlarmPartition1", "SetVirtualInput", {Input = 3, NewState = "0"}, partitionDeviceId)
a NewState of “1” will set it closed, and “0” will set it open.
the Input parameter must have a numeric value 1…16, representing the Virtual Input you’re modifying.

This [tt]ACTION[/tt] currently hangs off a Paradox Partition object, and it really should hang off the Panel object so I may change this. There are many reasons this only exists in the pre-production version of the AlarmPartition spec (which is “AlarmPartition2”, instead of “AlarmPartition1”)… this is one of those reasons 8)

But where’s the PGM?
Well, a Paradox Panel separates these Virtual Inputs from the PGM’s. Internally, within the EVO, you can tie them back together.

For the EVO’s PGM1…5, see programming sections 910…957

I’ve never had to do this, but IIUC, this example would trigger the EVO’s On-Board PGM1, for a Virtual Input (#3) that’s been mapped to EVO Zone 14[sup][size=6pt]4[/size][/sup]:

[table]
[tr]
[td]
Section[/td][td]Event
Group[/td][td]Feature
Group[/td][td]Start
#[/td][td]End
#[/td]
[/tr]
[tr]
[td]910 - PGM1 Activation[/td][td]001[sup][size=6pt]1[/size][/sup][/td][td]000[/td][td]014[sup][size=6pt]2[/size][/sup][/td][td]014[sup][size=6pt]2[/size][/sup][/td]
[/tr]
[tr]
[td]914 - PGM1 Deactivation[/td][td]000[sup][size=6pt]3[/size][/sup][/td][td]000[/td][td]014[sup][size=6pt]2[/size][/sup][/td][td]014[sup][size=6pt]2[/size][/sup][/td]
[/tr]
[/table]

Notes:
[sup]1[/sup] Zone Open
[sup]2[/sup] Zone 14, where a Virtual Input from the PRT3 has been mapped
[sup]3[/sup] Zone OK
[sup]4[/sup] For the example I’ve assumed that PRT3 Virtual Input #3 has been mapped to EVO Zone #14. Your specific mapping may be different.

171

Guessed,

Thank you for your excellent support, as always!

A quick question for you. Every few weeks, a Vera startup, or reboot will cause a problem with this plugin. Upon restart, it will fail to load along with the other plugins, and will generate an error along the lines of “Area Response label 0007” or something to that effect. I apologise for not having the exact language, as the damn thing rebooted on it’s own before I had a chance to record it. Obviously this isn’t very professional of me, and if I get it again, I’ll take note of the language. I’ve noticed this on multiple installs of EVO192/PRT3 arrangements and VeraLites, or Vera3s, on the latest UI5 firmware.

My hunch is what is happening is that the plugin is taking too long to load, so it times out. This appears to be as a result of having lots of plugins in my list, and them loading one at a time. Might you know what I’m talking about?

Appreciate it as always!

172

I’ve seen it, but it’s been so rare that it’s never bubbled to the top of the fix it list… esp how rarely I see it compared to how often I restart Vera (or, more accurately, Vera restarts itself).

I believe the “fix” might be to eliminate the auto-config stuff that I do at startup… moving this to a manually initiated action, from the Dash, would significantly lower the likelihood of it occurring (as far as I can tell) but that’s far too risky of a change, given the limited amount of time I’m spending on Vera plugins these days.

173

help prt3 paradox and remote control
Hello everyone I just ordered prt3 card for my evo paradox, and just ordered
Veralite ui6, I wanted to ask you if it works interfacing with imperihome,
'cause I wanted the tablet with wall arm and disarm alarm, and choking,
Is it possible?
thank you

174

help me
the plugin paradox is compatible with ui6???

175

I did some basic tests a few months ago using UI6, and identified a number of bugs. A number of these were visual-only and the code appeared to work, but the UI problems were annoying enough that I didn’t do a complete evaluation of either UI6 itself or the Plugin beneath that release.

After my initial stint of UI6 testing, there were enough product quality issues that I didn’t cutover. This aligns with the general recommendation on the board here, is that users should stay on UI5, or move back to UI5 if they’re shipped a box with UI6 on it (this is documented elsewhere)

I’ll leave it to other Paradox users to comment if they’re running UI6 or not.

176

Thank you for having responded to me guess you are a nice person. My problem is that in a week I install paradox evo 192 in my home. I purchased Veralite and is updated ui6! I test following the guides to go ui5 but I did not succeed! I also wanted to ask you, with the plugin you can also control the paradox of pgm evo192 to make the connecting relay on off extern?
Thank you.

177

Thank you for having responded to me guess you are a nice person. My problem is that in a week I install paradox evo 192 in my home. I purchased Veralite and is updated ui6! I test following the guides to go ui5 but I did not succeed! I also wanted to ask you, with the plugin you can also control the paradox of pgm evo192 to make the connecting relay on off extern?
Thank you.

178

@luise,
You’ll want to read this thread. In particular, your PGM question is answered on this page…

179

Thank you for having responded to the pgm I try to study me the post.
those that interest me more ‘is the downgrade I tried more’ times with firfox browser and googlecrome, but nothing does not work, you know, tell me why?

180

If you aren’t able to comfortable reverting your Vera unit to UI5 then you should contact support. They can either walk you through the process, or do it for you.