v4.1.7 Charge starts randomly when in eco mode

[SergioRius]

Since I updated to v4.1.7 (4 days ago), the charger starts charging itself even when it's on eco mode and there is no sun production.
I've started noticing strange behavior since the current shaper was implemented. In previous versions the shaper woke up the car several times a day, depleted the 12v battery on my Tesla M3 so the car went into failsafe/service request.
I saw it live and the effect was that it was waking the car and proceeding with a micro-charge of 2-3 seconds, then stopped. The car stood awaken. So I disabled the current shaper when I noticed it.

I don't know if its related but now it stays charging.
Yesterday:

Today:

As you can see, the solar excess topic is supplying negative (consumption) with a max rate of 5s, that it is on eco mode and that when it starts like this, it goes up to the charge limit that is set, in my case 28A.
It only stops charging if the wifi module is rebooted.

This is really bad. Today has done it 4 times, depleted my home battery to 20% (limit), and the last time I only noticed because it caused the inverter overload.

[SergioRius]

Also noticed during normal eco mode charge, that if sun hides so fast that the mqtt topic reduces rapidly and does not stay at 0 for a while, it doesn't reduce the charge power to the 6A minimum. It stays at the last sustained charge rate and doesn't stop after the time limit.
It only stops after the wifi module is rebooted.

[KipK]

There was a bug on 4.1.7 with mqtt entering in a loop and disconnecting. Can you try with latest dev builds if it fixes it ?

[SergioRius]

There was a bug on 4.1.7 with mqtt entering in a loop and disconnecting. Can you try with latest dev builds if it fixes it ?

I have the ethernet board, F revision. Would you mind to point (or tell) me to the correct binary?
Are you referring to "Development build" openevse_esp32-gateway-f_dev.bin or openevse_esp32-gateway-f.bin ?
Or "V2 GUI pre-release"? This last one makes me dizzi when I look into the choices for binaries. %/

Whats the difference between _dev and the without _dev binary?
If one installs a gui2 version, it allows burning back to normal gui version from the interface? Does the stored configuration gets altered?

Anyways I just noticed that also charge starts whenever you connect the car despite being in eco mode. Rebooting stops charging.

12/1/2023, 9:22:05 | information | Waiting - EV Connected | 0.04 kWh | 39.7 °C
<= Rebooted here.
12/1/2023, 9:22:05 | information | Charging | 0.04 kWh | 39.7 °C
12/1/2023, 9:21:20 | information | Charging | 0.00 kWh | 39.7 °C
12/1/2023, 9:21:20 | information | EV Connected | 0.00 kWh | 39.7 °C
11/1/2023, 22:45:15 | information | EV Not connected | 0.61 kWh | 42.2 °C
11/1/2023, 19:24:11 | information | Waiting - EV Not connected | 0.61 kWh | 42.2 °C

[KipK]

V2 Gui are dev builds compiled with either V1 or V2 gui ( files ending with gui_v2 have new gui, others don't.
You can try with new gui too as It needs testers :) and there's a bit more info displayed on what is controlling the state.

You always can roll back, no worry, there's no config change.

[SergioRius]

