6.16.3 Thermostat Status 2
Mon, 2024-09-16 17:38 — RV-C Admin
Justification: Byte 3 of thermostat status 2 already defines mode selection for low-noise. We want to extend this 0-1 = reduced noise (as existing) 2-3 = eco mode (for low energy operation) 4-5 = turbo mode (for high performance operation) 6-7 = reserved for future mode change These modes are supplementary to existing modes e.g. cooling + turbo, fan + eco are possible so we think better in this location than 6.16.2.
New Version 2 document posted
Objection is still valid
| Attachment | Size |
|---|---|
| 6.16.3 Thermostat status 2_v2.docx | 16.56 KB |
Does the current state mean
Does the current state mean that we can implement based on V2 or is there still something open? If the command needs update then we need to please get the word document. Maybe we need to do a call and update the document together in that case? If command is separate from status then does it become a new forum entry? I am not really sure what the status is here since our request is an exact copy of the original specification with only additional values.
OBJECTION One substantial,
OBJECTION
One substantial, two trivial.
1. This should not be considered without a corresponding submission for THERMOSTAT_COMMAND_2.
2. For both mode descriptions, remove "10b - Reserved" and "11b - Not Supported". Unless there is a very specific reason why the standard definitions for these values is not appropriate, we always leave these values out of the definition and allow the standard definitions to apply.
3. Remove Byte 3 / Bits 6-7. We do not "reserve" fields in DGNs. Developers should always assume that eventually the committee will find a use for these bits.
1. This should not be
1. This should not be considered without a corresponding submission for THERMOSTAT_COMMAND_2.
OK. The section describing THERMOSTAT_COMMAND_2 refers to THERMOSTAT_STATUS_2 so the text of the THERMOSTAT_COMMAND_2 section would not change but the data packet would be implicitly updated.
2. For both mode descriptions, remove "10b - Reserved" and "11b - Not Supported". Unless there is a very specific reason why the standard definitions for these values is not appropriate, we always leave these values out of the definition and allow the standard definitions to apply.
OK.
3. Remove Byte 3 / Bits 6-7. We do not "reserve" fields in DGNs. Developers should always assume that eventually the committee will find a use for these bits.
OK.
Same as with the other
Same as with the other submission . . . we always explicitly define each DGN, as they don't always match.