-
Notifications
You must be signed in to change notification settings - Fork 29
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to store flex-model & flex-context on sensor & asset #809
Comments
Regarding the first point, I would adapt the flexmeasures/flexmeasures/data/models/data_sources.py Lines 20 to 191 in 96e0a58
In this way, we can have multiple schedulers tied to the same sensors. In practice, this would work like this: scheduler = StorageScheduler(config=config)
db.session.add(scheduler.data_source) # save scheduler config to DB, this has id 2
...
scheduler = DataSource.query.get(2).data_generator
schedule = scheduler.compute(parameters=parameters) What do you think? |
I agree, that information should go towards the |
I don't agree that data sources are the correct and expected way to store this information about reality. The data source is a place you use when you express how the source wants to interpreted reality. Like in simulations, I can see that case. But it is a bad modeling decision in terms of mental concepts, which matter a lot. My proposal is that sensors and assets (and maybe sites) are the default places, and API calls and data sources can overwrite them (also partially). |
I don't understand especially this part. |
I understood @victorgarcia98 this way. You want to store this information on the data source so you can simulate different scenario's. I phrased this as interpretations of reality. I also recall you plan to create new data sources when this information changes, so as to keep perfect record about the context in which data was created. Those are practical considerations. I understand them, even if I don't really see the 2nd being very clean or easy to follow. My consideration is how natural this modeling feels. Any developer would expect this info on the assets or sensors. |
Thanks for clarifying. I agree it makes sense that the (current) defaults are specified on the assets/sensors. Specifically: the device's flex model as a sensor attribute, and the device's flex context as an asset attribute (because this context is potentially shared with other flexible devices). |
Good idea! That way we can keep the trigger schedule based on the sensor id. |
I'm not against keeping most of the information in the Asset or Sensor attributes, specially when we are talking about physical parameters: Nonetheless, I see some benefits of keeping the description of the scheduler as
More in general, we need to decide where each of the fields in
|
Instead of a I agree that these attributes are not all the same type of reality. Some are about physics (e.g. max_soc), some about preferences (e.g. prefer_charging_sooner). [I haven't looked at them all for now] Either the default info is on the physical model (sensor/asset/site), and schedulers (data sources) can save custom values (overwriting standard values on the physical model) to all the preferential settings. Those are the two directions I see here, and both have merits. Something I came across for motivation (from Kill It With Fire - Manage Ageing Computer Systems): "The lesson to learn here is the systems that feel familiar to people always provide more value than the systems that have structural elegances but run contrary to expectations." And people will feel feel that the physical things are the main or only places they think of when modeling. |
Instead of a I agree that these attributes are not all the same type of reality. Some are about physics (e.g. max_soc), some about preferences (e.g. prefer_charging_sooner). [I haven't looked at them all for now] Either the default info is on the physical model (sensor/asset/site), and schedulers (data sources) can save custom values (overwriting standard values on the physical model) to all the preferential settings. Those are the two directions I see here, and both have merits. Something I came across for motivation (from Kill It With Fire - Manage Ageing Computer Systems): "The lesson to learn here is the systems that feel familiar to people always provide more value than the systems that have structural elegances but run contrary to expectations." And people will feel feel that the physical things are the main or only places they think of when modeling. Btw, this issue should become a discussion first,right? |
In either case (keeping it in the Somehow, I lean more towards making the For example, in a hypothetical future scheduler that optimizes the participation in different ancillary services (FCR, aFRR, ...), we could define different schedulers to participate in different markets (e.g. just FCR or just FCR and aFRR). Maybe for this we need an entity to represent a
Regarding fallback mechanisms, I think they are convenient not to pass all the parameters but also they can induce a lot of confusion and lack of traceability.
Good quote!
I agree, this became a more transversal discussion. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
These two dicts should be looked up on sensor and/or asset by the scheduler (or other code that might need them). Then, sending each time per API call is not necessary.
This connects to #774 and #335, as well.
How would adding and editing work? Right now we can set dicts on attributes in the CLI and API I believe, and editing in the UI works. But maybe that support is not quite enough. For instance, I'd like schema checking these attributes, when they are so important as these two are.
The text was updated successfully, but these errors were encountered: