aWATTar binding: Beta and discussion

Dear all,

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.

Dear all,

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.

Yours

Wolfgang

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.

1 Like

For aWATTar customers with discovergy smart meter: There is also a discovergy binding being developed currently, see Missing: A binding for Discovergy Smart Meters! :-) - #38 by Holger_Richter

Did not try it out yet, but the combination of both bindings should allow to provide a real time tracking of energy costs.

1 Like

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

Hi Matthias, thanks for testing the binding. I will check that.

Yours

Wolfgang

@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

In the Appenders section, define a new appender:

                <!-- Trace file appender -->
                <RollingFile fileName="${sys:openhab.logdir}/trace.log" filePattern="${sys:openhab.logdir}/trace.log.%i" name="TRACEFILE">
                        <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSS} [%-5.5p] [%-36.36c] - %m%n"/>
                        <Policies>
                                <OnStartupTriggeringPolicy/>
                                <SizeBasedTriggeringPolicy size="16 MB"/>
                        </Policies>
                </RollingFile>

In the Loggers section, add a new logger:

                <Logger level="trace" name="org.openhab.binding.awattar" additivity="false">
                        <AppenderRef ref="TRACEFILE"/>
                </Logger>

Upload the trace file here: Klimts private Cloud

Thank you. Will try and let you know the outcome.

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.

Can you also add east switch between Austria and Germany? Thanks!
Also strange behavior in VS Code:
grafik

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.

1 Like

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

Hoi @tailor09, this means you at least don’t need net and gross prices computed by the binding, correct?

Any other opinions?

Should the binding compute net and gross prices
  • Yes
  • No

0 voters

Hi Wolfgang,

Would you be so kind to explain to me how to install the .jar file in OpenHab 3? I’m completely new to Openhab (i come from Pimatic).

Edit: Never mind, i found it under Things :wink:

Hi @fregger65 , sorry for not answering earlier.

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

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.

Thanks and Bye

Hi @Quautiputzli,

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

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.

I will try.
Bye