Any idea why the power flipped between min and max during a timed charge?
OpenEVSE Wifi 4.1.5
Current shaper is NOT enabled
Mode was set to eco (pv divert)
Grid Import would have been updating about every 15 seconds and showing import values
Timed charge set from 00:30 to 04:30 (Go tariff)
Max graph power corresponds to 28A (max the Leaf can take)
Min graph power corresponds to 6A (min pilot current I presume)
Nothing unusual happened at 1:15 when it stabilised
Nothing else unusual.
First time I’ve seen this but I’ve only recently updated to V4.1.5…
Thanks
Thanks for reporting, we’ll try and investigate this. Are you logging data to emoncms.org?
Cc. @jeremypoulter
Hi @glyn.hudson
Are you logging data to emoncms.org?
No, to Home assistant and my own separate emoncms V10.2.1 server.
Emoncms data not as high resolution but duplicates issue
Not going to recharge on OpenEVSE until next week. I’ll report back if the issue still there or has gone away.
[later]
Your comment prompted me to look back to preV4.1.5 and pre pv-divert charging in late September.
Too long ago for high res data but emomcms shows this
More info
I have a test ESP 32 which has V4.1.5 and I noticed the following:
Set a timed charge
Selected PV divert
When the timed charge started the pilot went (correctly) to 32A and an import/export of 6700 was mqtted at 15 second intervals.
This appears correct.
However when I mqtted 1000 to import/export the pilot went down to 6A.
This is possible as I have a battery and it can take time to respond and can overreact.
I then tried random +ve and -ve import powers and the status bar went wild - even showing >32A Charge rates. Fortunately the controller is limited to 32A
I’m probably missing something but I’d have expected timed charge to ignore the pv divert import power input.
[later]
Just had a look at my live system for the data I originally posted and yes, the drop to 6A was caused by my software sending 500W as the import power.
I guess I need to know if OpenEVSE does NOT ignore the mqtt import power by design or it’s a bug.
If it’s by design I’ll either have to turn off pv divert at night or get my s/w to send >7000 when in timed charge
It is indeed the expectation that the timer is used to charge at a cheaper rate over night and then the Eco mode takes over during the day. That being said I would expect that if the schedule was set during the day it would charge at full power (well actually can be any power you want, but the UI doesn’t support that yet). I will investigate.
Thanks for the clarification - that’s what I would have expected too.
When in eco mode, timed charges work properly if you don’t post import power via mqtt
If you do post import power it has to be more than than the charger’s power consumption to work.
Reducing the mqtt import power reduces the charger’s power.
That seems at best backwards to me - the opposite of Current Shaper.
It’s worth fixing so that eco/pv divert mode and the import power are ignored during timed charges as anybody with a house battery will fall foul of this.
I charge my house battery to 50% at the same time as the EV overnight but if the house battery is already over 50% (because of a good day’s sunshine) it will try to offset the import that the OpenEVSE is creating.
This means a low import will be posted to the OpenEVSE and it will reduce its power and not charge the car fully.
I could not reproduce the exact issue you had, but I have fixed the schedule/timer not forcing the full charge rate, some test binaries can be downloaded from https://github.com/OpenEVSE/ESP32_WiFi_V4.x/actions/runs/3365139716
Great - I’ll try later this week when I get home.
Confused by the list of binaries.
What’s the difference between openevse_huzzah32.bin and openevse_huzzah32_dev.bin as I presume I need one of these?
You should use the openevse_wifi_v1.bin assuming you have a OpenEVSE wifi module, which you probably will since we’ve not been using huzzah modules for a couple of years now. The hardware info section on the UI will tell you what WiFi module you have fitted:
1 Like
Definitely have huzzah module - been driving EVs for 5 years…
What I’m not sure about is the difference between openevse_huzzah32.bin and openevse_huzzah32_dev.bin
Ah yes, sorry I didn’t realise this was an older unit. That’s fine, you should use openevse_huzzah32.bin the dev version just has extra debugging output enabled for development and testing.
@jeremypoulter
I’ve just tested the release you posted. It’s better and works for me.
However you should be aware of the following scenarios with Eco and timed charge set:
-
No posting of the import via mqtt
Works just fine (full power during timed charge and switch off after timed charge ends)
-
Posting 500W as import during the timed charge and continuing to post after timed charge ends
Works but you have to keep posting a low positive (e.g. 500W) import for the charge to reduce and eventually go off. This can be minutes after the period ends depending on the pv smoothing.
-
Posting 500W import during the charge but not posting after the timed charge stops
It never goes off after the timed charge
The pv divert logic seems wrong during timed charges in that it calculates a positive charge current when you post positive import power via mqtt. Surely it should only calculate positive charge powers for negative imports?
It would probably make sense to block the pv divert logic from receiving the mqtt import power (or set the internal value for import power to 0) during a timed charge.
Hope this helps
The PV divert doesn’t have any knowledge of the schedule, it is designed to have the values posted to it continually. The charge doesn’t stop immediately on posting a positive value as we try to filter out spikes, eg kettle boiling, or cloud passing over, this will help with the lifespan of the contactor. You can configure the attack (how quickly the charge will start), decay (how quickly the charge will stop) and minimum time that the charge time by enabling the advanced settings.