as aWATTar (http://www.awattar.de/) customer I am now thinking of an aWATTar binding which fetches the daily prices and allows to turn on devices when electricity prices are low.
Besides the prices for the current and next day, the binding should provide switch things/items that turn on when the prices reach certain levels at a certain time of the day, such as:
the cheapest x hours between hour a and hour b, either consecutive or not.
all hours where the prices are lower / higher than a given limit
Is anybody already working on something like that? If yes, I maybe could offer some assistance. If not, I may find the time to start working on it.
update: I was working on the binding the last few days and expect to have a first test version available soon now. I will post an update here when it is ready for testing.
Please be aware that it will be an openHAB 3 version.
Finally, a first alpha version is available now. Feel free to try it out, but be prepared to find errors.
You can download the binding here:
A rough documentation can be found here:
I will add some more features in the next weeks and improve performance and code before opening a PR. Any suggestions are welcome. You may also already have a look at the code; as this is my first binding there are sure a lot of flaws, so if you find something that needs reworking I am glad to hear about it. Please be patient; although I am IT professional I would not call myself a Java Developer.
The binding needs openHAB 3. There are currently no plans to do a OH2.5 backport.
Hi Wolfgang,
thanks for the binding. Very usefull. But I run into an issue and not sure what the reason is.
At midnight the binding sets all its data to “UNDEF” or “NULL”. I use openhab3 on a Pi4.
Any ideas what is causing that?
Thanks and GrĂĽĂźe aus Bremen
Mathias
@MathiasK I think I found the reason. The binding did not take care of timezones, which may cause problems if the server it runs on uses a timezone different from CET (e.g. UTC). I changed that and uploaded a new version.
In case the problem is not solved with the new version, please enable tracing for the binding by adding the following definitions to /var/lib/openhab/etc/log4j2.xml
Found a bug in the bestprice logic for timespans covering midnight. Bug is fixed, please download the new version.
Besides that I am working on an additional feature: Determine the cheapest time within the next hours. I try to make this dynamically configurable over input channels, let’s see how it works out. Please be patient, it might take some time until it is ready for testing.
Hi @tailor09 , added the possibility to choose a country in the bridge definition. Did not yet look at the VS Code issue. To me it looks like VS Code shows only the channel labels, but not the labels of the surrounding channel groups, so you get the same four channels. 49 times.
We may open a discussion here: Is it helpful to deliver the four prices for every hour or would you prefer to only get the net market price and calculate the others in a rule or script according to your needs? If you opt for the 2nd version I am fine with that and remove the groups.
latest version works now perfectly for me. Sorry that I was not more specific in mentioning that the issue was with the bestprice thing only. At that that time I did not check if the prices worked after midnight. Thanks for the quick fix.
I would like to use the binding to find out which hours are the best of the day. During summer this may be during daytime. If the price is low my battery at home or car should be charged. This will be tricky as the time depends on battery size (kw). As example: does it take 4 hours or five? (Like go-echarger supports this)
I could also imagine switch on some power plugs if the price is below 0€ to mine cryptocurrency with outdated equipment
Did I get right that you solved the problem already? If not: Place the jar file in the “addons” directory of openHAB. For most installations, this should be
/usr/share/openhab/addons
Regarding prices: Please note that even if the net price drops below zero, it is very unlikely that the gross price ever will. In Germany the base price we have to pay for every kWh is around 20ct, so the net price would really have to drop heavily to make you earn money for consuming electric power. Partly this is caused by the Renewable Energy Contribution of around 6ct per kWh, so the situation in other countries might indeed be different.
One word regarding the planned extensions: Unfortunately I did not yet find the time to work on them and I doubt that this will change in the next days. So I have to ask you to stay patient (or start working on it yourselves )
Hi,
I found the link to your Binding on the german openhabforum. I will test it the text days. At the moment I do a similar thing with a python programm. But in openHAB it would be more comfortable.
It would be fine also to have the most expensive hours. I use my python to regulate my heatpump, an I have 4 options for this:
0 Heatpump locked (on the most expensive hour)
1 Heatpump reduced temp ( on the most 10 percent price range)
2 normal
3 Heatpump raised temp ( on the most 10 prcent cheapest price range)
If you can implement a thing “worstprice” in the same way like the pestprice we are able to lock the equipment in this hours.
I thought of this also in the beginning, but didn’t do it because I came to the conclusion that worstprice is basically nothing else than “NOT bestprice”. Hence I could work with a rule such as
when bestpriceitem receives command OFF
(pseudocode )
Let me check whether I got it right:
Most expensive hour:
logical NOT of a 23 hours non-consecutive bestprice range.
Reduced temp:
same, for 21 bestprice hours (how do you get to “10%” in your setup?)
normal:
none of the others
raised temp:
bestprice range
Ok, the advantage would be that no rules would be necessary to deal with worstprice hours. Is that what you mean?
Yes, your absolutely right. That’s the way to go. It’s so easy. As I see, I can use more bestprice things.
For the 10% I calculated the difference of the cheapest and the most expensive price. Then 10% of this difference minus the most expensive. This is the threshold. But your way with the number of hours I like better.