New PGN Proposed - DC Dimmer Status 3 - 0x1FEDA
Proposed:
An additional DC dimmer status PGN for monitoring the load with different parameters then presently defined in DC dimmer status 1 & 2.
DC_DIMMER_STATUS_3 requested PGN 0x1FEDA
Edit:
- Status Byte 0: Instances have been updated to 250 instances.
- Status Byte 1: Description has been updated to show group membership.
- Status Byte 3: The exception flags have all been broken up into 2 bit flags
- Status Byte 4: The ‘Delay/Duration’ value defines a unique scale that is consistent with other PGNs to show remaining time for the command.
- Status Byte 5: The commands that qualify for this field have been listed in a separate table with descriptions for each command as well as reference to the table.
Edit 2:
- Status Byte 2: We are requesting to note that for DC_Dimmer_Status_1, this is only for RGB lighting. This will remove any duplicate function that this Status PGN may have with DC_DIMMER_STATUS_1
- Status Byte 5: Commands that qualify for this field are referenced from the unified and centralized table now found in AC LOAD COMMAND.
| Attachment | Size |
|---|---|
| DC Dimmer Status 3 EDIT.doc | 75 KB |
| DC_Dimmer_Status_3v2.doc | 58 KB |
David Bailey - Byte 0
David Bailey -
Byte 0 Instances 0 to 250 OK
Byte 1 Group looks good.
Byte 2 Desired Level (Master Brightness)is in DC_DIMMER_STATUS1 best not duplicate, make reserved
Bytes 3,4 OK
Byte 5 Reference table of DC_DIMMER_STATUS2
Byte 6 OK
Byte 7 reserved
Engineering at Spyder
Engineering at Spyder Controls Corp.
Byte 2 - The DC Dimmer appears to have been initially developed for an RGB application. Though every effort was made to work with the existing DC Dimmer PGN’s, it was not possible to include all of the data for the functions and features that needed to be incorporated in the existing PGN’s. Though we could have spread out the all of the data over two or three different status PGN’s in an effort NOT to duplicate, this can become somewhat cumbersome and possibly impractical for development and interface. Another consideration was the increase in network traffic when each instance has to report its status by sending 3 different messages every second or two, especially in cases where there are over 100 different AC and DC load / Dimmer instances on a network.
In this case, if it is unacceptable to duplicate byte 2 within the DC Dimmer Status PGN’s, I submit a request that we be permitted to create a different name for the PGN to differentiate the ‘RGB Dimmer’ from a ‘Monochrome Dimmer’.
For byte 5, we will revise the doc’s to refer to DC_DIMMER_COMMAND2 command table.
Let's dive in. Byte 0 - Why
Let's dive in.
Byte 0 - Why only 124 Instances?
Byte 1 - Is this supposed to mean "This Instance belongs to these groups?". If so, call it "Group Membership". If you mean "This is the status of these groups", well, a particular node can only speak for its own instance, not the whole group. After all, nodes may belong to multiple groups, and not all Group 3 may be On if some belong to Group 4.
Byte 2 - This duplicates DC_DIMMER_STATUS_1.
Byte 3 - This should be broken up into separate flag fields.
Byte 4 - This duplicates DC_DIMMER_STATUS_1. The scaling is different - I assume that's the point.
Byte 5 - You need to document the commands. I'll bet they are in your DC_DIMMER_COMMAND_3!
Overall, I wonder why you don't just add to the existing DC_DIMMER_STATUS PGNs. There are four unused bytes in those PGNs, and these interrelate closely. I would make Byte 6 in STATUS_1 an "extended duration" field, and Byte 7 a "last command" field. Then I would add the flags to STATUS_2.