Alarm Panels and interface standardization

Plugins & Plugin Development General Plugin Discussion
#21

That sounds awesome! I thought the DSC plugin was no longer maintained. Besides the PIN code padding fix, I was going to just align it to the GE CADDX (AlarmPartition1) service definition anyways. I would love to test it when you are ready.

I will come up with a state diagram for the DSC panels in the next couple of days.

BTW, I’ve contacted the iVera guys and they are happy to add alarm panel support. They want to look at how the plugin worked in my Vera. Since I don’t have the “standardized” DSC plugin ready, I’ll just point them to this post for now. Where can I find the version 1 API so they can have at least something to look.

#22

Hello all,

My name is Alfonso and I've been working with MCV for a few months now on linux/Z-Wave type stuff. I was assigned to work on developing an ELK alarm panel plugin and have it be the example of a plugin according to some kind standard that all of us developers can agree upon.

Guessed,
Is your updated DSC code available? I’d very much like to make sure I’m working towards the same set of states/actions/logging style that you are and put the ELK plugin on the wiki as the reference implementation for alarm panels. I’ll post information on the forum as development progresses.

#23

[quote=“alfonso, post:22, topic:166000”]Guessed,
Is your updated DSC code available?
I’ll post information on the forum as development progresses.[/quote]
Not yet, I prefer not to post partially complete code, since people might start using it :wink:

I’ll be working more on it over the weekend, but only to the “v1” spec already implemented in the Paradox and GE codebases

