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.[/quote]
How about a separate Status variable altogether? If it’s anything like the Bell setting in the DSC and Paradox, it goes off independently of the Partition’s “armed” or “disarmed” state. Given that these 3x panels each have the feature, seems like it should be added. Unfortunaltely my Paradox doesn’t let me intraspect the setting, but I’ll assume others do.
I use the Chime setting, and have been woken more than a few times (just before the primary Bell goes off) by the Chime going off… when I was had a few failing sensors.
How about this addition:
[code] <!-- An indicator of whether the Partition has the Chime mode enabled.
Some Alarm Systems (DSC, Paradox, GE Caddx) can run in a mode where each Zone
that's opened will trigger a "Chime" or Bell to ring for a short period of
time. This setting is independant of any Armed or Disarmed state of the
Partition.
If the Panel supports intraspection of this property, then the value should
be brought forward. Some panels (Paradox) support the setting, but don't
support the intraspection of the setting. In these cases, the Partition
implementation must return "false" for this attribute.
true - The Partition is in Chime mode, and will ring a Bell when Zones are opened.
false - Chimes are disabled. No chime/sound will occur when a Zone is opened.
-->
<stateVariable sendEvents="yes">
<name>ChimeEnabled</name>
<dataType>boolean</dataType>
<shortCode>chimeenabled</shortCode>
<defaultValue>false</defaultValue>
</stateVariable>
so you can see the revisions from this morning, including:
[ul][li]addition of the [tt]ChimeEnabled[/tt] StateVariable for @futzle’s usecase
[/li][li]change wording of “mode” to “state” to be consistent with the Partitino’s [tt]State[/tt] StateVariable
[/li][li]addition of generic actions [tt]RequestState[/tt]/[tt]RequestQuickState[/tt] to support vendor-specific Arming States not already represented in our list.
[/li][li]addition of generic actions [tt]RequestPanicState[/tt] to support vendor-specific Panic States not already represented in our list ([tt]Police[/tt], [tt]Fire[/tt], [tt]Medical[/tt])
[/li][/ul]
@futzle, digitalperk, alfonso,
I’ve implemented most of this for the DSC, and you can see it in the /trunk line for it under Trac if you’re interested.
A few thoughts/comments now that I’ve worked with it a little:
a) stateVariable “[tt]State[/tt]” would be better named “[tt]ArmMode[/tt]” This would make it closer to [tt]D_HVAC_ZoneThermostat1.json[/tt], and make it less generic in name.
b) “[tt]status[/tt]” parameter should be “[tt]Status[/tt]” to be more consistent with other Action parameters. These are case-sensitive, so if we’re going to change it then it needs to be done now.
c) Eliminate the convenience methods for Arming and Panic states We currently have Convenience methods for Arming, Stay Arming, and Disarming. The same functionality is exposed via the generic [tt]RequestArmState[/tt] method.
This bloats/complicates the Service definition, and is really a throwback to the “v1” code. Suggest we eliminate the convenience actions for arming/stay/disarm, along with the convenience actions for fire/police/medical panic.
In both cases, the generic actions align better with existing services (like the Thermostat) and allow for easier Arm Modes down the line.
d) Consistent with the proposed change in (a), rename [tt]RequestState(…)[/tt], and [tt]RequestQuickState(…)[/tt] to [tt]RequestArmMode(…)[/tt] and [tt]RequestQuickArmMode(…)[/tt] resp.
Let me know your thoughts on (a)…(d). If none is opposed, then I’ll change them permanently on Wednesday in Source Control.
[quote=“guessed, post:44, topic:166000”]a) stateVariable “[tt]State[/tt]” would be better named “[tt]ArmMode[/tt]”
b) “[tt]status[/tt]” parameter should be “[tt]Status[/tt]” to be more consistent with other Action parameters.[/quote]
Agreed.
c) Eliminate the convenience methods for Arming and Panic states
That would reduce the size of my implementation file, agreed. So, two methods: one that takes a state and a PIN, and one that takes just a state.
d) Consistent with the proposed change in (a), rename [tt]RequestState(...)[/tt], and [tt]RequestQuickState(...)[/tt] to [tt]RequestArmMode(...)[/tt] and [tt]RequestQuickArmMode(...)[/tt] resp.
Ok, changed implemented. Latest [tt]S_AlarmPartition2.xml[/tt] in the Paradox space, and also in the /trunk link for the DSC.
I’ve attached some screenshots of the [tt]D_DSCAlarmPartition2.json[/tt] file (from the DSC) that works with this new [tt]S_AlarmPartition2.xml[/tt]. Feel free to borrow what you need from it (it’s in DSC’s /trunk also, but doesn’t have any DSC specific stuff in it right now)
@mcvflorin,
I think we need a “common/core” space in [tt]code.mios.com[/tt] that can be used to handle the core code (like Services, images, etc) that need to be included back into MiOS for all Alarm Panel authors to share. This will also help with install, since we want all have to upload a copy of [tt]S_AlarmPartition2.xml[/tt] etc.
Then we can move the files out of the Paradox source control area.
Additionally, it may be easier to leave [tt]S_AlarmPartition2.xml[/tt] as the source of truth for any low-level documentation, and focus the Wiki pages on how to assemble an Alarm system using this, or an overall methodology for building Panels (use of [tt]SecuritySensor:1[/tt]'s for Zones, etc, etc)
Stuff entered into the wiki like this tends to get stale over time, so we end up looking at the Service definitions and implementations, directly on Vera, to get a better understanding of what to do… At least, that’s what I do.
[quote=“guessed, post:48, topic:166000”]@mcvflorin,
I think we need a “common/core” space in [tt]code.mios.com[/tt] that can be used to handle the core code (like Services, images, etc) that need to be included back into MiOS for all Alarm Panel authors to share. This will also help with install, since we want all have to upload a copy of [tt]S_AlarmPartition2.xml[/tt] etc.
Then we can move the files out of the Paradox source control area.[/quote]
I agree, so I created the project Common Alarm Panel Plugin Files. I don’t like the name, but I couldn’t come up with something prettier. I made you and futzle project admins.
It’s easier to point new users to the wiki page than to a file in the repository. Also, this page is for the standard; a separate page could be created with a tutorial for making alarm panel plugins.
That’s why I put on the page a link to the latest version of the file in the repository. This way, at least the file won’t be outdated.
Aha! so there IS a way (for admins) to do that…
I moved quite some pages in the how to section to get them to reflect the content better than just “notifications” or " scenes" etc.
Would you mind going through them and do the same for those? that would clean up the database immensly.
As for orphaned pages (pages that have nog category linked to them) that is an issue that currently doesnt help the readability of the wiki. And i believe there are still many pages that have this issue. I was able in my minor revisions to capture about 8 or 10 of them and bring them into User Instructions and/ or how to. but someone should actually check the wikki for these pages and try to categorize them,
Is there an easy way for you to find pages recently moved or do i have to make a summary for you?
Let me know whats easiest (i will have to sift through my own revision work in the latter case)
PS good to see you’ re somewhat in an overlapping timezone with me (or just working at night :P)
I had a look through the logs. I think that the Advanced page should remain just Advanced, and not Advanced Network Settings, because it is about the Advanced page, with all the tabs, and not just the network settings.
should we move this discussion to a seperate thread?
There are SO many advanced tabs in the settings options of Vera (network, device, scenes etc) that its impossible for the user to know what the content of the page is just by stating “Advanced”
It could also be intended for “Advanced users” f.i.
For that reason a rename was verified IMHO just to have the name of the page relate better to the content
users might be looking for. Another solution could be “Advanced Tab of network setting” but that was quite long.
ArmMode and DetailedArmMode should be merged. In other words ArmMode should be dropped and DetailedArmMode should be renamed to ArmMode.
Argument: It’s redundant to have two state variables for the same thing.
RequestArmMode and RequestQuickArmMode should be merged. Implementations should read the PIN code from the Text Field. If it’s present, it should use it to Arm/Disarm (RequestArmMode). If it’s not, it should try to Arm/Disarm without the PIN code (RequestQuickArmMode). If it fails, an error should be displayed to the user.
PIN code should be made a string.
Argument: There are panels that have alphanumeric PIN codes. The standard should accommodate all types of panels.
These are my proposals. Let me know what you think about this.
I think this redundant information is necessary. I could see maybe changing the names to IsArmed and ArmMode. The first just a bool as to if the partition is armed and the second describing how the system is armed. However, I agree that a simple request should be made available that state simply if the partition is armed or not.
I’m with dfad1469 on proposal 1. ArmMode and DetailedArmMode are separate because some of us (guessed and me, perhaps others) found that different panels have different ideas about what constitutes “armed” or “not armed” (exit delay, for instance). Additionally, writing scene triggers for “panel is armed” rapidly get out of hand when you have to alter them to cover “panel is armed” OR “panel is force-armed” OR “panel is away-armed” OR … The idea is that those automation processes that don’t want that level of detail have a guaranteed maximum complexity (armed or not armed) and those processes that want the extra detail can get it when they want. Put another way: DetailedArmMode might get extra modes over time as we discover panels that use them. ArmMode is future-proof.
I’m ambivalent towards proposal 2. It’ll be extra code for the Caddx panel, since the with-PIN and without-PIN serial commands are fairly different, but not to the point of hardship.
I made you and