[Ovmsdev] System date set?
Michael Balzer
dexter at expeedo.de
Sat Mar 3 02:38:29 HKT 2018
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180302/a03debb6/attachment.htm>
More information about the OvmsDev
mailing list