@Wolfgang1966 I have the issue running with the openHAB docker. This might be the quickest way to be able to reproduce it if you have docker installed. (I just tried this and it reproduced the error)
Then install the awattar binding and try to install the bridge with the GUI. You will not see it as @martingwb describes.
You can docker cp new version into the container for testing a fix. Let me know if I can help testing or fixing. (I contributed the Renault binding so I might be able to help)
@Wolfgang1966 , @Doug_Culnane - thank you for your hints, I managed to see the current price in a label card and a chart is built under Analyze item.
Is there somehow a way to build a chart not only from the current prices but also including all the known prices for today and tomorrow in OH?
I guess the channels need somehow to be consolidated for that?
Hi @martingwb , the data for such a chart is available with the binding, use the āpricesā thing and the channel groups todayXX and tomorrowXX to retrieve them, However, I was not able to get a chart like the one I assume you want (something similar to the chart available on the awattar website), because the charts available in openHAB are all timeseries based and openHAB currently does not allow to set item values in advance to a certain time in the future. I searched for such a function in openHAB, but did not find any. So you can include all data in a sitemap as the example configuration shows, but there seems to be no way to set up a āpredictingā graph currently.
We may discuss this as a feature request for the openHAB core API, as it might be useful for weather predictions also, for example to show a temperature forecast graph.
@Wolfgang1966 - Thank you for clarifying. Yes, you guessed what I am looking for. Will integrate matplotlib awattar charts for now to display on the OH web gui.
I have the same setup like @martingwb . Docker/Synology OH3 3.3.0 stable. I am also do not get the Option to install the bridge as a thing. It does not show whgen you try to add a thing. Do you found in the meantime a solution/ workaround for that problem? Thanx!
@Wolfgang1966 I moved the bridge-types.xml bridge definition to the thing-types.xml file and the bridge can be added via the UI. (I do not know why this works but it works). Shall I submit a pull request or do you wish to solve this another way?
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.
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.
// 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?
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)
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.
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.
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ā¦
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.
: 