aWATTar binding: Beta and discussion

[masipila (Markus Sipilä)]

@binderth

Yes, de-coupling those requirements from the data providers seems like the best way to go forward. Perhaps the configuration within the Optimizer could be done via configuring existing items for various inputs. I’m thinking of how widgets work. So for each energy provider (grid, PV, battery,…) there must be a bunch of items, which are used within the Optimizer.
or, if that doesn’t work for some reason, the Optimizer can come with its own set of items, and you simply point your existing items to that (e.g. via “follow” profiles?).

This is exactly the architecture that I have in the openHAB Spot Price Optimizer.

See this example, where we have an Item called BoilerHours which defines how long the water boiler needs to be ON.

4.x ‐ Usage example: Generic Optimizer ‐ heating domestic hot water during...

The result of an optimization is stored as a Timeseries to another Item, in this example BoilerControl. Because it’s an Item like any other, the timeseries is trivial to be visualized using Charts.

Markus

[masipila (Markus Sipilä)]

I was thinking a little what would be a more “openHAB way” to provide the optimizer services and educating myself a little bit about the openHAB architecture. By “more openHAB way” I mean something “more” than the npm package how I have published the optimizer services now so that they can be used with Rules / Scripts.

What do you think about implenting the optimizer services as an Automation Module?

Since I don’t have personal experience on PV, I’ll stick to the spot price optimization use cases for now (we can extend the discussion towards PV and batteries later on).

Let’s consider one of the simplest possible use cases i.e heating domestic hot water in the water boiler.

Pre-requisites:

• spot prices have been persisted as a timeseries to an Item called SpotPrice which has the persistence strategy forecast.
• there is an Item called BoilerHours which is a number indicating the number of hours the boiler needs to be ON.

The user would create a Rule, which is triggered either when new prices are available (price provider binding such as Entso-E or Awattar or Tibber or whatever has triggered their “prices available” channel). Or the Rule can be simply invoked with a time-based trigger for example at 15:00 when we assume that prices should be available.

Our Automation Module would register a new Action Type, which could be called for example “Find cheapest period”.

In the configurations of this Action Type, the user would need to pass arguments:

1. Choose the Item which contains the Spot Prices
2. Choose the Item which contains the number of hours that are needed
3. Choose the Item where the optimization result will be persisted as a Timeseries
4. Choose whether the cheapest period needs to be consecutive or not
5. Earliest allowed start time
6. Latest allowed end time

Arguments 5 and 6 would be optional and would be used if the boiler needs to be ON for the cheapest possible time, say between 00:00 and 06:00 so that there will always be enough hot water for the morning showers even if it would be cheaper in the afternoon.

When the Rule gets invoked, the Action Handler would kick in and

1. validate that the SpotPrice Item has data for tomorrow.
2. Find either the cheapest individual 15 min slots or cheapest consecutive period for the number of requested hours, respecting the earliest allowed start time and latest allowed end time
3. And persist the optimization result as a Timeseries with 15 min resolution to the Item selected as an argument 3

Similarly we could develop all kinds of Action Types for different optimization use cases.

This way

• the user would not have to interact with any code snippets like in my current openHAB Spot Price Optimizer, all input arguments could be provided as parameters via the UI when creating the Rule
• the result would be a real timeseries i.e. it can be rendered using Charts along with other timeseries (e.g. spot prices, weather forecasts) like in the screenshot below. Blue area represents the price of the electricity and the red bars represent the time when the boiler would be allowed to be ON.
  
  

Thoughts?

Cheers,
Markus

[binderth (Thomas Binder)]

@masipila

Thoughts?

Would be a good start IMHO. It gets more complex, if more consumers compete against even more providers.
Let’s say, we have not only a heat pump, but a dish washer/washing machine, whirlpool,… with a constant consumption curve and an EV, who could adjust its curve from one-phase 6A to three-phases 16/32A (230V).
Then add another layer of providers such as PV, home battery with also “flattering” curves…

I think that could be added to your thoughts, but would possibly need some adjustments so it can be handled without making it too complicated…

[masipila (Markus Sipilä)]

For the actual optimization algorithms, the only thing that the openHAB Spot Price Optimizer doesn’t have is the PV handling. That is the area that I don’t have personal experience with, and I’m still wondering how much the algorithms should rely on solar forecast and how much on the actual, real time production data (some PV users are using a PID controller for this).

When optimizing against just electricity prices, all the needed algorithms that the community around the Spot Price Optimizer has (so far) came up with are already there.

The point of my previous post was more to discuss what would be the ultimate way to expose these optimization algorithms for the users so that it would be as easy as possible to use in their own optimization Rules. The Automation Modules is one approach, publishing them as an npm package like now is another, Binding is a third option. Are there more options?

Markus

[masipila (Markus Sipilä)]

@mstormi I would really appreciate your thoughts on the “correct” or most elegant way to do the de-coupling in terms of openHAB architecture.

What do you think about the Automation Module and Action Type approach that I was thinking out loud above? Would that be the most “openHAB way” to decouple different input providers (price provider, weather, solar forecast, …) and the actual optimization algorithms? Or is there some other way that would be even more elegant architecture wise?

Markus

[Quautiputzli (Raimund Huber)]

@Quautiputzli

@Quautiputzli

If I implement a transformation service between the link from (for example) the total-gross-channel to the total-gross-item. Will the bestprice thing work with this “transfomed” values?

@Wolfgang1966

Transformations work on Things level, in my understanding before the value reaches the item. And as far as I get it it is within the scope of the binding to define whether transformations may be used and where they step in. Hence I would guess that it is possible to have the bestprice thing worked on the result of the transformation.

Hi, can anybody say if this would work? This could be the first little step.

Hello,
I tested it with the transformation service, but there was no effect to the “best prise thing”.

Whould anybody work on the binding, to split the two parts

• get price
• best price thing / optimizer?

in addition this year will be a change in the spot prices. They will change in 15min time range instead of 1h.

It would be fine to take the prices for calculating the “best price thing” from any items you want.