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