Charging does not stop in Eco(PV divert)

[VictorTorrens]

I use OpenEVSE always in eco mode, and send to the charger the current available power with mqtt. The charger updates the value of avaliable power(Grid Import/Export) without any problem and it shows on the web UI, it updates every 5 seconds aprox.

But when the charger goes from available power (negative value), to not available power(positive value), the charger doesnt stop. It slows the charge rate to the lowest posible, 6A, but it doesnt stop.

Sometimes works properly, slows down the rate and then it stops the charging until power is available again.

I've seen similar issues from other users, seems related.

https://github.com/OpenEVSE/ESP32_WiFi_V4.x/issues/283 https://github.com/OpenEVSE/ESP32_WiFi_V4.x/issues/362

Before plugin the car, without power available.

Then if I have available power and plug the car, it starts charging properly

But after the power comes down to positive values, (unavailable for charging), it slows down charging rate but doesnt stop.

If I stop the charge by unpluging the car, it changes the state, waiting the car to charge again. Even if it keeps without available power. If I plug the car again, it starts charging at 5A, minimum rate.

The only solution I found, is toggle eco mode to off and on again, then it works properly. Waiting for available power. And with this the power cycles.

Sometimes, I don't know why, It works fine. It stops the charge until available power, but I can't find why.

Thank you

[JoseL-Tizon]

Me pasa lo mismo.

[DARDOLOR]

I have the same problem Tengo el mismo problema

[ayasystems]

I have the same issue for a long time.

I would be very grateful if this bug is reviewed

[Yenroff]

I also have the same problem, It is very annoying.

[GregoryFi]

Same here ... and also why is the timer deactivated in PVDivert mode ? It would make sure charging stops when there is no sunlight ...

[glynhudson]

Thanks for reporting this issue, I think there could be a bug with different timezones and the delay timer. Could you try clearing the delay timer and seeing if the solar PV divert stops? And also try setting the timezone to GMT London?

[VictorTorrens]

My car is in the dealership for service, I can't testit now. But I removed the timer and applied the london timezone and did tests without the car. When the power goes to unavailable it stays on charging mode for 2 more minutes. I will test with the car as soon as possible and report the results. Thank you.

[jeremypoulter]

@VictorTorrens that is not unexpected, there are several mechanisms to stop the relay being damaged with lots of switching. There is a minimum time that the power will be on and the signal is smoothed to avoid too much switching. Both of these can be configured by enabling the advanced settings:

[ayasystems]

I set it as 120 of minimal time of charger and sometimes never ends without available.

[jeremypoulter]

Had a bit of a look at this and it does look like there is a case where if the divert codes does not switch start the charge it will never stop: https://github.com/OpenEVSE/ESP32_WiFi_V4.x/blob/jeremypoulter/issue350/src/divert.cpp#L208 so I need to look at if divert_active is actually needed

[pdhoogh]

I recently upgraded to Wifi Firmware 4.1.4 and have not seen this behavior yet. In 4.1.3 I've seen it a few times. I may be chasing a ghost, but setting required pv power ratio to 1 seems to help.

It is not happening often enough and I have not yet found a reproducible failure mode to make this science.

[pbix]

I am using v4.1.3 firmware and I have observed that when the charger is running and I start sending a positive MQTT command the charger will not stop.

However, if I send exactly zero it will stop after a timeout.

The OP should try sending a zero reference (instead of +4000) and see if the charger stops in PV-Divert mode.

AND

OpenEVSE should stop when sent a positive reference once the power falls below the minimum charge current.

[pdhoogh]

That is interesting. Since I calculate +E/-I with Python and feed that to MQTT for the OpenEVSE to read out, I could clamp to zero. But I'm not doing it since I do not agree with the principle that EV charging should stop when the current is balanced.

1. The OpenEVSE does not have perfect accuracy and the total current usage of the house constantly fluctuates. It goes from -150 to plus 200, sometimes even +2000 for short bursts. I do not want the charge to stop all the time because of that.

2. Even if there is a time delay before stopping if Power1 is zero or positive, I don't always want the charger to stop. If it keeps charging at +600 Watt I'm still saving money: I pay more for taking power from the grid than I get for putting it in. Stopping the charge at Power1 = zero means Power1 will become -1600W. If I later need to charge the car and there is not enough solar, I need to take that 1600W from the grid later on and pay a premium and taxes on top for using the grid. That is how it works in Belgium. So I'd rather pay for taking 600W from the grid and keep charging and use my 1000W of "free" power.

In summer I don't do that. With good weather there is so much solar I do not need to shift Power1. But in winter I shift it by -600W.

[jeremypoulter]

