OpenEVSE ESP32 Firmware 3.3.1 MQTT Problems

So, I got my new ESP32 WIFI today and like any crazy nerd. I just had to install it and give it a whirl. Got it connected to WIFI no problem, got it to connect to EmonCMS with no issue. Sadly though, connecting to MQTT is not working. I’m not sure what is wrong. There are some new options that weren’t in the old WIFI firmware and I’m not sure if that might be the issue or not. Here is a copy of my config.

When I click save I get this error.


I realize I could just be screwing up the settings as well, but I went back and reused the settings I had before. So, something has changed.

Go figure. I did some more troubleshooting on it and now it’s working. Sigh…

With this said, I do have one question for @glyn.hudson. The NTP option. Does that handle auto time sync every day? Also, does it or will it in the future offer daylight savings adjustment?

I have NTP enabled and Europe/London set as the timezone.

The time being displayed and also used for my charging period (Go - 12:30am to 4:30am) is ‘correct’ i.e with DST added. I guess we’ll see if it works next Sunday morning when the clocks ‘go back’.

NTP only ever returns Unix Time as a decimal. It is for the local device to decide how to translate that to ‘local time’ if necessary.

It is always best to send date/time information between devices as a number (interger or decimal) as then you really do not need to worry about DST etc.

I believe that for ESP devices, the algorithm to convert between UTC and ‘local’ is hardcoded. It will be interesting to see what happens when the EU finally abolishes DST. Many devices will probably continue to apply the algorithm so 50% of the year ‘local’ will be wrong!

While I would love for DST to go away, unfortunately many like myself must live with it. Also, my local utility uses it with TOU, so DST on the OpenEVSE might be very useful since we need the time to be right for the timer function to ensure adherence to the TOU rates. Certainly will be interested to see what happens soon since DST is going to occur.

Well, just when I think it’s all good, it’s not. So, I just had a hard drive failure on my EmonCMS and of course I failed to backup. So, rebuilding everything. I noticed when I loaded up the new emonsd and got logged in that one of my OpenEVSE’s connected just fine over MQTT and the other did not.



I just find it odd, same settings, no changes made and one connects and the other won’t.

I assume you have powered down the unit that does not connect.
I had the same issue with a new OpenEVSE installation. Isolated the unit for a few minutes. When I switched back on it connected.

Does Debug serial log give any information?

I’d thoroughly recommend an old laptop with ProxmoxVE installed. Automated backups of the containers/VMs helps one sleep at night!

As for backups. That is my next task. I did get lucky and had an old backup back from Jan. that I found. So, it is restored. Just have to figure out how to get Iotawatt to reload the data it has without nuking all of my inputs and having to rebuild those. I would love some way to have it auto upload it’s backup once a week to Google Drive.

I haven’t tried that yet. I figure you are referring to the OpenEVSE unit. Still seems strange that one connected and the other did not. Might be a bug there with a process getting hung up on disconnect.

Good news, @jeremypoulter implemented DST in the OpenEVSE firmware as part of the NTP feature. It worked perfectly from me on Sunday the time updated automatically to reflect the DST change :smiley:

Sorry for the confusion, I was not aware this had already been implemented.

1 Like

Does the DST handle localities since I know it can be different depending on where you are?

yes it does

As an FYI the timezone is set using data from the pozix_tz_db dataset, which in turn is based on the Linux timezone database.

Also if you are interested in the insanity of timezones, you should watch this video from Tom Scott.

Taking a guess the dataset sets if you have DST or not based on the location you choose. Since some locations in the USA (Arizona I think is one) don’t follow DST. Either way, just checking the time on the units right now and they are synced nicely. Will see what happens this Sunday.