[Ovmsdev] System date set?

Mark Webb-Johnson mark at webb-johnson.net
Mon Feb 26 15:54:03 HKT 2018


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> 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 <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 <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 <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 <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 <mailto:OvmsDev at lists.teslaclub.hk>>
>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 <mailto:OvmsDev at lists.teslaclub.hk>>
>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 <mailto:OvmsDev at lists.teslaclub.hk>>
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20180226/667eff22/attachment-0001.html>


More information about the OvmsDev mailing list