There is certainly nothing in the code that is special casing 0, not to say that there is no issue it is just not an expected case.

[pbix]

That is interesting. Since I calculate +E/-I with Python and feed that to MQTT for the OpenEVSE to read out, I could clamp to zero. But I'm not doing it since I do not agree with the principle that EV charging should stop when the current is balanced.

For the benefit of Jeremy could you try a test and see if you can reproduce my results?

[pdhoogh]

Yes, I can and will, but note that I am on 4.1.4. I will include a trend taken with MQTT Explorer. We have cloudy weather now, so will need to wait for a bit more sun to do a representative test. And I'll include the code.

[pdhoogh]

I have been thinking about this a bit more. I do not have to code much, the Power1 we want to feed to the OpenEVSE comes straight out of the DSMRv5, so all I have to do is point the +I/-E OpenEVSE to the topic _dsmr/reading/phase_currently_returnedl1 and change its sign to negative. I don't think I can change the sign in the OpenEVSE subscription so I'll still need a bit of Python code:

When the dsmr starts importing current, the topic becomes zero. It is then the other topic, _dsmr/reading/phase_currently_deliveredl1, that becomes non-zero

@jeremypoulter and @glynhudson I'd like to test my understanding with you and what I expect the OpenEVSE to do.

• The +I/-E topic in OpenEVSE is used to calculate available current. Since it has no other reference and uses just +I/-E, the control algorithm is working incrementally. Meaning, if the present available current is x, the new available current is x+y where y is derived from the present +I/-E reading.
• If above is correct and +I/-E is sufficiently high (negative), the OpenEVSE in eco mode will calculate a high enough "current available" to start charging and start the charge with the calculated current. I'm leaving the filters and timeouts out here for simplicity.
• So, as long as +I/-E is negative, the OpenEVSE will keep increasing the charging current
• When +I/-E goes to zero, the control algo thinks the grid intake is balanced, so it won't change the available current
• The logical end state of the test is that OpenEVSE at some point will have reached Max Current and will stay there until you pull the plug. Regardless of what +I/-E will do, knowing it will never go positive.

So my expectation of this test is OpenEVSE will never stop charging in this test. Is my understanding correct?

[pbix]

To be clear about my test.

Run your charger at some positive value over 6 amps. Send it a positive reference like 4000 via MQTT. The current will reduce to 6Amps but not shut off. Change the MQTT reference to zero and the charger will shut off.

[VictorTorrens]

To be clear about my test.

Run your charger at some positive value over 6 amps. Send it a positive reference like 4000 via MQTT. The current will reduce to 6Amps but not shut off. Change the MQTT reference to zero and the charger will shut off.

I did this exact scenario and It works with my charger too. I don't know why but it works.

[pdhoogh]

To be clear about my test.

Run your charger at some positive value over 6 amps. Send it a positive reference like 4000 via MQTT. The current will reduce to 6Amps but not shut off. Change the MQTT reference to zero and the charger will shut off.

Ah OK, but that is not a representative test. I used to try sending MQTT data manually and saw "incorrect behavior". Glyn told me for the OpenEVSE in Eco mode to work correctly, it has to get an update from MQTT every 10 seconds. When I programmed that, the OpenEVSE started working correctly.

So to make this a better test, I will reprogram and use the values you propose, but with an automatic MQTT update every 10 seconds.

[pbix]

To be clear about my test. Run your charger at some positive value over 6 amps. Send it a positive reference like 4000 via MQTT. The current will reduce to 6Amps but not shut off. Change the MQTT reference to zero and the charger will shut off.

I did this exact scenario and It works with my charger too. I don't know why but it works.

What does "It works" mean? Can you be more descriptive of how the charger reacted in your case?

Also I agree with pdhoogh that you must update the MQTT reference at least once every 10 seconds or Divert Mode will not work. I should have said before that my references are sent every 10 seconds.

[pdhoogh]

Here is the result of my test. Python test code generates the "POWER1" every 10 seconds, generating the -3000 > +4000 > 0 profile. Even after dropping to zero the charger does not stop. The minimum charge time was set to 60 seconds. This test was after a normal charging session of 4 hours in eco mode with the "proper" Power1 calc, using true grid +I/-E.

It was evening, After the above test showing eco mode malfunctioning, I turned the proper Power1 calc back on and the charger kept charging, even though it calculated 1 Amp charge current. Only when I restarted the wifi did the charger stop. Time scale is 15 minutes for the complete X-axis.

Then I repeated the zero test. Now it did behave as should be expected: as soon as the Power1 went to +4k the charger stopped.

So it seems that the wifi module remembers stuff from the past that makes eco mode malfunction. After a fresh start it seems to work as advertised.

