Paradox Security Systems DGP/EVO Alarm Plugin

Plugins & Plugin Development General Plugin Discussion
101

Hi Guessed,

Thanks for your prompt response.

I definitely am at the beginning of the scale and not fluent with programming apart from just being able to modify an existing one slightly.
If I read your email correctly I am happy to help, trial / test and understanding this would potentially be commercial in the future and also happy to donate / pay… I’m just tinkering with it for personnel use it all started by wanting to control my sprinkler system remotely next my basic home alarm stopped working I looked at options ended up with Paradox unsure if there was a cheaper easier option …the supplier is around the corner from my work which has been helpful for setting up programming etc :slight_smile: and now here I am on a great journey thanks to this forum and great people like yourself !!.

Status with the current unmodified Paradox 1.51 app on UI5:

  • Remote Keys Triggers Arm and Disarm, quick arm enabled or disabled.
  • User Codes Triggers Arm and Disarm, quick arm disabled, does not arm with quick arm enabled.
  • iParadox iPhone app triggers arming, does not trigger disarming.

When I am home tonight will obtain the Ascii info on the above and update here.

Updated with File:

Scully

102

[quote=“beerygaz, post:95, topic:165163”]That’s for the quick response. Here are some of the things I’m struggling with:

  1. Do you poll the area status on zone status change to see if the area has gone from ready to not ready?[/quote]
    No, I don’t poll any of the Zones to do that. The Paradox implementation initially was fairly simple, in part because it was the first Alarm system integrated with Vera.

From it, we learn’t a lot of lessons, and as the community added more Panels we quickly determined that we needed a common “language” to express the states that our Panels were in, along with the Services needed to standardize the way they’re exposed to Control Points (UI’s)

Things like “[tt]Ready[/tt]”, “[tt]NotReady[/tt]” (etc) are these common states. Right now, we each have to find the corresponding points/events in our respective panels where we “attached” (set) these states.

Think of it as a super-set representation attempting to represent all types of Alarm panels… at least that was it’s goal.

In the Paradox, right now, the Ready/NotReady states are only set at Startup/initialization. After that, it moves to things like “[tt]Disarmed[/tt]”, “[tt]ExitDelay[/tt]”, “[tt]EntryDelay[/tt]”, “[tt]Armed[/tt]” (etc)

For the Paradox impl, in reality, “[tt]Disarmed[/tt]” should move to “[tt]Ready[/tt]” state after some-period-of-time. From what I’ve seen, events wise, the keypads must be doing something like that… since there’s always a delay (but not necessarily a corresponding COMBUS Event)

2. Do you set areas to just 'armed' or do you distinguish between force/instant/stay
Both. [tt]ArmMode[/tt] is simple Armed/Disarmed flag, for simple scripting. [tt]DetailedArmMode[/tt] is a full blown Arming state model, with all sorts of intermediate and/or transient states represented... for those that want fine detailed script options.
3. In a screenshot I saw you had a 'bypass' button - is that implemented?
Vera's default UI component for a Motion Sensor includes a Bypass Button. This is not wired to the Paradox in any capacity, but there are [Vera] triggers for "armed motion" and "motion", so users can do stuff with it.

Even if I could implement Zone Bypass, and pass it through, I wouldn’t do it. On a real panel this option requires some sort of AuthZ, but doing it via the Vera UI would require that PIN Codes (etc) be hardwired into the Config… which I’m not a fan of.

4. Do you set the area status to armed/disarmed immediately or do you handle exit/entry delay somehow? I can't work out when an entry/exit delay terminates.
Yes, it's a problem. There doesn't appear to be a clean "end of arming" state. I use several, in concert, to work it out... which is trickier than it needs to be.

The Paradox has a few flags that I mostly use for this and there’s [currently] one case where I need to put a timer in to ensure I don’t do a double transition (from Disarm → Stay, then onto Arm). That part of the code is a bit messy.

I also own the DSC Alarm code, it’s a LOT simpler/clearer to do it there because the terminal states, as well as the transitional states, are well documented and cleanly exposed.

