Address the power sequence by id for process control

[andig]

The four scenario 2 process control methods each start with

info, err := o.OptionalPowerConsumption(entity)
if err != nil {
	return nil, err
}

and then use exactly one field of the result — info.PowerSequenceId. Everything else the getter produces is discarded.

That getter belongs to scenario 1. Its result type cannot express "unknown": State, IsPausable and IsStoppable are value types, so a missing operatingConstraintsInterrupt would silently read as "neither pausable nor stoppable", which per OHPCF-011/7 is not a legal announcement. Erroring out is right for the overview call. It is not right for a request whose payload carries the sequence id and a state or a schedule, and nothing else.

The effect is that a remote which does not announce operatingConstraintsInterrupt, or announces a power sequence without a time slot value, cannot be scheduled, paused, resumed or aborted — while PowerConsumptionProcessState and the other readers keep working on the same data. The failure surfaces to the user as

The remote data structure is in an invalid state (alternative attribute present but no power sequence operating interrupt constraints defined)

on every control attempt (evcc-io/evcc#32252, a Vaillant aroTHERM plus whose stored sequence had lost that element).

This adds powerSequenceId(), which resolves the id through the same isDataAvailable check and the same "no power sequenceId defined" error, and points the four methods at it. OptionalPowerConsumption keeps its contract unchanged.

Note that the pausable/stoppable question is not lost: it was never enforced here. PausePowerConsumptionProcess validated that operatingConstraintsInterrupt exists and then ignored its values, so callers already have to consult ConsumptionIsPausable/ConsumptionIsStoppable themselves, which is what evcc does.

🤖 Generated with Claude Code

[Ka0o0]

Hi @andig ,

thank you for the PR. I am currently trying to understand the root cause of the problem that you observe. Do you maybe have trace logs available with the SHIP message payloads?

In theory it's correct to disregard messages with missing operatingConstraintsInterrupt since this field is marked mandatory. But there might be a bug in our RFE implementation in spine-go that causes this problem. To confirm this logs would be good.

[andig]

Sure, the detailed logs are right on top in the linked issue: evcc-io/evcc#32252, specifically https://drive.google.com/file/d/1chQU20VKxiXCVEgUJnVya4o3X5Lo8vth/view