Sean,
Vera’s motion sensor and door sensor implementations have a bypass flag. When you have these “children” attached to your device, the Vera UI gives you a bypass button. So if I add a zone “Kitchen sliding door” of type D_DoorSensor1.xml, i’ll get a UI element that shows me whether it’s faulted, and a button to bypass it.
See attached screenshot. The little “person” turns red when faulted.
[quote=“djrobx, post:61, topic:166000”]Sean,
Vera’s motion sensor and door sensor implementations have a bypass flag. When you have these “children” attached to your device, the Vera UI gives you a bypass button. So if I add a zone “Kitchen sliding door” of type D_DoorSensor1.xml, i’ll get a UI element that shows me whether it’s faulted, and a button to bypass it.
See attached screenshot. The little “person” turns red when faulted.[/quote]
I must have misunderstood the wiki page then. I was thinking it was supposed to be a state machine to capture all data about the current state of the alarm panel and be as generic as possible to encompass all/most alarm panels.
I also noted no attributes were available to track the alarm panel’s battery backup or if the panel was on AC or if the power was off. These also I think are common features all alarm panels have.
Re
Sean M
Good idea on the battery/AC info…
The code that controls these children can live in the parent (alarm panel/partition) code. Parent just sets its children’s flags as appropriate. I’m just pointing out that the info you’re looking for may be living in another pre-existing generic implementation.
The parent can also create these children on its own, so if I can ask the panel to give me zone labels and types, the alarm panel device can create these children without the user having to do it.
Hi mathewss,
Most of the focus at the moment is being spent on describing the service for alarm partitions. Your examples apply instead to the whole system or to individual zones, which is why there’s no mention of them in the documentation.
That’s not to say that zones and panels are done and dusted. It’s just that for the moment we are trying to get the partition service stable enough that it can be coded against.
[quote=“futzle, post:64, topic:166000”]Hi mathewss,
Most of the focus at the moment is being spent on describing the service for alarm partitions. Your examples apply instead to the whole system or to individual zones, which is why there’s no mention of them in the documentation.
That’s not to say that zones and panels are done and dusted. It’s just that for the moment we are trying to get the partition service stable enough that it can be coded against.[/quote]
I totally approve. I can personally vouch for how critical partitions are in an advanced setup they can be very useful.
I will keep watching if I can think of anything I will contribute my thoughts and kudos to all the hard work.
Re
Sean M
To sum up the results:
Proposal #1: 0 pro, 0 neutral, 2 against
Proposal #2: 1 pro, 1 neutral, 0 against
Proposal #3: 2 pro, 0 neutral, 0 against
So, my first proposal won’t be in the next standard version, the second proposal needs a deciding vote, and the third proposal will make it into the next standard version.
@guessed
What do you think about this?
[quote=“mathewss, post:65, topic:166000”][quote=“futzle, post:64, topic:166000”]Hi mathewss,
Most of the focus at the moment is being spent on describing the service for alarm partitions. Your examples apply instead to the whole system or to individual zones, which is why there’s no mention of them in the documentation.
That’s not to say that zones and panels are done and dusted. It’s just that for the moment we are trying to get the partition service stable enough that it can be coded against.[/quote]
I totally approve. I can personally vouch for how critical partitions are in an advanced setup they can be very useful.
I will keep watching if I can think of anything I will contribute my thoughts and kudos to all the hard work.
Re
Sean M[/quote]
I expect that once we get a little further down the road, and we start seeing Control Points implementing the UI, we’ll will need to standardize AlarmPanel itself. For now, we’ve mostly been stubbing device-specific representations of it.
Note that not all panels provide methods to intraspect things like battery state (my Paradox doesn’t, the DSC will only let you enquire on the AC status, not the Battery status).
That said, they both have events that fire when the Battery and/or AC goes down (VendorCodes) so you can readily event off them, but a permanent status won’t always work across all implementations.
One area we haven’t standardized, and perhaps there would be some value, is the Panel and/or Partition events we expose (likely derived from the VendorCodes)
[quote=“mcvflorin, post:57, topic:166000”]I propose some modifications to the standard:
Against. It was a deliberate choice to make ArmMode a separate “binary” state variable for ready scripting and UI implementation. The DetailedArmMode was added to handle the current, and future, expansion based upon what people “found” in their particular panels (both now, and over time).
BTW: I’d love to know if the other Panels have “more states” as I only added the few that we could readily find for the few Panels we were implementing at the time (plus those gleaned from some other Panel doco for the Elk) so we’re likely missing a few 8)
2. [i]RequestArmMode[/i] and [i]RequestQuickArmMode[/i] should be merged. Implementations should read the PIN code from the Text Field. If it's present, it should use it to Arm/Disarm ([i]RequestArmMode[/i]). If it's not, it should try to Arm/Disarm without the PIN code ([i]RequestQuickArmMode[/i]). If it fails, an error should be displayed to the user.
If someone can show me the Spec for how standard UPnP handles such cases, then we can change it if people really want it. I avoided “null” or “non-passed” arguments, since it wasn’t clear from what I could see from the UPnP specs how this was handled…
Of course, MiOS and Lua methods are fine with it, as they’re more like var-args in the way things are handled but it was not clear how UPnP wanted that handles, so I opted for the well-defined path.
If the UPnP spec is vague on this, then I’d opt to keep it as-is. If there’s a well-defined methodology for it, then just let us have a ptr and we can review the options.
3. PIN code should be made a [i]string[/i]. Argument: There are panels that have alphanumeric PIN codes. The standard should accommodate all types of panels.Sure, no problem changing it if there are panels that require AlphaNumerics. I tended to make the DT's match those found in panels, so that UI's could provide the [limited] UI's necessary to drive them.
ie. a numeric Keypad UI, or limited popup keyboard with Numerics only.
If we have panels that are shown to have AlphaNumerics then more than happy to change it over.
Can you list the Panels that permit this?
Unfortunately, the well-defined path isn’t also the user-friendly path. When the average user will see two ways of arming/disarming he will be confused. Since MiOS has no problem handling null values, I see no reason keeping two somewhat redundant actions.
Personally, I don’t know any ;D, but I saw somewhere (can’t remember where) a panel that used a hexadecimal PIN code.
Unfortunately, the well-defined path isn’t also the user-friendly path. When the average user will see two ways of arming/disarming he will be confused.[/quote]
Well, you chose UPnP as the transport, therefore you get to stick to it’s rules. The API will be no worse than any of the approved/vetted ones from the UPnP spec… 8)
Since MiOS has no problem handling [i]null[/i] values, I see no reason keeping two somewhat redundant actions.No, you're using a standard, you need to stick to it's rules. At some point, once the Alarm abstraction is really fleshed out (lots more than the current stuff) there's nothing stopping us from submitting it for review.
Hacking the UPnP standard for one (MiOS) UPnP implementation would mean that a wider use would not be possible down the road.
[quote="guessed, post:68, topic:166000"]Can you list the Panels that permit this?[/quote]Personally, I don’t know any ;D, but I saw somewhere (can’t remember where) a panel that used a hexadecimal PIN code.
Regarding #2, all UPNP variables can have an tag. The reason I really do not want to have 2 different ‘arm actions’ is because of how this will look to a “normal” lay user. If the standard is to have 2 arm actions, then all iphone interfaces, web interfaces, etc., will need 2 actions. The iphone app will be:
PIN: [ ] [arm] [quick arm]
This will create a support nightmare. Customers will call not knowing the difference between them, and not understanding why for some customers ‘quick arm’ works, and for others it doesn’t. I want the iphone interface to just be:
PIN: [ ] [arm]
It never hurts to enter the PIN code. And some customers may find that for their particular alarm they can hit ‘arm’ without the pin code and it still arms. That’s fine, it’s a shortcut, and won’t result in a support call. If a user hits ‘arm’ without typing in his pin code, and the plugin doesn’t support it, it simply returns the upnp error: “Invalid PIN”. So it’s obvious what the user needs to do.
Regarding #3, my bigger issue wasn’t alpha-numeric, it’s leading 0’s. I’m assuming alarm panels with variable length pin codes allow: 1234 or 01234 as valid pins. If it’s an unsigned int there’s no way to specify leading 0’.
Hunted through the specs and cannot find references to the [tt][/tt] XML Element, nor mechanisms for specifying the optionality of Parameters in an [tt][/tt] declaration.
Can you point to a fully worked example showing how this is done? Any of the examples from the UPnP spec bundle that do this will suffice.
On the String usage for Leading-0’s in PIN’s, that makes sense. I’ll do some research on how you can use the [tt]type=[/tt] attribute to “refine” the rules for the UPnP [tt]string[/tt] datatype. I’d like to see if we can at least spec it to be tightly validated, even if we have no validator.
Once I work that out, I’ll change the PIN to be a String declaration, and push this part whilst we work out how to get the [tt][/tt] parameter declaration sorted out correctly.
@guessed ask that I document here the UPnP calls that the forthcoming version of Automator.app uses to support alarm panels works to ensure minimal breakage.
The good news is that next version of the Automator.app does not hard code upnp/serviceids,etc at all anymore. It instead builds the UI for devices based on the static data, just like the vera web ui does. So any changes made to services should work fine in Automator.app 1.1 and later versions without any need to adjust the app itself. The ui presented contains both the ControlHeader format (e.g. what you see from the mios dashboard) and the Control tab presented when you click the wrench.
If there are additional alarm specific tabs (like how there is an additional tab for pin codes for door locks), that would be missing from Automator 1.1.
Florin,
I’d like to close this out, can we get answers the questions posed…
[quote=“guessed, post:72, topic:166000”]Hunted through the specs and cannot find references to the [tt][/tt] XML Element, nor mechanisms for specifying the optionality of Parameters in an [tt][/tt] declaration.
Can you point to a fully worked example showing how this is done? Any of the examples from the UPnP spec bundle that do this will suffice.
On the String usage for Leading-0’s in PIN’s, that makes sense. I’ll do some research on how you can use the [tt]type=[/tt] attribute to “refine” the rules for the UPnP [tt]string[/tt] datatype. I’d like to see if we can at least spec it to be tightly validated, even if we have no validator.
Once I work that out, I’ll change the PIN to be a String declaration, and push this part whilst we work out how to get the [tt][/tt] parameter declaration sorted out correctly.[/quote]
Well, in the official UPnP specs there isn’t an optional tag or attribute, but it has been used in several of our service files (e.g. S_Dimming1.xml, S_DoorLock1.xml, etc.). It’s like a vendor specific extension to the standard.
Ok, given there’s no standard for doing this, I opted for a more conventional route.
I have modified [tt]S_AlarmPartition2.xml[/tt] to include the semantic change as verbiage in it’s description. Specifically, it now indicates the following on the [tt]RequestArmMode[/tt] action:
The PIN Code may have a blank value. If the PIN Code is blank, or not-passed if a particular UPnP platform supports that, then the request should be interpreted the same as if the corresponding RequestQuickArmMode call had been made.
For now, I have left the [tt]RequestQuickArmMode[/tt] action in place. We can use this thread to discuss whether we should remove them or not, since they’re now conveniences for calling [tt]RequestArmMode[/tt] with a Blank Password (using standard UPnP Parameter conventions, avoiding vendor specific mechanisms)
eg. [tt]RequestQuickArmMode(“Armed”)[/tt] is functionally similar to [tt]RequestArmMode(“Armed”, “”)[/tt]
I also modified the JSON code for both the DSC and Paradox plugins to simplify the Device’s Dialog (screenshot attached), and modified the Event/Scene section to use the [tt]RequestArmMode[/tt] method exclusively (just in case we decommission the [tt]RequestQuickArmMode[/tt] action)
These can all be seen in the trunk version of the DSC Alarm code (which @strangely is testing for me before I publish it wider)
I’ll make similar changes for the next release of the Caddx plugin.
The Ademco Vista alarm panels have an arm mode called “MAXIMUM” (description from manual: Arms same as Away mode, but entry delay is off), which is basically Away Instant. I suggest adding AwayInstant in the allowed values list for DetailedArmMode.
Later edit: I noticed that all panels have an Away mode, and I think that it’s confusing that the default alarm panel partition interface has a button named Arm instead of Away. Also, I don’t like that this button is toggled regardless of the current arm mode. As long as this button isn’t visible from the dashboard, I see no point in having two highlighted buttons for an arm mode different from Away. I can see very well that the partition is armed by looking at the status, or at the highlighted button for a specific arm mode.
Thus, I suggest renaming Armed in the allowed values list for DetailedArmMode to Away, and changing the Arm button’s label to Away and its variable association to DetailedArmMode, Away value.
Even later edit: 
I attached the proposed file.
Florin,
At this point I’d err on the side of not changing the “[tt]Armed[/tt]” Detailed-mode label.
More than happy to add a counterpart (“[tt]ArmedInstant[/tt]”) to handle the new mode you’ve discovered in the Ademco, as we already outlined that case in the spec (extra Detailed modes being added for Vendor-specific stuff)
We locked down the spec some time back and it’s a bad idea to change things, like core-values, well-after the review periods are over. Adding last-minute “surprises”, and functional changes over the lifetime of something like this, only leads to unnecessary disruption. This is one of the reasons why we’d gone rounds of asking for each panel’s “model” early on, so we could get consensus on the values to represent the states.
As for the UI behavior, I can change it so that multiple Buttons don’t get “activated” if you need that. I changed the UI about a week back for the DSC and Paradox anyhow, and that type of change doesn’t impact Scene Scripting in any way.
Unfortunately I had other tasks back when the standard was defined, and I couldn’t provide any input. 
Isn’t it possible to change it and then increment the standard version, so that every new alarm panel plugin will use the altered standard (2.2)? The current plugins can be left as they are. Just a suggestion.
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules