Latest update seems to have broken blueprint.

[RogierSchuring]

Since this evening, the sessy x on the meter blueprint is lost. It compensates absurdly and overshoots by extremes. (+2200 to -1700 and back.).
Started after updating ha sessy to 1.0.4 this afternoon.

[PimDoos]

I doubt this is caused by 1.0.4 since the changes since 1.0.3 are only in the first setup config flow.
Are you on the latest version of the blueprint? Can you post your blueprint settings?

[RogierSchuring]

I think i' m at the latest version yes. (Although they are not versioned, right?) Re-imported to be sure.

Do you mean the automation settings i created through your blueprint? Here they are:

alias: Sessy X on the Meter
description: ""
use_blueprint:
  path: PimDoos/sessy-xom.yaml
  input:
    grid_entity: sensor.sessy_<ID>_p1_power
    battery_device:
      - <ID>
    offset_entity:
      - sensor.tz3210_power_10
      - sensor.meterkast_car_charger_3f_kwh_meter_power
      - sensor.tz3210_power_13
    update_timeout:
      hours: 0
      minutes: 0
      seconds: 30
    update_interval:
      hours: 0
      minutes: 0
      seconds: 4
    setpoint_optimal_value: 2200

[PimDoos]

Although the overshoot is big, it is gradually building over a long period, suggesting the control cycle is working with out of date sensor readings. Can you check whether any source entities are going unavailable? Are all of your source entities updating at least once every 4 seconds?

[RogierSchuring]

Unfortunately, updating the blueprint did not resolve the issue. To make sure the offset entity's weren't the ones causing this, I removed them, but also this did not resolve the issue.

The smart meter updates every 5 seconds and the grid meter is the sessy p1 meter (and as far as i can tell, does not go unavailable).
When I had the update interval on 5 seconds, it missed one update from the slimme meter (it only accepts new data 5 seconds after finishing the blueprint run, which takes +- 1 second), so in practice it was updating and adjusting every 10 seconds, while the slimme meter update interval is 5 seconds. That's why I adjusted the update interval a few months ago to 4 seconds. Was working great until now.
I did get a new omvormer board in the sessy on tuesday (dc circuit error), but Tuesday evening and night, everything worked as expected.
Like I said, it started going haywire after the sessy application update on Wednesday.
The sessy "net zero" setting works as expected and also uses the sessy p1 meter as input, so I have no clue why it doesn't work.

[PimDoos]

What version of ha-sessy were you running before?

[RogierSchuring]

I think i have found something.

Runtime has increased to +-5.2 seconds per run. This is causing two runs to be active simultaneously... That would explain the behaviour. Still strange that it is taking that much longer all of a sudden.

I was running 1.0.3 before updating (trying to keep it up-to-date :) )

[PimDoos]

Hmm, that is strange. The blueprint can (should) only have a single running instance at one time.

https://github.com/PimDoos/ha-sessy-examples/blob/a2eb8e53cdec77f81c2a25a3dd58c47fd8dbc337/blueprints/automation/sessy/sessy-xom.yaml#L1

Is the runtime of 5.2 seconds counted without the rate limiting delay introduced at the end of the automation?

[RogierSchuring]

Ah, you are right. It's including the update interval...