Fix: include belief time in fixed-value records for chart data

[joshuaunity]

Description

This PR resolves an issue where fixed values in graphs were not displayed during playback. These values are now visible.

Look & Feel

Before:

After:

How to test

1. Find an asset with a fixed value set in any of its flex-configs
2. Go to the graph page and add a graph using that flex-config field. (You could also have an already existing graph using a flex-config field with a fixed value)
3. Observe and confirm that the fixed value plot does not disappear on playback.

Further Improvements

None

Related Items

This PR closes #2110

Sign-off

• I agree to contribute to the project under Apache 2 License.
• To the best of my knowledge, the proposed patch is not based on code under GPL or other license that is incompatible with FlexMeasures

[joshuaunity]

NOTE: Changelog entry needed

[BelhsanHmida]

Manual tests passed. one thing i couldn't get to work is the panning feature but i don't know if that's in the scope of this pr.

[joshuaunity]

Manual tests passed. one thing i couldn't get to work is the panning feature but i don't know if that's in the scope of this pr.

No its not. There is no panning to this work

[joshuaunity]

@BelhsanHmida, are there any other findings?

[BelhsanHmida]

Small consistency concern: fixed-value records now get belief_time / bt set to the chart start, which makes sense for replay because the values should be visible from the first tick. But they still emit belief_horizon / bh as 0 for every generated timestamp.

For later timestamps, that makes the timing metadata a bit inconsistent: the record says it was known at the chart start, but also reports a zero horizon. Since replay only depends on belief_time / bt, could we either omit belief_horizon / bh for these synthetic fixed-value records, or compute it per timestamp if we want to keep the field?

@Flix6x do you see a case where we would need belief_horizon on these synthetic fixed-value sensors?

[BelhsanHmida]

@BelhsanHmida, are there any other findings?

here are my reviews. i forgot to press submit review

[BelhsanHmida]

Small UX follow-up: pressing “Add plot” multiple times keeps adding the same field again, so it’s easy to end up with duplicate entries for the same flex-config field in a graph.

Would it make sense to guard against adding the same field twice to the same graph, or at least disable the button once that field is already present there?

[BelhsanHmida]

Could you ask Copilot to add a test case for this?

We usually like to add coverage on most PRs, especially now that AI makes it cheaper to include.

[joshuaunity]

documentation/views/asset-data.rst

Hmm, we can add a guard. What do you think @Flix6x would it be better off as is currently?

From my perspective, there doesn't seem to be a case where one would need multiple of the same thing.

[Flix6x]

Hmm, we can add a guard. What do you think @Flix6x would it be better off as is currently?

From my perspective, there doesn't seem to be a case where one would need multiple of the same thing.

No, indeed. There should be no reason for having duplicate flex-config references in the same subchart. That also goes for sensors, actually. However, it should remain possible to use the same sensor or flex-config reference in different subcharts.