Solar Forecast PV

Add-on Marketplace Bundles
, ,
163

Hey there,

I’m running openHAB 4.1.1 release build.
The “estimate” items stay ‘null’.
I use rrd4j as default persistance and installed InfluxDB additionally.
For rrd4j I don’t use a *.persist file. For InfluxDB I added a file like mentioned in the readme.

How do I get the estimate items running?

  • do I have to exclude them in a rrd4j.persist file?
  • does this only work with an api key?
  • do I have to upgrade to openHab 4.2.0?

@weymann Thank you for this binding! :v:

164

Hello @Felox,

they shouldn’t be ‘null’. In log, a time series update should be easy to find (timeseries keyword, multiline output):

Item 'FS_Energy_Estimate' updated timeseries [Entry[timestamp=2024-03-15T05:45:03Z, state=0 kWh], Entry[timestamp=2024-03-15T06:00:00Z, state=0.040999999999999995 kWh], Entry[timestamp=2024-03-15T07:00:00Z, state=0.709 kWh], Entry[timestamp=2024-03-15T08:00:00Z, state=2.055 kWh], Entry[timestamp=2024-03-15T09:00:00Z, state=4.009 kWh], Entry[timestamp=2024-03-15T10:00:00Z, state=6.404 kWh], Entry[timestamp=2024-03-15T11:00:00Z, state=9.317 kWh], Entry[timestamp=2024-03-15T12:00:00Z, state=12.780000000000001 kWh], Entry[timestamp=2024-03-15T13:00:00Z, state=15.782 kWh], Entry[timestamp=2024-03-15T14:00:00Z, state=18.028 kWh], Entry[timestamp=2024-03-15T15:00:00Z, state=19.772 kWh], Entry[timestamp=2024-03-15T16:00:00Z, state=20.776 kWh], Entry[timestamp=2024-03-15T17:00:00Z, state=21.238 kWh], Entry[timestamp=2024-03-15T17:37:46Z, state=21.317 kWh], Entry[timestamp=2024-03-16T05:42:49Z, state=0 kWh], Entry[timestamp=2024-03-16T06:00:00Z, state=0.074 kWh], Entry[timestamp=2024-03-16T07:00:00Z, state=0.977 kWh], Entry[timestamp=2024-03-16T08:00:00Z, state=2.7030000000000003 kWh], Entry[timestamp=2024-03-16T09:00:00Z, state=5.181 kWh], Entry[timestamp=2024-03-16T10:00:00Z, state=8.083 kWh], Entry[timestamp=2024-03-16T11:00:00Z, state=11.241 kWh], Entry[timestamp=2024-03-16T12:00:00Z, state=14.58 kWh], Entry[timestamp=2024-03-16T13:00:00Z, state=17.852 kWh], Entry[timestamp=2024-03-16T14:00:00Z, state=20.788 kWh], Entry[timestamp=2024-03-16T15:00:00Z, state=23.186 kWh], Entry[timestamp=2024-03-16T16:00:00Z, state=24.875 kWh], Entry[timestamp=2024-03-16T17:00:00Z, state=25.804000000000002 kWh], Entry[timestamp=2024-03-16T17:39:26Z, state=25.991 kWh]]
  1. no need to exclude at other persistence services
  2. at least for Forecast.Solar option, no API key is required
  3. OH4.1 is minimum for time series support: OH4.1 release notes

Time series can only be presented in MainUI Charts and 3rd party visualizers like Grafana, but not e.g. Charts in Basic UI. I gave an example of persistence/items configs in this thread.

  • Are you sure your forecast items are linked to InfluxDB persistence and write their data to that DB, e.g. via Group policy?
  • As a test, you might change default persistence to InfluxDB and let forecast items update?
  • Did you test timeseries with OpenWeatherMap, a released binding as functional reference?
  • What if you browse to a forecasted item in Main UI Administration GUI and select “Analyze”? It should present a Chart.
1 Like
165

I have also seen the “null” when I created a new item and linked to channel.
I think you need to wait 1h or 2h until next update. Depends on your refresh setting.

FYI if you already have InfluxDB then it’s fine. I’m using now “In Memory” persistence. This is easy to setup and no need for additional/external tools:

image
image1237×841 47.8 KB

“In Memory” does not support “Restore at Startup”. But to show future values this is not needed in my opinion. I’m happy with it :slight_smile:

Configuration “In Memory”:

image
image857×495 29.1 KB

Then create a chart in MainUI and make this setting:
image

3 Likes
166

Hi @cwi,
I’ve checked my Items and now, they have a value but until now no forecast (no future values)

Seems like I meet the requirements you listed.

Yes I’ve bookmarked your example already. :sweat_smile:
As you created two groups I was unsure if this is because you do all your persisting with influxdb or to exclude the forecast from default. Thanks for clarification!

While I answere @michaeljoos hinted that I maybe have to wait a couple of hours to get the updates. Thank you! As the items are not null anymore, this sounds plausible to me :+1:

