Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Class: ContactClosure
#1
General Description

This thread is for discussion of the Contact Closure device class. Drivers that implement this device class will provide one or more sensors that sense whether a connection is open or closed.

Fields Provided

[INDENT]It is assumed that, in the general case, the fields will likely be nameable by the user, therefore there are no naming convention limitations on the fields of this device class, other than that they MUST use the appropriate prefix indicator, i.e. that all of them be in one of the forms:

CTCL#fieldname
CTCL#sub~fieldname


This indicates that the fields are implementing the Contact Closure device class.

If initial default names are assigned until the user can/does rename them, then it is SUGGESTED that they in some way refer back to device specific values, so that it is obvious what contact each field is attached to.[/INDENT]

Multi-Unit Considerations

[INDENT]Though it is generally assumed that these fields will be user nameable to reflect their function and therefore are all on an equal footing, if the device provides banks of identical sets of contacts with a specific purpose, the driver MAY use sub-unit naming conventions. In that case the fieldname parts become fixed, and the sub-unit part becomes the user or device provided name. Each sub-unit must provide an identical set of fields.[/INDENT]

Semantic Requirements

[INDENT]All such fields should be semantically marked with the ContactClosure semantic field type, and follow the conventions indicated by that semantic field type. Contact closures are read-only, since they only sense the open/close state of a contact.[/INDENT]

Backdoor Commands/Queries

[INDENT]None are required at this time.[/INDENT]
Dean Roddey
Software Geek Extraordinaire
Reply
#2
(reserved for expansion)
Dean Roddey
Software Geek Extraordinaire
Reply
#3
(reserved for expansion 2)
Dean Roddey
Software Geek Extraordinaire
Reply
#4
Is this one redundant? Is there any useful difference between a relay and a contact closure? Is a contact closure basically a read only relay?
Dean Roddey
Software Geek Extraordinaire
Reply
#5
In my mind DIO, Relay, Switch, and Contact closure are all redundant. They are all just boolean/binary fields. The only difference is read-only/read-write.

Maybe you could just get away with something like:

Switch (Read/Write Boolean)
Input (Read/Only Boolean)
Wuench
My Home Theater/Automation Website

[THREAD=5957]BlueGlass CQC Config[/THREAD]
[THREAD=10624]Wuench's CQC Drivers[/THREAD]
Reply
#6
Keep in mind that these will also used for filtering during field/driver selection. So they may want to find all the devices that provide relays. We'd find them by looking for all drivers that implement the Relay device class. So it's not just about functionality, it's also about finding and filtering.
Dean Roddey
Software Geek Extraordinaire
Reply
#7
OK, updated this one.
Dean Roddey
Software Geek Extraordinaire
Reply
#8
Updated to clarify access requirements and multi-unit naming stuff.
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Class: Thermostat Dean Roddey 17 4,016 01-29-2016, 10:15 AM
Last Post: Dean Roddey
  Class: SceneCtrl Dean Roddey 20 2,503 03-31-2015, 12:38 PM
Last Post: Dean Roddey
  Class: Irrigation Dean Roddey 8 1,311 01-28-2015, 12:09 PM
Last Post: Dean Roddey
  Class: NowPlaying Dean Roddey 8 1,293 09-23-2014, 02:01 PM
Last Post: Dean Roddey
  Class: Switcher Dean Roddey 9 1,419 08-20-2014, 08:17 AM
Last Post: Dean Roddey
  Class: Security Dean Roddey 33 4,172 08-13-2014, 03:02 PM
Last Post: Dean Roddey
  Class: Projector Dean Roddey 29 3,077 08-11-2014, 08:56 AM
Last Post: Dean Roddey
  Class: Lock Dean Roddey 5 935 07-31-2014, 01:24 PM
Last Post: Dean Roddey
  Class: DIO Dean Roddey 7 1,291 07-31-2014, 10:08 AM
Last Post: Dean Roddey
  Class: Relay Dean Roddey 4 861 07-31-2014, 09:56 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)