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