I've installed the "Development build" openevse_esp32-gateway-f.bin file and when my wife arrived and connected the car it didn't start charging. And now the car is already sleeping.
This is the state log of yesterday (with it being awake even when not driven (magenta = driven)

And this is todays so far:

I'll try with the gui2 flavour and give you the insights.

[KipK]

so is it fixed ? it's not waking up randomly anymore ?

About current shaper, it nows disable itself when Divert is active, there was probably some bug using booth on older firmware.

[SergioRius]

Mmmmm... I don't know if I like the new interface.

It seems to show more information, but it's difficult to understand to what refers.
On the configuration section I would liked a more condensed layout, with more sections per page.
But what I definitely dislike is the small arrow icon you have to click to exit every config page. In summary, it requires much more clicks and difficult ones for the complete setup.

I suggest changing the configuration section to one with those nice buttons of the main page in a side menu. And a floating save button or no button at all (automatic saving). Then one could just click on the side buttons in order and enter or peek the settings. A big back button on the left side and a save button on the right side of the tittle bar would also be nice.

[SergioRius]

so is it fixed ? it's not waking up randomly anymore ?

About current shaper, it nows disable itself when Divert is active, there was probably some bug using booth on older firmware.

I'll let some more time before telling you it's fixed. It seems though.

But why one wouldn't like to have the current shaper active at the same time than the solar divert?
That would prevent to excess the grid when sun is covered by clouds and allow for a longer minimum charge time.
I've experienced this necessity as I have a large solar field, so I reduced the contract power in order to save. But when sun went fast all the consumption came from the inverter as grid was limited by parameters. Openevse didn't stop charging so overload happened.

[SergioRius]

What do think about this?

If those buttons

[SergioRius]

Not fixed!

System overload is in progress.
It started without any intervention from anyone. Not plugged.
Changed the toggle to disabled and then back to auto stopped the charge.

I'll monitor the values passed by mqtt in case there's something it doesn't like, but yesterday I limited negative values to a max of 6400w. I saw they where big negative values in the first screenshots.

I'll change firmware to regular gui+prerelease+dev that is easier for me to diagnose.

[KipK]

the tag displayed on bottom left of status bar shows state is set to Disabled by Divert ( by using /claims/target ) so EVSE should be disabled and not charging

@jeremypoulter , this looks related to #481 , #452, #450,

[KipK]

@SergioRius can you post the output of /claims/target when its buggy?
It's strange as it display the Divert tag it should also diisplay the divert data just above, but not on your case... Never saw this issue yet.

edit: No worry I can reproduce, It only displays when it's active for now., I have corrected

About Shaper I cantry let shaper active for divert and add the energy produced to the sum of amp available on shaper side.
But I thought Divert was already using min_current ( 6A) when temporising with smoothed amp to prevent the relay life. What Shaper could do more ?

[SergioRius]

@KipK Thanks for all your efforts.

It started charging 3 more times during the rest of the day. 1/2H ago I told the wife to leave it unplugged for the night when she came back from shopping.

I started to collect in influx all the points I send through mqtt to the charger. The grid consumption (yellow) and the excess solar power in green. This in reality is a battery setpoint I calculate. It's the remain after taking out what I consider battery should be charging at a given SoC. And it's negative as it also affects other power sources. I was first flooring it to zero before feeding into openevse, but I read that openevse also takes into account negative numbers in production for cutting power. I've adjusted it to re-send the value every 10s when it doesn't change and floor it to 6400. If not is sent every 1s max.
Could be that the mqtt interrupt is blocking the rest of the program execution? I experienced some of this before.
Anyways today has been very cloudy and the battery was empty so those messages where always 6400 every 10s.
The grid value is not filtered, so it is sent every 1s. But I have the shaper turned off.

I can't see anything wrong with the data collected around the time it starts. I hoped I could find I was feeding something wrong via mqtt. It seems that the Tesla Api has @30s of delay, so the State band has this delay to the log on the last graph.

EDIT: I'll try tomorrow with limiting all the mqtt messages I send to max every 3s.

[SergioRius]

About Shaper I cantry let shaper active for divert and add the energy produced to the sum of amp available on shaper side.
But I thought Divert was already using min_current ( 6A) when temporising with smoothed amp to prevent the relay life. What Shaper could do more ?

I don't understand you. I mean that the shaper doesn't necessarily has to be inactive during PV divert. By feeding both values, It could be useful in case the production drops and the system starts to get the power from the grid. It could then lower or even stop charging overriding the remaining time.
I have batteries so it starts to pull amps from the battery first, until it arrives to overload when it compensates with grid.
But if reaches the grid max, and the charger still has more power band available, could take the inverter into overload while being in that delay to save the contactor. Perhaps I'm wrong.

More important is that openevse should be always at it's minimum rate while being in that discount time.
Here you can see that it was pulling 11Amps instead of 6 while solar production was 0 and it had been like this until remaining time was 56s from the 150s configured.

I think there's something wrong on the mqtt cycle or something.

[KipK]

From the doc:
The EVSE expects the MQTT/HTTP data to update every 5-10s, perforamce will be degraded if the update interval is much faster or slower than this

Can you try with such rates?

[SergioRius]

5-10s

I've modified my feed flow to include a 7 seconds rate limiter and an override to 0 if no messages arrive in that time.
But I think it won't change the charging starts every time the car is plugged in.

I'm publishing voltage, excess power and grid power into the following topics:
openevse/vrms
openevse/excess
openevse/grid

Could be a problem with it?

[KipK]

Is it the same as your base topic?

If it is, you shouldn't use the same topic as openevse for external data

I see you have negative values , it's supposed to be always positive for solar. Or use the Grid +I/-e divert mode if you want to divert based on your excess of power. ( Negative means export on the grid )

[SergioRius]

Is it the same as your base topic?

If it is, you shouldn't use the same topic as openevse for external data

At the time I checked if that topics where in use, but you are right, nothing says it wont be in use in the future or even now. I'll change them now to a base topic of "openevse_feedin" for example.

[KipK]

I have edited my post above also

[SergioRius]

I have edited my post above also

Limited excess to zero or greater values.
Turned current shaper on and feed the grid power value.

[SergioRius]

It seems that those changes don't have an effect. The charger starts itself on it's own being on eco mode without power availability. That renders it unusable and I may be forced to change for another solution.

I'm not happy at this time. This past Friday it started during the night, depleted the batteries and charged overnight at a high price of energy without me noticing it.

I've gathered mqtt statistics and I can't see anything wrong on them.
The only thing I've seen out of normal is that when I plug the car, it always starts charging, but the screen always says "override". If I push the button it stops charging and goes into normal mode, and should be inverse. After a reset the evse seems to stay in a normal behavior, but after some time it can go again into I change when I want.
If it is only related with "charging whenever a car is plugged" could be that the car awakes for anything Tesla wants through api and thus the charge port announces ready and the charger makes it's thing.

That could explain the overnight charges, that is when Tesla prefers to download FW.

Could you tell me what is the last version before the current shaper implementation?

[SergioRius]

I've noticed something more:
The values showed for current doesn't match with consumed power (nor pilot)

[SergioRius]

FYI Been testing the charger and hasn't start charging on it's own again.
Thanks!