Tibber-Binding: get "Best Price" items like aWATTar-Binding?

Add-ons Bindings
,
1

While trying to get a hang into this dynamic energy pricing thing, I installed the aWATTar-Binding, as they don’t require a personal API-Key connected with a client status.
The aWATTar-Binding already features some functions via Thing/Channel configuration, which come in handy for having your high-volume consumption-devices wait for “cheap” hours.

I can define some device and configure the “Best Price” hours for that device:

UID: awattar:bestprice:awattar:WhirlpoolLaden
label: "aWATTar Bestprice: Whirlpool"
thingTypeUID: awattar:bestprice
configuration:
  length: 6
  rangeDuration: 24
  rangeStart: 15
  consecutive: false
bridgeUID: awattar:bridge:awattar

In that example, the binding will calculate the 6 (length) hours within a 24h period (rangeDuration), starting at 15h (rangeStart) - and those hours mustn’t be consecutive.

Before I dive right into it and try to emulate those functionality: Is there someone out there having replicated or simply written something like that with rules with the Tibber binding?
or - better yet - are the Tibber-binding authors and aWATTar-binding authors willing to join forces? Perhaps both APIs are kinda similar, so we can have one binding “dynamic energy price” and one can chose, which provider is active at their home?

2

I can throw in a link which you may or may not find interesting:

Some of the rule code posted here you may find inspirational since the Tibber binding has a similar channel for providing prices in JSON format as the original rules posted here used.

I’m interested in finding the best approach for creating automations and other things around energy prices. I didn’t look into aWATTar previously, so will give it a look. Can you give some examples of the use cases you see in the Bestprice thing approach? I believe you still need to write rule code, or can you actually automate something fully using UI with this?

2 Likes
3

You don’t have to write code for calculation of the “cheap hours”, of course you have to write code to start your devices in those cheap hours.
The aWATTar-Binding already lets you create specific Things for specific devices. As in my example above, you configure a device by telling the thing to search for the cheapest price for xx hours. If you know, your dishwasher needs 2h or your EV loads in 6h typically, you just tell the “BestPrice”-Thing how long the device needs power and if it has to be consecutive hours and from what hour of the day it should start searching, then you get ab bunch of pre-filled items, you can work with:

grafik
grafik734×442 17 KB

so, basically you can just use the first one, which tells you: “Now is the cheapest hours”, but you can also use the DateTime-items or even the “Countdown”-items to prepare. The second to last here tells you, that for potentially loading my Kia EV6 the best hours (yesterday) would start at 23:00 and last till 03:00. The items get filled daily at around 13h, that’s the time, the EPEX spot prices are published. So best is to start searching for cheap hours at around 14h/15h (CET that ist).

So, I’d be happy, if the Tibber-Binding would also provide that same logic, as I find it quite cool and saves a lot of rule-work yourself.

5 Likes
4

Thanks @mstormi for pointing this thread to me!

I’m interested in joining forces with other contributors and contribute in writing a binding for fetching day-ahead prices from Entso-E Transparency Platform’s API, see discussion on planing of that Binding at Entso-E binding for Nordpool spot prices

I created this solution last July: Control a water heater and ground source heat pump based on cheap hours of spot priced electricity - #13 by masipila

I really like the idea that this aWATTar binding does in terms of allowing users to define these configurable “Cheapes xx hours”.

The use cases that I currently have are:

  1. Find cheapest consecutive xx hours for charging an electric vehicle
  2. Find cheapest consecutive yy hours for heating domestic hot water with a boiler
  3. Find cheapest zz hours for heating the house
  4. Visualization of when the big loads are ON so that I know not to schedule our dish washer / washing machine to be ON at the same time. We have “only” 3x35A main fuses so if all 5 big loads (car, boiler, heat pump, dish washer, washing machine) are ON at the same time, the fuse of phase 1 would be overloaded. I schedule the dish washer and washing machines manually with their own timers.

Point 1: I don’t need to charge the car every night and the number of needed hours is different between the nights. I have currently created an Item called “CarChargingHours” which I can use to select how many hours I want. Updating this Item triggers calculation of the cheapest consecutive slot with a lenght of my choice.

