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.
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.
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.
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.