These are som of the things I'm struggling with. In addition I often get a message for area 16 when my panel only supports 8. And I get a lot of G004N020A000 events?!
I currently have a DGP-848, so it's possible some stuff is different in the newer models. I've never seen an Area [tt]16[/tt] message. In mine, I see events for Area "[tt]001[/tt]" (My core Security partition), Area "[tt]002[/tt]" (I isolate for Automation) and the Broadcast/Any Area "[tt]000[/tt]"

[tt]G004N020A000[/tt] = a Non-Reportable Event of type 20, which isn’t documented… which is why I’m assuming you’re asking.

No idea. I wouldn’t worry about it, unless its just an interest-item.

If I really wanted to work it out, I’d attach WinLoad to the onboard Serial port and find out, but it’s not worth it (from a practical automation perspective)

103

I’m not planning on taking it commercial on Vera, as the platform isn’t stable enough to do that (in my experience) and would likely create too many support calls for any net-value.

I originally did it because I needed it. I’d be interested to know who your supplier is for components, since it’s v. hard for me to pickup stuff (apart from eBay, where I have TONS of it)

I'm just tinkering with it for personnel use it all started by wanting to control my sprinkler system remotely next my basic home alarm stopped working I looked at options ended up with Paradox unsure if there was a cheaper easier option ....the supplier is around the corner from my work which has been helpful for setting up programming etc :) and now here I am on a great journey thanks to this forum and great people like yourself !!.
That's definitely how the "bug" starts. I have about 40 Z-Wave nodes active, 2 Nest T-Stats, a 8x channel Web PowerSwitch, 26 Zones of Alarm Panel monitoring, 3 Sonos units and drivers for TV, Sat and Amp.... not to mention about 15 Z-Wave switches in boxes waiting for me to decide which system will replace Vera (and be stable)
Status with the current unmodified Paradox 1.51 app on UI5: - Triggers Arm and Disarm with remote keys, quick arm enabled or disabled. - Triggers Arm and Disarm with user codes, quick arm disabled, does not work enabled. - iParadox iPhone app triggers arming, does not trigger disarming.
The tests I normally run include arming via Keypad and KeyFob, since these appear to trigger different sequences of COMBUS event messages on the PRT3. I'm DEFINITELY interested to see how the sequence of events occurs for iParadox, since I don't/can't have that (I have an older DGP-848 model)

It just takes time for me to execute them since, unlike the DSC, I don’t have a test system and have to wait until the Family is out of the house. I’ve slowly been assembling a second system from eBay components, but some of the parts I just have to acquire since they never come up (PRT3) … hence the reason to ask your supplier. I can PM you and Email address, if you’d rather not post that info publicly.

Despite the oddities of the automation board, component pricing and US availability I love the Paradox system, it’s very solid, with no real false alarms and amazingly robust Motion sensors.

104

First, thanks so much for the detailed reply. I’m glad I’m not the only one experiencing some of the frustrations. (I guess misery loves company).

No, I don’t poll any of the Zones to do that. The Paradox implementation initially was fairly simple, in part because it was the first Alarm system integrated with Vera.[/quote]

I’m at a crossroads here. I have a device that represents each Area (Partition in other panel parlance). I thought it may be useful, at a glance, to see whether the area was ready to be armed, or some zones in that area were open. I know you could look at each zone to deduce this, but without knowing which zone is associated with which area it can be tricky in a big system. So as you say, going from Disarmed to Ready/Not-Ready over time would be a nice touch. OF course, the panel doesn’t report this status, you need to query it with an RAxxx message. So right now, every time I get a Zone status change message I send a corresponding RAxxx message to update the Ready/Not-Ready status of the area device.

