Oscillating setpoint in Export mode when BOTH solar production and grid powers are published via MQTT #901
Comments
|
Hum... You shouldn't be able to setup to use both Grid IE and Solar at the same time. They should be mutually exclusive, so if that is happening then the bug is that we are allowing both to be selected. Can you describe how you set these up? |
|
Hi Jeremy. I just set it up the way it looks in the screenshots. Then, on the Home Assistant side, I have 3 automations that publish the following topics:
You are correct in that the two modes are mutually exclusive (ie. only one can be selected in the combobox), but the problem is that both This is strange as OpenEVSE should only be subscribed to either PV power or grid power topics, not both. I'll dig a bit deeper and come back, maybe it's the announcements that are actually wrong. |
|
Does a reboot 'fix' the issue? |
|
I think this is an issue with not unsubscribing from one topic when you change the config: https://github.com/OpenEVSE/openevse_esp32_firmware/blob/master/src/mqtt.cpp#L381-L390 so if you reboot it should work ok, even if both are configured |
|
Sorry for the delay, the car was fully charged so I didn't have the chance to test this. I have enabled MQTT debug prints via I can confirm that the problem persists after restarting the WiFi module via UI: 
As a reminder, the topics announced from HA are:
Also note I have two inverters, this is not relevant to this problem but explains why there are twice the Relevant messages BEFORE REBOOT: AFTER REBOOT: Here is the full trace in case it helps. |
|
I'm also occasionally seeing the shaper setpoint oscillate (without solar divert, just normal shaper). As was alluded to above, it seems to happen because the reported grid power comes in late, and the shaper code subtracts off the instantaneous charge current. If the charge current has ramped up but is not yet reflected in the power value, the shaper will calculate a too large available current. Once the charge current has ramped up to this value and it's reflected in the power, the shaper cuts back sharply. This causes the charge current to drop but until this is reflected in the power value, an abnormally low available current is calculated and this usually causes the charge to stop. Then the cycle repeats, leading to repeated current overshoots and relay chatter. It's generally iffy to construct differences of quantities that aren't measured in the same timebase, like the internal charge current and the live power, since transients will lead to abnormal values. I'd suggest we put a filter on the shaper output _maxpwr to damp these transients. A simple IIR filter should suffice. Yes, putting a filter on it will slow down the ramp down when max power is exceeded, but a single short exceedance seems preferred over the repeated relay chatter that can happen now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello, first and foremost thanks for this GREAT project, both the hardware and the software are fantastic!
It seems that there is an issue in the divert control system, where the current setpoint keeps going up and down without settling. This happens when both solar power production AND grid import/export values are reported through MQTT.
I'm latest firmware (5.2.0). My current set-up is as follows (screenshots below):
I was also experimenting with
Productionmode, which is set up this way:But note that my currently selected mode is:
Export.In this scenario, the setpoint oscillates. I have compiled the firmware in debug mode (target
openevse_wifi_tft_v1_dev) with the-D ENABLE_DEBUG_DIVERToption enabled. See an example trace and walkthrough below:Walking through the trace:
Exportmode. However, and I believe here is where the bug lies, the setpoint calculation code is called again here.This over-shooting / under-shooting the setpoint (30 -> 33 -> 20) keeps going on forever.
If I stop reporting PV production from Home Assistant, the issue resolves.
However, that would prevent me from using the
Productionmode.I believe the solution should be to not call
divert.update_state();from MQTT callback iftopic_string == mqtt_solarand we're inExportmode but I'm not aware of other implications.I can raise a PR with a suggested solution for review.
Thanks again!
Export mode config screenshot
Production mode config screenshot
The text was updated successfully, but these errors were encountered: