Energi Data Service Binding [4.0.0.0;4.1.0.0)

Add-on Marketplace Bundles
1

logo

This binding integrates the Danish service Energi Data Service, making data available as:

  • Channels with current prices.
  • An advanced channel with future prices in JSON format.
  • Thing action for importing the prices directly into rules.

In this initial version, electricity prices are in focus, specifically the datasets Elspotprices and DatahubPricelist.

The binding is mainly targeting Denmark because of the tariffs and taxes provided which are specific to the Danish market and in currency DKK. However, spot prices can also be retrieved for other regions, for example Norway and Sweden.

Features

  • Optimized service calls: Spot prices are retrieved once per day and tariffs only upon expiry (usually months/years).
  • Error handing: Policies for retry strategies are in place to make sure data will be retrieved as soon as possible after failed calls. This includes exponential back-off with jitter.
  • Channel configuration for adding VAT to prices based on openHAB regional settings.
  • Grid company is selectable in configuration.
  • Pre-configured filters are included for all known grid companies.
  • Filters can be overridden by channel configuration.
  • Spot prices and all tariffs are supported.
  • Properties shows number of remaining calls as well as timestamp of last/next call.
  • Actions for getting prices and performing calculations.

Changelog

Version 0.1

  • Initial release

Version 0.2

  • Rename all channels
  • Remove VAT channel configuration (please use VAT transformation instead)

Version 0.3

  • Add grid company Midtfyns Elforsyning.

Version 0.4

  • Add grid company Sunds Net.

Version 0.5

  • Keep 24 hours of history in cache (previously 12).
4 Likes
2

I havnt got the time to test this atm. But I will for sure test this soon, as I have been looking for an easy way to get the spotprice.

Great work, Jacob.

1 Like
3

I made this post and another post for a 3.4 backport:

Unfortunately both my 3.4.2 production installation and 4.0 test/development installation sees the 3.4 version. I don’t know what I did wrong, but for 4.0 the JAR can be downloaded instead.

4

@wborn - can you spot what I might have done wrong since the 3.4 version appears in 4.0 as well rather than the version from this post?

5

The Maven ranges are a bit tricky, 4.0.0) also includes snapshots, that’s why I use 3.5.0) myself with JavaScript Scripting (Nashorn) [3.3.0;3.5.0)

1 Like
6

Thanks. I have changed it, but can’t test it right now. I’ll report back later how it turned out. :slight_smile:

7

The 3.4 version now disappeared from the list on a 4.0 system. But the 4.0 version doesn’t show either.

8

@rlkoshak - do you have an idea what could be the problem here, or maybe you know someone…? :slightly_smiling_face:

9

I’ve been using [4.0.0,) for my 4.x version rule templates. What you have here seems like it should work but :person_shrugging: , I’m not Maven expert.

The comment by @wborn might be telling. Maybe my approach includes the snapshots but your version would only include snapshots for 4.1.0 and above.

1 Like
10

That fixed it, thanks!

11

That won’t be considered as a valid range because it uses , instead of ; so it will show on any OH version.

12

I did some more testing and found that [4.0.0;) is not a valid range either.

It does consider micro versions as well, so what seems to work better is [4.0.0.0;4.1.0.0)
That allows for any snapshot/milestone build (and excludes 4.1.0 snapshots) but it becomes trickier to come up with a range whenever compatibility is lost after a certain date, milestone. :upside_down_face:

You can experiment with this like in the BundleVersionTest by adding a test like:

@Test
public void rangeTest() {
    String range = "[4.0.0.0;4.1.0.0)";
    
    assertThat(new BundleVersion("4.0.0").inRange(range), is(true));
    assertThat(new BundleVersion("4.0.0.M1").inRange(range), is(true));
    assertThat(new BundleVersion("4.0.0.RC1").inRange(range), is(true));
    assertThat(new BundleVersion("4.0.0.202201311711").inRange(range), is(true));
    
    assertThat(new BundleVersion("4.1.0").inRange(range), is(false));
    assertThat(new BundleVersion("4.1.0.M1").inRange(range), is(false));
    assertThat(new BundleVersion("4.1.0.RC1").inRange(range), is(false));
    assertThat(new BundleVersion("4.1.0.202307311711").inRange(range), is(false));
}
2 Likes
13

