Maintain forecasts through home assistant restart

[B-Hartley]

Is it possible for your integration to store and recall forecasts through a restart so I don't have to call update forecast again unnecessarily?

I guess I could store it into something raw like an input number. But would be easier if the integration could do it.

Thanks.

[dannerph]

How often are you restarting your Home Assistant 😄 ? I know, after an update it sometimes takes one or two restarts to get every integration fixed.

The issue with this integration is that it is designed as plattform, meaning there is one central mechanism that fetches the forecasts. After processing, the values are then set to the sensors. In this way I can handle API limits (centrally at one place). The RestoreEntity within Home Assistant can only be used within a sensor. As the sensor does not actively ask for an update but is feeded with updated values from the central mechanism, I cannot integrate this functionality in an easy way.

If you have an idea how to implement it, feel free to re-open the issue for discussion and/or provide a PR.

[B-Hartley]

I do re-start quite a lot as I'm still at the tinkering stage with home assistant and changing things a lot. Reloading rest sensors for example seems to duplicate them, so I often do a full restart.

I have it set to not auto update forecast, so I wouldn't expect it to be making API calls on a restart? Does it?

Also, I don't need history to be downloaded, I'm only interested in forecasts, so if any calls are being "wasted" on history, could I have the option to switch those off?

Thanks

[B-Hartley]

Could be a bit of a cludge. But could you write the api result out to json when received. Then you could read that back in if it was still “current” information. Or api wasn’t available ??

[dannerph]

Could be, but probably the better solution is to disable fetching at startup when disabled auto_fetching. Or the RsestoreEntity could be added and before fetching after restart, a check on all sensors, if the state hase been restored is done.

What do you think?

[dannerph]

I am also thinking to add a new sensor for "remaining API counts", might be useful for power users that do manuel fetching via automation

[B-Hartley]

Yes, ideally I wouldn't want any automated fetches if I've switched off auto_fetching. Restoring the entities at startup would be great, and a remaining API counts sensor would be a bonus. Out of interest, why is the default API allowance in your docs set to 10? I get 20 calls a day from Solcast ?

Do you make calls for forecast and for history ?

[dannerph]

I will try to find some time to implement the mentioned features:

• restore state using RestoreEntity
• remove fetching at start up when auto-fetching is disabled
• Sensor for remaining API counts

Solcast provides 10 API calls for researcher accounts and 20 API calls for hobbyist. I had a researcher account when writing this integration, default should be updated to 20 of course.

[B-Hartley]

ok, that all makes sense. Thanks for your work on this.

Regards, Bruce.

[dannerph]

By default forecast is fetched once per day and history depending on the configured API limit. So maybe also adding an option to turn off the automatic fetching of history then.

[B-Hartley]

that makes sense too. I'm not interested in the Solcast "history". If I turned the API limit down to 1, would it stop fethcing history then I could just manually call forecast when I wanted.

Thanks

[dannerph]

Should be working with newest version (I ran out of API calls for today, so I need to test it tomorrow :D)

[B-Hartley]

Hi, Have installed and tested. It seems to restore the main sensor value. But it isn't restoring the attributes, so the "tomorrow" attribute is null after a restart. Is it possible to make the attributes restore when the main sensor value restores?

Other than that it looks ok.

API count decreases when I call the service, I'm assuming it keeps it's own count resetting over night ?

[dannerph]

The RestoreEntity in the home assistant helper does not support attributes, as far as I understood. However, I already thought of splitting the forecast sensor in "today", "tomorrow" and "the day after tomorrow" sensor having the individual values as attributes, so that no infrormation is lost. (would be a breaking change)

Yes, there is no officially documented API to fetch the number of remaining API calls, so currently I use an internal counter. However i found this https://api.solcast.com.au/json/reply/GetUserDailyLimit call done by the webpage that I could use ...

[B-Hartley]

That's cool. I'd be very happy if you added those extra sensors for each forecast day. Keeping them as attributes of the main sensor to avoid the breaking change ?

The API Call to get the API calls remaining would be a bonus.

Thanks again for your work on this.