Hi All,
I’ve read a number of posts on the forum regarding Pv Divert
I have a OpenEVSE recently installed and having intermittent issues with PV Divert
It’s all setup to talk to EmonCMS and receiving the +/- WATT value from my utility clamp. This works well and it’s getting the right + (importing) and - (exporting) value every 30 secs or so.
The issue is when the car is first plugged in charging goes the max configured on the device (I’ve got it set to 28A) and stays there - ignoring PV Divert completely - despite having no solar available and 5000+ watts of import being reporting to EVSE via MQTT.
If I toggle between Normal and Eco PV Direct charging, the system will immediately stop charging and correctly wait for solar.
I’ve been scratching my head over this and can’t see any reason why it behaves like this.
From the debug it appears it sets the pilot at 28A and leaves it there despite what MQTT is sending it:
amps = 27.28, volts = 242.89
EVSE monitor woke: WakeReason_Scheduled, _count = 8756
Get charge current/voltage status
Get charge energy usage
amps = 27.50, volts = 242.89
session_wh = 63.82, total_kwh = 5.30
{"divert_update":0,"grid_ie":5920,"charge_rate":2,"voltage":241.6900024,"available_current":2.592060329,"smoothed_available_current":2.58305506,"pilot":28,"min_charge_end":0}
I’m really not sure from above what it believes it has an available current of 2.59A.
Also min_charge_end remains at 0 regardless if it using PV correctly or not (both in the debug and the GUI). Not sure of the relevance. For testing purposes I set it to 30 seconds.
Firmware is 8.2.0 and Wifi firmware is 4.1.4.
Does anyone have any ideas ? Obviously this is quite a serious issue as anytime the vehicle is plugged in, it will default to max charge costing fortunes in electricity.
Thank you
Alan
Small update.
From the webgui, restarting OpenEVSE triggers this behaviour. Restarting OpenEVSE WiFi after restarting OpenEVSE seems to cause operation to return as expected with PV_Divert (Ie, it stops charging it if no pv available).
Not sure if this helps and reading the divert.cpp code for the Wifi unit, I am not much wiser (yet). An alarm bell does sound when I read this code:
// Default to normal charging unless set. Divert mode always defaults back to 1 if unit is reset (divertmode not saved in EEPROM)
byte divertmode = DIVERT_MODE_NORMAL; // default normal mode
Not sure how relevant this is.
I found a problem with my setup - I was passing the wrong MQTT topic as the voltage topic and it was out by 4 volts. The conditions today were also edge case with the system flipping between import and export with a circa 400W swing.
Either way, this meant that when the EVSE calculates the power from utility MINUS power going to car, it saw an excess of around 1.7A - even though I’m IMPORTING 5Kw, the system thinks I have 1.7A spare (that must be export it can use). Therefore it keeps ramping up the power to the car and the race condition begins.
I think this is some sort of bug in the logic in the divert.cpp/divert_update_state function as this race condition effectively means charge at max. I’m still digging…
The code in divert_update_state compares a calculated value for current at the grid CT vs measured current going to the car. If this calculation shows that there is more current going to the car than coming from the grid - then by inference, it means we are generating power somewhere else (solar) and therefore the difference is power that can be utilised.
The race condition I think exists : The system will then try to utilise that power difference by increasing the power to the car , but the difference between the two values will stay the same (car current increases, grid current also increases, but still showing the same positive difference between them). Essentially, this cause the car current to ramp to Max and the system still thinks it has spare power available.
You could argue - well you did tell it the wrong voltage, but 4V is hardly a big difference and well within the error range for emonPI with the 9V AC wall plug.
I don’t think I’m explaining this very well as I ‘brain dump’ it.
I’m not sure why the code is written this way as opposed to always trying to keep the measured Utility watts < 0 (exporting) and trying to keep that status quo by increasing/decreasing the power to the car.
I’m sure there is something I’m missing here, but it sure does explain the behaviour which I cannot believe would be correct (when I’m IMPORTING 5Kw from utility and the system with PV_Divert enabled wants to ramp the car to max).
I’ll go back to scratching my head.
Some interesting observations, I guess the code does kind of assume a perfect setup, but in essence the main reason for converting to current is that is what the EVSE deals in current not power. I have been thinking that we should maybe add an option to provide the current rather than power which would hopefully get rid of any conversion errors, but even so there may me edge cases. I do have a few other divert bugs to look at so will try and take a look at this too. Please can you raise an issue on the GitHub repository?
Hi Jeremy
Thanks for the reply. I’m still looking at it, trying to get my little brain wrapped around how it should work, and also trying to make the problem repeatable. I will post an issue.
I’m curious about the scheduled events - I assume that when it’s in a schedule event it should run at max pilot ? (Common scenario I would think, charge by PV during day and then schedule cheap rate at night). Is that correct ?
If I recall, during a scheduled event, if I toggle the ECO mode charge off and on again then it will reduce charging to 6A. Again, I need to reverify this.
I also need to figure out how to compile and upload, as while I’m competent with STM32 and Atmel, ESP is new to me and all those web frameworks in the gui directory are scary…
Thanks again for any input, I’ll keep playing and report back.
On the scheduled events, the backend code can be configured in a few different ways, it is the UI that configures it to set to max current. As you say the expectation is that it will be used to charge over night at full, and divert during the day.
Don’t worry about the GUI unless you want to change it. The ‘built’ files are checked in so you can build the firmware without worrying about any of it.
Some, no, most of this issue can be safely filed in the category ‘User is An Idiot’.
First, I made 2 mistakes which took be down this rabbit hole
- As mentioned, I gave it the wrong MQTT topic for Voltage (from another phase) which is about 4V different
- Idiot user setup a scheduled charging event from 12:30 - 04:30 to take advantage of cheap rate electricity. Read that again and spot the problem … clue … 12:30 is not 00:30…
Therefore when plugging the car in, it thought it was in a scheduled event, so maxed the power. All the confusing readings given in terms of amps available would imho be a a small problem easily corrected in the code to check if we are in a scheduled event and if so the GUI could state that more clearly and avoid doing these calculations.
Note this doesn’t line up with the screenshots above where I’d already corrected the issue with the event start time, which brings me to this potential explanation:
To get this simulated consistently I was restarting EVSE (without restarting wifi board) and it would appear to consistently charge the car at max current. The GUI shows that ECO mode is on, but in effect I don’t believe it is - EVSE has restarted and defaulted to ECO mode off (the gui still showing it is on). Toggling ECO Off/On again and it immediately behaves as it should (or restarting the wifi board).
That’s my theory anyway and I can’t conclusively say there is a bug in the PV divert code, but I can suggest that Wifi/GUI/EVSE can get out of sync and maybe the GUI could be improved slightly.
I hope this helps others and if nothing else gives a way to simulate my issue.
It all appears to be working REALLY well now and I’m pretty chuffed.
Thanks for all the efforts to help me with this.
