FlexMeasures / flexmeasures / 40685376297

87%

push

github

Note members entering or leaving a type-filtered group report (#2724)

* data/models/reporting: aggregate a device group from the flex-config

Context:
- Issue #2573, and the review on PR #2525 and PR #2579: a site's topology already
  lives in the flex-config, which says which devices sit behind which equipment
  (their `group`), which sensor records each of them, which sign means consumption
  or production, and which sensor a group's aggregate belongs on. A reporter that
  describes the same site a second time, by sensor name or unit, gives two
  descriptions with nothing to keep them in sync.

Change:
- The AggregatorReporter takes a `group` reference and reports that group's measured
  aggregate. Membership comes from the same `group` field, through the same resolver,
  that the scheduler reads, so adding a device to a group adds it to the report.
- The group's own entry says where the aggregate is recorded, and whether the
  aggregate is consumption- or production-positive; members whose own convention
  differs are negated.
- An optional `members` filter narrows a group to a category, by asset type, since a
  group is a piece of equipment and holds everything behind it.
- Each sensor is converted to the output sensor's unit at its own resolution, before
  being resampled. Converting a stock to a flow divides by the duration of an event,
  so converting as though the data were already at the output's resolution reported a
  sensor recording energy more finely than the report four times too low.
- Resampling follows the quantity: energy adds up over a longer event where power
  averages, and a power recorded more coarsely than the report is carried across its
  own event rather than leaving gaps.
- The sensor a group records on is never read back in, so a second run cannot fold
  the first run into itself, and two input entries for one sensor both survive.
- Replaces the name and unit selection of PR #2525 and the `portfolio` field of
  PR #2579,... (continued)

86 of 90 new or added lines in 2 files covered. (95.56%)

22679 of 26043 relevant lines covered (87.08%)

0.87 hits per line