Historically, FlexMeasures saved consumption values in the database as negative values. At some point, we started supporting the opposite, too, using the consumption_is_positive to record the sign convention for any given power sensor.

Unfortunately, for power sensors that record consumption as positive values and also record schedules from our scheduler, the recorded sign convention is not correctly taken into account in the database. This shows in the UI, and is especially annoying when the same sensor is used to record user data sent over the API, because the sensor will then show realized consumption as positive values, and scheduled consumption as negative values.

This happens because the consumption_is_positive attribute is used wrongly in two places. We had left this unaddressed until now, because in this particular case, two wrongs happen to make a right. Let me explain. TL;DR The bug did not affect the API, so we thought of it as a bug affecting viz only.

Root cause

The first place is in our scheduling service, where we just got the schedule from the scheduler and are about to save it to the database. The schedule uses positive values to indicate consumption, and based on the sign definition that the sensor we save to uses we decide whether to flip the sign. The sign definition of the sensors is encoded in the consumption_is_positive attribute. This is the crucial bit of code that does the flip.

if result["sensor"].measures_power and result["sensor"].get_attribute("consumption_is_positive", True):
    sign = -1

As you can see, the sign is flipped when it shouldn't be. Instead, it should be:

if not result["sensor"].measures_power and result["sensor"].get_attribute("consumption_is_positive", False):
    sign = -1

This change also changes the default, making it agree with the nearby comment:

# For consumption schedules, positive values denote consumption. For the db, consumption is negative

The second place is in our API, where we have just fetched the data from the database and are about to send a response to a user's GET request. The user expects consumption as positive values (for the endpoint to GET a schedule):

if sensor.get_attribute("consumption_is_positive", True):
    sign = -1

As you can see, the sign is again flipped when it shouldn't be. Instead, it should be:

if not sensor.get_attribute("consumption_is_positive", False):
    sign = -1

So the current situation is:

• If consumption_is_positive is True or left out, we mistakenly switch the schedule's sign before saving to the database, but the GET API also mistakingly switches it back, so the API user does not notice, but the UI user sees consumption as negative values, in contrast to what was suggested by the attribute.
• If consumption_is_positive is False, we mistakingly do not switch it in the database, but the GET API also mistakingly does not switch it back, so the API user does not notice, but the UI user sees consumption as positive values, in contrast to what was suggested by the attribute.
• We want to correct both mistakes, by switching the default to False and applying the sign switch to the opposite case.

Expected user impact

More details will follow here. I'm envisioning hosts will require two features in an optional data migration.

1. Flipping the sign of data affected in the past.
2. Updating the attribute on relevant sensors (only power sensors with schedules) if the attribute was set explicitly on either the sensor or its asset. Why? Because if it was set explicitly on such sensors, it was probably done by the host (consumption_is_positive=false set as a sensor or asset attribute) or by the API/UI user (set as an asset attribute) to make the UI appear correct even though the setting suggests the opposite of what is observed in both the UI and the API. This seems like a rare case, but is in fact the workaround I would currently suggest for new users that are bothered by this visualization bug.

API user impact:

• API users of the [GET] /sensors/(id)/schedules/(uuid) endpoint would not be affected.
• API users of the [GET] /sensors/data endpoint may be affected.