How can we help you today?

Start a new topic
Discussions OpenEVSE Forums Feature Requests

Auto clock sync after power-on

Having had surprisingly many power outages in the past few weeks I've noticed that the OpenEVSE won't resync the time after the power returns. Whether this is because it syncs at a much later time and I'm too impatient, I don't know.


If (as long as time sync is set to "automatic" the charger resynchronised it's time every day at 12:05am, it would mean that five minutes after power-up (when it'll have gone back to midnight at whatever date it says it is, I can't remember) it'll resynchronise. Perhaps this would even go so far as to render the backup battery redundant?

1 person likes this idea
38 CommentsSorted by Popular

@Erich Hammer The developer(s) do not see anything here. The main contributor for the WiFi firmware is active on the OpenEVSE Discord (@_Jez) https://discord.com/invite/Y3ftbUd4rR 


 Issues and suggestions on tracked and documented on GitHub  https://github.com/OpenEVSE/openevse_esp32_firmware 


I am not a developer but I had Grok Review the code and give a summary of NTP.


NTP (implemented as SNTP via MongooseSntpClient) in the OpenEVSE ESP32 firmware updates periodically every 8 hours by default. The logic is in src/time_man.cpp and src/time_man.h (part of the TimeManager class, which runs as a MicroTasks::Task).Key details from the code:

  • Update frequency / interval:  
    cpp
    #defineTIME_POLL_TIME8*60*60*1000// 8 hours in milliseconds
    This can be overridden at compile time. After a successful time fetch, the next poll is scheduled for millis() + TIME_POLL_TIME.
  • When updates happen:
    • Immediately when the NTP/SNTP host is set (setHost()) or SNTP is enabled (setSntpEnabled(true)), via checkNow() which forces _nextCheckTime = millis().
    • Periodically every 8 hours (or the overridden TIME_POLL_TIME) only if the network is connected (net.isConnected()).
    • On error (e.g., failed SNTP query): retries after 10 seconds (_nextCheckTime = millis() + 10*1000).
    • The main loop() in TimeManager checks the conditions and calls _sntp.getTime(_timeHost, callback) when it's time to poll.
  • Other behavior:
    • The host/server is configurable via setHost(const char*) (stored in _timeHost).
    • SNTP can be toggled on/off with setSntpEnabled(bool).
    • On success, the retrieved struct timeval is applied with settimeofday, optionally pushed to the OpenEVSE hardware, and a JSON time-change event is triggered.
    • Timezone is set via setTimeZone(String) (uses the TZ environment variable).

In short: the firmware does not do continuous or frequent NTP polling (e.g., every few minutes). It does a full SNTP sync on initial setup / config changes, then every 8 hours while the network is up, with a short back-off retry on failures. 


raw.githubusercontent.com +1If you override TIME_POLL_TIME or change the host/enabled state at runtime (via web config, MQTT, etc.), the next update will happen immediately or at the new interval. The exact default host and whether SNTP starts enabled by default would be in the initialization code (e.g., net_manager.cpp or app_config*.cpp), but the core polling behavior above is fixed in time_man.cpp. 

1 person likes this
I'm not as knowledgeable as Doug, but I had the same issue. I lost power a few days ago and the date/time reset basically to 0 when it came back on. Power was out a few hours. Like Doug, I have a Juicebox v2 board. I installed it 3-4 months ago. I confirmed it is running the latest firmware. It is connected successfully to my wifi (I see it on my network and can access the web interface). NTP is not blocked by the router. When my vehicle didn't charge overnight after the outage, I went in to check the settings. The date/time was way off. I pulled up the time settings on the browser interface and it was set to pull NTP automatically. I switched it to manual time entry thinking I'd do that in the short term, but the correct time popped up without me entering anything when I toggled it to manual. I switched it back to NTP and it stayed with the correct time. It was as if it hadn't automatically checked NTP when the power came back on, but when I switched it to manual, for some reason it prompted it to check and adjusted then. I know that's not the way it's supposed to work, but that's what happened. I mostly wanted to confirm Doug isn't crazy and add my experience with it checking and adjusting when I switched to manual time entry.
1 person likes this

I can't say that it is definitely not the firewall, but all the other devices in my house connected through the same router don't have any issues with knowing the time after power outages. 


I posed my question because of the posts just a month about by @MikeK and @DougLaRue about using "manual update mode"/"manual time entry". If that hasn't been around for 5+ years, what are they talking about?


What is the meaning of the green check that appears when the NTP server is changed? Is that just to say it has been updated, or that the NTP server has been pinged and is reachable? 


I know when I have troubleshoot my network, rebooting the cable modem can take a couple minutes, and the router isn't particularly fast about establishing a connection either. Thus, if the OpenEVSE only checks time on boot, it very well might not be able to reach the NTP at that time. 


It seems to me that having a button in the time interface to update time on demand would be both useful and easy to implement. It would also allow folks like me who aren't sure about their firewall to at least update the time even if it is manual. 



1 person likes this

@doug The old time system uses a DS3231 RTC time chip with battery plugged into the OpenEVSE controller via i2c. The RAPI commands set and read the time on the chip. If you try to do so today, there is no DS3231 chip the to receive the set commands.

1 person likes this

all signs point to ntp working inside our Wifi network and I reset my OpenEVSE to factory defaults, setup my wifi( same network as the rest of the house ) and setup Time and ntp service but still no time update on OpenEVSE.  Stranger things?


image


it's just really odd because all of our devices use ntp on our WAP incuding esp32 devices I've made like tide clocks and LoRaWAN gateways, rPi's besides all the computers in the home.

@Doug. Do you have a phone with cellular data you can use as a hotspot? If yes, turn your phone into a hotspot and have your station join the phone hotspot. Does NTP work in this configuration?

Thanks @MikeK for confirming I'm not crazy. :-)  As for it getting the correct time when you clicked on Manual update mode, well that pulls the time from your browser which pulls it from the computer you are running the browser on. There is definitely something weird going on with the NTP section of the WiFi firmware because not only does it sometimes not get NTP time, it doesn't do it on reboot sometimes and it doesn't periodically get it nor log that it's having problems getting the time.


I had even setup a ntpd time server on a local computer and it wouldn't pull time from it but after changing my Wifi AP on the OpenEVSE to test if a moble WAP helped, once changing it back to my home WAP it started working and even worked across a forced reboot.


I've got my WAP only 20' away from my OpenEVSE but around a couple of corners yet for some reason my OpenEVSE would drop offline and never reconnect. I've made some setting changes in my WAP specifically for the OpenEVSE device like setting only 2.4GHz and running a channel optimiation routine.


It's a more serious bug when things like your scheduled charge doesn't happen and you're left with a car that can't get you to work and back or something like that. 

I am also not getting time updates. I have no idea how long it has been like that as I don't check it often, but it currently says it is February 7, 1970. 


I'd change it to "manual", but I don't see that option. Is it in the web interface somewhere? 


Thanks!

I should add that when I put in a time server and hit enter, a green checkmark briefly appears. I would assume that means it has checked that it can reach the server. Is that not the case? 

@Erich Manual Browser sync was an option 5+ years ago when the stations had no WiFi and a RTC chip and battery. It is not applicable anymore. Most NTP issues are firewall issues. Check that NTP is allowed by your internet firewall.

OK. Well, I did say "I suspect". :-)  


