openevse_esp32_firmware

openevse_esp32_firmware copied to clipboard

(Bug present in release version but also confirmed present on latest dev build)

My system is configured in "SolarPV-gen" mode with the MQTT topic reflecting generation published to every 10 seconds. Attack/decay are at their defaults.

When divert mode is activated and sufficient generation becomes available (>= 6 Amps), ESP32 Wifi will set the pilot to the maximum charge current regardless of actual generation. It will remain at maximum until either that setting is changed or the generation available would cause the pilot to be set to another integer current level.

Both the "Charge rate" (both main and service tabs) and "Pilot" values in the web GUI reflect what should have been sent to EVSE based on available generation but the actual current is still at the maximum level.

A little more info:

• The maximum charge current used is whatever the "Max Current" is currently set to in the GUI.
• ~~Once the integer current level has changed then this behaviour does not recur until the mode has been toggled from eco to normal and back again. That is, if the EVSE is left in eco mode this will only happen on the first charging session.~~ I just witnessed the charge current being set to maximum after generation dropped below the threshold and then returned.
• I have "Pause status" set to "Disable". Might be related to the previous point.

+1 I've seen my car frequently go to 32A when my Grid (+I/-E) has just crept over the 6A mark.

I want to add, this only happens with one of my two evs. It happens with a BMW i3, but I haven't seen it happen with the Outlander PHEV. My hunch is that the evse sends a current below 6A that the bmw ignores and then goes to 32A, where the outlander doesn't ignore it and remains charging at 6A. Here's a graph to show it happening. I'll setup something to store evse logs at the same time so I can get more info.

Will look at that, but the EVSE should error if that case happens. But interesting that you get different results with the two vehicles.

I noticed that I do have the pilot in emoncms and it looks normal to me, but the car does seem to simply ignore it sometimes. At the start of this graph, the pilot drops to 6A as it wakes to start charge, but the car just starts at 30A until the pilot moves to 7A at which point the car starts behaving normally. In the middle of this graph it gets even weirder. The charger sleeps for a minute, wakes and the car is behaving normally but then after 4 minutes the car just decides to go to 30A!

I wonder what else can be changing besides these variables that might cause the car to go to 30A....

If you enable the developer mode and go to the RAPI tab, what is the pilot value as reported via RAPI?

I've started logging the GC and GS RAPI data so I'll get back to you the next time this happens.

@cholawo if your car is ignoring the pilot signal, that is a major safety problem. The car has no way of knowing why the pilot is limiting you to that current, in this case it's just because you are trying to limit to your solar output, but it could just as easily be because you're on a low-powered circuit. The car should never be ignoring the pilot, and if that's really what's happening, you should be taking that up with the manufacturer pronto!

I saw it happen today and I see the rapi pilot stays at 32 whilst frontend shows pilot at 6. So it seems that under some circumstances the frontend pilot value doesn't update rapi. I can send an rapi command to correct it and the car obeys whatever rapi pilot is set to. So I guess it's some frontend issue?

I also did a little more experimenting, I could reproduce this a few times when unplugging and replugging the car, but not when I unlock and lock the car (which also causes charging to stop and restart). For now I'm going to automate the problem away by sending an rapi command when rapi pilot remains at 32 and wifi module pilot is 6.

I was fairly certain that is what was happening as it was not creating an error, so thanks for confirming.

same issue than #450 , #452, #481