FlexMeasures / flexmeasures / 34330049935

85%

push

github

Fix inverted sign of aggregate-consumption schedules (#2499)

* Fix inverted sign of aggregate-consumption schedules

The flex-context's aggregate-consumption and aggregate-production sensors record the
aggregate power schedule of all devices scheduled together. Their sign convention is
implied by the field name and, as documented, is meant to be recorded on the sensor
itself through the consumption_is_positive attribute.

That attribute was never set for either field: the code that sets it only walked the
flex-model's per-device consumption/production output sensors, and the make_schedule
safety net only recognizes results named consumption_schedule/production_schedule,
whereas aggregate schedules are emitted as storage_schedule. So an aggregate sensor
kept the default production-positive convention for power sensors, and the scheduler's
consumption-positive values were saved sign-flipped: consumption showed up as
production and vice versa. The aggregate-production sensor was unaffected, because
there the two conventions cancelled out.

Mark both sensors at job-creation time (so a conflicting attribute is still reported
before the job is enqueued) and again after compute(), as a safety net for direct
make_schedule calls.

The API test covering these sensors encoded the bug rather than catching it, negating
the stored values on the way in. It now reads them as stored, and covers the case from
the issue as well: with only aggregate-consumption defined, the sensor records the full
aggregate schedule, which is compared against the sum of the scheduled device flows.

Closes #2496

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012nk1JXQKQNvKa8iuvdqqWW
Signed-off-by: F.N. Claessen <claessen@seita.nl>

* Add PR link to changelog entry

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012nk1JXQKQNvKa8iuvdqqWW
Signed-off-by: F.N. Claessen <claessen@seita.... (continued)

23 of 27 new or added lines in 1 file covered. (85.19%)

18508 of 21770 relevant lines covered (85.02%)

0.85 hits per line