From it, we learn't a lot of lessons, and as the community added more Panels we quickly determined that we needed a common "language" to express the states that our Panels were in, along with the Services needed to standardize the way they're exposed to Control Points (UI's) ... Think of it as a super-set representation attempting to represent all types of Alarm panels... at least that was it's goal.

I like the idea of starting from a common interface and then adapting the data from different panels to reflect that common representation. Unfortunately I think the HS community didn’t start from that perspective and now different plugins for different panels have popped up, all with different interpretation - it’s shame really.

For the Paradox impl, in reality, "[tt]Disarmed[/tt]" should move to "[tt]Ready[/tt]" state after some-period-of-time. From what I've seen, events wise, the keypads must be doing something like that.... since there's always a delay (but not necessarily a corresponding COMBUS Event)

I see WinLoad reflects this too - the event window shows “Exist Delay” and “Exit Delay Over” events.

3. In a screenshot I saw you had a 'bypass' button - is that implemented?
Vera's default UI component for a Motion Sensor includes a Bypass Button. This is not wired to the Paradox in any capacity, but there are [Vera] triggers for "armed motion" and "motion", so users can do stuff with it.

Even if I could implement Zone Bypass, and pass it through, I wouldn’t do it. On a real panel this option requires some sort of AuthZ, but doing it via the Vera UI would require that PIN Codes (etc) be hardwired into the Config… which I’m not a fan of.

While I’m happy to store a hashed version of a user code in my plugin, I can’t find any way of implementing bypass. I’d be happy to forgo this, but would really find it useful to reflect whether a zone is bypassed or not in the zone status devices, but I can’t find a reliable way to identify whether a zone has been set to bypass or not. Something that I think could have easily been implemented in the RZxxx response.

4. Do you set the area status to armed/disarmed immediately or do you handle exit/entry delay somehow? I can't work out when an entry/exit delay terminates.
Yes, it's a problem. There doesn't appear to be a clean "end of arming" state. I use several, in concert, to work it out... which is trickier than it needs to be.

The Paradox has a few flags that I mostly use for this and there’s [currently] one case where I need to put a timer in to ensure I don’t do a double transition (from Disarm → Stay, then onto Arm). That part of the code is a bit messy.

I have a similar issue here. When setting the panel to “Armed” I get Disarmed->Armed->Exit Delay->Armed. But when setting it to “Stay” I seem to get Disarmed->Stay->Armed->Exit Delay->Armed->Stay - So it’s getting tricky to distinguish between whether the penal is “Armed” or “Stay Armed” and given the fact that the user can elect to trigger events based on this status, right now I’m triggering all manner of duplicate events.

It sounds to me like you’re maintaining some sort of state table that tries to correlate a sequence of messages from the panel into a single event to reflect in your code. I was hoping to avoid this and react to each message individually. To implement the former it strikes me you’d need to know all the permutations in order to handle them all successfully and not end up in some strange “limbo” state. (For instance, I noticed that if my panel goes into a troubled state while in exit delay, all manner of additional messages are received).

I also own the DSC Alarm code, it's a LOT simpler/clearer to do it there because the terminal states, as well as the transitional states, are well documented and cleanly exposed.
Ah how I long for my DSC panel back. I was happy then ::)
These are some of the things I'm struggling with. In addition I often get a message for area 16 when my panel only supports 8. And I get a lot of G004N020A000 events?!
I currently have a DGP-848, so it's possible some stuff is different in the newer models. I've never seen an Area [tt]16[/tt] message. In mine, I see events for Area "[tt]001[/tt]" (My core Security partition), Area "[tt]002[/tt]" (I isolate for Automation) and the Broadcast/Any Area "[tt]000[/tt]"

[tt]G004N020A000[/tt] = a Non-Reportable Event of type 20, which isn’t documented… which is why I’m assuming you’re asking.

No idea. I wouldn’t worry about it, unless its just an interest-item.

OK, we’re on the same page, ignore the undocumented stuff - and I think I’m getting area 16 as an equivalent of area 255 in my configuration.

How do you manage situations like low battery, loss of supervision, tamper, etc? A zone can be open/closed/in alarm but it can be those other states simultaneously. The same goes for an area, which could be “armed/trouble”, “armed/OK”, “disarmed/trouble/zone-in-memory” etc. Or did you elect to ignore that additional data?

