Okay, thanks! Still, I find it weird that the forecast does not even settle on a value after sunset.
thereâs basically two channel âtypesâ:
- general forecast
- actual forecast
your item seems to be one of the âgeneralâ ones. the general channel values differ as Andrew explained throughout the day because of fluctuations in overclouding or whatever. the actual channels also follow those fluctuations, but they fall gradually until sunset.
one channel/item is for comparisons based on âwhole dayâ-operations/rules, the other for âremaining dayâ operations.
for example: I use the âremainingâ-values for my rules to check, how much energy I can expect for the remaining day until sunset (e.g. can I turn on âluxury devicesâ without risking a low or empty battery over night). the âwhole dayâ-forecast is irrelevant in my case.
Hi Bernd, any news/ idea when an updated version of the add-on will be available, that supports the time-series feature of OH 4.1? 
Hey,
iâm looking forward for this too, iâve checked out the PR at https://github.com/openhab/openhab-addons/pull/13308 and thought it was integrated there, as youâve mentioned before, but thats not the case 
The update towards TimeSeries takes much more efforts than I thought! Itâs not working out of the box. See picture below of the OH 4.1 Release Notes. You need e.g. an influxdb to store future values - standard RRD4J will not do it. Due to this fact a graph for future values isnât provided also
So the OH4.1+ binding has channels
- power / energy estimate as TimerSeries - raw forecast data
- actual / remain / total data for todays forecast - interpolated
- rule actions for any timestamp / time period you want
When I use the example in the readme the things go online but the items are not updating. Anyone had this issue before?
openHAB 4.0.1
Release Build
@weymann I just updated from OH v4.1 to v4.2M1 and I find that the binding does not work any more. I suppose this is due to the new time series stuff. ?? During the OH update process I did not specifically load your new jar. So I am wondering if the OH update process did somehow change to your new jar without me actually doing anything?
EDIT: after further checking, it seems that with the upgrade from OH v4.1 to v4.2M1 the following things happenâŠ
- Yes, the new version of the Jar gets installed
- The prior existing things remain, but all of their channels are deleted
- Unfortunately the âsolutionâ is to delete and recreate all the things
- PS my issue was NOT due to the lack of persistence service, since I donât actually use such channels
@J-N-K is it correctly interpreted that persisting future values wonât work when you run rrd4j ?
Iâm struggling to infer that from the description in the Release Notes.
Given thatâs our default OH database itâs the most important that all bindings to make use of TimeSeries should work with, shouldnât they.
Do the openweathermap and Energi DS bindings work with rrd4j ?
Correct. RRD4J canât be used with timeseries because the databsse is not modifiable. In fact, for most cases where future values are useful (like prices / forecasts) the aggregation done by rrd databases would be a bad idea anyway.
1 Like
InMemoryPersistence would also be easy to use and it supports timeseries.
So whenever a user cannot or doesnât want to move over to some other default database, how would that need to be implemented in a real system?
We cannot use InMemDB for data we need to really persist, i.e. write to disk at some point in time to have graphs and statistics.
So we would need to configure to explicitly use InMemDB for those TimeSeries item(s) but keep rrd4j for the rest?
I vaguely remember there was a xxx.cfg file for every(?) active persistence db service that listed the items to get persisted by that service.
Is there any docs how that definition would work âgraphicallyâ in current OH 4.1 or .2 ?
OWM is a great example for new timeseries use. New persistence strategy forecast needs to be added to persistence config, e.g. for InfluxDB
Items {
gPersistInfluxDB* : strategy = everyUpdate //classic persistence of live data
gPersistInfluxDBforecast* : strategy = forecast,restoreOnStartup //forecast persistence
}
Items:
Number:Power FS_Power_Estimate "Leistung Vorhersage" (gPersistInfluxDBforecast) { channel="solarforecast:fs-site:haus:power-estimate", stateDescription=" "[ pattern="%.0f %unit%" ], unit="W" }
Number:Energy FS_Energy_Estimate "Energie Vorhersage" (gPersistInfluxDBforecast) { channel="solarforecast:fs-site:haus:energy-estimate", stateDescription=" "[ pattern="%.3f %unit%" ], unit="kWh" }
Number:Power FS_Power_Estimate_vorne "Vorne Leistung Vorhersage" (gPersistInfluxDBforecast) { channel="solarforecast:fs-plane:haus:PVvorne:power-estimate", stateDescription=" "[ pattern="%.0f %unit%" ], unit="W" }
Number:Energy FS_Energy_Estimate_vorne "Vorne Energie Vorhersage" (gPersistInfluxDBforecast) { channel="solarforecast:fs-plane:haus:PVvorne:energy-estimate", stateDescription=" "[ pattern="%.3f %unit%" ], unit="kWh" }
Number:Power FS_Power_Estimate_hinten "Hinten Leistung Vorhersage" (gPersistInfluxDBforecast) { channel="solarforecast:fs-plane:haus:PVhinten:power-estimate", stateDescription=" "[ pattern="%.0f %unit%" ], unit="W" }
Number:Energy FS_Energy_Estimate_hinten "Hinten Energie Vorhersage" (gPersistInfluxDBforecast) { channel="solarforecast:fs-plane:haus:PVhinten:energy-estimate", stateDescription=" "[ pattern="%.3f %unit%" ], unit="kWh" }
This works well in parallel to rrd4j (and others). Makes most sense for forecasting items, other items can be persisted the classic way to efficient rrd4j:
Number:Power FS_Actual_Power "Leistung gesamt jetzt [%,.1f %unit%]" (gPersistRrd4j) {channel="solarforecast:fs-site:haus:power-actual", stateDescription=" "[ pattern="%.0f %unit%" ], unit="W" }
Number:Power FS_Actual_Power_vorne "Leistung vorne jetzt [%,.1f %unit%]" (gPersistRrd4j) {channel="solarforecast:fs-plane:haus:PVvorne:power-actual", stateDescription=" "[ pattern="%.0f %unit%" ], unit="W" }
...
On single data reception, items of that forecast enabled group gPersistInfluxDBforecast write to future timecode in DB. Can be queried e.g. in Grafana, where you have full time range control. Sadly, OH-native ClassicUI Charts donât have that option (yet?). MainUI Charts can show it.
I have it working well for OWM and Solar Forecast - but need home net access and web browser to watch graphs.
1 Like
After migration to OH v4.2M1 I am seeing a pair of messages relating to the ârawâ channel for each of my three solar planesâŠ
2024-03-06 15:15:54.019 [WARN ] [re.thing.internal.ThingFactoryHelper] - Could not create channel 'raw', because channel type 'solarforecast:raw-channel' could not be found.
2024-03-06 15:15:54.044 [WARN ] [.thing.internal.GenericThingProvider] - Could not create channel 'raw' for thing 'solarforecast:fs-plane:g24:east', because channel type 'solarforecast:raw-channel' could not be found.
2024-03-06 15:15:54.057 [WARN ] [re.thing.internal.ThingFactoryHelper] - Could not create channel 'raw', because channel type 'solarforecast:raw-channel' could not be found.
2024-03-06 15:15:54.064 [WARN ] [.thing.internal.GenericThingProvider] - Could not create channel 'raw' for thing 'solarforecast:fs-plane:g24:north', because channel type 'solarforecast:raw-channel' could not be found.
2024-03-06 15:15:54.093 [WARN ] [re.thing.internal.ThingFactoryHelper] - Could not create channel 'raw', because channel type 'solarforecast:raw-channel' could not be found.
2024-03-06 15:15:54.102 [WARN ] [.thing.internal.GenericThingProvider] - Could not create channel 'raw' for thing 'solarforecast:fs-plane:g24:west', because channel type 'solarforecast:raw-channel' could not be found.
As @cwi linked the OWM docs, they explain how to setup persisting weather forecasts, but I guess they could probably be improved further.
For most cases, I guess a hybrid-persistence setup is the best solution. Use your existing persistence for historical values, and I would recommend InMemoryPersistence for forecasts, as I donât see benefit in having the weather forecast from three weeks ago storedâŠ
Exactly, see above.
In 4.2 snapshot or milestone, go to the settings menu, youâll find a new peristence entry there. On the new persistence config page, you can go to the add-on store to install additional persistence add-ons, and configure installed persistence add-ons. The persistence editor itself is relatively self-explaining if you know the concept of persistence (which you do I guess ;-)).
To store the forecasts, I would recommend to create a group for the OWM TimeSeries or Solar Forecast Items and use persistence strategy forecast when adding these groups to the InMemory (or Influx or any other persistence service with TimeSeries support) persistence config.
With Setup wizard add separate step for persistence by mherwege · Pull Request #2431 · openhab/openhab-webui · GitHub, we would introduce a separate step in the setup wizard to select persistence services from a recommended list (with rrd4j and mapdb the defaults). Should we add in memory persistence to this as well?
What speaks against this, is that in memory db does not have a default persistence strategy, so would still require more configuration. Would it harm to make persisting forecast a default strategy for in memory? I know about the concern for memory consumption, but I expect forecasts to be limited in volume. Most items would not persist forecast. I would think it is most relevant when setting up a weather service, which most starters would do.
AFAIK (but I may also be wrong), forecast persistence strategy should be used for TimeSeries Items, but it does not âfilterâ between TimeSeries and non-TimeSeries Items. Therefore I donât see a chance to preconfigure InMemory for forecasts, as we would need to know the Item names of the future created forecast Items.
There is only one exception: Depending on how much the wizard helps with OWM setup, it would probably also create items, and in this case it could create the required persistence config.
Whatâs the memory consumption for an item if there is no forecast? If that is 0, we could still allow it for all. Only items with forecast would see any memory being consumed. I will investigate a bit further.
Thatâs what Iâm not sure about. I donât know what forecast strategy does with normal Items. If it really does only persist TimeSeries Items we should be fine.
Well, fine that you will investigate it a bit further 
I tried with a debugger, two items, one getting a temperature forecast (time series) from openweathermap, one getting the current temperature. I added both items to the in memory persistence configuration with a strategy of forecast (and nothing else!). Only the time series got persisted. So this looks good. None time-series items will not take up any memory with an exclusive forecast persistence strategy. By default, the number of datapoints for a time series is also limited to 512.
2 Likes
I get following warning in OH 4.1.1
20:36:32.738 [WARN ] [core.internal.thing.ThingTypeResource] - Cannot find channel type: solarforecast:raw-channel
1 Like