Justification:
The existing standard doesn’t specify how Groups are set within the DC_DIMMER_COMMAND_2. A simple way of implementing this and staying within how the standard normally functions is specifying both the Instance and Group in one message.
Submitted by Troy Roersma
Monday, July 27, 2026 | 15:17pm
| Attachment | Size |
|---|---|
| 6.24.6 DC dimmer Command 2 Submission r2.docx | 22 KB |
Please Sign in to View
Log in to view member-only content.
If you believe you are receiving this message in error contact us at memberservices@rvia.org.
Martin Perlot Member for 11 months 3 weeks
OBJECTION
More explanation is needed here. I suggest writing a full description of the desired scheme and inserting it after the DGN table (but before table 6.24.6c) - that would give you much more room. The description should include a full explanation of how this idea could be used to add (and also subtract) instances from a group. It should also describe how errors should be handled (e.g. either the instance or the group is invalid).
Beyond the readability issue, I have another concern. There should be some sort of discovery process - a way for a device or tool determine whether a specific instance belongs in a particular group. This could be as simple as creating a new command code (byte 3) and defining the appropriate ACK/NAK response.
Lucas Salviano Member for 3 months 3 weeks
Considering Martin's concerns (some of which I also share), as suggestion you can add:
Also, to verify the current Group configuration of a device you can use the Information Request DGN (0xEA00) asking for the desired status DGN (adding a note about this might also be a good idea).
Steve Duncan Member for 4 years 6 months
Updated document to include updates based on previous objections
Troy Roersma Member for 3 weeks 3 days
I updated the submission to include the suggestions. I had to use 01111111b to remove from all groups as 00000000b is actually making it a member of all groups.
Clayton Lorenz Member for 9 months 1 week
OBJECTION
This change is not backwards‑compatible. Historically, Byte 0 (Instance) and Byte 1 (Group) were mutually exclusive. When a group command was issued, the Instance field was required to be set to 0xFF. Existing hardware therefore assumes that only one of these fields is ever meaningful at a time.
If a command is sent using both fields simultaneously, older devices may behave unpredictably—potentially prioritizing one field arbitrarily or ignoring the combination entirely, since using both was previously invalid.
Although providing a way to set the group via an RV‑C command is reasonable, implementing it by reusing the existing fields conflicts with their established meaning and must be reconsidered.
A possible solution is to introduce a new command value dedicated specifically to group configuration. For example, a new command value such as 100 (Group Assignment) could be defined. This command would be treated separately from normal load‑control commands (currently 0 through 32) and would explicitly allow both the Instance and Group fields to be used together. Only when this new command is used would the dual‑field usage be considered valid.
Troy Roersma Member for 3 weeks 3 days
I would argue that it is backwards compatible. Since Byte 0 (Instance) and Byte 1 (Group) were mutually exclusive, the proper handling if both were sent in the past would be for group members to ignore the command as it is not a Group command. The existing language of the standard is that the instance is set to FF when it is a group command. Editing the group of the instance is not a group command, therefore the instance is not set to FF and is specified.
Clayton Lorenz Member for 9 months 1 week
That is an interesting perspective, but since this never was done before you cannot assume that every manufacturer carefully handled this case, and therefore it isn't inherently safe to send both an instance and a group currently, so the objection stands.
Regardless of the first point a unique command would need to be added, as it wouldn't make sense to use either a command of 0xFF or one of the currently assigned commands in order to add or remove individual instances from groups.
The two options I see would be to write a new DGN for this purpose or to add further safety within the existing mechanism being presented, and I am happy to remove the objection once one of these approaches has been taken. I believe there is merit in the addition and am not objecting to that in any way.
Troy Roersma Member for 3 weeks 3 days
What if it specifies that when editing the group all of the remaining bytes (Bytes 2-8) must be FF? That way no changes are made other than the group. If any past devices don't support this then no changes will be made anyway.
I'm not sure what your middle paragraph is objecting to as FF in the group field is treated as an instance command and no change to the group happens.
Clayton Lorenz Member for 9 months 1 week
Adding a unique command which is specifically for this purpose is more intentional and obvious. We are in no danger of running out of available commands so one should be assigned for this purpose.
Martin Perlot Member for 11 months 3 weeks
I suggest defining two Command values, one for adding the instance to the group(s), one for deleting the instance from the group. That kills a flock of birds with one stone.
There still isn't any way to determine whether an instance is in a particular group. We could use a third command value to ask "Is this instance in this group?", with the response being a ACK or NAK. It wouldn't work well for mapping out a system from scratch, but I suspect that the use case for this scheme is only for initial installation or to tweak the setup, not redefine the whole system on the fly. (If I'm wrong about that, we can pursue other ideas.)
The command-value tweak should be safe - there would be no harm if devices with and without this capability were to gets mixed together on a network. It's efficient - no new DGN is required. And it is explicit - there is little chance that a developer misinterprets the intent.