Point 2: I don’t need to heat the domestic hot water every night. We have enough capacity to skip two nights if there is no cheap hours. I have DS18B20 sensors in the boiler which allows me to monitor how much hot water is left. I currently have a habit of checking the Finnish wind power production forecast (10 days ahead) to see if there are cheaper (or more expensive) nights coming. This forecast is available at Sähkön hintapuntari - Foreca.fi. I have an Item called “WaterHeatingHours” which allows me to select the number of hours for the next day. Updating this Item triggers the calculation to find the cheapest consecutive slot for the heating.

Point 3: This is the most complex / advanced of my use cases.

I fetch the weather forecast from the Finnish Meteorology API. I combine tomorrow’s forecasted temperature points with tomorrow’s wind speed points and derive a “wind chill compensated temperature”. This is the “feels like” temperature that you might be familiar with in weather forecasts. The formula is available at Wind chill - Wikipedia.

Based on the “feels like” or “wind chill compensated temperature”, I calcualte how many hours of heating our house needs tomorrow. The result of this calculation is stored to an Item called “HeatingHours” and I can manually adjust it if needed. Updating the value of this Item (either the scheduled calculation or manual adjustment) triggers the calculation of which hours the house heating will be ON. These hours do not need to be consecutive.

If tomorrow is very cold, my algorithm will divide the day into 3x8h parts and finds the cheapest hours from each 8h “slice” so that it’s guaranteed that each 8h part will have at least some heating hours. This way I avoid a situation that could otherwise easily occur that I would not have any heating in ~15 hours in a row, which would cause the house to cool too much.

As mentioned, I would like to contribute in designing the ultimate kick-ass solution concept which could be used with multiple different spot price sources, whether it’s Entso-E (most of Europe) or country-specific or company-specific data sources.

Cheers,
Markus

1 Like
5

In the opening post of this thread there was there was an example of

awattar:bestprice:awattar:WhirlpoolLaden

which has 4 configuration attributes.

Question: is technically possible to give another Item as configuration input? If yes, then use cases 1-3 of my previous comment would be conceptually doable.

6

Joining forces is always a good idea. Maybe you can consolidate Tibber, aWATTar, Entso-E, Energi Data service bindings or identify at least some common ground i.e. share software architecture and code, eventually.
Pinging @laursen, @kjoglums, @Wolfgang1966

1 Like
7

I tested the aWATTar briefly and it looks to me that the only thing that is needed to get the prices from Entso-E would be to write a new Bridge to aWATTar. I’ll check this avenue next at aWATTar binding: Beta and discussion - #76 by masipila

8

Hi folx, having a quick look at the documentation of the tibber binding, this provides many power consumption metrics which the aWATTar binding doesn’t (don’t know whether there is an API for that at aWATTar or Discovergy), while the aWATTar binding provides ways to automatically turn on power consuming devices at the times when prices are low. So I would not combine them to a single binding as every electricity provider offering variable rates will offer slightly different API capabilities, and a binding trying to combine them might very soon become a maintenance nightmare. But I would be glad if we could provide an Entso-E binding (either as separate binding or by extending the aWATTar binding with an additional bridge) for everyone who likes to do automation based on energy prices.

9

I agree that we should not merge Tibber, aWATTar, Entso-E and Energi Data Service into a single binding. I’ll add that I have also been considering implementing a binding for Eloverblik which provides tariff prices as well as metering data.

  • Energi Data Service: Provides electricity spot prices as well as Danish tariffs and taxes. There as several other datasets available, including CO2 emissions, gas, production/consumption/transmission lines etc.
  • Eloverblik: Provides Danish tariffs, taxes and metering data. Metering data is also provided by the DSMR and SmartMeter bindings. (Note: binding doesn’t exist yet)
  • Tibber: Prices/consumption data.
  • aWATTar: Prices.
  • Entso-E: Prices and a lot more. (Note: binding doesn’t exist yet)

