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
Objection is still valid, moved back to Official business
| Attachment | Size |
|---|---|
| 6.16.7 Thermostat schedule status 1_v2.docx | 16.22 KB |
THE OBJECTION REMAINS It
THE OBJECTION REMAINS
It seems that there is a misunderstanding. Once approved, the submission (minus the Justification) will be placed VERBATIM into the specification document. The Administrator does not have the authority to edit anything - all he is allowed to do is update any internal links. So it's your job to write to a professional standard and follow the same style and formats as the rest of the document, and there must be absolutely no ambiguity or opportunity for the Administrator to misinterpret your intent.
So, as pedantic as this sounds, you must address all of these issues precisely:
- Handle the COMMAND and the STATUS DGNs in separate sections, no matter how similar they are. (And they are not identical, as at the very least the explanatory text after the table will be different, as one should link to the other rather than duplicate it.)
- Provide an explanation, not just an example, of how the relative time values are to be used. The explanation should include the CONTEXT in which they are meant to be used (i.e. when no RTC is present), a DESCRIPTION of their use, and at least one EXAMPLE.
- Remove the FFh and FEh values from the table. These values are already implied in the RV-C spec.
- Clean up the formatting of the fields. As it stands, the values run together and are confusing.
Thank you.
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?