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. Overview | ECB Data Portal) 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:
hi!
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:
00,01,02,03,04,05,09,10,11,12,13,14,15,23
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.
thanks
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.
hi,
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 
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.
Thanks
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.
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. 
Cheers,
Markus
Bit OT, but: I see your finish winters, and want to add, you guys are one of the inventors of “passive house”-concept. https://www.passiivitaloyhdistys.fi/
Dear All,
Appreciate if you could get me in the right direction to further automate my car charging.
Currently I have defined 6 things for night loading with 1,2,3,4,5,6 hours and depending on the charge requirement I select the respective best hours thing in a rule. (Range start 18 and range duration 14)
This works perfekt when I want to leave home in the Morning. But very often I have home office and I would also like to use the time for charging until I would leave home.
Of course I could now add 6 more things and extend the range duration until e.g. noon next day and another 6 for until next day e.g. 16:00 …
But before I go this direction it would be so much easier if I can just have one thing where Range start and Range duration can be defined by items/variables.
I found there should be also a chance to change things definition via rules but again before I go into this trial and error experience I highly appreciate any suggestion what would be best way forward
Cheers, Chris
Thanks for the great binding
no binding I know does offer changing it’s configuration directly via rules.
You can however change every binding’s configuration via the REST API.
And that’s the way for you to go, if you really want to follow that rabbithole. Write a script to change the binding via REST and restart it.
But be aware: most - if not all - bindings assume, they’re more or less static. Especially if you change the aWATTar binding mid-day it could lead to unpredictable outcomes in the current price calculations depending on the time of change. That’s one reason bindings don’t have an direct “dynamic” attribute, which influence the behaviour of the binding directly. There’s literally no way to support this as there would be loads of confusion and a huge need for personalized support no one can expect from a open source software.
Hi Thomas, thanks for your advise … so for sure I will not go down that rabbit hole … I would need to spend a lot of time with my limited knowledge for a questionable outcome
you are a bit overthinking I guess for that part. I would just go with the median time you need to charge your EV. I for one have an 77kWh battery in mine, but I’ll settle for a time period of 4hours and use that. That’ll include charging to 80% most of the time. The times dynamic price explodes from one hour to another are scarce and so I’m content with that time period.
on the other hand, you could use evcc.io for that. If you handle it like any other appliance, you can let evcc charge your car. evcc has an option to just set the end time for loading and if it knows aWATTar, Tibber etc. prices it’ll just start loading your car on the cheap hours itself. evcc lets you change that via API, so you simply can have openHAB “know” somehow your timetable (iCal binding, simple manual item) and set the “charge my car til xx time” and it can set this it via http-binding via item and/or rule logic. There’s even a binding for evcc, but I’m not sure, if this binding keeps track of the constant API-changes of evcc!
Thanks for the tip with evcc.io … looks like it would also cover PV charging which for the time beeing I have not really touched …
Currently I calculate hours needed when I plug in my car (with normal SOC 80% or 100% if I have a business trip planned) only for night loading
I will just double the things and select if I want to have it loaded until 6oclock or until 15:00 … will cover 95% of my use cases …
@Wolfgang1966 Thanks for this very useful binding. I would like to persist the data in a variable with timeseries support for visualization-support in grafana.
Would you please be so kind and add some functionality like the energidataservice (openhab-addons/bundles/org.openhab.binding.energidataservice/README.md at 2a72e1cab70ffb48047017340f0405f924b6c455 · openhab/openhab-addons · GitHub) provides:
" Persisting Time Series
The binding offers support for persisting both historical and upcoming prices. The recommended persistence strategy is forecast, as it ensures a clean history without redundancy. Prices from the past 24 hours and all forthcoming prices will be stored. Any changes that impact published prices (e.g. selecting or deselecting VAT Profile) will result in the replacement of persisted prices within this period."
That would make your binding working for me perfectly.
Br Thomas
Hi @aMUSEd ,
I read about this persistence some time ago, and of course it would be the correct one to use for the aWATTar binding now as it is available. However, I am not sure about the future of the aWATTar binding at all. There is a far more general solution available with the Entso-E binding, so I think on the long run it will be a successor of the aWATTar binding. This binding also seems not to use the TimeSeries persistence yet, but making it available there would provide a solution for many european energy markets instead of only Austria and Germany. So if I have spare time I think I will use it to assist there instead of further maintaining the aWATTar binding.
1 Like
Hi Wolfgang,
sorry to hear that. The Entso-E binding does not gives us all the outstanding capabilities like least cost calculation for configurable timeslots and cost offsets like aWATTar handles the gross pricing. Hopefully you will find some time to enhance this binding to make it as comfortable as your aWATTar binding is.
Br Thomas