This is the change in ev_energy feed post the upgrade as you can see the feed looks to have changed from kWh to Wh
Could you post a screenshot of your Emoncms input processing? The OpenEVSE has always reported wh then this is converted to kwh using Emoncms Input Processing e.g
See setup guide: OpenEVSE / EmonEVSE Setup Guide - Guide | OpenEnergyMonitor
Glyn,
charging at the moment so will post tomorrow as I made a change to the input processing as with the new version it showed that I had charged on Thu which I had not and you could see on the xls output the figure rising even though nothing was connected. Let us hope the change I have made sorts it. The display on the unit is showing in Wh where before it was kWh so I think something changed between versions 
John
The display on the unit cannot have changes due to the update. The WiFi module plays no part in controlling the lcd. The lcd is controlled by the evse controller. The energy in the current charge session has always been shown in wh, while the total energy ever delivered is shown in kwh
Good news! After re-configuring everything and with the patient assistance of @JJC John Cabra’s telephone support I am now running version 2.9.0 successfully. The solution was to copy all of John’s emoncms and openevse configuration details, then my various problems disappeared. So thank you John and all.
I have made various tests using both normal and eco modes and conclude that 2.9.0 is operating as described at the top of this page. This is very good although there is one feature that I anticipated being a slight problem which is initiating the charge. I shall explain:
I have an energy diverter based upon the Martin Roberts excellent design. This < 3kW load, has a greedy capacity of 18kWh and is designed to reduce gas consumption. My PV system is only 4kW consequently if I plug in the car charging lead the available PV surplus at any time is usually below 1.4kW whatever the PV generation and EV charging does not start. Manual interruption of the diverter will allow the surplus PV level to rise and depending on the level of sunshine this may initiate PV charging.
All the above is correct and working as expected but is not ideal.
Curiously, if the diverter is manually interrupted and EV charging starts the two loads (car and DHW) seem to happily share the available power. I am not sure why this is but I am quite pleased with it.
Anyhow, the reason for this post is to see if anyone else has both an energy diverter and openevse. If so how do you deal with the problem of initiating PV charging?
The only solution I have thought of so far is for the diverter to periodically interrupt power for long enough so the openevse can take over. This could be conditional on the PV power being above some sensible threshold although I don’t know how long the openevse requires surplus PV to be available before it will initiate charging. Also, there is a delay before the EV and openevse complete their communication and a further delay while the car activates the on-board charger.
The obvious problem with that idea is the inefficiency.
So, what are others doing?
Fantastic! Nice work @JJC 
Would it be possible to add a delay to the hot water diverter? That what the EV will take priority. Or change the OpenEVSE divert to use the SolarPV MQTT feed rather than excess. This will mean the EV will gobble up all the solar PV, but usually the house consumption during the day is low, almost insignificant compared to charging an EV.
1 Like
I did look for it but only found 2.9.0. Do you have a link?
All the firmware releases and pre compiled binaries are listed on the releases page:
1 Like
The firmware.bin listed as 2.9.1 states it is 2.9.0 when installed.
[EDIT] Scrap that - hadn’t restarted it - 2.9.1. shown now.
1 Like
attached are some screenshots showing the car charging, since updating to 2.9.1 this is the change I get. Before the two reports were the same but now the one for emoncms.org shows power going into the car even when it is not connected. both setups use the same input setup and display feed. I have just ordered the ESP32 so will see if I still have the issue after, but just for info something must be different between the two versions
This is todays EV charging plot over a 30 minute period with intermittent cloud plus occasional oven and microwave cooker. Looks very good!
1 Like
OK, I changed the openevse setting to SolarPV-gen. The openevse then switched to sleeping (code 254) even though the PV was about 4kW. I waited several minutes but the unit did not wake up until I switched back to Grid(+I/-E) mode.
Presumably I need to change something else as well? Maybe adding another MQTT feed? I am cautious so as not to break something.
Your screen shot shows -4kW. Solar PV gen should always be positive.
1 Like
Mm here should not be any changes in the way energy reporting is done between the two versions. Check your emoncms.org config and the setting in the evse config?
I don’t quite understand you screenshots, which is which? Which is correct? To debug this further I will need to some screenshots of your evse config and emonPi / emoncms.org Input and Feeds pages
The two shots are of the same data feeds on my phone one is from the emonpi the other from emoncms.org on the top of each shot you can see the source. I have now switched out the module for the ESP32 version so will see over the next few days and report back if anything changes. Before the software update to V2.9.1 both systems showed the same data and when the car was not connected showed now power draw, with no changes other than the update to V2.9.1 the emoncms.org data went wrong. Thanks for the offer to look at it once I have some more data will post it up and we can see if there is anything I am doing wrong.
John
Hi,
I recently upgraded to WiFi 2.9.1 (with EVSE 5.1.0.EU)
In Eco mode with Solar PV Divert enabled and using Grid Feed the unit starts charging when there is sufficient surplus power but doesn’t seem to increase the charge rate above the base 6A level even when there is available power.
Also in that screen shot the update time shows 84s even though the power value was correctly updating, though this was also the case on previous versions.
David
Hi David,
The updates to solar PV divert in V2.9.1 include a ‘smoothing’ algorithm so changes in solar PV may not take effect instantly. You can adjust the parameters of this algorithm in advanced settings if required.
Your screenshot shows an excess of 997W, an excess of 1600W would be required to increase the charging rate to 7A.
6A is the minimum charge rate, if the excess power drops below 1400W for a period the charging will pause.