Fallback components in generated formulas in LogicalMeter

[shsms]

What's needed?

Support for automatic logical meter formulas to be regenerated with fallback components from the component graph, if available.

For example, in the grid_power() formula, power values from all components directly attached to the grid component are added. These are usually just meters. But one of these meters fails, and that meter has a fallback component, values from the fallback components can be used in the formula instead.

In the first version, this can be done for just meters attached to inverters. If such meters fail, values from the inverters can be used instead.

This might also be possible with meters attached to ev-chargers, if we can be confident that there are no hidden load behind such meters, and it is just the ev chargers.

This will NOT be possible

• if the main meter fails, whether it is on the grid side or not,
• if a PV meter fails,

because both those don't have fallback devices in the component graph that we can get power readings from.

Proposed solution

No response

Use cases

No response

Alternatives and workarounds

No response

Additional context

No response

[matthias-wende-frequenz]

Additionally the LogicalMeter might raise an alert that it is working in fallback mode and that can be picked up by an app, which can e.g. trigger an UI alert.

[thomas-nicolai-frequenz]

if a PV meter fails,

Well we can read that from the PV inverter which is a component on the component graph.

[matthias-wende-frequenz]

if a PV meter fails

that's not necessarily true. If we have support for PV inverters, these can be used as a fallback.

[daniel-zullo-frequenz]

Writting here suggestions from Matthias and Sahas, so they don't get lost

Addressing this issue involves having an dynamic graph that self changes on certain conditions.

This can actually be done without having to rebuild the formula. There are MetricFetchers to which we give one receiver. We can just modify them to take multiple receivers, and if the first one gives None, try the second. And then just specify the fallback components from the chain when building the formula, and that way we can isolate the dynamic stuff to this one part.

This is a good starting point even that suggestion wouldn't cover the case of one meter in front of many PV inverters.
And we can get it to cover the multiple inverter situation as well. But extending the MetricFetcher feels much easier than dynamically adding/removing formula steps.