6.16.7 Thermostat Schedule Status 1
Mon, 2024-09-16 17:39 — RV-C Admin
Justification: Byte 2 currently specifies real time clock values from 0-23 based on local time. We are developing a low-energy climate control that should be capable of long periods without power. We want to use relative-time clock only (no real time clock available). Therefore we would define within the same byte 24 = 0 hours real time up to 224 = 200 hours from now. 255 is reserved since 0xFF is generally otherwise meaningful in RV-CAN and 254 indicates some issue with the timer/clock system
New version 2 document loaded
| Attachment | Size |
|---|---|
| 6.16.7 Thermostat schedule status 1_v2.docx | 16.22 KB |
Is this latest feedback from
Is this latest feedback from the V2 of the specfication? Currently we are assuming that our fixes are aligned with your comments.
We don't have the word documents for the command (they also don't contain full table but reference the status table in the current specification) if we can please recieve these then we can update to break the link and specify explicitly. OR we can agree that the command table is updated. I do think that it makes absolute sense that command and status match perfectly because otherwise we can't reuse the code.
1. This should not be
1. This should not be considered without a corresponding amendment to THERMOSTAT_SCHEDULE_COMMAND_1.
Yes, this is correct. The content of ‘THERMOSTAT_SCHEDULE_COMMAND_1’ references the table of ‘THERMOSTAT_SCHEDULE_STATUS_1’ without repeating the content of the table itself. So the command function is implicitly updated by the update of status function. I don’t see how we should update the text of the command section to reflect this change. Do we need to apply for the change in command function, even though there is no difference to the actual text. Originaly we requested and recieved both word documents but then realised the table is referenced and not copied.
2. The wording is ambiguous and does not fit the context. I suggest something like:
In the table: 24 - Within 0 to 1 hour, 25 - 224 - Within 1 to 200 hours.
We expect the meaning to be precisely defined so 24 = exactly 60 minute, 25 = exactly 120
minutes etc. But I think we mean the same. Do we update the text in the table and resubmit?
After the table:Hour values from 24 to 224 indicate the schedule is based on the time relative to now, rather than being based on the real time. This supports applications where no real time clock is available.
OK
DISCUSSION Why is there no such extension for minutes? One hour is an extremely imprecise unit - how would you even test this in the field
We use the minute to mean minute for relative or absolute time but the use of hour field for real vs relative time is enough to communicate with system is used. If we have relative and absolute for minutes then there could be a conflict where the input uses relative minutes and absolute hours.
As an example, if I want to start in one and a half hours, I send THERMOSTAT_SCHEDULE_COMMAND_1 message with
Bit 2 = 24
Bit 3 = 30
Since it seems unclear in our draft, we could update the comment of bit 3 with text “minutes are considered as past the hour that is referenced in bit 2, whether relative or absolute” and also include the example to be 100% clear in the text following the table.
1. For a variety of reasons,
1. For a variety of reasons, COMMAND DGNs do not always match the STATUS DGNs. Each has to be fully described.
2. Yes, just update the text.
DISCUSSION
That seems fine. Examples are always appreciated.
OBJECTION 1. This should not
OBJECTION
1. This should not be considered without a corresponding amendment to THERMOSTAT_SCHEDULE_COMMAND_1.
2. The wording is ambiguous and does not fit the context. I suggest something like:
In the table:
24 - Within 0 to 1 hour.
25 - 224 - Within 1 to 200 hours.
After the table:
"Hour values from 24 to 224 indicate the schedule is based on the time relative to now, rather than being based on the real time. This supports applications where no real time clock is available."
DISCUSSION
Why is there no such extension for minutes? One hour is an extremely imprecise unit - how would you even test this in the field?