ESP8266 OpenEVSE WiFi V2.9.0 beta: Significant update Solar PV Divert 🎉

All OpenEVSE and EmonESP units we have ever shipped (until July 2020) contained an ESP8266 WiFi module running OpenEVSE WiFi 2.x firmware. This WiFi module has now been superseded by the ESP32 WiFi module running OpenEVSE WiFi 3.x firmware. The new ESP32 WiFi module has been getting all the new shiny features and will continue to receive updates and new features going forward.

However, we have managed to backport some of the most significant new features to the ESP8266, this means that all existing OpenEVSE / EmonEVSE users should be able to easily apply this update via the OpenEVSE WiFi web interface without any hardware upgrades :tada: :grinning:

See the OpenEVSE ESP8266 WiFi V2.9.0 Github Release page for the pre compiled .bin which can be uploaded via web interface.

Significant update to solar PV divert functionality:

  • 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.
  • Improved user display to communicate charging state e.g “Charging from Solar”, “Waiting for Solar” etc
  • Enable ‘advanced’ mode to adjust smoothing and minimum charge time settings:


Here are some example of the new solar PV divert in action:

1 Like

Do you mean persists?



  1. (especially of an unwelcome influence or physical effect) spreading widely throughout an area or a group of people.


Great work, updated last night and tested today (bit more sun would have been nice) stopping the charge as expected when spare solar is low and starting again when there is spare. Only bug I have found so far is that the car’s app reports each “stop” to my phone as I suspect it considers this a fault if the car is not fully charged. Keep up the good work :slight_smile:


Installed the update yesterday. Thank you for your effort so far.

All looked OK so when the sun came out today I used the Eco mode and when the export to grid reached about 2kW the car started to charge.

The PV continued to increase until about 2kW were going to grid but the car continued to charge at about 6A even though Max current was set to 20A.

I then took a screenshot and switched the charge mode to Normal at which point the wifi connection from the EVSE to hub was lost. I powercycled the EVSE unit but it was not displaying the IP address so checked to see if it was in broadcast mode which it was therefore I had to run through the setup procedure again. After this it is back to normal but the sun has gone now. It has never done this before.

Happy to run any tests you recommend.

Good to hear. Thanks for testing.

What car are you charging? I’m afraid there is not much we can do about this, as far as the car is concerned charging as stopped before the charge threshold is reached. You could probably disable the notifications on your phone.

I’m assuming you are using a ‘Grid +I-E’ MQTT feed? This feed must also include the power drawn by the EVSE. Please check the CT for the grid feed is on the main grid incoming cable before the EVSE and house consumer unit.

Solar PV divert requires the EVSE to be continuously connected to WiFi to receive MQTT messages from the emonPi. If the WiFi connection is weak and the EVSE is often dropping a connection this could be the source of the problems.

That’s interesting, I’ve not heard of the WiFi modules loosing its config while running before. Let us know if it happens again.

Solar PV divert requires the EVSE to be continuously connected to WiFi to receive MQTT messages from the emonPi. If the WiFi connection is weak and the EVSE is often dropping a connection this could be the source of the problems.

My wifi mesh network has several nodes and one is about 200mm from the openevse box so no problem with signal level and it has never dropped out before. -32dbm

That’s interesting, I’ve not heard of the WiFi modules losing its config while running before. Let us know if it happens again.

My problem now is to get the system running again. I have some notes but it’s years since I did this and need some help.

I have two sets of API keys for some reason. I tried both but did not connect.

How do I find out the real API key?


no problem, the car I have is a Skoda Superb iV PHEV the issue is with their system not yours, it is a small price to pay for the benefits


You need the write API key from your local emonPi. This is available on the Account page of your local emonPi: http://emonpi/user/view

I think the issue could be that your trying to connect to http://emonpi/emoncms while newer emonPi’s don’t require the /emoncms URL, try posting to http://emonpi instead. You can test which URL works for your emonPi by clicking these links.

Thanks. Now using the API key from my local emonPi but I still get a server error.

The pi is working fine and correctly displays my solar and house power.


Not sure if this helps but when the evse is in eco mode but is not seeing any solar the car puts up this error message.


I get similar alerts from the system on my Skoda, but I suspect it is just something we will have to put up with for the enhanced functionality :slight_smile:



Like you, I also receive optional notifications from the car when charging is interrupted. This is expected and not a problem. The alert message is new, it did not happen with the previouw version but it’s also not a problem.


The “Emoncms server” in the EVSE config should just be “emonpi” not “http://emonpi

The “Emoncms Node” name should be something like emonevse not “data.openevse…” as your screenshot shows.

That’s expected and nothing to worry about. The message is just alerting you that the charge point is letting the car charge which is what we want when there is not any excess solar.

Any further ideas on why my evse can no longer see the server?

If not should I revert to the earlier software?

Any further ideas on why my evse can no longer see the server?

Try the IP address. mDNS is very flaky and dependent on local network configuration - it shouldn’t be relied upon. Can you open a command window and ping emonpi? If not, it won’t work.

Pinging emonpi.local [] with 32 bytes of data:
Reply from bytes=32 time=5ms TTL=64
Reply from bytes=32 time=6ms TTL=64
Reply from bytes=32 time=7ms TTL=64
Reply from bytes=32 time=6ms TTL=64

Ping statistics for
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 7ms, Average = 6mstest_01

2 different errors (no I don’t know why) @glyn.hudson.



Did you ping emonpi or emonpi.local?

Are you sure it is the right, write API Key?

@glyn.hudson, how do you know what the right node name is?


there also looks to be a change in the feed values, as this weeks mail looks totally wrong (I hope I have not used this much power) suspect the new software is feeding out a different multiplier possibly Wh in place of KWh. hope the attached pics help

Glyn asked how I know what the right node name is. Well I have no idea! and I dont know how to find out apart from asking you guys.

This morning I noticed that I was no longer able to manually set the Max current so I power cycled the evse unit. When it restored it briefly generated an error message on the LCD display saying OpenEVSE errror vent required. Now I can change the Max current although the minimum is 10A I thought it was 6A in the previous version.

The previous ping went to emonpi.

This is the reply if I use emonpi.local:
Ping request could not find host emonpi.local. Please check the name and try again.

Glyn asked how I get the write API key
I use a browser to inspec this page:

I then press the write API key copy button

Then I browse to here:
and paste into the Emoncms write-apikey box