[Ovmsdev] v.c.timerstart units
casner at acm.org
Fri Mar 20 00:55:58 HKT 2020
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
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
More information about the OvmsDev