06-22-2014, 09:11 AM
(This post was last modified: 09-21-2017, 12:39 PM by Dean Roddey.)
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.
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
Explorans limites defectum
Explorans limites defectum