I elected to add two devices for each zone and area, one to reflect primary states, and another to reflect additional information (low battery, trouble, etc) but it makes things a little messy. The only other option was to have a huge number of possible states for every permutation - which is also messy.

105
First, thanks so much for the detailed reply. I'm glad I'm not the only one experiencing some of the frustrations. (I guess misery loves company).
It's just an interesting challenge to solve ;)
I'd be happy to forgo this, but would really find it useful to reflect whether a zone is bypassed or not in the zone status devices, but I can't find a reliable way to identify whether a zone has been set to bypass or not. Something that I think could have easily been implemented in the RZxxx response.
I believe it might come in on the G023 messages, on some panels, but I never pursued it, because I didn't want to mess with the user-state Bypass (what Vera users use it for) *and* if I miss the delivery of that Panel event, then I have no way to catch it again (no poll)

As you say, the Bypass state should hang off the [queryable] RZ responses.

How do you manage situations like low battery, loss of supervision, tamper, etc?
I don't attempt to implement everything on the Panel, it's just too broad for that. There are certainly more things I *should* implement, like Battery stuff, since I can just attach that to the device services Vera already exposes for Battery level (it's a Level in Vera, but I'd convert it to "0%" if I got warnings, and have to work out a way to poll/clear it once the condition passes)

For general stuff, we hook a “Vendor Event” into the common service we defined. People can use that in scenes, with the knowledge of how to interpret the low level [Vendor specific] event/message and do whatever they want. That’s the general out-clause for stuff that cannot be mapped.

So far, I haven’t needed to do that, mostly because I can still read the [3] Keypads I have that’ll tell me there’s a Battery problem in the few battery devices I have.

It’s also hard to test, since you have to simulate a lot of stuff to trigger those events. I applied the 90/10 rule here, and stopped implementation. 8)

For the most part, I was not looking to replicate my Alarm system in a clunky HA UI, I was instead looking to automate certain things that “required” alarm state.

eg. “Turn off the Nest T-Stats when I leave the house, turn them back on when I return”
eg. “Turn off the Amp, TV, Lights, etc, when I leave the house”
eg. “Lock the doors 30 seconds after the house is armed”
eg. “Disable the AirConditioner when I open a Window”
eg. “Turn on lights as I move around the house”

These are done with the “90” part of the “90/10” and the rest relies upon the traditional keypads. It also puts some of this stuff into perspective, since it’s going to be a lot of work to get little additional value (for the typical usage)

106

guessed,
Gees 40 I will probably end up there one day ;D , please PM \ email me re bits.
Updated my previous post with the ASCII file including iParadox, noticed something else afterwards in iParadox if you use “instant” or “stay” it will disarm, if you use “Arm” it will not trigger disarm. (In iParadox there is 4 buttons Arm, Instant, Stay, Disarm)

morpheus \ guessed
Ran the quick arm txt file as is in “developer apps\luup files” and no joy on my 1.51 app :frowning: , do I need to edit or drop out the first line in the txt, or have I totally loaded it wrong ,or need the latest app version ?

Scully

107

@rscully,
@morpheus’s patch proposal needs to be merged into the corresponding lines of your existing [1.51] based I_ParadoxSecurityEVO.xml file.

You can do that by doing the following:
a) downloading the I_ParadoxSecurityEVO.xml file from your existing Vera unit,
b) make a backup
c) opening it in a [PLAIN-Text] editor (preferably not under Windows, since they tend to corrupt the files)
d) adding in the designated line at/around line 1550
e) Re-uploading the I_ParadoxSecurityEVO.xml file to Vera

What I did to work out how the various “devices” were Arming/Disarming, is to monitor the log files (with Verbose-logging enabled) for the codes as they went by. This gives me the sequence of what the APR3 fires off during various Arming/Disarming activities (with each device, these appear a little different)

In order for iParadox to work correctly, I’d need the sequence from your [Verbose] log files, covering a time period where you’re performing the actions with iParadox.

I will PM you my Email address.

108

Does anyone know if the VeraLite and PRT3 adaptor will work with a USB over ethernet adaptor like this one?

LINK

109

@93732,
The PRT3 has both a USB and an RS-232 connection. You can use either (but not both) for HA purposes.

I imagine you’d just run a longer RS-232 cable (DB-9), and then put a standard (FTDI) USB-Serial adapter at the end that plugs into Vera.

The other option, if you want to relo the PRT3, is to extend the Combus wiring. I have mine going over a [short] run of CAT-5, using “pairs” of the CAT-5 bundle (4 pairs, 8 wires total). This allows me to have the PRT3 near Vera, and the Combus wiring is dragged through the wall to the Panel.

I tried one of those USB Adapters once before, and was not reliable. Note also that it’s an extender over CAT-5, not Ethernet. It’s just using the wires in the wall, and not Ethernet framing/switching.

110

@guessed,

Thanks for the quick and thorough reply. I will avoid the USB adaptor based on your advice. First, I see how my VeraLite works when located near my Paradox board. If not, I will try moving the PRT to another location. I am still in the planning stages right now and have not purchased the PRT module yet.

111

When powering down a Digiplex-848 to install the PRT-3, is the configuration/memory (zones, labels, user codes, etc) erased?

I tried search the forms and this thread but could not find the answer.

112

Nope. All of your setting will be retained. You will need to configure the PRT-3 however. The easiest way is via WinLoad but it can be done via a keypad too.

113

When I set mine up, I did it via the Keypad. There aren’t that many settings, so it’s not that big a deal.

I’ve since bought a 307USB and Winload, and that’s a lot easier if you’re going to mass-edit your configuration… but is probably slower for simple changes (like just setting up the PRT3)

PS: You’ll find hints of Paradox config here and there within the thread, but in general I’ve avoided documenting that stuff since we’ll get cluttered with that information fairly quickly. For the most part, I just followed the sheets that came with the various devices (I have a lot of extras attached to it since I initially got the system)

114

Thanks for the reply. That will make installation of the PRT-3 a lot easier knowing that it retains the settings. I’ll do it via the keypad as guessed did. I’ve become pretty sufficient at programming the DGP-848, adding in wireless receivers and dectors, etc.

Its nice to know that MiOS and Vera have active dedicated communities. I’m sure I’ll be back with more questions. Once I get my setup up and running, I hope to answer others questions someday as well.

115

Hello everyone,

I have successfully connected my PRT3 to DGP-848 panel, I can see the status when connected via HyperTerminal (all these GC**** events), but for some reason it doesn’t accept any commands, e.g. if i try to use ZL001, it doesn’t respond anything.

Did I forget to make something? Home automation is enabled for sure (cell 016 in PRT the first 4 bits are set to one - enable home automation with 57600 baud, the rest are off - ASCII protocol).

Please let me know what else I can do.

116

Re-read all the documentation, tried everything - still no luck, the module seems to work only in reporting mode.

I’d appreciate any help or comments.

117

Got it to work by switching the home automation off, and then on again via keypad menu.
Finally.

118

Does anybody know how to get the user code the system was armed/disarmed with? I tried to use detailed trigger, but it doesn’t trigger whenever the system is armed/disarmed.

Any advice is appreciated.

119

[quote=“VictorMSK, post:118, topic:165163”]Does anybody know how to get the user code the system was armed/disarmed with? I tried to use detailed trigger, but it doesn’t trigger whenever the system is armed/disarmed.

Any advice is appreciated.[/quote]
The Paradox supports the same “LastUser” variable that’s part of the alarm panel standard. So you can use Luup code like this example from DSC to access it:
http://forum.micasaverde.com/index.php?topic=12529.0

120

Thanks a lot for your reply.

The problem is that the LastUser is not a usercode, but the programmed name, and my system is in Russia, therefore, cyrillic characters are not transmitted correctly. Is there a way to get a usercode instead of the username? There is no way to program names in latin, as the whole system is in russian and no latin symbols available.