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.

Cheers,
Markus

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 AwattarPriceHandler.java and AwattarBrigdeHandler.java 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ā€¦)

Cheers,
Markus

@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. 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 :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.
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.

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:

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 :slight_smile:
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 :slight_smile:

:wink:
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! :wink: