Can openEVSE default be set to Eco Mode?

glyn.hudson · 2020-06-25T16:44:22.465Z

Hi guys,

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.

Bill_Burgess · 2020-07-22T22:45:33.583Z

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

glyn.hudson · 2020-07-23T17:59:04.218Z

Hi 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

Bill_Burgess · 2020-07-23T21:45:32.367Z

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

glyn.hudson · 2020-07-24T11:21:00.585Z

Bill_Burgess:

Still think a version of this in the EV code would be good option

This is on the roadmap

shallowal · 2020-07-31T02:20:43.509Z

Hi Glyn,
Is there any update on the ESP8266 ECO-Mode mod availability?

glyn.hudson · 2020-08-01T11:55:54.889Z

shallowal:

Is there any update on the ESP8266 ECO-Mode mod availability?

Yes, an update to Eco Mode Solar PV divert for the ESP8266 WiFi so now available:

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

OpenEVSE

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 exi…

Bill_Burgess · 2020-08-06T07:42:08.396Z

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

many thanks bill

glyn.hudson · 2020-08-06T11:46:27.757Z

Bill_Burgess:

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

Great, good to hear.

Bill_Burgess:

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

Bill_Burgess · 2020-08-06T20:31:30.000Z

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

.

image3.jpeg2016×1512 1.07 MB

image1.jpeg2016×1512 1.13 MB

image2.jpeg2016×1512 1.04 MB

Regards. Bill

Morning note. It started charge at time set on demand shaper. But failed to turn off. At 6:30.
Demand shaper reports settings mismatch

Bill_Burgess · 2020-08-07T06:30:54.771Z

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

image1280×958 250 KB

image1280×958 298 KB

image1280×958 348 KB

glyn.hudson · 2020-08-07T10:58:13.122Z

Hi Bill, thank for testing.

Bill_Burgess:

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 .

Thanks for reporting this issue, this is indeed a bug. I’ve opened an issue on github, we will get this fixed:

github.com/OpenEVSE/openevse_esp32_firmware

Timezone Issues

opened 10:44AM - 07 Aug 20 UTC

closed 10:36AM - 29 Mar 23 UTC

glynhudson

bug

