[Ovmsdev] System date set?
Michael Balzer
dexter at expeedo.de
Sat Mar 3 19:08:44 HKT 2018
Looks good, tried some forced reconnects, no crashes.
Also cooperating nicely on the time:
OVMS > time status
UTC Time: Sat Mar 3 11:05:36 2018
Local Time: Sat Mar 3 12:05:36 2018
Provider: ntp
PROVIDER STRATUM UPDATE TIME
gsm-nmea 2 1 Sat Mar 3 11:05:37 2018
*ntp 1 264 Sat Mar 3 11:05:36 2018
Regards,
Michael
Am 03.03.2018 um 10:24 schrieb Mark Webb-Johnson:
> Although apparent in SNTP, I think the core issue here is in ovms_netmanager.
>
> When wifi goes down, that issued a network.reconfigured event followed by a network.down event. The network.reconfigured causes a stop/start of sntp and I
> guess there is a race condition there.
>
> Best fix is to change ovms_netmanager so that network.reconfigured is NOT issued if the network is down (only if say two networks were up, and one went down,
> so one is still up).
>
> I’ve also moved the SNTP init code into module startup (rather than network availability) to try to work around the race condition in SNTP.
>
> Regards, Mark
>
>> On 3 Mar 2018, at 2:38 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
>> Just fetched the latest updates, now getting a crash / reboot as soon as the ppp gets an IP:
>>
>> I (45514) gsm-ppp: StatusCallBack: None
>> I (45514) gsm-ppp: status_cb: Connected
>> I (45514) gsm-ppp: our_ipaddr = 10.170.195.13
>> I (45514) gsm-ppp: his_ipaddr = 10.64.64.64assertion "Operating mode must not be set while SNTP client is running" failed: file
>> "/home/balzer/esp/esp-idf/components/lwip/apps/sntp/sntp.c", line 604, function: sntp_setoperatingmode
>> abort() was called at PC 0x400f6e2f on core 0
>>
>> Backtrace: 0x4008f64c:0x3ffcc770 0x4008f823:0x3ffcc790 0x400f6e2f:0x3ffcc7b0 0x401935f5:0x3ffcc7e0 0x400e237a:0x3ffcc800 0x400e2a5c:0x3ffcc820
>> 0x400e6c45:0x3ffcc860 0x400e6ecc:0x3ffcc890 0x400e9249:0x3ffcc920 0x400e9ab8:0x3ffc
>> c990 0x400e6c45:0x3ffcc9d0 0x400e6ecc:0x3ffcca00 0x40126a3a:0x3ffcca90 0x401a20ad:0x3ffccb00 0x401a2f46:0x3ffccb20 0x401a5fbb:0x3ffccb40
>> 0x401a61b2:0x3ffccb60 0x401a2873:0x3ffccb80 0x401a1d71:0x3ffccba0 0x401a25e8:0x3ffccbd0 0
>> x401a2735:0x3ffccbf0 0x4018f581:0x3ffccc10
>>
>> Rebooting...
>>
>>
>> Switching esp-idf to the new branch origin/sntp-extension didn't help.
>>
>> Regards,
>> Michael
>>
>>
>> Am 26.02.2018 um 08:54 schrieb Mark Webb-Johnson:
>>>
>>> Not too bad, so long as you live in a sensible area without DST :-)
>>>
>>> OVMS > config list vehicle
>>> vehicle (readable writeable)
>>> id: TESTCAR
>>> name:
>>> timezone: HKT-8
>>> units.distance: K
>>>
>>> OVMS > time set 1519631172
>>> Time set (at stratum 15)
>>>
>>> OVMS > time
>>> UTC Time: Mon Feb 26 07:46:13 2018
>>> Local Time: Mon Feb 26 15:46:13 2018
>>> Provider: time
>>>
>>> PROVIDER STRATUM UPDATE TIME
>>> *time 15 1 Mon Feb 26 07:46:13 2018
>>>
>>>
>>> It is also mapped as parameter #23 for OVMS server v2.
>>>
>>> Committed to github. I’ll look at SNTP next.
>>>
>>> Regards, Mark.
>>>
>>>> On 26 Feb 2018, at 1:40 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>>
>>>>
>>>> I’ve extended ovms_time to also include suseconds_t timu, if available.
>>>>
>>>> I think NTP can be done within ovms_time, as an ‘ntp’ source in a similar way to the ‘time’ source for manual configuration. The issue I am hitting is
>>>> finding out when the time has actually been set. It seems that LWIP SNTP doesn’t provide any facility to expose that. There is a
>>>> macro SNTP_SET_SYSTEM_TIME_US that is defined in the Espressif LWIP options file as:
>>>>
>>>> #define SNTP_SET_SYSTEM_TIME_US(sec, us) \
>>>> do { \
>>>> struct timeval tv = { .tv_sec = sec, .tv_usec = us }; \
>>>> settimeofday(&tv, NULL); \
>>>> } while (0);
>>>>
>>>>
>>>> but there is no easy way of overriding that from a client app. It seems I’m not the only one who found this:
>>>>
>>>> https://www.esp32.com/viewtopic.php?f=2&t=4695
>>>>
>>>> by vonnieda <https://www.esp32.com/memberlist.php?mode=viewprofile&u=4952&sid=4f2bdf4eea4ed434cf38cf94a2df7709> » Tue Feb 13, 2018 11:48 pm
>>>> It's working well, but I need to know when it has received a time update and set the time.
>>>>
>>>> by loboris <https://www.esp32.com/memberlist.php?mode=viewprofile&u=2849&sid=4f2bdf4eea4ed434cf38cf94a2df7709> » Wed Feb 14, 2018 8:34 am
>>>> I've needed the same thing and ended up adding the global variable sntp_is_synced which is set to true before calling SNTP_SET_SYSTEM_TIME_US in "sntp.c".
>>>> Not a very elegant solution because I've modified the file in the esp-idf, but it works fine.
>>>>
>>>>
>>>> Urgh. But, the Laboris solution seems fairly neat and would meet our requirements.
>>>>
>>>> Time zones seem messy (without all those compiled zone files), but workable. I’ll add it.
>>>>
>>>> Regards, Mark.
>>>>
>>>>> On 25 Feb 2018, at 5:44 AM, Stephen Casner <casner at acm.org <mailto:casner at acm.org>> wrote:
>>>>>
>>>>> Mark,
>>>>>
>>>>> Thanks for this. I've made a small change to make 'status' the
>>>>> default argument for the command if you don't give one. (I made a
>>>>> change to the command system this some months ago to enable this but
>>>>> it hasn't been used much yet.)
>>>>>
>>>>> I have a few comments on the time system:
>>>>>
>>>>> - A full NTP daemon does much more than select among time sources by
>>>>> stratum. Given multiple sources, it also has mechanisms to try to
>>>>> detect "falsetickers" (a Dave Mills term) and strategies to choose
>>>>> between stepping or slewing time depending upon which is more
>>>>> appropriate for the way the time source is used.
>>>>>
>>>>> - One of the ESP-IDF example programs is SNMP (simple NTP) using the
>>>>> capability built into LwIP. It is easy to invoke -- as a test I
>>>>> just added this to console_ssh to take advantage of its existing
>>>>> event notification for wifi coming up:
>>>>>
>>>>> @@ -32,6 +32,7 @@
>>>>> #include <lwip/def.h>
>>>>> #include <lwip/sockets.h>
>>>>> #undef bind
>>>>> +#include "apps/sntp/sntp.h"
>>>>> #include "freertos/queue.h"
>>>>> #include "ovms_log.h"
>>>>> #include "ovms_events.h"
>>>>> @@ -153,6 +155,11 @@ void OvmsSSH::NetManInit(std::string event, void* data)
>>>>> // Only initialise server for WIFI connections
>>>>> if (!MyNetManager.m_connected_wifi) return;
>>>>>
>>>>> + ESP_LOGI(tag, "Initializing SNTP");
>>>>> + sntp_setoperatingmode(SNTP_OPMODE_POLL);
>>>>> + sntp_setservername(0, (char*)"pool.ntp.org <http://pool.ntp.org/>");
>>>>> + sntp_init();
>>>>> +
>>>>> ESP_LOGI(tag, "Launching SSH Server");
>>>>> int ret = wolfSSH_Init();
>>>>> if (ret != WS_SUCCESS)
>>>>>
>>>>> One problem with fitting this into the time scheme that you have
>>>>> implemented is that it will be updating time in the background on
>>>>> its own. The other operating mode is SNTP_OPMODE_LISTENONLY, which
>>>>> I don't think would be useful. There are parameters defined in
>>>>> components/lwip/include/lwip/apps/sntp/sntp_opts.h that might be
>>>>> useful to change. The current update interval is one hour.
>>>>>
>>>>> - Another aspect of the SNMP example program is the use of the
>>>>> environment variable TZ to control the local timezone. Here is the
>>>>> 'date' command I implemented as a test:
>>>>>
>>>>> void date(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv)
>>>>> {
>>>>> time_t now;
>>>>> struct tm timeinfo;
>>>>> char strftime_buf[64];
>>>>> setenv("TZ", "PST8PDT,M3.2.0/2,M11.1.0", 1);
>>>>> tzset();
>>>>> time(&now);
>>>>> localtime_r(&now, &timeinfo);
>>>>> strftime(strftime_buf, sizeof(strftime_buf), "%c", &timeinfo);
>>>>> writer->printf("The current date/time in Sunnyvale is: %s\n", strftime_buf);
>>>>> }
>>>>>
>>>>> Perhaps we should have a config parameter for timezone?
>>>>>
>>>>> -- Steve
>>>>>
>>>>> On Sat, 24 Feb 2018, Mark Webb-Johnson wrote:
>>>>>
>>>>>> I’ve done a very rough implementation of this:
>>>>>>
>>>>>> OVMS > time set 1519486746
>>>>>> Time set (at stratum 15)
>>>>>>
>>>>>> OVMS > time status
>>>>>> UTC Time: Sat Feb 24 15:39:09 2018
>>>>>> Local Time: Sat Feb 24 15:39:09 2018
>>>>>> Provider: time
>>>>>>
>>>>>> PROVIDER STRATUM UPDATE TIME
>>>>>> *time 15 4 Sat Feb 24 15:39:10 2018
>>>>>>
>>>>>> OVMS > time status
>>>>>> UTC Time: Sat Feb 24 15:39:14 2018
>>>>>> Local Time: Sat Feb 24 15:39:14 2018
>>>>>> Provider: time
>>>>>>
>>>>>> PROVIDER STRATUM UPDATE TIME
>>>>>> *time 15 9 Sat Feb 24 15:39:15 2018
>>>>>>
>>>>>> I’ll work on it some more tomorrow. As it is, components can now call MyTime.Set(…) to feed their opinion of time into the system.
>>>>>>
>>>>>> Regards, Mark.
>>>>>>
>>>>>>> On 24 Feb 2018, at 10:23 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>>>>>
>>>>>>> I forgot about vehicles. Tesla Roadster is the same.
>>>>>>>
>>>>>>> I’ll write an ovms_time component now. Then, we can all submit time to it appropriately.
>>>>>>>
>>>>>>> class OvmsTime
>>>>>>> {
>>>>>>> public:
>>>>>>> OvmsTime();
>>>>>>> ~OvmsTime();
>>>>>>>
>>>>>>> public:
>>>>>>> void Set(char* provider, int stratum, bool trusted, time_t time);
>>>>>>> };
>>>>>>>
>>>>>>> extern OvmsTime MyTime;
>>>>>>>
>>>>>>> Just follow the NTP stratum approach (distance from a zero-delay device). Trusted is a separate indication that just sets stratum level to 16. The
>>>>>>> provider is simply the logging TAG.
>>>>>>>
>>>>>>> Internal implementation is like NTP. We track the last times from all providers, and pick the one with the lowest stratum that has reported within a
>>>>>>> reasonable time.
>>>>>>>
>>>>>>> We can add the boot-time save/restore later (once Michael has done that code for safe boot, etc).
>>>>>>>
>>>>>>> Regards, Mark.
>>>>>>>
>>>>>>>> On 24 Feb 2018, at 9:19 PM, Geir Øyvind Vælidalo <geir at validalo.net <mailto:geir at validalo.net> <mailto:geir at validalo.net>> wrote:
>>>>>>>>
>>>>>>>> Sounds like a plan. I can get time from the car too, but the resolution is several seconds, so I think we need to have some sort of priority here.
>>>>>>>> Maybe SNTP first, then GPS, cellular and finally “car”?
>>>>>>>>
>>>>>>>> Geir
>>>>>>>>
>>>>>>>> Sendt fra min iPhone
>>>>>>>>
>>>>>>>>> 24. feb. 2018 kl. 04:36 skrev Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net> <mailto:mark at webb-johnson.net>>:
>>>>>>>>>
>>>>>>>>> I don’t think so.
>>>>>>>>>
>>>>>>>>> There are various sources for date/time. GPS. Cellular. SNTP. Need to ensure that they are not all fighting.
>>>>>>>>>
>>>>>>>>> Another module to do this? Have components tell it their opinion of the time, then it centrally decides and updates system clock if necessary
>>>>>>>>>
>>>>>>>>> Also store last clock in RTC ram so during a crash/reboot it can recover the last know time?
>>>>>>>>>
>>>>>>>>> Regards, Mark
>>>>>>>>>
>>>>>>>>>> On 24 Feb 2018, at 9:44 AM, Stephen Casner <casner at acm.org <mailto:casner at acm.org> <mailto:casner at acm.org>> wrote:
>>>>>>>>>>
>>>>>>>>>> Does the sytem date get set anywhere (presumably from GPS)?
>>>>>>>>>>
>>>>>>>>>> This question occurred to me as I'm working on a side project using
>>>>>>>>>> the DEVKIT-C module which won't have access to GPS so I added the code
>>>>>>>>>> to set the data using SNTP.
>>>>>>>>>>
>>>>>>>>>> -- Steve
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OvmsDev mailing list
>>>>>>>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk> <mailto:OvmsDev at lists.teslaclub.hk>
>>>>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OvmsDev mailing list
>>>>>>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk> <mailto:OvmsDev at lists.teslaclub.hk>
>>>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OvmsDev mailing list
>>>>>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk> <mailto:OvmsDev at lists.teslaclub.hk>
>>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>>
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>> --
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/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: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180303/94aa2ca6/attachment.htm>
More information about the OvmsDev
mailing list