Merging all this into a monolith of a binding would IMHO introduce more problems than it would solve.

However, I agree about joining forces, and I think we could design an architecture making it possible to share code/logic/algorithms/API’s. Or at least - on short-term - perhaps standardize some ways to interact with these bindings. The dynamic things in aWATTar looks interesting, this is something I plan to look closer at.

Energi Data Service is currently ~9500 lines of code in total. ~250 lines for generic price calculations not directly coupled with the API. Actions accounts for ~400 lines of code, which is mostly boiler-plate code for calling the calculator with provided data.

See also: Energy management/calculations · Issue #14181 · openhab/openhab-addons · GitHub
And parallel thread: aWATTar binding: Beta and discussion

1 Like
10

The first separation that I would make is to make a clear differentiation between energy consumption related things from energy price related things. (and I don’t mean openHab Things when I write things with lowercase).

These are related topics and one data provider may even provide both, but I still see them as clearly separate things. This does not mean that we could not have a electricty company specific Bindings, but if there is a company specific Binding, then it is clearly its own Binding.

  • I’m currently fetching day ahead spot prices from Entso-E and doing the calculations for scheduling the biggest energy consumers (house heating, water boiler, car charging) to cheap hours based on this data.

  • I’m currently fetching yesterday’s energy consumption data from Caruna (my network company) or from Fingrid (national grid operator which has a datahub where all network companies must feed the consumption data). Neither offers a real API but there are python scripts for both which allow a script to log in on my behalf and fetch the data, which means that I can save it to the same database where openHab persists the data.

Anyway, in my eyes these are two different topics.

We came to to a conclusion with @Wolfgang1966 that we will try to develop aWATTar to a direction where it is not specific to aWATTar day-ahead spot price API but it will support multiple spot price providers. See our discussion which starts here: aWATTar binding: Beta and discussion - #76 by masipila. We already touched the need to rename the Binding so that it’s not implying it would be company-specific anymore.

The benefit that I see here is that aWATTar already has a brilliant concept of configurable “BestPrices” which searches the optimal times for different loads. Which is essentially exactly what I currently do with my 100% custom javascript / rule based solution, but aWATTar has found an elegant way to overcome the openHab core limitation where you can’t persist future-timestamped points which my current solution does by bypassing the openHab persistence layers.

3 Likes
11

The problem I see here is that ENTSO-E is not only a spot price provider. So when someone wants to extend it to provide other data, you have two options:

  • Add this to the new monolith binding (aWATTar + ENTSO-E).
  • Create a new ENTSO-E binding duplicating the API and functionality from the “spot price” binding.

Also, this “spot price” binding would be lacking spot prices from other bindings like Tibber and Energi Data Service, because they are already more than “spot price” bindings.

12

Correct, like Tibber is not only a spot price provider either.

Correct. I think of Entso-E Transparency Platform as a data hub for gazillion differnet kinds of data. openHab Bindings in my eyes are supposed to focus on providing specific capabilities. The source of the data should not dictate which Binding provides the capability that utilizes the data.

I would like to see this discussion to converge into a direction where we would have one very good “spot price optimizer” Binding with two focus areas:

  • It has capabilities to fetch spot prices for users in multiple countries
  • It has highly configurable calculation capabilities for figuring out optimal schedules for different kinds of loads

If somebody would have a need to fetch for example the Accepted Offers and Activated Balancing Reserves from Entso-E, that would most definitely not belong to the “spot price optimizer” Binding just because the data happens to be available on the same Entso-E Transparency Platform where the binding is capable of reading other data (spot prices).

Markus

13

That’s a valid point, although we are probably in a gray area here due to the generic nature of such data hubs providing all kinds of different data. I still think one binding could provide everything we would ever need from ENTSO-E.

You could also argue that the Bosch SHC binding is too broad, and we should rather have one binding focusing on lighting and merge this domain with the Hue binding.

IMHO a binding should provide an integration to a specific device or service. In this case we have a few different services that provides similar data. A binding should expose this data from the implemented service, but I’m not sure I agree to which extent it should utilize the data. This can be done outside the binding, for example by rules that can even be shared as templates on the Marketplace. Some parts can possibly be implemented in core if we come up with an API for this.

