laursen
January 29, 2023, 2:26pm
4
I also recently found this service through AMS reader, and also for a moment considered writing a binding for it. However, for me to use that personally, we would also need to integrate some currency exchange service because prices are in Euro. See this issue I created for discussing these things in general:
opened 08:56PM - 07 Jan 23 UTC
enhancement
I'm creating this issue to start brainstorming ideas which may or may not grow i… nto something. For starters, I will share some unstructured thoughts, which could grow into something structured and potentially into something that could be designed and implemented.
Let me start out by sharing some links which can shed some light into where I'm coming from with this:
- https://github.com/openhab/openhab-addons/pull/13416#discussion_r980432359
- [Dishwasher price calculation automation](https://community.openhab.org/t/dishwasher-price-calculation-automation/139207)
- [Meter readings from Kamstrup Omnimeter with Pow-K+](https://techblog.vindvejr.dk/?p=523)
My initial need is integration to services providing future energy prices. After that, having these prices, I would like to be able to perform calculations. These calculations should be implemented once with a common interface, no matter from which service the prices were obtained. I wonder, from an architectural point of view, if this already means something is needed within openhab-core, since addons cannot depend on other addons? For example, core could provide some interfaces and calculations, while addons could integrate various API's implementing such interface.
Now really brainstorming/dreaming. For the dishwasher example, I logged energy consumption during our most frequently used program and manually mapped that into a timetable in a rule. Considering being able to select the last run specific program on some device (having an energy consumption channel which can be persisted) and map that into another timeslot to calculate the price of that, or having the ideal timeslot calculated automatically within some boundaries. I guess this is just a use-case for the price integrations and calculations and an application which should be built outside of openHAB itself, but just wanted to mention this, so that the parts needed for this could emerge.
I now also have almost real-time logging of the power consumption in my house (see third link above) provided a current power (W) as well as accumulated energy consumed (kWh). The accumulated value is updated once per hour, and current power is updated every 10 seconds. With this data I would like to be able to create a graph like this (screenshot from [AMS reader](https://github.com/gskjold/AmsToMqttBridge)):
For this some post-processing is needed, since I receive the kWh data like this:
```
2023-01-07 21:00:07.940 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Omnipower_Accumulated' changed from 14609.85 kWh to 14610.24 kWh
```
i.e. as totals, not hourly contributions. So (14610.24-14609.85) kWh = 0.39 kWh from this log example, which is shown as last bar on the graph above. I'm not sure what is the best approach for doing this, but again it would be nice with something consistent and reusable.
I will update this issue with additional thoughts and knowledge from all of you.
I'm currently considering providing a small binding fetching data from EnergiDataService which is a Danish service providing prices. Yesterday I was also able to receive the same prices from ENTSO-E, but in EUR. So this could reach a broader audience, but would additionally require integration to online currency exchange rates to have conversion to local currencies. Currency question: Do we have any kind of currency handling in openHAB?
Therefore, to start with something simpler, I ended up creating a binding for the Danish service Energi Data Service:
opened 11:46PM - 14 Jan 23 UTC
closed 04:16PM - 03 Jul 23 UTC
enhancement
In order to make data from [Energi Data Service](https://www.energidataservice.d… k/) easily accessible in openHAB, I would like to create an add-on implementing this [API](https://www.energidataservice.dk/guides/api-guides).
The first milestone will have focus on [Elspot Prices](https://www.energidataservice.dk/tso-electricity/Elspotprices) and add a channel being updated with the current electricity price (per kilowatt hour). This was immediately achieved when starting the work on this add-on today:
### Data Filters
Filters were based on https://github.com/MTrab/energidataservice/blob/master/custom_components/energidataservice/tariffs/energidataservice/chargeowners.py
They have all been optimized and tested, and issues based on findings were created in this repo.
## Plan
This is the public TODO (in headline form) in order to reach "MVP" and publish a pull request:
- [X] Expose future prices as advanced channel with JSON array (since I'm not aware of any neat way of doing this currently).
- [X] Implement smarter retry policy on failures (e.g. exponential backoff and jitter).
- [X] Add support for tariffs (dataset **DatahubPricelist**).
- [x] Provide pre-made filters for known grid companies.
- [x] Add channel configuration for overriding pre-made filters.
- [x] Add grid companies to option list.
- [x] Add channels for Energinet (TSO) tariffs.
- [x] Add action for calculating price for specified consumption in a period. See https://community.openhab.org/t/dishwasher-price-calculation-automation/139207.
- [x] Load/keep retrospective data, e.g. 12 hours back in time. This would make it possible to write rules giving feedback on price when an appliance has ended a program.
- [x] Documentation cleanup.
- [x] Code cleanup (and a few more unit tests).
# Status
Draft code is here (work in progress):
https://github.com/jlaur/openhab-addons/tree/14222-energidataservice/bundles/org.openhab.binding.energidataservice
## 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 call.
- Actions for getting prices and performing calculations.
## Testing
- [org.openhab.binding.energidataservice-4.0.0-SNAPSHOT.jar](https://drive.google.com/file/d/175bvVisUXeTT9OUo_GUw2va0nJ6Gr3Af/view?usp=sharing) (latest)
- [org.openhab.binding.energidataservice-3.4.2-SNAPSHOT.jar](https://drive.google.com/file/d/1uNi7JTGcRCDWcAzCOrwb9Lme_UauG2eD/view?usp=sharing) (backported 27.01.2023, last updated 08.02.2023 21:53)
## Screenshots
### Properties and Configuration
### Channels
### Channel configuration
### Total price
Related to openhab/openhab-core#3478
I have the same problem as you regarding how to model future prices. For now I’m providing a JSON channel with this data, so it can be parsed and used by rules/automations. Having 24 channels where each represents an hour seems very much like a work-around. Also it would be quite dynamic - each hour it’s rotated, so one channel will have a different meaning (e.g. 15:00 tomorrow, not 15:00 today, when we are past that point in time).
Having support for persisting future data (forecasts and prices for example) in core would be preferable. Some discussions, proposals and context here:
openhab:main ← altaroca:main
opened 04:01PM - 14 Jun 22 UTC
please refer to #844
this adds a method `BaseThingHandler.updateHistoricState (… ChannelUID channelUID, State state, ZonedDateTime dateTime)` and all logic to route the corresponding `ItemHistoricStateEvent` through the core to the persistence layer and any `ModifiablePersistenceService`.
I have tested it using my [fork](https://github.com/altaroca/openhab-addons/tree/E3DC) of the E3DC binding and influxdb modified to implement `ModifiablePersistenceService`.
I made some choices for simplicity sake:
- the item current state and its historic state only meet in the persistence. Thus the historic state (even if younger) does not affect the current state.
- the events are separate but share the same publication topic
See also this post:
Hello,
I have been eager to get real time information on Danish electricity prices into Openhab for potential automation - inspired by this Rest-API setup in openhab . In Denmark it is possible to create an account into https://watts.dk/ for example and use their app to see both real time electricity prices (for your concrete electricity meter) as well as 3 days delayed usage statistics. This is nice if you can remember to check if you should start the washing machine now or set it for 3 hours l…
I know I’m not answering your questions, but I hope adding this additional context can help you.
