ESP32 beta V3.2.0: Significant update Solar PV Divert šŸŽ‰

Iā€™ve just published a beta WiFi 3.2.0. Firmware release for the ESP32 OpenEVSE/EmonEVSE WiFi module.

The update is a significant improvement to the solar PV divert (Eco Mode) function.

Once the updated has been tried and tested we hope to back port the update to the ESP8266 WiFi module (currently installed in most OpenEVSE/EmonEVSE units).

If you are already running an ESP32 module, you can update to this firmware by downloading the pre-compiled .bin attached to the release via the web interface.

Please feedback on this thread, if possible include Emoncms graph of solar pv / Grid IE vs EV current/power to illustrate.

Here is the change log from the release:


  • Realtime VRMS via MQTT for improved solar PV divert calculation. e.g from emonPi emon/emonpi/vrms

    • Note: this feature will in the future be used to improve the OpenEVSE energy calculation, this will require a OpenEVSE controller firmware update (as yet unreleased)
  • Significant update to solar PV divert functionality: Divert mode updates by jeremypoulter Ā· Pull Request #76 Ā· OpenEVSE/ESP32_WiFi_V4.x Ā· GitHub

    • Eco Mode is now pervasive between charging sessions

    • PV divert (ā€œEco Modeā€) will now pause charging once solar PV / Grid IE drops below the minimum (6A ā‰ˆ1.4kW) and will resume when more power is available.

    • Charge current calculation is now processed via a smoothing algorithm to avoid any stopping/starting charging unnecessarily

    • Timer charge functions as an overnight boost timerā€™. If EcoMode is left enabled and a timer is set e.g overnight off peak period, the EV will charge at full current for the duration of the timed charge.

    • Enable ā€˜advancedā€™ mode to adjust smoothing and minimum charge time settings:
      small

    • Improved user display to communicate charging state e.g ā€œCharging from Solarā€, ā€œWaiting for Solarā€ etc

  • Screenshot from 2020-06-08 14-19-47

  • Screenshot from 2020-06-08 15-47-13

Pre-compiled FW for Huzzah32 attached below. For other hardware builds see platformio.ini for supported hardware: Release V3.2.0 Ā· OpenEVSE/ESP32_WiFi_V4.x Ā· GitHub

3 Likes

ESP8266 V2.8.1 user here really looking forward to this! :slightly_smiling_face:

Here you go! :grin:

1 Like

Thanks for this update - looks like a good new list of features and fixes (I only just spotted this, Iā€™m still on 3.0.3).

This will be the first update I have done, and Iā€™m not yet familar with this firmware. There seem to be 4 different .bin files associated with the release on GitHub, bootloader.bin, esp32-gateway.bin, firmware.bin and partitions.bin. Would I be correct in guessing that esp32-gateway.bin is the one I need to upload via the web interface to do the upgrade?

Thanks,

Pete

No, you just need firmware.bin assuming your using a ESP32 module on WiFi. The esp32-gateway.bin is for an Ethernet gateway module.

Just upload firmware.bin via the web interface. Please let us know how you get on using the new features, especially the solar PV divert.

Thanks, that makes sense.

I notice one slight oddity.

Iā€™m pretty sure itā€™s an esp32 wi-fi module, here is a pic from my build:

But the GUI says it is ESP8266:

image

Can I safely assume that it is the GUI that is reporting wrongly and that I am safe to go ahead and upload the ESP32 update?

Thanks,

Pete

Yes, itā€™s an ESP32

This bug will be fixed once you update.

Correct, fire away with the update!

Ok, done the update no problem. I can see straight away it working nicely on this sunny/cloudy intermittent day, cutting out after 10 mins of not enough sun and then kicking back in when the sun comes out again.

Nice to be able to configure the smoothing parameters, Iā€™ll be fiddling with those so hopefully I get to keep a little more of the solar to myself, hopefully reducing that margin that it doesnā€™t use.

Itā€™s till reporting it as ESP8266, no big problem, I wonder if that parameter is coded in the boot loader so didnā€™t get updated?

Itā€™s also mis-reporting that Energy Monitoring is ā€œConnected:Noā€ on the service tab , but I think it is connected because I can see it updating the feeds in the OpenEVSE topic when I look at it using EmonCMS, it is updating the Amps, Wh, voltage etc at about 30 second intervals - so I think it is just the GUI mis-reporting that it is not connected.

What are the thoughts about how often it should be allowed to pause and restart without causing excessive wear to the contactors in the EV?

I donā€™t see V3.2.0 on the site any more - server error, or have you pulled it for a reason?

Thatā€™s good to hear :+1:

You will certainly be able to squeeze more solar charging by adjusting the parameters, the defaults were chosen to minimize contactor wear in the EVSE and the car by avoiding too many stops/starts. Probably not a major issue but just be aware that stopping and starting very frequently may not be the best long term for the equipment.

Ah, this fix must not have made it into the release. Itā€™s only text that was left over from the migration, it doest mean anything just ignore.

Interesting, Iā€™m unable to replicate this. It says connected ā€œyesā€ for me. What emoncms server are you posting to? Could you share a screenshot?

I would recommend sticking to the default settings.

No, itā€™s still there. Nothing has changed: Release V3.2.0 Ā· OpenEVSE/openevse_esp32_firmware Ā· GitHub

So it is! Thanks Glyn.
I could only see 3.1.0 yesterday, I swear.
Updated my unit just now - will let you know how it goes.
Just need the sun to come out briefly over N.E. Scotland :sun_with_face:

Quick question. Does having the time set to NTP allow for the units to auto update their time? Also, will Daylight savings be implemented in the future or is it auto?

No I donā€™t think NTP will enable auto Daylight Saving. For the moment itā€™s probably easier to set the time via the browser to apply the daylight saving change.

Iā€™d suggest yes otherwise having it is pointless.

NTP is local timezone agnostic - it only ever returns UTC. Timezone and local time is up to the underlying OS to implement.

Kinda of what I was thinking would be the issue. Do you have plans to stick that piece of code in for the many who must suffer with DST?

Certainly, itā€™s on the list

Timezones, including DST, are supported, see discussion here