Skip to content
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

Support passing constant prices in flex context #1027

Open
Flix6x opened this issue Mar 29, 2024 · 0 comments · May be fixed by #1028
Open

Support passing constant prices in flex context #1027

Flix6x opened this issue Mar 29, 2024 · 0 comments · May be fixed by #1028

Comments

@Flix6x
Copy link
Contributor

Flix6x commented Mar 29, 2024

The use case I have for this is to support a control policy to charge immediately, or actually rather, as soon as possible, while still taking into account other constraints such as grid capacity. This is already nicely supported by the storage scheduler, which introduces a small preference to charge sooner rather than later, all else being equal. That is, if prices are constant. Rather than, as a workaround, creating a constant price sensor explicitly, I'd like to convey this in the flex-context, by passing it a constant price.

My idea to support this is to take a step towards harmonizing the flex-context fields with fields in the flex-model that already employ the QuantityOrSensor schema. This specifically means moving from the consumption-price-sensor field to a consumption-price field, which should then support passing any quantity (which can be expressed in some quantity per MWh) or a sensor with any unit. Likewise for production-price.

I have done a tech spike that I'll start a PR with soon. The old fields need to stay alive to avoid introducing a breaking change, but we can adapt our documentation and stop mentioning the old fields.

@Flix6x Flix6x linked a pull request Mar 31, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant