Validation rules for timed beliefs

[victorgarcia98]

Introduction

Recently, we have introduced the possibility to define some of the parameters of the StorageScheduler as sensors (See #957). This allows defining time-varying values but we are sacrificing some of the data validations that we are performing with quantities. For example, now, it is possible to define a negative power constraint via a sensor.

Ideas

There are at least three moments to consider:

1. When sensor data is UPSERTed
2. When a trigger references a sensor in its flex-model or flex-context
3. When a scheduler GETs sensor data

Gathering some thoughts:

1. When sensor data is UPSERTed

• It's still unknown whether the sensor will even be referenced in a flex-model or flex-context.

2. When a trigger references a sensor

• Allows early validation whose results can be immediately returned to the user.
• Sensor data may still get updated in the time between triggering (creating the scheduling job) and scheduling (executing the scheduling job).

2. When a scheduler GETs sensor data

• Validation against the exact data that would be used in scheduling
• Validation errors would show up in failed task logs.

Originally posted by @Flix6x in #985 (comment)

[nhoening]

Still looks like an interesting idea to me. Maybe a constant monitoring can also be an idea. Otherwise I would opt for 1) where validation logic simply checks if the sensor is being ised in flex-context and derives what to check for.

[nhoening]

Closing this for now, as we have recent work for making sure input data as well as produced data (for forecasts and reports) adheres to some simple rules:

• Let the scheduler clean its inputs with bounds on a sensor reference #2561
• Feat: forecast input bounds #2555
• Feat: add configurable forecast post processing  #2273

Feel free to re-open or open a specific new discussion.