Perhaps we should add another enumerator to metric_unit_t named Time or maybe HMS that would be implemented for OvmsMetricInt::AsString and OvmsMetricFloat::AsString to display the value in the %H:%M:%S format. Or if it would be useful to distinguish timezones, add separate enumerators TimeUTC and TimeLocal. Should the timerstart value for Tesla Roadster be changed to seconds since midnight? -- Steve On Wed, 18 Mar 2020, Stephen Casner wrote:
I have just fixed a presumably quite old typo/copy-paste bug in vehicle_teslaroadster that caused CAN decoding to miss the message sent when the charge start time is selected or adjusted on the VDS. That value is stored in v.c.timerstart.
Now comes the question how should v.c.timerstart be interpreted -- the user guide does not say. What the code in vehicle_teslaroadster did was to set the GMT hour in the high 8 bits of a 16-bit integer and the minutes (always 0) in the low 8 bits. The current implementation of "metrics list" shows the value as a decimal integer, so for my car set to 11pm in the -7:00 time zone the value displayed is 1792, which is not very user-friendly.
The Demo and Zeva vehicles just set the value to 0. The Kia Soul sets the value to seconds after midnight UTC/GMT. The Smart ED also sets the value in seconds, but the comments don't indicate what timezone.
What should be the right interpretation and display of that value?
It seems that a resolution of minutes would be sufficient because it is unlikely that any vehicle would allow starting at a second other than 0 within a minute, but keeping track of a time in seconds is a pretty standard unit.
-- Steve