Solar Forecast PV

AndrewFG · May 1, 2024, 4:10pm

I understand what you say. But I seem to have the case where the binding thinks that my north facing solar plane was getting sun on it, even when the sun was physically below the ridge line of the roof. (note: winter in northern hemisphere)

weymann · May 1, 2024, 7:18pm

I see your point. Think I’ve a similar situation, one pv plane facing north-east the other total opposite south-west The picture with comparison NE vs SW is below.
I’ve the luxury to compare the forecast against my inverter measures.

There’s no way in yellow mark in the morning that my SW plane is getting direct sunlight.
But I get the measures from my inverter and it’s producing.
There’s no way in red mark in the late evening that my NE plane is getting direct sunlight.
Again the measures from inverter shows production.

I think this has to do with diffuse sunlight which hits your pv plane rather than direct sunlight. Maybe @Forecast.Solar who owns forecast.solar service and is member of the forum can elaborate on that.

KaFu · May 20, 2024, 8:39pm

Have you found a solution for this problem?

weymann · May 21, 2024, 9:11pm

What do you mean with solution?

As you can see from picture in previous post pretty much aligns with the forecast. If it doesn’t you’ve the possibility to tweak your forecast with advanced parameters like

damp factor
horizon

If it still doesn’t match the bindings will not do any corrections on the data provided by Solcast or forecast.solar

KaFu · May 21, 2024, 9:41pm

Sorry that I didn’t describe the problem in more detail.
I refer to a post 87 from June 2023:

Error in my log file:

> Script execution of rule with UID '037_Solcast-1' failed: An error occurred during the script execution: Could not invoke method: org.openhab.binding.solarforecast.internal.actions.SolarForecastActions.getPower(org.openhab.core.thing.binding.ThingActions,java.time.Instant,java.lang.String[]) on instance: null in 037_Solcast

Rule:

val solarforecastActions = getActions("solarforecast","solarforecast:sc-site:homeSite")

        // get power forecast in 1 hour
        var hourPlusOnePowerState = solarforecastActions.getPower(LocalDateTime.now.plusHours(1))
        //logInfo("SF Tests","Hour+1 power state: "+ hourPlusOnePowerState.toString)
        if (hourPlusOnePowerState instanceof Number) { SolcastHourPlusOnePowerState.sendCommand(hourPlusOnePowerState as Number) }

It worked for me too and suddenly stopped after an update.
Is anyone able to help me?

weymann · May 21, 2024, 10:45pm

Thanks for the details,

correct, Actions have changed during the review process so lets solve them step by step

First

Script execution of rule with UID ‘037_Solcast-1’ failed: An error occurred during the script execution: Could not invoke method: org.openhab.binding.solarforecast.internal.actions.SolarForecastActions.getPower(org.openhab.core.thing.binding.ThingActions,java.time.Instant,java.lang.String) on instance: null in 037_Solcast

Please assure solarforecastActions isn’t null, Maybe you’ve to restart your system with clean-cache

Second
You’ve to provide an Instant timestamp to get power

var hourPlusOnePowerState = solarforecastActions.getPower(ZonedDateTime.now.plusHours(1).toInstant)

After these changes it’s going to work

chill.kroete · June 21, 2024, 7:56pm

I have an issue with my JS rules. The following code:

        const solareForecastActions = actions.get('solarforecast', 'solarforecast:fs-site:homeSite');
        const forecastTomorrow = solareForecastActions.getDay(time.LocalDate.now().plusDays(1));
        items.getItem('SolarForecast_Energy_Tomorrow')?.postUpdate(forecastTomorrow);

leads to the following error:

