OpenEVSE lost time/date and started charging

Checking on my house electricity usage late this evening and noticed it was way, way higher than it should be. Quick scroll down showed that the OpenEVSE charger was dutifully filling my wife’s Zoe with electrons, when it is programmed only to do so between 00:30 and 04:30 i.e. the Octopus Go cheap period.

Logged into the charger straight away and saw that it had been charging for over two hours and the date / time was wrong. The car had been plugged in about two hours earlier than it had started.

Hit the button to reset date/time to NTP and charging stopped, as the time was now correct.

Any ideas as to what may have happened?

It’s an OpenEVSE bought and installed earlier this year, upgraded and been working with the ESP32 / latest firmware quite happily. We haven’t had a broadband outage (house has two DSL lines, one from BT and the other from Sky running through a Draytek router so we get 2x speed plus failover/redundancy) and the unit had WiFi (else I couldn’t have connected to it).

Of the 32A draw, just over 3kW was coming from the battery system I have so not all of the fill was at full cost but I’d like to try and find out the cause and stop it happening again. I’m guessing it rebooted for some reason and didn’t correct / fetch the time correctly. I’ve had it set to NTP since the board upgrade and it handled the DST transition faultlessly.

I know the unit was OK around 7pm as I had to take the recycling boxes down the road and the unit was sleeping, showing the charging period correctly and also the correct time.

Unit again has the wrong time tonight. Fortunately the car was unplugged earlier today and not re-connected as there was no real need to top up.

The unit is currently showing the date and time as 01/02/2000 (which I guess is Epoch for these things) and 05:46:49 (plus NTP showing as the source).

I took a quick look at the code and see there’s an eight hour interval between resets so I won’t press ‘set time’ and see what it shows tomorrow morning. I don’t think the unit has been up 50 days since we last had a power cut here so it’s unlikely to do with millis() wrapping and poor code logic in that area but I’ll take a closer look at the code tomorrow.

Any ideas welcome. Having a configurable NTP check interval might help but that would only mask the real issue.

This morning the time had corrected itself so I guess the time loop is working.

Figuring out why it happened in the first place is the issue.


best bet is to buy a button cell to put on the clock module then it keeps going if the power has a problem they are CR1220 I bought 10 from Amazon and it was sub £2 delivered even though I only wanted 1, would send you one but that is nearly as expensive as buying 10 :slight_smile:


Argh, happened again today. Luckily checked the webpage about 15 minutes after the missus had plugged in her Zoe and sure enough, it had been charging because the date/time was wrong.

Assuming it resets itself to midnight, whatever happened to cause the loss of time happened about two hours ago and AFAIK, nothing did i.e. the network didn’t drop and no brownout.

Seems that I’ve got a couple of problems.

I’ve got a matt:e monitoring and protection unit and it seems that it is cutting the power to the OpenEVSE because my voltage is going above 253V.

There’s also the fact that the unit isn’t getting the time correct after it reboots but I guess solving the first problem will help.

My two emontx units are showing different Vrms values (both have the AC charger) and they are around 4 to 4.5V higher than my (non-calibrated) multi-meter plugged into a test socket. Even so, I’ve seen 252.5V on the meter today and 257V on the emoncs - given it logged 260.1V when the unit seemed to trip yesterday that would equate to around 255v+ and explain why the protection kicked in.

Hi Nick,

Sorry to hear you’re having trouble, I’ve not been able to replicate the NTP time issue. The unit should persist the correct time between reboots since there is an internal RTC with button cell battery backup. Does the time get lost on every power cycle? If so then there must be an issue with your RTC, maybe the button cell battery if flat or missing?

If your voltage is going above 253V you should contact your DNO this is above the permissible limit.

The standard domestic mains supply for Europe is 230 V ± 10%, giving a lower limit of 207 V and an upper limit of 253 V. It is permissible under BS 7671 to have a voltage drop within the installation of 5%, which would give a lower limit of 195.5 V. The UK standard prior to harmonization was 240 V ± 6%, giving an upper limit of 254.4 V.

1 Like

Yeah, engineer due at 5pm.

I’ll check on the battery - is that on the top board?

Yes, on the rear of the LCD. Be sure to isolate the unit before opening.

So the SSE engineer cam and measured 251.5V after disconnecting the house. I did tell him that was lower than earlier and he accepted that but can’t do anything right now. The suggestion was that he’s put a note on the file and if it keeps tripping. they’ll install a monitoring device.

Whilst the power was off, I took a look inside the unit and see there isn’t a battery installed so I’ve just ordered 10 from Amazon which will arrive tomorrow so at least the time issue will get sorted.

Glyn, can you add a call to set time from NTP (assuming it is configured) at boot. I haven’t looked at the code again but from leaving it to sort itself out, it’s clear the eight hour kicks in and does the reset then but it should also happen at start-up if that’s possible.

Of course if you had an EmonPi or an EmonTX you’d have a record of the voltage to show him.

I’ll get my hat… :laughing:

There is precedent. Others have used OEM equipment to successfully challenge power their power company. Even if it wasn’t accurately calibrated, a comparison at the time of the visit and a recorded history of the readings should have been powerful evidence.