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_returned_l1 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_delivered_l1, 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.