Open jamarju opened 2 months ago
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:
ha/sensor/inverters_input_power
ha/sensor/power_meter_active_power_pos_import
ha/sensor/power_meter_voltage
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 mqtt_solar
and mqtt_grid_ie
remain set to their respective topics, thus on mqttmsg_callback divert.update_state()
gets called twice.
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 -D ENABLE_DEBUG_MQTT
additionally to -D ENABLE_DEBUG_DIVERT
.
I can confirm that the problem persists after restarting the WiFi module via UI:
As a reminder, the topics announced from HA are:
ha/sensor/inverters_input_power
= PV prodution wattsha/sensor/power_meter_voltage
= grid voltsha/sensor/power_meter_active_power_pos_import
= grid +I/-E wattsAlso note I have two inverters, this is not relevant to this problem but explains why there are twice the inverters_input_power
as the topic is announced whenever any of the inverters get an update.
Relevant messages BEFORE REBOOT:
MQTT received:
Topic: ha/sensor/inverters_input_power
--
MQTT received:
Topic: ha/sensor/power_meter_voltage
--
MQTT received:
Topic: ha/sensor/power_meter_active_power_pos_import
--
MQTT received:
Topic: ha/sensor/inverters_input_power
--
MQTT received:
Topic: ha/sensor/inverters_input_power
--
MQTT received:
Topic: ha/sensor/power_meter_active_power_pos_import
--
MQTT received:
Topic: ha/sensor/inverters_input_power
--
AFTER REBOOT:
MQTT received:
Topic: ha/sensor/power_meter_voltage
--
MQTT received:
Topic: ha/sensor/power_meter_active_power_pos_import
--
MQTT received:
Topic: ha/sensor/inverters_input_power
--
MQTT received:
Topic: ha/sensor/inverters_input_power
--
MQTT received:
Topic: ha/sensor/power_meter_voltage
--
MQTT received:
Topic: ha/sensor/power_meter_active_power_pos_import
--
MQTT received:
Topic: ha/sensor/inverters_input_power
--
MQTT received:
Topic: ha/sensor/inverters_input_power
--
MQTT received:
Topic: ha/sensor/power_meter_voltage
--
MQTT received:
Topic: ha/sensor/power_meter_active_power_pos_import
--
MQTT received:
Topic: ha/sensor/inverters_input_power
--
MQTT received:
Topic: ha/sensor/inverters_input_power
--
MQTT received:
Topic: ha/sensor/power_meter_voltage
--
MQTT received:
Topic: ha/sensor/power_meter_active_power_pos_import
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.
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
Production
mode, 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_DIVERT
option enabled. See an example trace and walkthrough below:Walking through the trace:
Export
mode. 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
Production
mode.I believe the solution should be to not call
divert.update_state();
from MQTT callback iftopic_string == mqtt_solar
and we're inExport
mode 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