Hi @Doug_Culnane , a deep thank you 
for finding the solution!! I was too busy to find time to dig into this myself. I would be glad if you could open a PR; I could not think of any other solution. I already suspected that it might have to do with some problem in the config files.
Thanks for this binding! As being an aWATTar customer myself since recently I’m trying to visualise the data combined with my current power consumption and PV-production.
I used the code from @Doug_Culnane to display the curve which is already quite useful (unfortunately a small issue with the wind turbine icons which don’t come through but this is negligible).
One question now: how can I show the lowest rate of the day in a label card? I can show the time frame but I can’t get my head around on how to show the rate itself.
Thanks for you help!
Hi @matzR ,
One idea that comes to my mind is using the prices thing which delivers all prices for today and then use the channel groups today00…today23 to identify the lowest one. I think this could be done with a rule, however, it will be a lengthy one and needs some programming skills (a long row of if statements for example).
I take this as an RFE to add more channels to the bestprice thing: lowest, average and highest price of a bestprice period. However, don’t expect me to do this soon, I can’t tell when I will find the time to implement it.
I had a similar idea and created this rule now:
// aWATTar - get lowest rate for the day
rule "get lowest rate of the day"
when
Item aWATTar_BestPrice_HoursList changed
then
// check which hour has the lowest rate today
val int lowRateHour = (aWATTar_BestPrice_start.state as DateTimeType).getZonedDateTime.getHour()
// loop through group to get the rate of the identified hour with the lowest rate
gAWATTAR_dayRates.members.forEach [rate|
if ( rate.name.contains(String.format("%02d", lowRateHour))) {
//logInfo("TEST", "lowRate: " + rate.state.toString)
aWATTar_BestPrice_price.postUpdate( rate.state )
}
]
end
First I thought I could thought take the n-th element of the group based on lowRateHour but I didn’t figure out how to do that?
@Wolfgang1966 I’d like to contribute and add a capability to read spot prices from the Entso-E Transparency Platform so that your wonderful binding could be used by folks from other countries and regardless where they are purchasing their electricity from.
I installed the aWATTar Bindingin and had a 10 min look at it and it looks to me that the only thing that would be needed is to enhance this so that there would be another Bridge option which would take the following arguments:
- Entso-E API token (this is free of charge and can be obtained from Entso-E service desk)
- Bidding Zone, for example 10YFI-1--------U means Finland
- VAT multiplier
- Currency exchange rate so that folks who do not use Euros can see the prices in their own currency
Is my assumption correct that the only thing that is needed is to write this additional Bridge?
Cheers,
Markus
Notes to self (others: feel absolutely free to correct if there I have misunderstood something)
-
Code can be found here: openhab-addons/bundles/org.openhab.binding.awattar at main · openhab/openhab-addons · GitHub
- Needs update if other countries / bidding zones would be supported
- Add a new bridge type called for example bridge-type:awattar:entsoe-bridge
- Strings seem to go here so that they can be translated
- Reflect the new entsoe-brigde type also here
- This seems like a good candidate for date helper methods for preparing the date input arguments in the format Entso API expectes them
- No changes should be needed, the Prices that Entso-E provides can be saved to the same data model
- Need to implement same kind of class for Entso-E Bridge configurations
- Factory class for creating new instances of the Handler classes
- See next points
- This contains the data refresh logic, will probably require some changes when there will be other Bridges
- This is where the prices are fetched from the current data source.
- This class needs some love when there will be another data source as there is also a lot of other logic in this class which should not be duplicated.
- These are for converting JSON to Java structures
- Entso-E responses are XML so needs to be handled differently
Please add a parameter for basePrice to the Entso-E Bridge (aWATTar - Bindings | openHAB, aWATTar binding: Beta and discussion - #17 by Wolfgang1966).
If you don’t trust your energy supplier to calculate the base price correctly, it gets quite complicated to calculate the base price per kWh in Germany 
: Understanding the Tibber price model (Germany)
Hi @masipila ,
I really like your idea and I’m confident that it could work that way, maybe with a few adaptions to the existing code. As the Entso-E API might use a different data model there might also be the need to add additional dtos for the Gson parser of your bridge.
Also, I think about the naming. How do we get the folx that is interested in Entso-E data to have a look at the aWATTar binding for their needs. Renaming the binding would be a breaking change for all users of the current one, but code duplication to a separate Entso-E binding also looks like a bad idea to me. I do not have a good solution at the moment, but maybe somebody reading this has an idea.
So, feel free to start! 
Regarding the naming. I was also thinking about it this morning for the exact reason.
One option which is backwards compatible is to keep the old code as it is but mark it as deprecated. We could then clone it with a new name and all further changes would only go to the new code base.
But let’s worry about that latrr when we have first got it working with Entso-E API.
Cheers,
Markus
1 Like
@Wolfgang1966 and @masipila,
As a user of the Awattar binding I would be happy to rename my things to a generic name. The Items I guess can keep the same so it would not be a big problem for me to set this up again. The rules etc use the item names so all I got to do is link them to the right thing channels.
I find the discussion and ideas very good. I think automating electric use, mini smart grids and costing calculations etc… is really interesting and so any initiative that makes this easier for more people to set up generic solutions is great. I would be happy to test and help.
Currency exchange rate is tricky as this is dynamic. I would not add this to the scope of the binding. I would hope the prices are supplied in the local currency. If not then it is the job of another binding to get the currency rate (or an http binding get)… and a rule to calculate the local cost… that is how i would try to solve it.
I do not know enough about energy markets to know if they are all the same… I guess the awattar binding model is good for EU Spot market customers and suppliers. There might be other models out there.
I use the binding to soak up the cheapest hour of electricity each day to keep the car topped up and water warm if (the price is lower than the price I get for solar) or (car is very low). This is not very sophisticated but it works well and I have to occasionality manually intervene when not.
What would be cool to to define a target charge level (with a dimmer in the UI so you can slide it depending on future usage needs) and time in the morning to try to achieve this. A rule can calculate the required energy needed and the time that it would take to supply it. Then the energy binding gets a time and an end timestamp. The binding then could supply a switch that would switch on for long enough to supply this (in periods or one period) when the electricity is cheapest. It would be perfect if the time needed could be recalculated so that if the car did not get plugged in till late (or once the sun has gone down) then it would still charge on time… just an idea for discussion or ignoring…
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
-
Would you have a moment to check if I missed something essential?
-
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.
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…