Suggestion: Use openWB daily_imported topic to trigger SoC retrieval

[jmerifjKriwe]

I've noticed that the current calculation used to determine the timing of the next data retrieval (SoC) doesn't work very well when charging with PV, especially when the PV yield fluctuates heavily due to clouds.
The calculated time was often far off, resulting in me charging to almost 90% instead of it stopping at 80%.
Therefore, here's an idea, although it only works if you use an openWB – but there's already special handling for that anyway. Specifically, one could use the topic openWB/chargepoint/3/get/daily_imported. It outputs how much energy (in watt-hours) has already been charged into the car. And now, one could calculate how many watt-hours are needed to reach CHARGE_MIN_PERCENTAGE, taking BATTERY_CAPACITY into account. So, you subscribe to the topic above, take the current value, add this calculated watt-hour amount, and react as soon as this calculated value is reached. Then you perform the data retrieval and get the new, current SoC. (Calculating the SoC based solely on daily_imported instead of retrieving the value doesn't make sense due to highly variable charging losses.)

[tosate]

I’m experiencing similar behavior with my openWB system. Occasionally, the gateway stops updating the state of charge (SoC), causing the car to charge to 100% instead of the intended 90%.

The number of openWB users in our community is probably small, but the solution isn’t limited to openWB. It could work with any charging station that provides data via MQTT.

Did I understand that correctly?

If a charging station can provide the recently charged energy (e.g., the watt-hours charged over the past 24 hours in openWB), this value should be used to calculate the next API request.

Of course, incorrect assumptions can occur. For example, if charging happens in the morning, the car is driven during the day, and charging resumes in the evening.

Is the counter in openWB reset at midnight? That could distort the calculation if charging continues overnight.

For pure PV surplus charging, however, this approach seems reasonable to me.

[jmerifjKriwe]

I'm referencing the openWB specifically because an "integration" (the charging-stations-json) already exists for it. This just seemed like the most straightforward starting point for me. However, fundamentally, this concept should be applicable to any wallbox that can publish its meter readings via MQTT, either directly or indirectly.

And yes, that's the core idea: the system would subscribe to that specific MQTT topic. Then, once a defined amount of energy has been charged (a delta), it would trigger a new API request based on that energy delivery.

(If we were to support various wallboxes or meters, we would also need to make it configurable whether the respective topic publishes its data in Watt-hours (Wh) or kilowatt-hours (kWh), to ensure the energy delta is calculated correctly.)

For the openWB, the workflow could look something like this:

• The chargingValue (defined in charging-stations.json) changes to true.-
• The system then stores the current value from the openWB/chargepoint/3/get/daily_imported topic as $old_counter_value.
• It calculates a delta x (which would be based on the CHARGE_MIN_PERCENTAGE setting).
• When the openWB/chargepoint/3/get/daily_imported topic updates, it checks if the new value is greater than $old_counter_value + x.
• If it is, the system executes the API request.

The openWB/chargepoint/3/get/daily_imported topic presumably resets to zero at midnight. I'm not sure what happens if a charging session is active during this reset.

However, we could probably handle this with a simple check, something like:

Logic: If the new value from openWB/chargepoint/3/get/daily_imported is less than $old_counter_value (which indicates a midnight reset), then simply update $old_counter_value to this new current value.

Of course, this entire energy-based logic only really makes sense for charging sessions running completely on variable PV surplus. When charging at a constant rate (like at a public fast charger or full-speed from the grid), the charging power is generally so stable that the existing logic (which I assume is time-based) is perfectly adequate.

[tosate]

I’ve implemented the suggested workflow, and it seems to be working well. There was a bit of sun at noon, which triggered the workflow just as expected.

2025-11-02 13:00:02,493 [INFO]: Received imported energy message for vehicle with vin ABCDEFGH123456789 - publisher.mqtt_publisher
2025-11-02 13:00:02,493 [INFO]: OpenWB Integration: Imported energy threshold of 490.0 Wh reached (current: 522.0 Wh). Triggering vehicle refresh. - integrations.openwb
2025-11-02 13:00:02,493 [INFO]: Triggering refresh due to imported energy 522.0 Wh for vehicle ABCDEFGH123456789 - handlers.vehicle

I will test it over the next few days and then submit a pull request.

[tosate]

Last night, I charged my vehicle. While doing so, I noticed in the logs that the daily_imported value is reset at midnight. However, this does not cause any problems, as the update is triggered based on relative values.

During the normal charging process, vehicle data is mainly updated via OpenWB integration, which I do not consider to be a disadvantage.

As I am currently very busy, I will probably only be able to create the PR at the weekend.

[jmerifjKriwe]

That sounds great. And I believe even EVCC publishes the charged energy via MQTT, so we could even use this topic, and the API updates would also become more reliable when using EVCC instead of openWB.

But something just occurred to me: a completely different car could be charging at that charge point. In that case, it doesn't quite fit ;-) BUT: the openWB integration doesn't currently check that for chargeStateTopic and chargerConnectedTopic either; they also pull data directly from the charge point without checking if the correct car is associated with it.

Theoretically, you could also add a safety check by checking openWB/chargepoint/3/get/connected_vehicle/info. However, that contains a JSON. You would have to extract the ID from that and also store the corresponding ID (of the car in openWB) in the charging-stations.json. But that would surely be going too far for now.

[tosate]

I don't use EVCC. My setup relies on an openWB charging station integrated directly with the inverter.

I have created a car in the openWB configuration that represents my EV. The SoC-Module is configured to use MQTT, exposing topics for publishing the current state of charge (SoC). I also have a default car with no SoC-Module configured. If another car uses the charging station, I can switch to that car in the openWB web interface.

The scenario you described: someone forgetting to switch the car, could be detected using the vehicle ID in the JSON payload, but implementing that would add complexity for end user.