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
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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@validalo.net <mailto:geir@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@webb-johnson.net <mailto:mark@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@acm.org <mailto:casner@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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"); + 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@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@validalo.net <mailto:geir@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@webb-johnson.net <mailto:mark@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@acm.org <mailto:casner@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Oh, I should also remark that GPS time is considered statum 1 if the receiver is well-designed for timekeeping and conveys fractions of the second accurately (that is, doesn't just present time as a string with one-second resolution). I don't know much fuzz there would be between the actual GPS receiver built into the OVMS modem and the system's access to the time information. Similarly, the cars with GPS may get time from there but might not convey the time to OVMS with particular accuracy. -- Steve
Following this recommendation, I've added the MyTime.Set() to our GPS receiver with stratum 2, as we don't receive fractions and we've got the radio delay + possibly a second delay from the modem update frequency. Regards, Michael Am 25.02.2018 um 01:23 schrieb Stephen Casner:
Oh, I should also remark that GPS time is considered statum 1 if the receiver is well-designed for timekeeping and conveys fractions of the second accurately (that is, doesn't just present time as a string with one-second resolution). I don't know much fuzz there would be between the actual GPS receiver built into the OVMS modem and the system's access to the time information.
Similarly, the cars with GPS may get time from there but might not convey the time to OVMS with particular accuracy.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@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
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@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"); + 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@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@validalo.net <mailto:geir@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@webb-johnson.net <mailto:mark@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@acm.org <mailto:casner@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@acm.org <mailto:casner@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@webb-johnson.net <mailto:mark@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@validalo.net <mailto:geir@validalo.net> <mailto:geir@validalo.net <mailto:geir@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@webb-johnson.net <mailto:mark@webb-johnson.net> <mailto:mark@webb-johnson.net <mailto:mark@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@acm.org <mailto:casner@acm.org> <mailto:casner@acm.org <mailto:casner@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> <mailto:OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk>> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> <mailto:OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> <mailto:OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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 :-)
There may eventually be some progress on this in Europe now… http://www.dw.com/en/european-parliament-votes-for-review-of-daylight-saving... …but thorough assessments need to be carried out first… and proposals need to be written… and revised… and rewritten… Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
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@webb-johnson.net <mailto:mark@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@acm.org <mailto:casner@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@webb-johnson.net <mailto:mark@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@validalo.net <mailto:geir@validalo.net> <mailto:geir@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@webb-johnson.net <mailto:mark@webb-johnson.net> <mailto:mark@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@acm.org <mailto:casner@acm.org> <mailto:casner@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> <mailto:OvmsDev@lists.teslaclub.hk> >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> <mailto:OvmsDev@lists.teslaclub.hk> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
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@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@webb-johnson.net <mailto:mark@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@acm.org <mailto:casner@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@webb-johnson.net <mailto:mark@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@validalo.net <mailto:geir@validalo.net> <mailto:geir@validalo.net <mailto:geir@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@webb-johnson.net <mailto:mark@webb-johnson.net> <mailto:mark@webb-johnson.net <mailto:mark@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@acm.org <mailto:casner@acm.org> <mailto:casner@acm.org <mailto:casner@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> <mailto:OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk>> >>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev> >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> <mailto:OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk>> >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev> > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> <mailto:OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk>> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@expeedo.de <mailto:dexter@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@webb-johnson.net <mailto:mark@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@acm.org <mailto:casner@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@webb-johnson.net <mailto:mark@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@validalo.net <mailto:geir@validalo.net> <mailto:geir@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@webb-johnson.net <mailto:mark@webb-johnson.net> <mailto:mark@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@acm.org <mailto:casner@acm.org> <mailto:casner@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> <mailto:OvmsDev@lists.teslaclub.hk> >>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> <mailto:OvmsDev@lists.teslaclub.hk> >>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> <mailto:OvmsDev@lists.teslaclub.hk> >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
participants (4)
-
Geir Øyvind Vælidalo -
Mark Webb-Johnson -
Michael Balzer -
Stephen Casner