Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Class: Security
#11
Dean Roddey Wrote:Ultimately, the term 'zone' may be a little loose. It's effectively what the Elk or Omni consider a zone. That's really a single sensor, right? So I guess 'zone' doesn't mean a place, but zone in the sense of something being protected by a sensor. In which case you might have a Zone_MBRWind1_Status or something like that, to distinguish between one window and another.

I can't see how we can support *arming* individual zones. Ultimately only areas can be reasonably be armed in any way that would be portable to the Elk/Omni world, right? I can't imagine how it would be useful to arm a single zone.

Perhaps in the DSC they are calling a zone what Elk/Omni call an area?

It is unfortunate, if that is the case, that Elk/Omni used the term zone for a single discrete device, the nomenclature is confusing. A door opening is a single opening it is not a zone. The end zone on a football field is not a one dimensional abstract thing on the field, it is a large area containing multiple attributes.

To abstract out of a particular manufacturer's wording, you have sensors that monitor something and then you have areas/zones that can contain 1 - n sensors. Whether it is Elk, DSC, or whatever, it makes sense to have a higher level of abstraction then individual sensors, a container if you will, of devices that monitor the environment in some way. In some cases there may only be 1 sensor but in most there are multiple sensors that monitor the integrity of a zone/area.

Meh, semantics are the hardest part of this, it's what we are used to / have been exposed to over time. I don't really care what it is called as long as the concept of a zone/area with 1-n sensors is represented and one can differentiate between the container and the single sensing device.

-Ben

Please also consider that while Elk/Omni may be mainstream in HA circles it is the DSC's of the world that are mainstream in much much greater numbers. At the end of the day, what audience do you want to accommodate/reach? Ideally, both I would think...
Reply
#12
I certainly don't have a problem with calling it something else. I just used the term zone because both the Elk and Omni use that nomenclature. If we do call it a sensor else, I don't think we can really support a 'zone' in that more generic sense, i.e. some way to interact with a group of sensors. It would be sensors that belong to some 'area'. I don't think this device class could really have any functionality related to do something to a group of sensors other than the extent to which they are part of an area. It wouldn't be portable.

Would that prevent any fundamental functionality that would be important in terms of generic solutions like auto-generated stuff?
Dean Roddey
Software Geek Extraordinaire
Reply
#13
Dean Roddey Wrote:I certainly don't have a problem with calling it something else. I just used the term zone because both the Elk and Omni use that nomenclature. If we do call it a sensor else, I don't think we can really support a 'zone' in that more generic sense, i.e. some way to interact with a group of sensors. It would be sensors that belong to some 'area'. I don't think this device class could really have any functionality related to do something to a group of sensors other than the extent to which they are part of an area. It wouldn't be portable.

Would that prevent any fundamental functionality that would be important in terms of generic solutions like auto-generated stuff?

Dean,

When I think of the context of a multi-area home or business I could see where one might be interested in the abstract of a floor plan of the building in which the building area in alarm state is outlined by red with a specific indication of the sensor(s) that are in alarm state. In the context of the generic auto generated UI depicting alarm conditions would you do this?

Also, in the context of the DSC panel (and likely with the Elk / Omni) I can arm a particular area of my home but not all of it or the flip side if there there is are sensor(s) problems, I can choose to not arm that particular zone.

Perhaps a clearer example is the case where we have in-laws living in a separate living space that is attached and we want to manage it separately but with the same security system. In a business / office building environment this makes even more sense.

To your point about this particular device class only handling discrete sensors as opposed to collections for portability, I understand that but then how would collections "zones/areas" be represented? You have separate thermostats individual sensor/control point and HVAC (which is a collection) classes.

Thanks for humoring my conversation! Security, HVAC and a few other automation sub-systems are in my mind core/fundamental things that people are going to want to control.

-Ben
Reply
#14
Area arming and disarming is definitely supported. I was just saying that, currently, we have areas and zones (in the sense that Elk/Omni define them, i.e. sensors.) If we don't call them zones, I didn't mean discrete, I just mean no collection of sensors smaller than an area, I.e. there isn't still a 'zone' which is some sub-area-sized collection of sensors. We just have areas and sensors. Each sensor can be in an area.

Lists of sensors are naturally supported via the naming conventions in each of the device classes that has to deal with that. It's just assume that, in general, the sensors will be nameable, so there's no real enforced numbering or order of them. Other than being able to ask the driver what sensors are in a given area, the naming convention you choose to use could also imply some sort of grouping for your own needs.

