Solar Forecast PV

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”:

  1. general forecast
  2. 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? :slight_smile:


i’m looking forward for this too, i’ve checked out the PR at and thought it was integrated there, as you’ve mentioned before, but thats not the case :confused:

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


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 :+1:

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.

See [inmemory] Default persistence strategy Forecast by mherwege · Pull Request #16496 · openhab/openhab-addons · GitHub


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