[ayasystems]

Same error with last dev firmware

No available but still charging

[jeremypoulter]

@ayasystems can you post the content of /claims ? eg http://openevse-1234.local/claims but this may point to this comment being true as the fist screen shot shows Active: no

[ayasystems]

[{"client":65538,"priority":50,"state":"active","charge_current":5,"auto_release":false},{"client":65537,"priority":1000,"state":"disabled","auto_release":true}]

But this data is after stop it manually

Yes, I saw that active was NO in my screenshot but eco was activated, I don't know why active was not.

I think that you need xxxxx/claims in the moment not now, right?

[jeremypoulter]

That is great, thanks. I think it must be something to do with that active flag. It used to be used to stop the divert messing up other modes but should be redundant now.

[ayasystems]

I saw ready 5A in display without solar available. I check that eco mode is set.

Before plug the car

After plug the car charging was started

/claims

[{"client":65538,"priority":50,"state":"active","charge_current":6,"auto_release":false}]

I hope it can help

Still charging without pv

[jeremypoulter]

Thanks, think I know what is going on, I will try and fix it this week.

[jeremypoulter]

431 has a fix for this issue, test binaries can be downloaded from https://github.com/OpenEVSE/ESP32_WiFi_V4.x/actions/runs/3118530150

[pdhoogh]

Thanks Jeremy!

Is this going to be rolled up in an “official” version 4.1.5 in some time or will that take many months before another point release is done ?

I’m asking because I can wait a bit as we have entered the rain season here and there is not a lot of PV divert opportunity the coming months. I can be patient. Also, testing the fix would require a "Power1" testcode. Without any real sun, I'd need to shift the +I/-E. But if you'd like me to test it, I can.

[jeremypoulter]

Bit of a catch 22, it will be released as soon as it has been tested, so if you can test with the PR binary that would be great. You can use the PV ratio to adjust the trigger level, for example a value of 0.5 will start the charge at 0.5 will start a charge at 3A (~700W), but will still charge at 6A

[pdhoogh]

Great! Will do the test. Since the previous test was using Required PV power ratio = 1.0 and I do not want to change the test conditions other than the new firmware, I will shift the power1 calc. I do not want to uncover another issue related to using Required PV power ratio other than 1.0. Rather I'd be looking for the update resolving the reported issue.

I've downloaded and installed the new firmware. There is a new parameter "Random start adjust". What does it do precisely? Should I leave it at 600 secs default ?

[glynhudson]

Testing and feedback of the beta will be very useful!

I've downloaded and installed the new firmware. There is a new parameter "Random start adjust". What does it do precisely? Should I leave it at 600 secs default ?

This setting is to comply with the new UK regulations governing charging points, it will apply an element of randomization to the start time of a charging session. You can set this to 0 if you don't want this. See https://github.com/OpenEVSE/ESP32_WiFi_V4.x/issues/350. Here's a good video which explains the new regulations: https://youtu.be/jMagvdqlF9c

[ayasystems]

This looks good. It has stopped it 5 times without fail

I'll back in a few days and tell you the results.

[pdhoogh]

Thanks for the video, Glyn. Instructive. We're not there yet in Belgium.

I did some preliminary tampering. We may not be out of the woods yet... I'm still seeing behavior I am not expecting.

Since there is heavy overcast and rain, my 10.4 kW peak solar array produces about 200 Watts... that is going to last at least a week. So yesterday I decided to do a little test following Jeremy's suggestion.

That did not seem to work all right. Here is the event log:

• On September 25th we had a bit of sun. I Updated and installed the test firmware openevse_wifi_v1.bin
• Noticed the new "Random start adjust" variable in the Charge Options panel. I cancelled the timer setting and the Random Start Adjust variable no longer showed on the GUI. That seems intended, so OK.
• In the Services tab, changed Required PV power ratio to 0.4. Other settings remained: Eco Mode on, max current set to 15 Amps.
• With 4 Amps Available Current there is not enough sun for 6 Amps, but with the PV ratio at 0.4 charging should start
• Connected the EV. Charging started and promptly went to 15 Amps. Restarting the WiFi of the OpenEVSE through the web GUI brought expected behavior back, the charge current stayed at 6 Amps
• Over a period of six hours, we had episodes of more sun and much less sun. The OpenEVSE behaved accordingly in an expected way.
• It had been dry all day, time to start the robotic mower. That uses a 27 MHz signal an emitter injects into a wire around the lawn, interfering with the WiFi. The OpenEVSE looses WiFi intermittently. OpenEVSE keeps up a good show using the data it gets.
• At the end of the mowing, I inadvertently hit the power switch to the outlet the OpenEVSE is plugged into. OpenEVSE loses power.
• I switch power back on. OpenEVSE initializes and starts charging the EV. There is no sun. But the charge current again goes all the way to 15 Amps. I need to reset the WiFi to get expected behavior back.