That was just based on my observation that it didn't update the time on it's own even after many weeks, but immediately did so upon rebooting the WiFi. I'll move my observations to GitHub.


Thanks.



Just for fun... I pulled a station off the shelf and connected to WiFi here in the shop. Once connected time updated automatically, I set the time zone and it immediately updated. The station has the correct time after reboot.



@Doug LaRue What I'm trying to understand is how you are accomplishing manual time setting. I see nothing that would do that or allow for either receiving the time from the browser or typing in the time by hand. 


Also, it's not that the NTP settings are being forgotten. I suspect the root of the problem is that the time is set ONLY when the WiFi service/daemon is started up, and it is possible the time check is attempted before the WiFi connection is fully established. When house power goes down the network in general can take up to 2 minutes before being fully ready. The OpenEVSE boots up much faster than that, and if it never checks for the time server again, it will never set the time. 


In my case, either I don't have an internal battery backup to maintain the time, or the battery has died, so the time is always reset to "0". As luck would have it, I had a brief power outage just this morning. Of course the time was reset, but I logged back in, went to Settings -> Firmware and rebooted the WiFi (NOT the whole device). The time was then set correctly, so it was NOT a firewall or network issue. You should try that too and report back.


I'm including this information in case any of the developers see to it to set up either a delayed time check on boot. What would the harm be to wait 300 seconds after boot to check on the time? Alternatively, have it check periodically. Once a day wouldn't hurt either. Either one of those would certainly fix the issue I am having. 


@Doug LaRue NTP network time settings are saved in the exact same manner as SSID and all other settings. NTP works great for 10s of thousands of people. It is very difficult to troubleshoot a problem that very few people can reproduce. The code is developed by the community, is open source and published on GitHub. 

Login or Signup to post a comment
More topics in Feature Requests
See all 31 topics