Bringing electricity information from eloverblik.dk and energidataservice.dk into Openhab

Hi @laursen Thank you for your reply!
Indeed the following trigger and cron expression at midnight will work for me:

Channel 'energidataservice:service:energidataservice:electricity#price-event' triggered 'SPOT'

So the trigger will be available in 4.2 I assume? Looking forward to try it!

Blockquote
I think you can do all of this using Persistence Extensions. For example, you could use <item>.averageBetween(ZonedDateTime, ZonedDateTime) - example

I kind of need a time series of time series - in my uses case I keep avg prices between 17-21 in an item (group AVG function), and then I have a history of avg prices between 17-21 in the past days, I then compare if today/tomorrow is more/less expensive to the previous week (so avg of avg prices in the past 7 days). I think even with the time series support, I still need to persist the avg prices, or do I misunderstand how it works?

Many thanks for your help!

I wanted to check with you first that this solution would be viable. It seems so, so I will then publish the PR soon and would expect it to be included with 4.2.

In order to be able to access prices for the past 7 days, InMemory persistence will not be sufficient. The binding only fetches and publishes the last 24 hours. However, with another persistence service such as MySQL, you would be able to accomplish exactly that. Not only will it allow you to access the historic and future prices, but it can also calculate average prices for you within requested periods as shown in my example above.

Hi.
I’m looking for some advice on how to calculate if and when it’s a good idea to charge my house battery during the night, I hope this thread is a good place for that.

Currently I’m doing this at 22:00 every evening:

actions.calculateCheapestPeriod(now.toInstant(), now.plusHours(10).toInstant(), java.time.Duration.ofMinutes(60))

…and on the cheapest hour that I get back, I charge my battery (depending also on values returned from solarforecast). This often works very good, since the prices are higher in the morning, so the battery will be charged when the prices are at the lowest. Some days however the prices look something like this:


…which means I’m effectualy charging my battery at one price and then the prices get even lower the next hour. What do I do about this? I mean, I could of course ask for the lowest price the entire next day, but no matter which time period I chose I’ll be risking that the period will be ending with falling prices and the hours after it will be even cheaper. Am I thinking this wrong? How do you others do about things like this?

I think what I’m really trying to achieve is: Get the cheapest hour in this 10 hour period. But only if the hours directly after the period are more expensive. Guess that couldn’t be that hard to achieve…

Could the problem be as simple as this: You are looking for the cheapest hour within the next 10 hours (second argument in your rule), so at 22:00 you are only checking prices until 08:00 the next morning?

Yep, that’s correct. And as I said, this mostly works fine, but sometimes (like in the day in my screenshot) the price is going down after 08:00 which makes this problematic. Maybe I need to first check when it’s cheapest (like I’m already doing), then check the exact price for that hour and then check if that price is actually lower than the price between say 8 and 12 oclock…

I guess I don’t fully understand what you are trying to accomplish then. If you really want to find the cheapest hour, even if after 8:00 the next day, you should simply extend your search, e.g.:

actions.calculateCheapestPeriod(now.toInstant(), now.plusHours(24).toInstant(), java.time.Duration.ofMinutes(60))

I guess you also need to know how long time it takes to charge your battery, unless you can always do that within one hour?

Yep, ended up doing something like that. So it it’s even cheaper some time between 8:00 and 11:00 I’ll simply abort the rule completely. Hope this logic will hold.

It’s funny, I thought this would be something that everyone with a house battery would want to do, optimize things like night charging, but I struggle to find any good design patterns for it. Guess it differs so much from user to user that it would be hard to do…