So it seems there is still something in the initialization of the OpenEVSE that is not always leading to behavior consistent with the settings visible in the Web GUI. Resetting the WiFi seems to help.

I also noticed a Current Shaper panel on the services tab. That is precisely what we need in winter! I see the idea behind it, I tried it but the behavior was a total mess so I stopped tampering with it, it seems that one is not ready yet.

[pdhoogh]

Some further test results. The behavior today was as intended. I also have a few suggestions.

Contrary to weather forecasts we had 20% clouded sky, little rain and lots of sunshine.

Test Conditions

• EV plugged in during the evening of September 26th.
• ECO mode on OpenEVSE, so no charge overnight.
• Required PV power ratio at 1.0
• September 27th. A bit before noon my wife started the washing machine
• Around noon, the swimspa starts heating with heatpump

Test Result

While Power 1 is above zero and the minimum charge timer has run out, there should not be any charging going on. That is precisely what happened.

Suggestion

For the purpose of reducing wear on the contactor and in light of legislation trying to avoid peak grid load, as discussed in the video Glyn put a link to, I would propose a Minimum Idle Time, rather than a Minimum Charge Time.

The test above shows that e.g. when the swimspa kicks in and the minimum charge time has not yet run out, the OpenEVSE keeps charging and causes a peak load of 4 to 5 kW. If that coincides with the sun being obscured by a cloud, as happened yesterday, the peak power can go higher than 8kW.

The UK is putting in legislation for EVSE behavior to counter these peaks. In Belgium the electricity distribution tariff will add a load peak component. The smart meter registers the load in 15 minute chunks. If one 15 minute chunk shows 8kW continuous, that 8kW peak is used to charge you for a 8kW peak during the whole month. My proposal is trying to avoid such high peaks while still saving the contactor.

[jeremypoulter]

Thanks for the suggestion, I don't recall why we did just the min charge time, but we can certainly add an idle time as well, both can be added and configured to suit a user's particular use case.

As this is a new feature request, best to add it as a new ticket.

[pdhoogh]

Agreed. Taking away an existing feature and replacing it with another might make some customers angry with you too.

Also, the minimum charge time is one way of not interrupting a charge session shortly after it started and before the car has fully initialized the charge session. My Peugeot bites back at this with a red status light on the charge port and refuses to take any charge after that as long as the type 2 plug stays in. That has caused me to miss a considerable charge on a sunny day a few times. I made another suggestion earlier to never break off an initiated charge before the charge current reached a minimum level (mostly 6A). That could possibly replace the minimum charge time for that use case.

Thanks and a deep bow to the OpenEVSE Openenergymonitor crew. With the current state of the WiFi firmware, the OpenEVSE is sooo much better than last year for my use case. There may still be the occasional glitch, but my use case with Eco mode has now gone from "check this thing because I'm worried it is not doing the right thing" to pretty much "plug it in and forget about it".

And I'm looking forward to the current shaper. That is precisely what we need for the winter. Way to go, guys!!

[pdhoogh]

Hi Jeremy,

I have not seen a way for opening a ticket, should I open a new issue with the new feature request so you can make a ticket, or did I miss something?

Met vriendelijke groeten,

Philippe D’Hooghe

Meidoornlaan 10

9820 Merelbeke

Belgium

+32 485 655 669

@.***

From: Jeremy Poulter @.*** Sent: dinsdag 27 september 2022 15:30 To: OpenEVSE/ESP32_WiFi_V4.x Cc: pdhoogh; Comment Subject: Re: [OpenEVSE/ESP32_WiFi_V4.x] Charging does not stop in Eco(PV divert) (Issue #387)

Thanks for the suggestion, I don't recall why we did just the min charge time, but we can certainly add an idle time as well, both can be added and configured to suit a user's particular use case.

As this is a new feature request, best to add it as a new ticket.

— Reply to this email directly, view it on GitHub https://github.com/OpenEVSE/ESP32_WiFi_V4.x/issues/387#issuecomment-1259511484 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AZFKZFUDFVJB74KDTEY46RTWALZEDANCNFSM522BCWMA . You are receiving this because you commented. https://github.com/notifications/beacon/AZFKZFTSNTY5IRQXOHET4G3WALZEDA5CNFSM522BCWMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOJMJJ5PA.gif Message ID: @.***>

http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient

Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com

[jeremypoulter]

Sorry, I ment issue ;-) use ticket in other places