@cwi for the completeness here the answers to your questions:

  • Yes forecast items are linked and receive (now) updates.
  • I did not change default persistence.
  • I did not test other bindings like OWM
  • Forecasted item graphs in MainUI are empty until now…

For the moment I will wait a bit more and let you know if it works later.

Thanks for your both envolvement!
Greethings Felox :smiley:

167

I don’t think you can see the forecast values in the item or item analyzer. Because:

I use rrd4j as default persistance and installed InfluxDB additionally.

Item analyzer uses rrd4j in your setup and rrd4j does not support future values.

Only way I could make the future values visible (with rrd4j as default persistence) was to create a new chart (pages), add a new grid and configure according above screenshot I have posted.

1 Like
168

Good news @cwi @michaeljoos,
It’s now working as expected.

Yes this works great!
A hint for future readers: I had to change the persistence service in the advanced settings to influxDB to get this working.

Thank you! :partying_face:

169

Hi all,

I’d like to use the forecast feature too. Yet I fail to set it up correctly. Here is what I did using OH 4.1:

  • install InMemory Persistence Service from OH Add-on Store
  • created the file conf/persistence/inmemory.persist
Strategies {
	default = forecast
}
Items {
	gInMemory* : strategy = forecast
}
  • created group item “gInMemory” of type String
  • added the bindings Raw_JSON Items to group “gInMemory”
  • created a new chart in the sitemap referencing group “gInMemory” and service=“inmemory”

So far so good, so errors in the logs. Still nothing is shown on the chart page. I’m still not clear how the timeseries is created from the bindings channels. What am I missing?

Thanks!

170

You need a 4.2 code base.

171

… oh, I see. Is it sufficient to drop the latest .jar into the addon folder or do I need to upgrade to 4.2M1?

172

As mentioned in previous posts I have succesfully implemented time series with future data using “In Memeory” persistence.

In below screenshot we can see:

Green = Forecast Energy
Yellow = Actual Energy (from Inverter, not Binding)

image
image621×559 35.1 KB

I’m not sure if people who use InfluxDB see the same thing, but there are strange values in the past. The day before and 2 days before are OK (in above screenshot March 16 & 17), but older dates are weird.

Is this what we are getting from Solcast (yes, I use Solcast and have not tested Forecast Solar) or is it a bug in the binding? Is there a way to not updating past values?

173

Using Forecast.Solar subservice and persisting in InfluxDBv1, I don’t see such effect.
Yet, on any new timeseries transmission, openhab log warns that InfluxDBv1 doesn’t support data removal: [rnal.influx1.InfluxDB1RepositoryImpl] - Removing data is not supported in InfluxDB v1. This appears both for SolarForecast and OpenWeatherMap timeseries transmissions. With this I suspect that timeseries in openHAB tries to “sync” persistence service with transmitted data? InMemory persistence specifically allows deletion (maxEntries). Your graph might show leftovers? What if you double or cut the maxEntries setting?

174

Hi.
Firstly I have to say that I really love this community! I have a new solar system (installed yesterday) and now I’m trying to figure out how to use it the best. My current plan is to charge the battery when the price is low during the night if the forecast for tomorrow show little chance of sun. So I had planned to spend hours fiddling around with weather forecasts, trying to calculate this myself. Ten minutes later I had found the forecast.solar site (had no idea there were specific sites for that), another ten minutes later I had found this binding and now I have values for tomorrow’s prognosis right in an item in my dear openHAB!

Two questions:

  1. I see the “Cannot find channel type: solarforecast:raw-channel” in my log. I saw it was mentioned above but no real explanation. Is this a problem?
  2. Is there any way of controlling when the refresh is done? I mean, I really only need it to refresh once a day, but if I input a refresh interval of 1440 minutes I doubt that it will refresh at a time that suits me.

I’m running openHAB 4.1.2 and the official binding version.

175

I see it too. It is irritating. But the binding still works nevertheless.

Yes that would be a problem. I simply let the binding set its own default polling interval (whatever that is I dont recall, and I dont worry about it). The default works just fine for me.

176

Yep, me too. It’s just that 47 out of 48 polls are completely wasted :joy:

177

I‘ve just noticed that Solcast has reduced the number of free requests/polls via API to 10. It would be nice to have an option to configure when the polls takes place. Thank you.

178

From where do you have this info? I have just logged into my Solcast account and see this:

image
image785×38 4.05 KB

179

In the past I also had 50 free requests per day. Now only 10, as you can see in the screenshot:

Solcast
Solcast1330×125 11.6 KB

180

grafik
grafik941×101 6.15 KB

That’s strange… I still got 50.

181

Yes, but:

You won’t have access to our other Live and Forecast products, and you’ll only be able to access data for one location (with up to two tilt/azimuth combinations at that location). You’ll be able to make up to 10 API requests per day. Our team will verify your location is residential, and may ask for proof that it’s your home.

Grrrr :rage:

Most probably they will change.

182

That would mean:

1x request for Solcast Site (Bridge)
1x request for Solcast PV Plane (Rooftop Resource Id)

Total 10 requests per day = Forecast Refresh Interval 5h ??? :frowning:

1 Like