Charmed Quark Systems, Ltd. - Support Forums and Community
Class: Lock - Printable Version

+- Charmed Quark Systems, Ltd. - Support Forums and Community (
+-- Forum: General Discussion (
+--- Forum: Device Classification (
+--- Thread: Class: Lock (/showthread.php?tid=8910)

Class: Lock - Dean Roddey - 06-22-2014

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.

Class: Lock - Dean Roddey - 06-22-2014

(Reserved 1)

Class: Lock - Dean Roddey - 06-22-2014

Forgot to define this very obvious one. It'll be included in 4.4.930 and beyond.

Class: Lock - batwater - 06-22-2014


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


Class: Lock - Dean Roddey - 06-22-2014

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.

Class: Lock - Dean Roddey - 07-31-2014

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.