@jlikonen To help your guessing, you should be able to cleary distinguish those time series transmissions on items in openhab logs. Their data is spanning multiple lines, carrying multiple timestamps and values - in a single item update. In case those items are members of a proper forecast persistence profile, their data is automatically appearing in DB and read by visualization. No need for extra care.
As this is general time series support related, it applies to all forecasting options, incl. Solar Forecast and OpenWeatherMap.
Example single item update log:
2024-04-26 09:11:41.545 [INFO ] [hab.event.ItemTimeSeriesUpdatedEvent] - Item 'FS_Energy_Estimate' updated timeseries [Entry[timestamp=2024-04-26T04:14:13Z, state=0 kWh], Entry[timestamp=2024-04-26T05:00:00Z, state=0.358 kWh], Entry[timestamp=2024-04-26T06:00:00Z, state=1.653 kWh], Entry[timestamp=2024-04-26T07:00:00Z, state=3.6109999999999998 kWh], Entry[timestamp=2024-04-26T08:00:00Z, state=6.11 kWh], Entry[timestamp=2024-04-26T09:00:00Z, state=9.012 kWh], Entry[timestamp=2024-04-26T10:00:00Z, state=12.177 kWh], Entry[timestamp=2024-04-26T11:00:00Z, state=15.434000000000001 kWh], Entry[timestamp=2024-04-26T12:00:00Z, state=18.616 kWh], Entry[timestamp=2024-04-26T13:00:00Z, state=21.586 kWh], Entry[timestamp=2024-04-26T14:00:00Z, state=24.225 kWh], Entry[timestamp=2024-04-26T15:00:00Z, state=26.412999999999997 kWh], Entry[timestamp=2024-04-26T16:00:00Z, state=28.015 kWh], Entry[timestamp=2024-04-26T17:00:00Z, state=28.963 kWh], Entry[timestamp=2024-04-26T18:00:00Z, state=29.43 kWh], Entry[timestamp=2024-04-26T18:46:31Z, state=29.552 kWh], Entry[timestamp=2024-04-27T04:12:18Z, state=0 kWh], Entry[timestamp=2024-04-27T05:00:00Z, state=0.37 kWh], Entry[timestamp=2024-04-27T06:00:00Z, state=1.649 kWh], Entry[timestamp=2024-04-27T07:00:00Z, state=3.5700000000000003 kWh], Entry[timestamp=2024-04-27T08:00:00Z, state=6.031000000000001 kWh], Entry[timestamp=2024-04-27T09:00:00Z, state=8.904 kWh], Entry[timestamp=2024-04-27T10:00:00Z, state=12.036 kWh], Entry[timestamp=2024-04-27T11:00:00Z, state=15.257 kWh], Entry[timestamp=2024-04-27T12:00:00Z, state=18.402 kWh], Entry[timestamp=2024-04-27T13:00:00Z, state=21.336 kWh], Entry[timestamp=2024-04-27T14:00:00Z, state=23.924 kWh], Entry[timestamp=2024-04-27T15:00:00Z, state=26.027 kWh], Entry[timestamp=2024-04-27T16:00:00Z, state=27.526 kWh], Entry[timestamp=2024-04-27T17:00:00Z, state=28.403 kWh], Entry[timestamp=2024-04-27T18:00:00Z, state=28.839 kWh], Entry[timestamp=2024-04-27T18:48:08Z, state=28.957 kWh]]
The bridge cannot provide data without a fs-plane attached. The plane is configured with your photovoltaic parameters like kwp, declination and azimuth which is mandatory to calculate the forecast. Without an attached plane the brdige stays in state unknown.
So did you already attach a fs-plane to the bridge?
Ah, I see your confusion.
The item displays âonlyâ one number, this is right. But behind the item thereâs the TimeSeires with all future values. The display shows the number of the TimeSeires which fits to the current timestamp!
You can verify if TimeSeries is correctly in influxdb with the below rule.
Please note: historicState call is going to persistence (in your case influxdb) so if it runs fine all values are already stored correctly.
rule "Solcast Forecast"
when
System started // start manually, lot's of log output!
then
val solcastActions = getActions("solarforecast","solarforecast:sc-site:3cadcde4dc")
var query = ZonedDateTime.now.plusHours(1).withMinute(0).withSecond(0) // startpoint
val endPoint = solcastActions.getForecastEnd // latest forecast available
val duration = 30 // thirty minutes steps
// query TimesSeries items via historicState with future timestamps!
while(query.toInstant.isBefore(endPoint)) {
val pessimisticState = Solcast_Site_Pessimistic_Powerestimate.historicState(query).getState
val averageState = Solcast_Site_Average_Powerestimate.historicState(query).getState
val optimisticState = Solcast_Site_Optimistic_Powerestimate.historicState(query).getState
logInfo("TimesSeries HistoricState","{} : {} | {} | {}",query,pessimisticState,averageState,optimisticState)
query = query.plus(duration, ChronoUnit.MINUTES)
}
// query via RuleAction if you don't have influxdb
query = ZonedDateTime.now.plusHours(1).withMinute(0).withSecond(0)
while(query.toInstant.isBefore(endPoint)) {
val pessimisticState = solcastActions.getPower(query.toInstant, "pessimistic")
val averageState = solcastActions.getPower(query.toInstant)
val optimisticState = solcastActions.getPower(query.toInstant, "optimistic")
logInfo("SolcastActions","{} : {} | {} | {}",query,pessimisticState,averageState,optimisticState)
query = query.plus(duration, ChronoUnit.MINUTES)
}
end
I think itâs a permission/authentication error, but donât know whatâs wrong. Itâs still working at my sideâŠ
But like @weymann wrote, try using the forecast persistence. I had to use the latest snapshot to enable the timeseries options:
I just configured it, and it 's working fine!
Maybe 2 questions for @weymann:
with the previous version fo the binding (was still a 4.0.0 version), I also had a forecast for âtomorrowâ in the Solcast service, is it correct this is no longer the case?=> my bad, I just saw the rule in the readmeâŠ- the power estimates have the unit
W, but I store all my power data askW, so now my graph with my actual PV generation and estimates are looking weird (one on W and one in kW). Maybe this is just a UOM thing, but I canât figure it out.
No, there are no more items which are showing future predictions by default.
You can calculate the forecast for any day or even every timeframe via Actions.
Example for tomorrow forecast is in readme
My lovely UOM topic 
If you want another unit than default you need to configure the item. See readme items definition and change unit from W to kWh
Number:Power ForecastSolarHome_Power_Estimate "Power estimations" (influxdb) { channel="solarforecast:fs-site:homeSite:power-estimate", stateDescription=" "[ pattern="%.0f %unit%" ], unit="kWh" }
If kW makes more sense than W for this particular channel, itâs now possible to add a unit hint in the binding. See:
My rule failes on this line
val energyState = solarforecastActions.getDay(LocalDate.now.plusDays(1))
2024-04-26 11:14:24.006 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'forecast_solcast_tomorrow' failed: class org.openhab.binding.solarforecast.internal.actions.SolarForecastActions cannot be cast to class org.openhab.binding.solarforecast.internal.actions.SolarForecastActions (org.openhab.binding.solarforecast.internal.actions.SolarForecastActions is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @153f6b5; org.openhab.binding.solarforecast.internal.actions.SolarForecastActions is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @bc0a5a)
The content of solarforecastActions is org.openhab.binding.solarforecast.internal.actions.SolarForecastActions@1e40c32
I tried this, but apparently I had to wait a little bit longer before the changes were reflected.
Looks like two conflicting SolarForecast bindings are installed. Perhaps installed one via Marketplace and additional dropped one jar into addons folder?
If you deinstalled Marketplace binding please check folder /var/lib/openhab/marketplace/bundles if bundle is really deleted.
Thanks guys for your help. Persistence of forecast data into influxdb seems to be working now.
I just upgraded OH to 4.1.2 and realized, that I had to reinstall the Solar Forecast PV Add-On.
Now all my Channels from Solcast and Forecast Solare are gone. Also the Links to the items.
Any chance to get them back without doing it one by one?
I understand your words but Iâm unsure if i understand what youâre asking. Let me try to use pictures 
The bridge is unknown so I need the plane. But whatever data I add, the plane is erroring with http 400, but I cannot see anything wrong with my data:
And the bridge is stuck here:
Is there something obvious escaping me??
Edit: forgot to add that I went through this page:
https://doc.forecast.solar/api:misc
Tested my values without errors. Iâm probably doing something dumb but yeahâŠ
Hi, I tried that, but it still does not work.
Wirth 4.1 everything works. With 4.1.2 I had to reinstall the Add-On. But now it looks like that:
Hm, Iâm womdering why horizon is shown in your plane cpnfiguration without Show advanced checkbox activated.Are these really your values or did you just copy them from https://doc.forecast.solar/horizon?
Code 400 is described as invalid locaition. If you click on Map Symbol right to your location settings is your location correctly shown on the Map?
From pictures I see this is not the latest binding version. Which one did you install before? Maybe from Marketplace?
To be safe remove Marketplace Installation and simpy drop the latest jar into addons folder.
Yes to both questions.
Values are my own, and I used the map tool to pick my location. I even tried with the example values, same error 
I have a (partly related) question concerning the horizon angles: How is the angle of the roof included in the horizon? e.g. My actual South horizon is 0 degrees. I have a North-South roof with 30 degree pitches on both sides. So I assume that I should set the South horizon of the South part of the roof as 0 degrees, and the South horizon of the North part of the roof as 30 degrees? Or does the algorithm automatically adjust for the roof plane pitch? And its azimuth?
It actually is the actual jar binding. The one before was the marketplace binding, yes.
Or do I need OH 4.2 M2 for it?
Ok, to be sure letâs sync on version and dive down:
- If youâve installed binding from Marketplace please remove and replace it by the latest version from top post
- set loglevel to TRACE in openhab console via
log:set TRACE org.openhab.binding.solarforecast - first configure only the mandatory config fields without horizon which is an advanced and optional config parameter
Letâs see what the log is telling then.
Not at all. The config of your roof is already given with azimuth and declination.
The horizon is describing obstacles like big buildings, mountains or hills or nearby trees - nothing to do with your roof config.
Itâs up to the forecast service to calculate e.g. a high building on your west side is influencing your pv panels headed east with 45 deg declination
Iâm not sure if Iâm getting this right but I think youâre getting this wrong. For horizon forget your roof parameters! Imagine youâve a skywalk around your roof. Go around this skywalk and check which obstacles are located east, south, west, north - this is the horizon.
If youâve a tall building looking south you need to calculate how much degrees you need to look up to see clear sky. And thatâs the tricky part - this isnât easy and thatâs why itâs an advanced parameter and you should know what you do. Some hills in the surrounding will influence your horizon e.g. for some degrees but if youâve a skyscraper next to you it will cover the sun in this area.
You can go to PVGIS Tool to check which horizon is in the database for your location. This is the default horizon which is taken into account.
No
Ok, channel names changed during the official review. I think you still have the items but linkage isnât correct anymore. Sad but true you need to do the linkage one more time accoring to the readme examples. But Iâm close to finalize the official review and then the channels will not change anymore