Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Class: Lock
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:


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

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
Explorans limites defectum

Messages In This Thread
Class: Lock - by Dean Roddey - 06-22-2014, 09:11 AM
Class: Lock - by Dean Roddey - 06-22-2014, 09:11 AM
Class: Lock - by Dean Roddey - 06-22-2014, 09:12 AM
Class: Lock - by batwater - 06-22-2014, 12:03 PM
Class: Lock - by Dean Roddey - 06-22-2014, 12:06 PM
Class: Lock - by Dean Roddey - 07-31-2014, 01:24 PM

Possibly Related Threads…
Thread Author Replies Views Last Post
  Class: Security Dean Roddey 34 35,424 01-02-2019, 12:26 PM
Last Post: Dean Roddey
  Class: Weather Dean Roddey 6 6,688 10-11-2018, 11:09 AM
Last Post: Dean Roddey
  Class: Thermostat Dean Roddey 17 26,481 01-29-2016, 10:15 AM
Last Post: Dean Roddey
  Class: SceneCtrl Dean Roddey 20 20,839 03-31-2015, 12:38 PM
Last Post: Dean Roddey
  Class: Irrigation Dean Roddey 8 9,532 01-28-2015, 12:09 PM
Last Post: Dean Roddey
  Class: NowPlaying Dean Roddey 8 9,785 09-23-2014, 02:01 PM
Last Post: Dean Roddey
  Class: Switcher Dean Roddey 9 10,626 08-20-2014, 08:17 AM
Last Post: Dean Roddey
  Class: Projector Dean Roddey 29 27,011 08-11-2014, 08:56 AM
Last Post: Dean Roddey
  Class: ContactClosure Dean Roddey 7 8,743 07-31-2014, 10:14 AM
Last Post: Dean Roddey
  Class: DIO Dean Roddey 7 9,181 07-31-2014, 10:08 AM
Last Post: Dean Roddey

Forum Jump:

Users browsing this thread: 1 Guest(s)