aWATTar binding: Beta and discussion

Your hope is unfortunately not a safe assumption. Entso-E API returns the spot prices in EUR/MWh, just like the aWATTar API does.

@Wolfgang1966 or anyone else: Is it possible to update Thing configuration parameters programmatically from a Rule? I believe the easiest way to solve the currency exchange rate would be that the users of non-EUR currency would be responsible for fetching the current exchange rate by one way or another and storing that to an Item. Then they could have a Rule that when that Item changes, the new value is updated to our Thing configuration.

I actually need this capability (or similar that produces the same result) to be able to fulfill my current use cases which I mentioned in a couple of comments above.

@Doug_Culnane you might enjoy reading my current solution: Control a water heater and ground source heat pump based on cheap hours of spot priced electricity - #13 by masipila

I charge our electric vehicle so that I have one Item called “CarChargingHours” which I can manually update with a stepper widget. The cheapest consequtive slot is then calculated so that the end time is next morning at 6:00. The “how many hours will I need” math is very easy to count as 10% of battery is reasonably close to 1h so if the battery level is for example 40% and I want to charge it to 80% I would allow 4 hours.


1 Like

@Wolfgang1966 I completed the first pass of my code review, see comment #77 above. aWATTar binding: Beta and discussion - #77 by masipila

  1. Would you have a moment to check if I missed something essential?

  2. Do you have immediate thoghts on the top of your mind to address points 10 and 11 i.e how and should be restructured so that they would support different data sources in an elegant way without need to duplicate all the code or make the classes to explode?

It will most probably take me a while to set up a local dev environment so that I will be happy with it so if you have any comments while I’m working with the dev environment I would highly appreaciate it to get a kick start! (I’m familiar with object oriented programming but it’s been about 20 years since I last was writing Java so current conventions and patterns do not come from the top of my mind…)


@masipila Your analysis looks good. Just a few remarks:

Regarding language properties: Translations are handled with Crowdin since some time, I was made aware of this during my initial contribution, but I don’t know how this works exactly. I assume it is documented somewhere, but I did not yet look it up.

Regarding BridgeHandler: The question for me is whether this should be modified to handle different data sources or whether it is better to extract an abstract superclass with the common stuff and use subclasses for the specific stuff.

Regarding XML: For Json the openHAB developing guidelines recommend (force?) the use of Gson. There may be something similar for XML also.

PriceHandler does the refresh logic for the thing, not for the bridge. It recomputes the prices with the price data the bridge helds. The amount of necessary changes depends on the possible differences of the data model the bridges can provide. If this is similar enough and the abstract bridge class can provide the necessary methods, it might be that there are not too many changes necessary here.

This sounds good to me.

Ach so… I don’t foresee any differences in the data model so the impact to this class should then be minimal. Entso-E API provides essentially the datetime and the spot price for that hour. The price is before taxes, which I believe is also what aWATTar API returns.

Thanks for the hint, found it here: Coding Guidelines | openHAB

Considering that the Epex Spot Market is entirely EUR based, I would suggest implementing a default currency conversion provider (e.g. ECB SDMX 2.1 RESTful web service) that can be overridden by the user. Installing and configuring a Currency Converter Binding, a Spot Market Prices Provider Binding and a Timeslot Provider Binding might make things unneccesarily complex for the average user.

OTOH: A Currency Converter Binding could be re-used for other purposes.

Would somebody be kind enough to bump me to the right direction in setting up a development environment so that I could start with the plan above?

I created this issue, so you can comment directly to this:

I am using the BestPrice Thing. Works pretty good!
My problem: I am using the cheapest 14hours for my heat pump. This is ok, but If I look at the cheap hours I find for today those hours:
So i can find out, that between 3pm and 11pm there is a huge gap for my pump.
Therefore it would be cool to start maximum at 3pm.
Therefore I thought I could use the remaining channel, but this is only for the whole period…
would be great to implement a remaining during period.
Otherwise I have to write a rule with gap analyze and if greater than 4hours for example, I start adavanced heat pump mode.

either that - or just find the acceptable period of time for your heat pump and then use multiple best price things? just use a shorter time span and two or more best price things.
Depending on the type of heat pump (air-air or air-water) you can elaborate this to your own needs - also depending on you type of insulation of course…

Hi @Klaus_Schuster , I’m afraid I didn’t get your requirement completely. What I understand is: You want to run your heatpump 14 hours per day, but with a certain maximum gap between the pauses. Due to the maximum gap you would accept that you do not always get the cheapest 14 hours. Did I get this right?

This would also require to take into account the gaps of subsequent days. For example, let the cheapest hours on day 1 be 00:00 until 13:59 (the first fourteen hours), but on the next day 10:00 to 23:59 (the latest 14 hours), you would get a gap of 20 hours in between. This should also not happen, correct?

Furthermore, what are your requirements for the minimum “on” period between the gaps? Would one hour be enough?

I just try to understand what requirements such an “extended bestprice” thing would have to fulfill.

Maybe the approach of @binderth would come close enough to a solution, splitting the day into 2x12 hours with 7 cheapest hours per period or 3x8 hours with 4-5 cheapest hours. This would limit the gaps between the active times.

i think I was missunderstood.
I want to use the 14 chepaest hours for my heatpump. Most of the day, the cheapest hours are closed to it. for example i have the cheapest hours from 1 do 10 o clock each hour. But after that a long period of expensive hours are next.
So my heatpump has a long time without work. therefore it could be a problem, because my rooms get cold.
so I want only 14hours which have no longer periods of a second given parameter in hours for MUST run. (4hours for example).
Therefore if the chepest hours stop at 10 o’clock, it must realize that i have to get another hour on 2pm. because of running out of warm rooms :slight_smile:

non-smarthome advice: get a decent insulation for your house, if it cools out that fast!
Because that means, you’ll have to heat your home 24/7 in worst case! In the long run, this will save you more than you could save with dynamic pricing…

on the other hand the smarthome solution is as we described: don’t pick either that long of an interval - and/or lengthen your “cheap hours” so you can extend your heating period.
But, from what I can see here, you’ll be better of to optimize your heating curve and then don’t work with cheap hours only but with combined prediction based on current temperatures and expected temperatures. Because if your home cools that fast you can save a few bucks, if you can predict some really expensive and cold hours → so you can perhaps slightly overheat your home in expectation of those expensive hours. Then if the price is right you can rebounce.

You are absoutely right. My house has massive 50cm bricks and was built in 2010. There is no cooling out in 4hours. I was a little bit afraid of those long stop periods.
It works well, the only thing is the warm water, but therefore I heat a higher temperature for later stop periods. Or in photovoltaik excess time.

1 Like

so I want only 14hours which have no longer periods of a second given parameter in hours for MUST run. (4hours for example).

Ok. That could be difficult to achieve, because it would have to take into account also the (not yet known) following day to ensure that the gap between the “On” period for this day and the “On” period for the next day would not extend 4 hours also. So in this example, the bestprice period for today must never end earlier than 20:00, which is achieveable with this parameter, but the one for the next day has to “know” at which time the bestprice period for this day ended and let the new bestprice period not start later than 4 hours after that. I think this is possible, but makes the calculations much more complicated than they are at the moment.

One way to achieve a result that comes close to what such an algorithm would get is as described above: Use 4 bestprice periods of 6 hours starting at 0:00, 6:00, 12:00, 18:00 with a length of 3/4/3/4 hours. In the worst case the gap is then 5 hours. If you can live with longer pauses, go down to 3 or to periods per day.

From your description I would guess that a sequence of 4h Off/1h On/4h Off, which would be a possible result of the additional parameter you propose, would in reality also not fit your needs, because 1h would not give enough energy for the next 4 hours when your buffer is already cold due to the last 4h period. If I’m right, we would have to add 2 parameters: Minimum “On” Period and maximum “Off” Period. This makes it even more complicated to compute and also reduces the savings you can achieve by running only during cheap hours.

I have implemented a solution for this need in my rule based solution with a concept were the day is divided into for example 4 x 6h or 3 x8 h slices. And each slice need to be allocated a configurable percentage of the day’s heating hours.

See Control a water heater and ground source heat pump based on cheap hours of spot priced electricity - #13 by masipila

And to the comments like “get a better insulation”. Welcome to Finland when it’s -20 degrees (and windy on top of it) to experience how fast the house cools down. :sunglasses:


Bit OT, but: I see your finish winters, and want to add, you guys are one of the inventors of “passive house”-concept.