Door Lock Status PGN
Fri, 2020-09-18 18:13 — VonLindsey
Nathan Romanowski of Firefly Integrations proposes to add Door Lock Status under table 6.40.2b
Byte Bit Name Data Type Unit Definition
4 to 5 Voltage uint 16 V See table 5.3
Justification
The changes proposed above are to support a wireless lock that will connect to a wireless bridge that will report status of the lock(s) over the can bus.
We're seeing a variety of
We're seeing a variety of wireless devices in development and entering the market. In time we'll surely be adding this datum to a number of different devices. For developers it would be easier to have a common format for all such devices - just as we have a common format for Alarms created by different devices.
I propose to replace this submission with this:
------------------------------
INTERNAL_BATTERY_STATUS
DGN TBA
Broadcast Gap: On Change/On Request
Acknowledgment Requirement: None
Byte 0: uint8 Device DSA
Byte 1: uint8 Device Instance
Bits 2.0-2.1 uint2 Device Type. 0 = Standard, 1 = Control Device. See Below
Bits 2.2-2.4 uint3 Low Voltage Warning. 0 = Ok, 1 = Voltage Low, 2 = Voltage Critically Low, 6 = No Reading Available
Bits 2.5-2.7 uint3 Device Subidentifier. See Below
Byte 3-4 uint16 Battery Voltage, See Table 5.3. FFFEh indicates that the device has not yet reported a value.
Byte 5-6: uint16 Time Elapsed Since Last Reading Minutes
The Device Type flag identifies whether the battery is located in the device described by the DSA and Instance, or to a fob or panel controlling that device. A Device Type of 0 indicates the former case, a Device Type of 1 indicates that latter. For example, a wireless fresh tank sensor would use Device DSA 72 (Tanks), Instance 0 (Fresh), Device Type 0 (Standard Device). A keyfob for the main door lock would use Device DSA 135 (Door), Instance 1 (Main), Device Type 1 (Control Device). As a system may have several keyfobs or similar devices, the Device Subidentifier field is provided to allow each device a unique report. Only the primary vendor of the device should use the SubIdentifier. Secondary control products should be uniquely identified using one of the alternatives described for multi-function controls below.
Note that a wireless control can have multiple functions. For example, a wireless switch panel may control several lights, shades, and the water pump. It can report with any of these three DSAs and their corresponding Instances (always with the Device Type = 1), but it should use the same identifiers in every report. An alternative is to report using DSA 68 (Control Panel), assign a DC Input Instance (per DIGITAL_INPUT_STATUS) to identify the unit, and report with the Device Type 0 (Standard Device). Note that, as with any instanced device, care must be taken to avoid having duplicate DIGITAL_INPUT_STATUS Instances on the network. It is not acceptable to use DSA 68 without an assigned digital input Instance and to rely on the Device SubIdentifier, as this value may not be unique on the network.
Note that a node that broadcasts this DGN may be a general purpose wireless receiver, and itself be neither a control panel or a device to be controlled. Requests for the DGN are to be addressed to such a receiver in the standard way, and the receiver shall respond with separate packets for each wireless battery it is monitoring.
--------------------------------
Also, I propose a group of new Generic Alarms, which would apply to all DSAs. This is the first set of "universal" alarms so far proposed. I propose numbering such alarms from 127 on down.
--------------------------------
Alarm Instance 127 - Internal Battery Low
Alarm Instance 126 - Internal Battery Critically Low
I am not sure I see the need
I am not sure I see the need for Bits 2.0-2.1 uint2 Device Type. 0 = Standard, 1 = Control Device. If a device does not have a battery, then it would not need to send the INTERNAL_BATTERY_STATUS. I am also confused what the Bits 2.5-2.7 uint3 Device Sub identifier is, what kind of information does it try to relay? Other than those two questions I would agree that this proposal could work in place of my proposal.
Here's why.
Here's why.
Consider a Thermostat system that has two wireless elements: a keyfob to allow the user to turn it on and off, and a temperature sensor hidden in the ducting. Both items would have the same DSA (thermostat) and Instance. The flag eliminates the ambiguity - the temp sensor is a "standard" device, the keyfob a "control" device. Granted, it is possible to call all keyfobs and such "control panels", but that would run into instance-management issues as there may be keyfobs from multiple suppliers.
Perhaps a better terminology would be a "status" device and a "command" device. That connects more closely the device to the types of messages it triggers.
An example where the SubIdentifier is necessary is when there are multiple keyfobs to control the same device. If we have, say, a Vent Fan with two fobs to control it, each fob battery would report with the same DSA (vent fan) and Instance. To eliminate the ambiguity, the vendor would use different SubIdentifiers for each.
I could see in very rare
I could see in very rare cases needing to use the Device type as you put it above.
After talking over your proposed changes with some of the other engineers we do not think that wireless devices should be considered nodes in the can bus but rather let the wireless bridge represent a gate keeper node. By this I mean the wireless bridge would have a DSA and keep a record of all connected devices according to the standard that the devices communicate in. Then changes byte 0 to the type of devices and byte 1 to be the instance. So for example if we assign Standard device types to be the following
Locks: 0
Tanks:1
Heating unit:2
...
The lock would then send a 0 on byte 0 saying the status is from a lock then what the instance is on byte 1. We could use table 7.2 (Source address) as an outline for possible device types but I think that it should be one value per type and then instanced from there.
This would cut down on complicated firmware on the wireless device and bridge to allow for the DSA negotiation.
I think you are
I think you are misinterpreting the proposal. The original proposal assumes that the wireless devices run through a "gatekeeper". (At the moment, the proper DSA for the bridge is 253 (network bridge), although an argument can be made for creating a new DSA for it.)
In fact, I don't think there is a meaningful difference between the original proposal and what you suggest - you simply invent new identifiers to replace the DSA. And I don't see any good reason to do that - it's just an invitation for confusion. All of your examples already have DSAs, and if there is some wireless device being contemplated that does not currently have a DSA, then we should simply create a DSA for it. That's much simpler that creating a whole new table.
It could work as long as the
It could work as long as the wireless devices can share the same DSA for their type and don't have to negotiate for it. For example if you have 4 wireless tank systems they would all use the DSA 72 but use different instances. So that way the gateway module can just keep track of the instance and not try to negotiate for DSAs every time something connects.
Ok, then. DSA's are not
Ok, then. DSA's are not something that ever has to be negotiated - it's simply an identifier - and Instances are already required to be unique within the device type. So it seems we're in agreement.