rlkoshak
(Rich Koshak)
November 23, 2023, 2:29am
21
This issue is relevant to this discussion.
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?
STSC
(STSC)
November 23, 2023, 8:58pm
22
What is this timeseries stuff which comes in 4.1? A virtual persistence item what you can fill in a rule?
e.g.
virtualPersistenceItem = [ {“22.11.2023 21:50:00”, 32001}, {“23.11.2023 21:55:00”, 32005} ] ?
splatch
(Łukasz Dywicki)
November 23, 2023, 9:24pm
23
Pretty close: https://github.com/openhab/openhab-core/pull/3597 . Its a new thing to work with forecast, but as far I understand it is not limited only to that.
I failed adding decades (because it would require a lot of changes through out several components as decades isn’t something that is not supported by the underlying libraries) but I have added 3Y, 5Y and 10Y for the initial range of a dynamic period.
See
openhab:main
← stefan-hoehn:chart_period_extension
opened 04:14PM - 26 Nov 23 UTC
Allow further settings 3Y, 5Y, 10Y for dynamic period of chart.

Hope that helps a bit.
STSC
(STSC)
November 27, 2023, 4:19pm
26
This is what I was afraid of, but thanks for your efforts!
It seems that there will be a new InMemoryPersistenceService, this would be very very helpful.
I’m not 100% sure, but I think in the future functions like myItem.store(ZonedDateTime,State) can be used in rules for persistence items.
openhab:main
← J-N-K:inmemorypersistence
opened 05:54PM - 08 Jun 23 UTC
As discussed in https://github.com/openhab/openhab-core/pull/3597 sometimes a "s… hort-term" persistence service should be available. This adds a volatile persistence service (unfortunately using "volatile" is not possible because it can't be used in package names) with a configurable number of entries per item. When the maximum number of entries is reached, the earliest is removed. This makes it especially useful for storing forecasts and similar data that is populated at runtime and does not need to survive restarts.