In the meantime, whilst you’re waiting for me to get that out for the DSC, please Diagram the model of the Elk Arming states, and Alarm states, similar to what’s been done above. We need this to make “v2” of the interface definition that we can all align to (and ultimately get the control point vendors to implement also). There are shortcomings in the v1 spec as I slapped it together when I wrote the Paradox (without benefit of understanding of the other panel interactions.

For V2, no code at this time please, Model diagrams only so we can converge on a API interface proposal

#24

@alfonso, how did you go getting the State transition diagram together for the Elk? Really like to get yours in so we can get some closure on a proposal for “v2” of S_AlarmPartition.xml (etc)

Definitely want to ensure that the Elk is covered also.

#25

Here is the DSC state diagram:

#26

@diitalperk, thanks for taking the first stab at the DSC diagram, I think it’s got a good representation of the primary states (particularly like the Ready and Not Ready ones).

I think we need to separate out the Alarm-based states, as “sub-states” of an “armed” (stay, instant, arm, etc, etc) state. Having worked with this panel for a few weeks now I see that, like the Paradox, it never really “exits” the Armed state it’s in when the Alarm goes off. Instead it stays in whatever Armed “mode” that is, and has it’s own sub-state transition for the Alarm states.

This is what I was trying to diagram in my 2nd Paradox diagram.

More and more I’m leaning towards having a “macro” state (simply “Armed/Disarmed”) followed by sub-armed states (like "Armed/Ready/NotReady/StayArmed/Instant/Force/etc, etc) and then the Alarm states (which I really haven’t thought of in detail but would include “None/Alarm/PriorAlarm” or something like that)

Thoughts on the diagram changes?

#27

You are correct about the alarm states and it wasn’t clear from my diagram. I strongly like the Armed/EntryDelay/Disarmed/ExitDelay “macro” states with the sub-armed states. Since the alarm sub states are the same for whatever arming state the panel was in, couldn’t we just separate alarm (true/false) variable? What are some use cases for having a priorAlarm state?

#28

@alfonso, care to chime in with information, and a diagram, relative to the Elk?

We’d like to have a complete picture if at all possible. If you’re not ready, we can certainly move it forward without the Elk, but that’ll make it harder for you to align later on (if the model is fundamentally different, etc)

#29

Just another “rev” of a theoretical [tt]S_AlarmPanel2.xml[/tt] to get the discussions going.

I’ve broken out a “high level” [tt]State[/tt] of simply [tt]Armed[/tt] or [tt]Disarmed[/tt], as separate from a [tt]DetailedState[/tt] showing all the intermediate states.

For now, I have left the [tt]EntryDelay[/tt] and [tt]ExitDelay[/tt] as a [tt]DetailedState[/tt] only, with each Panel working out whether they represent “[tt]Armed[/tt]” or “[tt]Disarmed[/tt]” since there are differences for [tt]ExitDelay[/tt] interpretation across Panels.

…but that’s certainly up for discussion.

I haven’t worked out how to handle the Armed + Alarm + AlarmInMemory state indicated by @futzle’s diagram, nor how to handle the potential additional Detailed Alarm states for Fire/Panic/Emergency (might have the same parallel I draw above, except Alarm ([tt]None/Active[/tt]) and DetailedAlarm ([tt]None/Memory/Emergency/Fire/Panic[/tt])… not sure how best to handle that…

The additional Arming modes (Force, Instant and Armed-Instant (??)) don’t yet have methods to activate/request.

#30

btw, I really want to know what a “Violated Burglar” is in this screenshot:

 http://www.cocoontech.com/portal/articles/news/25-apple/429-ekeypad-alarm-is-now-free

sounds quite funny… :wink:

#31

Forgot to mention, I also removed the “setVirtualInput” block from the bottom, since I’ll relocate it to a Paradox-specific Service.

#32

I think it might be more flexible to group some of the related sub-states as separate variables. This will allow for possible combination states that different panels have.

Every implementation should have these variables:
Status: boolean - Current armed status. Should use boolean for binary value.
Target: Disarm, Arm, ArmAway, ArmStay, ArmInstant - The target state requested. Disarm and Arm should be required while others can be implementation specific. UIs can use this to highlight the selected button.
Alarm: boolean - Current alarm status

Implementation specific variables:
DetailStatus: Disarmed, Armed, ArmedStay, ArmedAway, EntryDelay, ExitDelay, ArmedInstant, etc… - ArmedStay and ArmedAway should be required while others can be implementation specific.
Ready: boolean - Separate to handle possible combo state: Armed + Exit Delay + Not Ready. Could also be used for a Ready LED on the UI.
DetailAlarm: Burglary, Fire, Panic, Emergency, etc… - Burglary should be required while others can be implementation specific.
AlarmInMemory: boolean - Separate to handle the Armed + Alarm + AlarmInMemory state indicated by @futzle’s diagram.
LastAlarmActive
LastUser
LastStatus

For the actions, should we just have SetTarget with different values from the Target variable? This allows the implementations to add their own states without adding actions. The request panic actions are fine.

What do you think?

#33

Hi everyone,

I must say that the several-variables approach appeals to me. It’s clear from all of the state diagrams that all of the panels have subtly incompatible ideas about how delays and alarms and armed states are implemented. It’s likely that the only way we are going to have useful states that users can derive scenes from is to have very broad macro-states.

Apart from choosing a data model that fits the panels, it’s important that we pick a data model that is useful to users. Examples:

  • Do the states cover what users want to see in the UI? I’m thinking of the user logging into the web UI to see what’s happening to the security system back home. (Example: I’ve already had a request for the Caddx panel to tell the user of an alarm that has occurred and already reset before the user logs into the UI.) These are long-term “states” in the true sense of the word. I think we are close to achieving this.

  • Do the states cover what users need to program their scenes? I’m thinking of the user getting a notification when the panel is armed or disarmed (“The kids are home”), when the panel fails to go from Exit Delay to Armed (“you left a window open; go home and re-arm the system”), when the panel is disarmed and a zone is triggered (“turn on the hall light”), and so on. These are more transitions than real states per se. I think we are still a way off getting this right.

I don’t think that Luup devices do transition-style events well. I’m open to ideas about how better to handle this.

#34

Some interesting info about the Elk, since I’m revising the [tt]S_AlarmPartition2.xml[/tt] with some of the feedback here and wanted to see what influence it would have (in absence of Alfonso contributing here)

A few “night” modes we hadn’t accounted for, but seem reasonable:
[url=http://www.automatedliving.com/forums/showthread.php?t=2856]http://www.automatedliving.com/forums/showthread.php?t=2856[/url]

A full blown event list:
[url=http://www.elkproducts.com/downloads/ElkRM/Events.xml]http://www.elkproducts.com/downloads/ElkRM/Events.xml[/url]

I’ve added “[tt]Night[/tt]” and “[tt]NightInstant[/tt]” to the DetailedStates, and moved “[tt]Instant[/tt]” to “[tt]StayInstant[/tt]” to clarify it’s usage.

Moved “[tt]Alarm[/tt]” to be a boolean to make the minimalist alarm implementation simpler. Broke out “[tt]AlarmMemory[/tt]” as a separate Boolean for the Prior Alarm state representation.

Added in [tt][/tt] tags into the Service Decl file for each StateVariable.

Moved from [tt]LastStatus[/tt] to a tuple of StateVariables:
[tt]VendorStatus[/tt]
[tt]VendorStatusCode[/tt]
[tt]VendorStatusData[/tt]

descriptions included, but intended as an “escape” to let people do Vendor specific eventing (data that would also be required for the .json Events file for MiOS)

I haven’t changed the Actions as yet, and need to add [tt]DetailAlarm[/tt] (not sure this is a single-state kinda thing between the “Panic” states, and the regular Alarm states). I’d like to hear input based upon people’s vendor-specific knowledge.

The “instant” version of the various arming modes (Arm, Stay, Vacation, Night) might just become a boolean parameter to the various methods. Would like to have convenience methods for each of these, even if we end up with a “common” [tt]requestArmedMode(…)[/tt] type action to handle all the other Vendor specific methods.

@digitalperk, thanks for your input on this!

@futzle, can you elaborate what improvements you think are needed to handle the cases you outline? I’d like to start driving this to ground so we can each go off and prototype against it.

PS: I will check something into my source control system shortly so we can “diff” the various evolutions of what’s being proposed here.

At some later point, we can move onto standardizing a S_AlarmPanel1.xml for the Panel itself, since some of the concepts here are applicable at that level (like Status’s for Battery and AC Failure etc)

#35

I’d like to apologize for my lack of communication on this matter. I had been pulled off the Elk plugin temporarily to work on collecting data for some advanced Z-Wave routing issues that has finally yielded a response from Sigma. Aaron will be posting more information soon, but we’re working on a workaround and Sigma is working on a fix to a big bug that’s plagued Z-Wave routing for a long time.

Now… back to alarm panels.

The elk, as you’ve discovered, has some arming states that aren’t present on the DSC panel(Vacation, etc). I think the best way to ensure a compatible interface is an action like you suggested. requestArmedMode(int zone/partition/area, int mode, bool instant). We can say that disarm/away/stay are modes 0, 1, 2 and leave the rest of the modes up to the specific implementation. This should allow interface developers to have a universal way of arming/disarming an alarm panel, while still allowing for N custom alarm modes.

Also, here is V0 of the ELK plugin, that doesn’t implement any of the ideas in this thread, if anyone is interested. I’ll be working on modifying the interface to make things more standard in the next couple days, but I needed to get something to some people interested in getting started on ELK/Vera integration asap.

#36

forgot to attach…

#37

@alfonso,
What we most need at this time is a MODEL Diagram showing the states, and transitions, for the Elk… per my original comment:

In the meantime, whilst you're waiting for me to get that out for the DSC, please Diagram the model of the Elk Arming states, and Alarm states, similar to what's been done above. We need this to make "v2" of the interface definition that we can all align to (and ultimately get the control point vendors to implement also). There are shortcomings in the v1 spec as I slapped it together when I wrote the Paradox (without benefit of understanding of the other panel interactions.

For V2, no code at this time please, Model diagrams only so we can converge on a API interface proposal

The code will drop out relatively easily once we agree on the Model, and thus the states that we need to represent. If you don’t model the Elk, then we’ll likely build in an incompatability that doesn’t handle it’s specific states and/or transitions… and that would be bad.

It’s also easier to argue the states/transitions based upon a picture, and not a coded interpretation, which could well be mis-understood, or wrong :wink:

#38

@futzle, digitalperk, alfonso,
All 3 versions of the UPnP Service declaration file proposal are now checked into here:
http://code.mios.com/trac/mios_paradox-alarm/browser/S_AlarmPartition2.xml

This is just a placeholder location until we can get agreement on the model, and validate it’s contents against our respective Model Diagrams for completeness.

It also means we can now formally “diff” the revs that go in, and readily read it, and see what’s changed from one rev to another.

#39

@futzle, @digitalperk, @alfonso

I’d like to make final changes to “v2” this weekend, and lock it down. I plan to implement it in directly in the DSC and Paradox code bases at that time.

If there are specific, concrete, additions to either the Actions, or State additions, now is the time to pipe up and let me know.

“v2” is the only spec-rev I’d like the Control Point (Remote) owners to consider. Any implementation of the “v1” spec into a CP would be ill-advised :wink:

@alfonso: I haven’t seen any state trans diagrams from you, so I’ll assume you’re ok with the latest model proposed, and are can implement the Elk against it.

@computerjohn, strangely: Just FYI, but the current DSC prototypes you’re working with are the only examples of it running “v1”. I plan on checking it into source control, and making it more widely available, after it’s been brought up to “v2” spec (and the “v1” impl has been removed from the code).

#40

I’ve been having IT emergencies all this last week; sorry for being quiet.

Into DetailedState I’d like to add:

  • Chime: The partition is in a mode where tripping zones causes the keypad to emit a “ding-dong” tone. This mode may be considered either Armed or Disarmed as far as the State variable is concerned.
    On the Caddx panel, Chime really is a mode on equal footing with Stay and Away, so it belongs in DetailedState and not VendorStatusCode.

Everything else I can do through the VendorStatusCode variable.