Selecting `Europe/London` timezone and NTP results in the correct time being set… on the WiFi interface and on the controller :+1: ![IMG_0154](https://user-images.githubusercontent.com/758844/89637950-f0887e00-d8a2-11ea-890d-cabe320e2224.JPG) However, selecting `GMT+1` which should be same, results in the correct time being displayed on the WiFi interface, however the controller is 2hrs behind :-1: Could a solution just be to remove the GMT+X timezones? Since these seem to be a duplicate of the `Continent/City` timezones. ![IMG_0153](https://user-images.githubusercontent.com/758844/89638138-35141980-d8a3-11ea-82b9-1aedadb96f61.JPG) Thanks to Bill for reporting on the forum:https://community.openenergymonitor.org/t/can-openevse-default-be-set-to-eco-mode/11278/14 *** I've also noticed that the timezone dropdown menu does not work on iOS, tested on both iOS Chrome and iOS Safari on an ipad mini: ![IMG_0152](https://user-images.githubusercontent.com/758844/89638071-1c0b6880-d8a3-11ea-9a5c-44467916486d.jpg)

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.

Bill_Burgess:

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

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.

Bill_Burgess:

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

A demand shaper schedule charge will work at full current overnight when the solar PV is not generating.

Bill_Burgess:

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

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?

Bill_Burgess · 2020-08-07T21:56:10.000Z

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

image3.jpeg2016×1512 1.42 MB

image1.jpeg1512×2016 1.57 MB

Regards. Bill

Bill_Burgess · 2020-08-07T22:03:19.000Z

image0.jpeg2016×1512 1.5 MB

Sorry missed this pic
Also my Avalable current

image1.jpeg2016×1512 1.62 MB

Regards. Bill

Bill_Burgess · 2020-08-09T08:25:32.215Z

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

evpilot evcurrent evstate2016×1512 917 KB

IMG_3005.PNG1242×2208 306 KB

IMG_3006.PNG1242×2208 251 KB

mains power + ev power2016×1512 1.09 MB

glyn.hudson · 2020-08-10T16:56:54.511Z

Bill_Burgess:

If car is plugged in and no timed charge is set then if solar power is available 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 .

This is exactly how the solar PV divert feature works if EcoMode is enabled

Bill_Burgess:

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 .

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.

Bill_Burgess:

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

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.

Bill_Burgess:

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

Yes, divertmode can be controlled via mqtt

Topic: <base-topic>/divertmode/set
Value: 1 = Normal or 2 = Eco

Bill_Burgess · 2020-08-11T10:32:32.000Z

Hi thanks for the reply I will try and use mqqt. To enable and disable the pv function. Based around my normal charge times . And give it a go …
this is looking good when it is operating
Will let you know how I get on
Thanks

Regards. Bill

Bill_Burgess · 2020-08-12T21:51:15.000Z

Hi Glyn
Ok I have managed to use node red to set up the solar Eco divert to a timed shedual. From 9 am to 4 pm it will do solar / export excess charging now .
Could I ask if it is also posable to change the state of the solar PV divert enable command that you have added bottom of the services page
As with this enabled And the Eco divert off in normal
I have found that the demand shaper does not always update the times for charging slots
And also found to night that while not it a charge time slot it suddenly woke up and started to charge at full power. Have included picture. Showing the mains power which was at 0 w for a number of min before it woke up
I have set min Charge time to 300 seconds
Hope this helps you

image0.jpeg2016×1512 1.16 MB

Regards. Bill

Bill_Burgess · 2020-08-15T11:55:49.000Z

Hi Glyn
Been playing with this last few days
I have node red turning on and off the pv Eco setting 9:00 on. 16:00 off
Few things I have noticed.
If eco is turned off by node red 16:00 and car is charging due to export. Then charge rate now is set to max and car keeps charging .
Even though time shedual is for charging to be off .

All so regarding the charger just randomly starting when eco. Is off and also solar pv divert is disabled .
This has been happening very regular my system seems to have made two entry’s in the emon feeds
Emon/openevse-1. The Base topic I set on the charger
And also emon/openevse-Bill
This is the host name I gave it on setting up the charger
I have been use Mqtt explorer
And find that the under openevse-Bill. I get a msg. Rapi. In. $ST. = 11 00. 07 00.
This is a start time that keeps coming up every time it starts to charge .
But As far as I know I don’t have anything that writes to this topic
And in the demand shaper I have it set at the moment to a timed fixed charge from 00:00 to 06:00
This seems to be changing every 30 min I have just watched as it went from 11:00 -07:00 To 11:30 -07:00
What I can’t work out at the moment is if this is being generated from the
Evse esp32 Or is it being generated by my emon pi.
Also why is the host name being used for a feed input when the rest is being logged under the Mqtt name .
The good point is it’s making me look a lot more into node red programming and the details of how this all works

image0.jpeg1512×2016 1.04 MB

image1.jpeg2016×1512 1.51 MB

image2.jpeg2016×1512 1.69 MB

image3.jpeg2016×1512 1.46 MB

Regards. Bill

glyn.hudson · 2020-08-17T18:41:33.078Z

Bill_Burgess:

If eco is turned off by node red 16:00 and car is charging due to export. Then charge rate now is set to max and car keeps charging .
Even though time shedual is for charging to be off .

The command to turn off EcoMode only changes the mode. If you want changing to stop you will also need to send a RAPI stop command $FS. You can send this via MQTT:

topic: <base-topic>/rapi/in/$FS

See: GitHub - OpenEVSE/openevse_esp32_firmware: OpenEVSE V4 WiFi gateway using ESP32

Bill_Burgess:

All so regarding the charger just randomly starting when eco. Is off and also solar pv divert is disabled .

Interesting, this should not happen. Could it be demand shaper starting the charge?

Bill_Burgess:

Also why is the host name being used for a feed input when the rest is being logged under the Mqtt name .

The emoncms HTTP input uses the hostname as the nodename. But since you have used emon/xxx as the base topic the emonPi is also logging the data via MQTT. Anything posted to the emon/xxx MQTT topic gets logged to Emocnms, see MQTT — OpenEnergyMonitor 0.0.1 documentation