You could then as a user select:

  • Service for obtaining data (prices): install binding.
  • Rules for processing this data, for example calculating cheapest timeslots: marketplace/forum.
  • Persistence/charts according to needs.

Now you are free to combine all those components as you see fit.

For Energi Data Service most of the work was implementing the infrastructure and API. At this point it would be very easy for me to add data on gas prices, for example. And already it contains tariffs and taxes which are variable in Denmark. So it does not make sense to perform any kind of calculation based only on the spot price.

Depending on your grid company, you will have different net tariffs. For example, in my area the net tariff is more than doubled from 17:00-20:00, and can often account for most of the price (exceeding the spot price). In some areas they have two different expensive periods, 17:00-21:00 and some hours in the morning.

The tax also changes from time to time, so if I’d be programming my dishwasher the night before July 1st 2023, I certainly would like the tax to be included in the “best price” calculation. In other words: We are solving the same problem. But for me, taking only the spot price into consideration is not sufficient.

For reference/comparison: README

Would you consider all of this as a candidate for being merged into the aWATTar binding?

If not, then you haven’t accomplished the goal of avoiding the redundancy you wanted to avoid by merging ENTSO-E and aWATTar. You did it only for those two, but you still have Energi Data Service, Tibber and possibly others. Even though we have different data sources and different data to take into account, we still need the same calculations to be performed on this data.

So you are suggesting to implement a “price optimizer” binding? Definition of a binding: “A binding is an extension to openHAB that integrates an external system like a software service or a hardware device.”

To me this doesn’t meet the definition.

14

@laursen I think you have a very good point here. Right now both aWATTar and Energi Data Service are doing complex business logic (calculating optimal times for the high energy consumers) in the same binding which is also responsible for fetching the data from a very specific data source.

As long as the calculation logic and data fetching logic are is in the same Binding, that means that they are tightly coupled.

15

From a design perspective, in the Energi Data Service binding there is no tight coupling between data and calculations in the sense that it would be really easy to move the calculations somewhere else and to expose the data by implementation of an interface. However, since we have no API to abstract them from each other, you are of course right that they are currently coupled.

Right now the calculations are provided with the binding for convenience and speed, but I would be very happy to move them out of the binding once we figure out a better alternative.

The evolution for me has been:

  • Move Energi Data Service data fetching from a rule to a binding. Expose future prices as a JSON channel. The JSON approach was needed because channels cannot be updated with past or future timestamps.
  • Provide an action to import the prices directly into a rule without having to deserialize JSON from this channel. This was mostly for speed, but also convenience and reuse.
  • Provide actions for performing calculations for a few scenarios I could think of. This optimized the speed a lot (from seconds to 50 ms on a RPi 3), and also made the calculations reusable between different DSL rules, and also with other users of the binding.
  • Abstract the data and calculations, so calculations could be reused between bindings. This seems like next natural evolution.

In other words, I consider the actions within the binding as a temporary solution (a pragmatic compromise).

16

I am not into binding coding at all, but is it possible to create a core code base (framework) for these bindings to centralize the code parts?

It would be nice to keep this DRY and maintain some functionalities only at one place which could be used by all if these bindings.

17

Yes, I created this issue for discussing a possible way forward/architecture:

Of course, it might turn out to have been created in the wrong repository, we’ll see.

2 Likes
18

29 posts were split to a new topic: Energy management and scheduling

47

I’m out of here. This discussion leads to nowhere, I’m afraid. I’m not in the mood to discuss “edge cases”, which are really the ones in my experience a mulitude of users will face.

What I wanted with this thread is to have an easy access to cheapest hours with configurations

  • how long
  • consecutive or not

everything else is something nice-to-have and it’s not part of a binding, but even more so of a concept. I don’t care, if an EMS does this or that. We’re talking tariffs here - at least that’s what I started this thread on.

48

A post was merged into an existing topic: Energy management and scheduling