Patrick Ohly

Darn these Heisenbugs. I tried restarting twice today with more log output, but it worked okay in both cases. While I keep trying, a question: should the integrate_on_max_sub_interval_exceeded_callback code get...

Or phrased differently: directly after a restart, should it update the area once with the time since the last update (3 hours when I first encountered this), or multiple times...

> it should update with the current state and last state previous to the restart What I see is that it updates with a very small time delta, not the...

> The first 2 means that the source sensor.solar_energy published the value twice... (since the value did not change, it probably update an attribute) So that there was no area...

More log output, now including `async_added_to_hass`: ``` 2024-09-19 14:10:12.318 WARNING (MainThread) [homeassistant.components.integration.sensor] *** Restored state 27698551.73 and last_valid_state 27698551.73033163888888801574 sensor= 2024-09-19 14:10:21.679 WARNING (MainThread) [homeassistant.components.integration.sensor] *** integral on_state_change: big area=0.2342400000000000059342808445,...

I got the sqlite database cleaned up through a Python script. Log output shows that the new area is sane. *But* somehow all new `sensor.solar_energy` are still to high. Isn't...

Found it. It's the old state in `.storage/core.restore_state` which serves as base for the first update after a restart, not what is found in the sqlite database. My cleanup script...

/wg device-management

> can you point us where this can be exercised in the e2e driver? The test/e2e/dra/test-driver? That driver has no hardware dependency, so the code in this PR cannot be...

/test pull-kubernetes-apidiff