A device like an Elk would implement HVAC, Security, Lighting, DIO, and possibly other device classes. The conventions of those device classes would control how it creates the fields for those various areas of functionality it provides. There would not be any sort of grouping mechanism that would cut across those to include everything in an area, other than convention and to the degree that the device does something when you arm/disarm an area. The auto-gen system is told what to use in any given room, so it doesn't have to figure out on its own what is in what area really.
Dean Roddey
Software Geek Extraordinaire
Reply
#15
Dean Roddey Wrote:Area arming and disarming is definitely supported. I was just saying that, currently, we have areas and zones (in the sense that Elk/Omni define them, i.e. sensors.) If we don't call them zones, I didn't mean discrete, I just mean no collection of sensors smaller than an area, I.e. there isn't still a 'zone' which is some sub-area-sized collection of sensors. We just have areas and sensors. Each sensor can be in an area.

Lists of sensors are naturally supported via the naming conventions in each of the device classes that has to deal with that. It's just assume that, in general, the sensors will be nameable, so there's no real enforced numbering or order of them. Other than being able to ask the driver what sensors are in a given area, the naming convention you choose to use could also imply some sort of grouping for your own needs.

A device like an Elk would implement HVAC, Security, Lighting, DIO, and possibly other device classes. The conventions of those device classes would control how it creates the fields for those various areas of functionality it provides. There would not be any sort of grouping mechanism that would cut across those to include everything in an area, other than convention and to the degree that the device does something when you arm/disarm an area. The auto-gen system is told what to use in any given room, so it doesn't have to figure out on its own what is in what area really.

Got it, this helped clarify, thanks!
Reply
#16
Ultimately, I think I'm going to stick with the 'zone' nomenclature, because the standard trigger for them is a 'zone alarm', and that's not practical to change at this point. No matter what is chosen, some device is likely to have some sort of terminology clash. The point here is to create a virtual view of things, so the actual denotation of things in the devices themselves is ultimately irrelevant. Since the security zone is a long established tradition by now in CQC, and used by two extremely common devices, we'll stick with that.
Dean Roddey
Software Geek Extraordinaire
Reply
#17
Dean Roddey Wrote:Ultimately, I think I'm going to stick with the 'zone' nomenclature, because the standard trigger for them is a 'zone alarm', and that's not practical to change at this point. No matter what is chosen, some device is likely to have some sort of terminology clash. The point here is to create a virtual view of things, so the actual denotation of things in the devices themselves is ultimately irrelevant. Since the security zone is a long established tradition by now in CQC, and used by two extremely common devices, we'll stick with that.

Dean, first, my apologies, they say the memory is the 2nd thing to go...

Well anyway, I went back and reviewed the DSC documentation and they use the term partition to describe a separate "area" the term zone is used to describe individual sensors. For the life of me I cannot figure out where I got myself crosswise. At any rate, my bad, and please accept my apology for confusing the situation temporarily. :oops:

-Ben
Reply
#18
It was probably good to force more consideration on the whole thing. If these aren't well thought out, then it'll get a mess down the road. Looks like the partition would map fairly reasonably onto this guy's area concept. Presumably partitions are the things that are armed/disarmed, right?
Dean Roddey
Software Geek Extraordinaire
Reply
#19
Dean Roddey Wrote:Looks like the partition would map fairly reasonably onto this guy's area concept. Presumably partitions are the things that are armed/disarmed, right?

Yes, that is correct, a partition is armed/disarmed.
Reply
#20
Updated the SecAreaList backdoor query to include both the area status and the arming mode fields, since both of these will be important to know.
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Class: Thermostat Dean Roddey 17 4,359 01-29-2016, 10:15 AM
Last Post: Dean Roddey
  Class: SceneCtrl Dean Roddey 20 2,619 03-31-2015, 12:38 PM
Last Post: Dean Roddey
  Class: Irrigation Dean Roddey 8 1,364 01-28-2015, 12:09 PM
Last Post: Dean Roddey
  Class: NowPlaying Dean Roddey 8 1,351 09-23-2014, 02:01 PM
Last Post: Dean Roddey
  Class: Switcher Dean Roddey 9 1,484 08-20-2014, 08:17 AM
Last Post: Dean Roddey
  Class: Projector Dean Roddey 29 3,205 08-11-2014, 08:56 AM
Last Post: Dean Roddey
  Class: Lock Dean Roddey 5 1,007 07-31-2014, 01:24 PM
Last Post: Dean Roddey
  Class: ContactClosure Dean Roddey 7 1,132 07-31-2014, 10:14 AM
Last Post: Dean Roddey
  Class: DIO Dean Roddey 7 1,357 07-31-2014, 10:08 AM
Last Post: Dean Roddey
  Class: Relay Dean Roddey 4 917 07-31-2014, 09:56 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)