The binding has now been merged and will be included with openHAB 4.0.

14

Hi Jacob.

Does the binding have option for reduces taxes when having electrical heating?

15

If I understand your question correctly, there is no need for that. If you mean that when having electrical heating, you won’t have to pay electricity taxes at all, you can simply omit using the electricity-tax channel. I don’t have electrical heating myself, so I’m not into any specifics about “reduced taxes”, so probably you can clarify your question for a better answer. :slight_smile: From a binding perspective the answer is no, but there are probably still (better) ways to achieve what you want.

16

I have reduced tax (reduceret afgift).
I pay full tax of the first 4000kWh/year, due to having heatpump. Evey use above 4000kWh/year the price is 0,8øre/kWh.

Its quite a mess to deal with when trying to calculate the actual full price for one kWh. My electricity company do it by calculate with 333kWh a month for full tax, and then reduce the rest. But thats not really usefull when trying to calculate the price every hour.

17

Thanks for the clarification. Got it: Energi Data Service query

image
image1068Ă—194 21.6 KB

I can add this to the binding and expose it as a new channel.

Would you like to see the actual total prices, i.e. including electricity tax for the first 4000 kWh, and without when exceeded, for the rest of the year? Or how would like like to actually use/see it?

1 Like
18
  1. Priority.
    Finding an easy and simply way to expose the full price of the actual hour.

Some people in the family tends to think that electricity costs nothing, and I just pay the bill. So they´ll never know. Its time for me to show them the reality of life :grin: (I will still be paying the bill though :sweat_smile: )

  1. Priority
    I will extend this to show the total price of the actual hour, and the next two or three hours.

And then the advanced setup:
Adding my solar system and re-calculate everything depending on consumption and solar energy produced.

I already have my solar system added to openHAB, so I guess this is a matter of math… I really suck at using math in rules. So this is advanced because of that…

Its not a neasy task in Denmark due to the idiotic system and prices tasks and tarifs which different from company to company. Even inside the same company there can be different prices depending on the time of the day.

I´m connected to Cerius (net) and customer at Modstrøm. I have no idea about the full price of an hour. But I think it should be possible to find, somewhere. Modstrøm has different prices pr kWh depending on the time of the day, as far as I recall. (No wonder why I just close my eyes and pay the bill).

19

That requirement is pretty vague. :wink: The actual price of the hour depends on whether you have exceeded 4000 kWh in current year. The binding cannot know that, so you would need something additional.

For example you could buy a Pow-K+ module for your meter which can be integrated into openHAB through MQTT: Meter readings from Kamstrup Omnimeter with Pow-K+ | Jacob Laursen's techblog

Or you could get the same data from eloverblik.dk - but unfortunately there is no binding for that, so you would need to implement that yourself (might be possible through HTTP binding).

When you have your meter data available, you can set up some rules monitoring the year till date consumption. I would suggest to use a proxy item for your electricity tax. At the beginning of the year you can then set it to the state of the electricity-tax channel. When you reach 4000 kWh, you then set it to 0,008 (or the state of the new channel reduced-electricity-tax channel when I’ve had a chance to add it). This will be the value that will have affect until next year starts.

You can then create a group item representing the total price like described here:

For this group item, you simply include your new proxy item.

I’m sorry it’s not easy, but this is the only way I can think of that would show you the actual price.

20

Through my Fronius power meter, I allready got the data for consumption I need updated every second.

What I dont have is:
Something that collect the spotprice/kWh pr hour, (for DK2). Auto update at least once pr day.
The Tarifs from the net company.

I think thats what your binding does, right?

The price from the electricity company (spotprice+advance/kWH), I could use a proxy items for this.

Regarding taxes, I guess I have to decide wether to go for reduced or full. It seem impossible to add in advance, ofcouse.

And then “moms” :cold_face: