Yeah – I’ve got a patch to fix the comments/documentation on that and the other changes already up that changed the default format for m.time.utc and v.p.gpstime as well as now v.e.serv.time. I’ll do a p/r separately for this //.ichael From: OvmsDev <ovmsdev-bounces@lists.openvehicles.com> On Behalf Of Michael Balzer Sent: Sunday, December 3, 2023 3:33 PM To: ovmsdev@lists.openvehicles.com Subject: Re: [Ovmsdev] VWEUP module service interval? Michael, yes, v.e.serv.time is local time. Please also fix the comment "Time to", I think that remained from the initial draft. IDF5 migration probably could use some help: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752#... sorry to have been silent such a long time - I unfortunately have been busy on other subjects, and I didn't have the time (and still don't) to make significant progresses on the ESPv5+ front Regards, Michael Am 03.12.23 um 03:13 schrieb Michael Geddes: Hey All, I've been paving the way for 64 bit time_t that's apparently in the newer esp32 releases. I'm keen to know how that update to the newer sdk is going too? For persistence, I am registering the high 32bits as a second metric with "_hi" suffix (Similar to how the arrays work). One thing I've noticed is that there's a standard metric: OvmsMetricInt* ms_v_env_service_time; // Time to next scheduled maintenance/service [Seconds] cf the doc v.e.serv.time 1572590910Sec Time of next scheduled maintenance/service [Seconds] So it's a bit ambiguous but vweup (the only one who sets this metric) implementation treats this as a time_t. I think I will convert it to a 64 bit 'DateLocal' metric. Thoughts? //.ichael _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26