Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Class: Security
#21
I got the security device simulator driver updated to V2 standards. I gave up trying to make backwards compatible. That will be necessary with other drivers of course, but I just couldn't justify the time overhead for these simple device simulator drivers. Hopefully this doesn't cause too much grief but it's just not practical.

It's a good test of what will be required for some of the real drivers. It may just get too tricky to try to have one driver that does both modes in some cases, I dunno. You don't want to split them due to double maintenance, but you don't want to make already complicated drivers a lot more complicated. I think mostly the Elk/Omni drivers would be the hard ones, since they are already complicated and the V2 architecture requires more than just simple field name changes.
Dean Roddey
Software Geek Extraordinaire
Reply
#22
I updated the definition of the backdoor command:

QSecPanelInfo/SecAreaList

It now just returns a list of area names as a quoted comma list. The old scheme, which returned the various fields, was redundant now in the V2 world. Given a list of area names, you can easily create the various area oriented fields by just formatting those names into the known pattern for the area fields. And this also allows this query to be used to just get a list of raw names for display, so it's more convenient all around.

The only drivers affected so far are the Omni and security device simulator, since those are the only ones that implements the new V2 security device class so far. I'll get them updated, and of course the others will be able to do it this way from the start when they are converted here before long.
Dean Roddey
Software Geek Extraordinaire
Reply
#23
Do we need to make the 'arm up' or 'ready to arm' field for areas part of the device class? They won't arm unless they are ready to arm, and we don't really get back a meaningful error if we try to arm them when they aren't ready to be armed. So having the client interface look at the ready to arm field and warn the user that the arm isn't going to work, seems like the only practical thing to do?

I guess it's safe enough. If a security system doesn't have the concept, it can just leave the field at True all the time to allow arming any time. But it allows us to deal with this situation where it's a relevant.

We don't need any fancy info, just is it ready, is it not. If we require that the field have at least a Ready value, with all other values indicating not ready, then as long as the field is Ready, then arming should be ok.
Dean Roddey
Software Geek Extraordinaire
Reply
#24
BTW, how do you clear an alarm on the Elk? Even if you disarm and get the zones un-violated aagin, the alarms stay active. Does it require rearming again to clear? If so, then the above wouldn't work since it wouldn't let you arm because it's not ready to arm.

If I arm and violate, and let it time out and go into alarm state, then disarming will stop the chime but it will be in alarm. It will be in not ready to arm state. If I then do an arm, it will not arm, but it will clear the alarms. That's not good because if we do an arm, it should either arm or fail.

The Omni driver doesn't even expose any sort of ready to arm status, and I'd have to go digging to see if it even reports such stuff.

How would we deal with that generically in a way that works across various security systems? It seems like something that needs to be supported in the auto-generated interfaces, but that means no per-driver stuff. It has to be supported generically. And if so, it would be MUCH better to do it now than after 4.5 goes out, because then we'd already have to create a Security2 device class and all that.
Dean Roddey
Software Geek Extraordinaire
Reply
#25
disarm twice, at least that's how you do it on the keypad
Wuench
My Home Theater/Automation Website

[THREAD=5957]BlueGlass CQC Config[/THREAD]
[THREAD=10624]Wuench's CQC Drivers[/THREAD]
Reply
#26
Meaning, if there's any alarm, then we could just present the login dialog as a 'clear alarms' dialog and just send the command twice? Or just always disarm twice to be sure to clear alarms?
Dean Roddey
Software Geek Extraordinaire
Reply
#27
Thinking about this more as I'm looking at the DSC, we can probably safely add a 'ready to arm' Boolean field to the standard fields, which just indicates whether the area is ready to arm or not. That should be safe enough and potentially useful. Even if it's not directly supported by the unit (and it is by the three we support so far, Elk, Omni, DSC), the driver can probably figure it out itself based on other available info.
Dean Roddey
Software Geek Extraordinaire
Reply
#28
I do not believe the Caddx has a Ready To Arm indicator but it would be easy enough to formulate from all of the non-bypassed zones. I would think that would be the case for any system that does not have the indicator already built-in.
Reply
#29
Three questions:

1) how are smoke detectors classified or how should they be classified? In the context of the DSC panel each is considered a separate zone but the zone type is designated fire in order to communicate the proper message to the monitoring service.

2) In thinking about the wired vs wireless sensors I have on my DSC panel where do you encapsulate the battery status? Looking at the current config documentation for the v2 DSC driver, does it make sense to add a Bat, NoBat designation. NoBat obviously means that we don't have to worry about battery status. Bat means that there is a battery status to be monitored

3) On the DSC zones can have 3 states, open, closed, fault. How is/should fault be treated in the context of security
Reply
#30
1. There's currently nothing that could be done differently for a fire zone vs. a security zone. The zone either have to be security and have the three standard values, or motion (which means they aren't part of this device class.) So, there wouldn't be anything gained by marking them as fire zones, at least not for now. You'd just have to look at any zones you know are fire zones and if they are not Secure, then that's bad.

2. It could be done outside of the V2 scheme of course, if the status is reported.

3. It would have to be treated as not-secure. Basically the deal is that there's secure and not secure. If not secure, if the owning area is in alarm, then it's violated, else it's not-ready. I'm pretty sure the driver is doing that now, i.e. treating closed as secure and anything else as non-secure.
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Class: Thermostat Dean Roddey 17 9,141 01-29-2016, 10:15 AM
Last Post: Dean Roddey
  Class: SceneCtrl Dean Roddey 20 3,778 03-31-2015, 12:38 PM
Last Post: Dean Roddey
  Class: Irrigation Dean Roddey 8 1,971 01-28-2015, 12:09 PM
Last Post: Dean Roddey
  Class: NowPlaying Dean Roddey 8 2,085 09-23-2014, 02:01 PM
Last Post: Dean Roddey
  Class: Switcher Dean Roddey 9 2,164 08-20-2014, 08:17 AM
Last Post: Dean Roddey
  Class: Projector Dean Roddey 29 4,491 08-11-2014, 08:56 AM
Last Post: Dean Roddey
  Class: Lock Dean Roddey 5 1,629 07-31-2014, 01:24 PM
Last Post: Dean Roddey
  Class: ContactClosure Dean Roddey 7 1,746 07-31-2014, 10:14 AM
Last Post: Dean Roddey
  Class: DIO Dean Roddey 7 2,042 07-31-2014, 10:08 AM
Last Post: Dean Roddey
  Class: Relay Dean Roddey 4 1,517 07-31-2014, 09:56 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)