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

This thread is for discussion of the LOCK device class. Drivers that implement this device class will provide one or more lock or entry control devices.

Fields Provided

It is assumed that the fields will likely be nameable by the user or will be queried from the device, therefore the name itself will indicate which lock is represented. It's assumed that there are never any multi-unit concerns for Locks, each one is just a separate entity, so they MUST be in the form:

LOCK#fieldname

As long as the 'fieldname' portion follows the standard CQC field name conventions, that is all that is required from a field naming point of view.

If the driver has to assign initial default names, it is RECOMMENDED that they be named based on some aspect of the device (internal node ids, etc...), to allow the user to associate them back to the actual locks.

The field MUST be Boolean type, with true representing locked and false representing unlocked. Unfortunately, many locks are battery powered and are not readable, so there is no way to get their current value. And, given their nature, it is not safe to allow the driver to fake an initial value until the lock sends out a value. This creates a dilemma because, to create truly useful graphical interfaces, having access to the current lock state is absolutely required.

In this case we just have to compromise. Locks MUST be writable in order to control the lock, and MAY be readable if they support it. This means that it may be impossible to create really reusable logic related to locks. Any logic or user interfaces that are intended to be portable should not assume readability of locks. The current state of the locks would only be available via the state change triggers that the locks send.

Multi-Unit Considerations

There are no multi-unit considerations for implementations. The fields are assumed to be nameable based on actual usage in the environment, and all are assumed to be on an equal basis, not divided into chunks that are important for this purpose. So no sub-unit naming requirement exists.

Power Management Issues
None

Backdoor Commands/Queries

None are required at this time.

Event Triggers

Locks MUST send out standard Lock Status event triggers when their lock state changes. They MUST provide as much of the standard event trigger information as they have available.
Dean Roddey
Software Geek Extraordinaire
Reply
#2
(Reserved 1)
Dean Roddey
Software Geek Extraordinaire
Reply
#3
Forgot to define this very obvious one. It'll be included in 4.4.930 and beyond.
Dean Roddey
Software Geek Extraordinaire
Reply
#4
Dean,

It is almost a given that this type of device is battery operated, how will/should the battery state be handled?

Thanks,
-Ben
Reply
#5
It's actually discussed in the original post. It warns that you shouldn't depend on the value of the field if you want to create generic functionality, but if you know you are using locks that can be queried then you can do so. Otherwise, just assume they exist only to send out event triggers.

Some of them, though battery operated, do support queries.
Dean Roddey
Software Geek Extraordinaire
Reply
#6
Further clarification of read/write access. Unfortunately, locks are a worst case scenario. Many are not readable and it's not safe to allow drivers to fake it. So they have to be writeable, and they can be readable if they support it, and it's just necessary not to depend on readability if you want to create portable logic/interfaces.
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Class: Thermostat Dean Roddey 17 4,043 01-29-2016, 10:15 AM
Last Post: Dean Roddey
  Class: SceneCtrl Dean Roddey 20 2,517 03-31-2015, 12:38 PM
Last Post: Dean Roddey
  Class: Irrigation Dean Roddey 8 1,317 01-28-2015, 12:09 PM
Last Post: Dean Roddey
  Class: NowPlaying Dean Roddey 8 1,301 09-23-2014, 02:01 PM
Last Post: Dean Roddey
  Class: Switcher Dean Roddey 9 1,429 08-20-2014, 08:17 AM
Last Post: Dean Roddey
  Class: Security Dean Roddey 33 4,190 08-13-2014, 03:02 PM
Last Post: Dean Roddey
  Class: Projector Dean Roddey 29 3,086 08-11-2014, 08:56 AM
Last Post: Dean Roddey
  Class: ContactClosure Dean Roddey 7 1,074 07-31-2014, 10:14 AM
Last Post: Dean Roddey
  Class: DIO Dean Roddey 7 1,295 07-31-2014, 10:08 AM
Last Post: Dean Roddey
  Class: Relay Dean Roddey 4 867 07-31-2014, 09:56 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)