[Ovmsdev] v.c.timerstart units

[Stephen Casner]

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