2024-06-21 21:37:29.308 [WARN ] [e.automation.internal.RuleEngineImpl] - Failed to execute action: 1(Error: Failed to execute rule Solar-Forecast–Calculate-for-tomorrow-591b3a30-b1ff-41b9-980c-64281c026d29: TypeError: invokeMember (getDay) on org.openhab.binding.solarforecast.internal.actions.SolarForecastActions@16de93f failed due to: Cannot convert ‘[object Object]’(language: JavaScript, type: LocalDate) to Java type ‘java.time.LocalDate’: Value must have date and time information.: TypeError: invokeMember (getDay) on org.openhab.binding.solarforecast.internal.actions.SolarForecastActions@16de93f failed due to: Cannot convert ‘[object Object]’(language: JavaScript, type: LocalDate) to Java type ‘java.time.LocalDate’: Value must have date and time information.

So basically

Cannot convert ‘[object Object]’(language: JavaScript, type: LocalDate) to Java type ‘java.time.LocalDate’: Value must have date and time information.:

What can I do to make it work?

weymann · June 23, 2024, 3:54pm

Just checked with DSL and looks fine with LocalDate.now.plusDays(1).

    val tomorrow = solcastActions.getDay(LocalDate.now.plusDays(1))
    logInfo("EMS PRED Tomorrow","{}",tomorrow)

What is time.LocalDate in your rule below?

chill.kroete · June 24, 2024, 10:13am

Yeah, the examples are with DSL, I was not able to find a working example with JS based rules.
I assumed that time.LocalDate is the equivalent to the Java LocalDate, but it seems like this is not the case.

Other methods work fine in my JS rules like

const forecastPower = solareForecastActions.getPower(time.Instant.now().plusSeconds(60 * 60 * i));

weymann · June 24, 2024, 6:25pm

Right, same name but these are different objects! Looked at javascript binding and LocalDate doesn’t fit. While testing I faced some basic problems calculating the correct date.

This works on my side using js:

forecastTomorrow = solareForecastActions.getDay(time.convert(time.ZonedDateTime.now().plusDays(1)).toDate());

chill.kroete · June 24, 2024, 7:11pm

Thanks, that did the trick. What works now is this:

const forecastTomorrow = solareForecastActions.getDay(time.convert(time.ZonedDateTime.now().plusDays(1)).toDate());
items.getItem('SolarForecast_Energy_Tomorrow')?.postUpdate(forecastTomorrow.toString());

Although I have no idea on how I should’ve figured out this myself.

weymann · June 24, 2024, 9:11pm

Don’t worry, DateTime is a very sensitive topic => DateTime Conversion (openHAB 3.x)

Let me try to break it down

tomorrowDateTime = time.ZonedDateTime.now().plusDays(1); // tomorrow as js-joda
tomorrowDate = time.convert(tomorrowDateTime).toDate(); // convert to javascript date
forecastTomorrow = solareForecastActions.getDay(tomorrowDate);

time. is referring to js-joda library like described in javascript binding
tomorrowDateTime is exactly one day ahead as joda object
tomorrowDate is the conversion from js-joda to javascript date
use this tomorrowDate to query forecast for next day

DanielMalmgren · July 9, 2024, 8:57am

Hi.
For me the following code stopped working after upgrading to 4.2:

val solarforecastActions = getActions("solarforecast","solarforecast:fs-plane:0e8335fb8a:c056ab1541")
val forecastTomorrow = solarforecastActions.getDay(LocalDate.now.plusDays(1));

…my log just says:

 The method getDay(LocalDate) is undefined for the type ThingActions

When reading your conversation above (and also the examples in the binding documentation) I think that this should work, right? Is this something that changed in 4.2 (worked fine when running 4.0)?

edit: I think you can ignore this questions. Seems the binding wasn’t even installed any more, must have disappeared in the OH upgrade for some reason?

weymann · July 9, 2024, 5:19pm

Hard to say because to be bloody honest I don’t know exactly how the upgrade process works. But I know OH4.2 is the first official release containing the solarforecast binding. So either you placed a jar in addons folder or you installed it via Marketplace before.
I propose to double check - delete jar from addons folder if it’s in and check Marketplace installations and remove. After check/cleanup install official approved binding.

DanielMalmgren · July 9, 2024, 6:51pm

Yep, you’re right, I had an old jar in there (according to the name made for 3.4). Guess OH 4.2 simply did ignore it as being too old. Simply deleted the file now, everything seems to work fine also after that. Thanks!

fmeili1 · August 3, 2024, 5:19pm

Since updating to OH 4.2.0 and re-installed the solarforecast binding it is not stable anymore (I’m using the free Solcast service).

It’s working for some hours and than the sc-site went to status “OFFLINE” and showing
"Exception during update: solarforecast:sc-plane:myhome:SolcastSolar_PV # Forecast invalid time range"
the sc-site to “ERROR:COMM” and showing
HTTP Status Code 429

Before I’ve updated from OH 4.1.3 to 4.2.0 the binding worked without issues.

The thing is defined via things file:

Bridge solarforecast:sc-site:myhome "SolcastSolar site" [ apiKey="..." ] {
  Thing sc-plane SolcastSolar_PV "SolcastSolar plane" [ resourceId="...", refreshInterval=120 ]
}

I’ve try to activate detailed logging with
log:set TRACE org.openhab.binding.solarforecast
but the only additional messages in the logfile are

[DEBUG] No PV plane defined yet
[TRACE] Get new forecast Expiration: 2024-08-03T17:13:44.022669174Z, Data: {}
[DEBUG] SolcastSolar plane PV Call https://api.solcast.com.au/rooftop_sites/.../estimated_actuals?format=jso
n failed 429

After disabling the sc-site and sc-plane for some hours and re-enable it, it works again for some hours and then the above error happens again (Forecast invalid time range).

Any ideas what may be the problem?

fmeili1 · August 4, 2024, 4:53pm

I’ve disabled the sc-site and sc-pane yesterday afternoon and re-enabled it this morning. It’s working again for now - curious how long it will take before I see the above error the next time.

I’ve enabled first the sc-site and 2 seconds later the sc-plane. The only logging information are the following two lines:

2024-08-04 08:02:15.794 [DEBUG] [solcast.handler.SolcastBridgeHandler] - No PV plane defined yet
2024-08-04 08:03:15.794 [TRACE] [.solcast.handler.SolcastPlaneHandler] - Get new forecast Expiration: 2024-08-04T15:02:18.756403794Z, Data: {}

I think the first line is because the sc-plane was still deactivated while I enable the sc-site. But I don’t know why the second line showing Data: {} - maybe it’s normal?!

I’ve just two items defined and for how, I can see correct data:

Number:Energy SolcastSolarForecast_energy "SolcastSolar forecast energy" <sun> (gSolar, gForecastSolarToday) {channel="solarforecast:sc-plane:myhome:SolcastSolar_PV:average#energy-today" }
Number:Power SolcastSolarForecast_power "SolcastSolar forecast power" <sun> (gSolar, gForecastSolarPower) {channel="solarforecast:sc-plane:myhome:SolcastSolar_PV:average#power-actual" }

fmeili1 · August 5, 2024, 1:31pm

OK, this morning the error looks a little bit different.

The sc-site still showing status “ONLINE” but the sc-plane showing “OFFLINE” with the error message “HTTP Status Code 429”.
This error indicates, that the rate limit has been reached for my current subscription level (I’m using the free hobbyist plan).
I’ve double checked the sc-plane settings and the “Forecast Refresh Interval” is set to 120 (minutes).

After double checked, it looks like Solcast changed the hobbyist plan to a limit of 10 API calls per day. Now I’ve changed my refresh rate to 150 minutes to stay below this limit to see if the error will not longer occur.

update:
I’ve got the same error (sc-site is ONLINE and sc-plane is OFFLINE with error HTTP 429) after setting it to 150 minutes and also to 180 minutes.

It only works for about 24h before it shows the error again.

Any ideas?

update 2:
After setting the interval to 5 hours (refreshInterval=300) it works and I don’t have any further errors. I have no idea why it does not work with shorter intervals, even if it should. My my situation 5h interval is good enough, so I’ll keep it like it is.

weymann · August 12, 2024, 3:19pm

Correct investigation, error 429 indicates throttling limit is reached. Double check this with logging in into your Solcast account. On the top you should see

how many calls are placed today
how many calls you have in total available

If you have the total calls available you’re able to caclculate your update rate.
Note that each time you stop/start things or bridges or you update configuration will result into destroying the objects and new initial calls are placed. So if the config is running - keep it running!

fmeili1 · August 12, 2024, 5:18pm

Thanks, great hint! I didn’t know about this indication on top of the page until now.

It looks like the free API is now limited to just 10 calls per day.

With just one plane I think I will stick with 5h (300 minutes) interval for my situation. This will also gives room for at lease one restart/reload scenario.

Thanks for clarification.