From frog at bunyip.wheelycreek.net Sun Dec 3 10:13:19 2023 From: frog at bunyip.wheelycreek.net (Michael Geddes) Date: Sun, 3 Dec 2023 10:13:19 +0800 Subject: [Ovmsdev] VWEUP module service interval? Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dexter at expeedo.de Sun Dec 3 15:32:38 2023 From: dexter at expeedo.de (Michael Balzer) Date: Sun, 3 Dec 2023 08:32:38 +0100 Subject: [Ovmsdev] VWEUP module service interval? In-Reply-To: References: Message-ID: 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#issuecomment-1791558855 > 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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From frog at bunyip.wheelycreek.net Sun Dec 3 16:38:13 2023 From: frog at bunyip.wheelycreek.net (frog at bunyip.wheelycreek.net) Date: Sun, 3 Dec 2023 16:38:13 +0800 Subject: [Ovmsdev] VWEUP module service interval? In-Reply-To: References: Message-ID: <002401da25c4$0f45c7a0$2dd156e0$@bunyip.wheelycreek.net> 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 On Behalf Of Michael Balzer Sent: Sunday, December 3, 2023 3:33 PM To: ovmsdev at 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#issuecomment-1791558855 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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ckambiselis at gmail.com Mon Dec 11 22:10:26 2023 From: ckambiselis at gmail.com (Christos Oscar Kambiselis) Date: Mon, 11 Dec 2023 16:10:26 +0200 Subject: [Ovmsdev] CAN2 turning off without reason Message-ID: Good afternoon, I've been trying to log CAN data using CAN2 in listen mode and connected to a different bus in the car ,I stopped the logging to the SD card yesterday and was going to test network streaming the data directly today, since I was having problems downloading the file, but I noticed that it goes to "Off" after an unspecified time. Yesterday I made sure it was on "Listen", after failing with the SD card file. And there is no mention of a timer, in the dev docs. Oscar -------------- next part -------------- An HTML attachment was scrubbed... URL: