Apologies if I have missed an answer in my search.
Is it possible to configure the openEVSE / emonEVSE with a user default for the starting position of the toggle switch between max rate charging and Eco Mode (where the charge rate is throttled to some available surplus wattage)?
Presently, my emonEVSE always starts up in Max mode but I normally want to charge in Eco Mode.
Perhaps the toggle could be sticky and the unit starts up in the last-used mode?
Many thanks for a great product that’s working really well for me.
David.
Hi David, Sorry it’s not currently possible to set EcoMode as default. We may look at adding this option in the future. However, the design decsion was made to always default to ‘Normal’ mode to avoid the situation when a user expects normal charge speeds ang gets caught out by Eco mode charging much slower.
It is possible to enable EcoMode via MQTT so you could create an automation using something like NodeRED to auto enable EcoMode every time a car is plugged in.
I use openEVSE every day and am very pleased with it but like [dmajwool] David Woolley my preference is to use the EcoMode as this automatically matches the output from my solar panels.
The default state when I plug in is max charge rate therefore I have to remember to open the openEVSE App and enable ECO mode every time. This is not a huge problem but for me the whole point in purchasing the unit was to make use of its ECO mode and I guess that others with solar panels are in the same boat.
My suggestion is not to set ECO as the default but to have a toggle for the user to select between the default states.
I am sure there are other ways this could be achieved but I don’t have the time or inclination but I do think the product would benefit from this improvement.
Good news, we have an update for OpenEVSE coming soon which will make EcoMode persistent between charging sessions and enable the OpenEVSE to pause charging when solar PV stops generating. These features have already been released to the new ESP32 WiFi module (see change log), we’re currently working on back-porting these changes to the existing ESP8266 WiFi module so the new features will be available for all existing users.
Once the update is available (eta 1-2 weeks), I will post a beta on the forum.
hi Glyn this looks to be good .
can you tell me if it will interact with the demand shaper modual to give solar charge during the day if pluged in and timed charging at full rate under timed instruction from the demand shaper ?
thanks regards bill
Yes it will work fine in conjunction with Demand Shaper. This is the ultimate setup: solar PV trickle charging by day then charging will stop when excess solar is no longer available and demand shaper will schedule a full speed charge to happen during the cheapest Octopus Agile rate overnight
Lol. Yes that is what I have been looking to do with node red. But you beat me to it …
I will have a go this weekend to update to this
And try it out . I am not 100% confident in the demand shaper at the moment so would like to see it work over weekend before I trust it with a work day . It seems to work well. Then for some reason it does not update the times correctly but I have not been able to duplicate the issue. To report it or how to break it yet . Still think a version of this in the EV code would be good option . With the option to charge when price is less than **. Also to calculate best time to charge when it sees car plugged in . Ready for. A predetermined time. Ie 7 am .
Thanks for your efforts with this update.
Cheers bill
Hi Glyn i have loaded the 3.2 beta version you posted for the esp32 esp32-gateway.bin
via the web interface . this all seemed to set up ok and allowed me to set the solar divert and also set the mqqt for the true system voltage . but it did not revert to the demand shaper
timed charge over night and only seemed to start charging when sun came up in morning and we started exporting … i then see you have released V3.3 but i can only see the Firmware.bin
file i try uploading this with the web interface and it hangs at 68%
can you let me have the link to the correct file for the esp 32 gateway please .
allso how do i instruct platformio to link to these later versions of software
Apologies, I’ve just updated the V3.3 release with a pre-compiled firmware for the esp32 gateway esp32-gateway-e.bin. The firmware.bin binary is for the Huzzah module. If you have tried to upload the firmware.bin to the ESP32 gateway I think you will need to use a USB to serial to upload `esp32-gateway-e.bin, see:GitHub - OpenEVSE/openevse_esp32_firmware: OpenEVSE V4 WiFi gateway using ESP32
Hi Glyn.
Thanks for your fast response I have loaded the updated version 3.3.
No problem s getting it loaded .
A few issue that I come across you may be able to shed light on
I have set time zone gmt+0
When I adjust the time on the esp32 from the app or pc. The time being displayed on the lcd screen is not the same I have had to set correct time via the button on the charger .
Initially it was not starting the charge at the time I was setting due to the above times being diferant
Should these times not sync ?
Now I have a charge starting at the time I request and initially it charged at full output this is with system in Eco. Pv divert
I then found at one point I was still exporting a small amount of power and it now seems to have changed control back to eco pv divert and is limiting the charge current. Even though it Is is a timed charge period where it should be charging at max output . Even updating the timed charge time will not bring it back to full charge
ok i have watched this work from the demand shaper and at the start time it started to charge at full power as expected then after a few min the power seemed to drop and it reverted back to the 6 amp pilot nothing i did would get it back to full power unless i turn off eco and ajust the start time to in the future again . i am making a asumption that the program only responds to a start time that is in the future ie time has to go through the start time to triger a response . what may be causing a problem is that at times if large load switches off then my battery system may export a few hundred watts for a few seconds …
i will switch the solar part off over night and see if it will charge from the demand shaper
wonder if we need to use the start and stop times as a inhibit for the solar routeen
Update. Just looked at logs. And it would seem that the charger did turn off. At the end of demand shaper period. But then started to charge again at about 7am. When we seemed to hit a export value of -240 W At the moment the charge option is set for normal (fast)
The new solar pv divert. Under mqqt. Is enabled
Thanks for reporting this issue, this is indeed a bug. I’ve opened an issue on github, we will get this fixed:
A workaround for the moment is to use Europe/London timezone, this results in the correct time being set on both the WiFi interface and the controller. Or to set the time via the browser or manually via the WiFi interface.
If EcoMode is active a timed charge will only charge at full current when solar PV is not generating. Timed charge is designed to be used as a nighttime boost to charge at full current during an overnight off-peak period when the solar is not generating. To charge a full current during the day I would recommend disabling Eco Mode. I admit, this is a bit confusing, we are working to overhaul
the way the timer function works and add a weekly timer schedule. This issue will be fixed then.
A demand shaper schedule charge will work at full current overnight when the solar PV is not generating.
It looks like the charger switched back on since EcoMode was active and there was some solar PV export. Is it possible to post a screenshot of a multigraph showing your solar PV export on the same graph as the EV power?
Could you also share a screenshot of the OpenEVSE solar PV divert MQTT settings so I can check if the setup is correct?
Hi Glyn
Happy to test
I am not quite sure I follow the logic on what you have explained above .
My thoughts would be . If car is plugged in and no timed charge is set then if solar power is avalable then this should be made avalable to charge the car and modulate the charge current to match pv production. Or as in my case export power .
If a timed sheduall has been set it is assumed the user will have set the time for the amount of charge he wants in the car based on max output which he can set elsewhere in the settings if solar is being generated then this will still be used to offset the demand from the grid but he should get the max charge rate day or night .
Again if using the demand shaper
If the user sets a charge period to finish at say 4 pm One must expect that he / she will want the car to be charged and ready to go by that time. There for again if it is a timed on period it should charge at max rate until the demand shaper switches it off where if solar is avalable it will still charge but at a reduced rate until the demand shaper gives the next on command where it will return to max charge rate . So on . Until the finish time . When if a lot of pv was avalable it still will have been used to ofset import from the grid . But the car will be fully charged when it is sheduled to be.
I include some pictures as you requested. It would seem that my unit switched back on the charger this morning with a export value of -110 W Now I thought that it had to be at least 1.5 kw. Export 6 amp. For this to happen .
Also I had the ECO switch in normal fast mode. So I was not expecting it to do this.
Also below is a picture showing my import at 8 kw I had min charge time time set to 120 seconds I waited with this load for around 5 min and it still did not stop charging the car .
.
Also can I ask how the Avalable current value is being calculate as it seems to me that the current it is displaying on my system is too high
I assume that you are taking the power in Watts and dividing by voltage to give amps .
My system is reporting. Import /export. -70W. Volts 245.4. Avalable current. 6.477751A
Sorry to bombard you with so many things
Hi Glyn update on my previous reply, sat night i set demand shaper to charge as i would normaly 6 run period to compleat by 08:00 ok to interrupt this setting i normaly use
and i find it works ok .
this morning i noted that the car had only recived 13.88 kwh over a 9 hours +
it would seem that the car had been charging on solar divert during the evning before the demand shaper started last export value i see logged is -80W at 11:22 from that point on it seems to have been held at 6 amp pilot all through the night …
I have been trying to find other posts on this new software but have only managed to find one other where a user was having problem with set up . is there a dedicated post ? page
I was wondering if there is a way that i can enable/ disable the solar say from 20:00 disable 09:00 enable from the emonpi via mqtt
so that the demand shaper gets a clear run throough the night …
as a work around .
as at the moment i think that due to my battery system giving the ocasional export it seems to break the logic of the code
also i noted that the time control uploaded from demand shaper seems to have got it wrong as the start is 7:30 stop is 7:00
also in the demand shaper this morning it is showing settings mismatch and the time run period has changed now to 3:58
it may be that i am miss understanding some of these settings
regards bill
This is exactly how the solar PV divert feature works if EcoMode is enabled
Currently, the timed schedule functions as a nighttime boost. eg If EcoMode is enabled and the timer is set for 2am-4am off peak boost the EVSE will charger from solar during the day then charge at full current during the off-peak nighttime timed charge period.
As I mentioned earlier a current limitation is that a timed charge cannot work at the same time as solar PV is generating more than 1.4kW. Solar will take priority. We are looking to improve the way the timed charge works in the future. Currently, a workaround is just to disable EcoMode if you want to do a timed charge during the day time.
Interesting, thanks for reporting this. I think this is the issue why the demand shaper gets interrupted during the night. I’ll investigate this further.
Yes, divertmode can be controlled via mqtt
Topic: <base-topic>/divertmode/set
Value: 1 = Normal or 2 = Eco
