Newmar, TriMark, and SilverLeaf Electronics submit a device definition intended for generic alarms. This protocol has application for a wide variety of alarms in the RV - not just burglar alarms, but such features as a door-open alarm on a refrigerator.
Attachment | Size |
---|---|
Generic Alarm.doc | 37 KB |
In private correspondence,
In private correspondence, committee member Mark Moeller indicated his intention to add a set of fields to support timed reset functions. To clear some extra space in the packet, I propose reducing the size of the Elapsed Time field. Specifically:
Byte 3-4 Elapsed Time uint16 min Time elapsed while triggered. This should not be reset to zero until the alarm is triggered again.
This allows a value of up to 65530 min (about 45 days). The loss of precision should not be an issue, as the purpose of the data field is to give user feedback on alarms that occur when the user is away from the vehicle (e.g. just how lock the freezer door has been open.)
As Administrator, I propose
As Administrator, I propose some additional verbiage:
The RV-C committee shall, from time-to-time, define specific alarm instances for particular devices. The committee shall number these alarms starting at 1 and work up. Therefore, product-specific alarms (which, for whatever reason, the device manufacturer does not wish to submit to the committee for standardization) should use instances well above the range.
The following alarm instances are defined:
DSA 107, 108, 109, 110 - Refrigerator, etc.. Alarm Instance 1. Door Open
DSA 107, 108, 109, 110 - Refrigerator, etc.. Alarm Instance 2. Interior Temperature High.
Justification: This method should allow us to standardizing some common alarms, such as the two I list here. Such alarms are useful for conditions that are not "faults", worthy of a DM-RV, are not frequent or important enough to merit a dedicated flag in a status DGN, or require the acknowledgement scheme present in this pair of DGNs.