API last polled x days ago

[kosymodo]

I'm getting a recurring issue whereby the integration is failing to poll the API for days at a time. This morning it was 'API last polled 4 days ago'. I can get around this by triggering a manual force update, but this depends on me noticing that the future forecasts are missing. Any ideas what I might do to troubleshoot why the API isn't being reliably polled?

[autoSteve]

Yep.

Post DEBUG level logs @kosymodo.

[kosymodo]

Thanks @autoSteve - is this just a case of enabling debug logging and posting the results once some logs have been created?

[autoSteve]

Pretty much.

#38 (comment)

Or give a bit more configuration detail and context and I'll try and crystal ball it.

[autoSteve]

But before you do that, is auto-update enabled? Or are you using an automation to call the service action for update?

Post your configuration, redacting any API keys.

Also include some context. Is this a recent "upgrade" from a much older version of this integration, maintained at the time by another? Or have you been running the BJReplay flavour for ages and this has only recently started happening?

[kosymodo]

Going off on a slight tangent now, bt do I need to adjust the '10' in the API limit field? I'll assume not, as it was working fine, and I guess behind the scenes it knows to split the 10 between the 2 arrays

[autoSteve]

The integration knows. 10 in the field, two sites = five auto-updates.

[kosymodo]

OK, so there's an abundance of these errors:

2025-09-02 09:04:09.564 ERROR (MainThread) [custom_components.solcast_solar.solcastapi] Client error: Cannot connect to host api.solcast.com.au:443 ssl:False [Timeout while contacting DNS servers]
2025-09-02 09:04:09.565 ERROR (MainThread) [custom_components.solcast_solar.solcastapi] Unexpected response received
2025-09-02 09:04:09.565 ERROR (MainThread) [custom_components.solcast_solar.solcastapi] No data was returned for forecasts
2025-09-02 09:04:09.565 ERROR (MainThread) [custom_components.solcast_solar.solcastapi] API did not return a json object. Returned None
2025-09-02 09:04:09.565 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] Forecast update for site b8e5-7a0e-7cfb-7ee3 failed so not getting remaining sites
2025-09-02 09:04:09.599 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] Forecast has not been updated, next auto update at 11:46:39

Definitely looks like DNS error, which could well be IPv6 DNS issues, like you said it might be ;) Next stop, disable IPv6 in HA networking and will see if that helps matters

[autoSteve]

Thank the Lords of Cobol that my crystal ball isn't broken...

Yeah, don't worry about DEBUG. You've got bigger fish to fry...

[gcoan]

Definitely looks like DNS error, which could well be IPv6 DNS issues, like you said it might be ;) Next stop, disable IPv6 in HA networking and will see if that helps matters

May not be your issue, but I find that if my internet connection goes down then HAOS really struggles to deal with that. Visible sign is that any external calls to REST services or to Solcast fail and I get similar logfile messages (if I remember to look).

Where it gets more weird is that with no external connectivity timesync gets itself very confused and I have seen HA sets the date/time to a random date in the future. This then causes problems with long term stats being written in the future and the HA 2FA doesn't work because the time is wrong!

The ONLY solution I have found when I get similar DNS errors is to shutdown everything, HA and all the addons and do a clean reboot. Just restarting HA or the supervisor doesn't fix it.
And yes, I have IP v6 disabled.

[autoSteve]

It's been a couple of days, @kosymodo. How's your network situation?

Did IPv6 bite you 🔮, and did disable it get the forecast flowing?

[autoSteve]

Another user needed to change their HA DNS settings to point to Google at 8.8.8.8 (or CloudFlare at 1.1.1.1) to resolve their dodgy networking, @kosymodo. I think their issue may have been dodgy DNS resolution / caching done by their router, but that is just a guess.

Yet another report of, "Nothing to do with the Solcast integration code", but a network issue.

There is actually an unresolved 'issue' logged against the aiohttp Python module which could be implicated. That is a desire for IPv4 fall-back should IPv6 turn to custard, which may be happening for you.

Just FYI.