I probably shouldn’t have said “not replying”. It may very well be replying it’s just that the requested XML file doesn’t exist. Maybe 8:00 PM is some sort of downtime period when all of their files are being refreshed.
Or their service is momentarily overwhelmed by the number of incoming requests.
I’ve experienced this error before and it throws my dashboard display right off but doesn’t last long, I’ve reconfigured my Jinja macro to catch this and show nothing rather than a whole whack of ‘Unavailable’.
I saw this post earlier today but figured I’d wait until after 8:00 pm to see if the timing was right, I don’t have the error yet tonight. I’d actually always figured that the integration was just trying to grab the XML file at the exact same time as it was being updated/refreshed, never thought to check the actual time stamp for consistancy.
Thanks for pointing out this thread! Definitely curious about the regular timing.
I’ve been pondering a change to the integration that it would return cached data for some period of time (probably no more than an hour) when an error occurs. So instead of the error everything would continue working. Probably log a warning that cached data was used.
Could also add a new sensor to indicate cached data was provided.
Still some details to work out, but that’s the just of what I’m pondering.
Would that be useful? Should it even be done? What would you change?
I like the idea of cached data. That would stop the errors in the script that runs when the EC integration updates. I don’t see any value in adding a warning in the log but do see the benefits of a sensor.
Thanks for developing and maintaining the integration.
I’ve started to implement some ideas around what I’ve talked about. It’s such a simple feature but I’m on around my fifth iteration of ideas.
I’m still playing in the support library and haven’t done anything in HA yet.
Where I’m at at the moment is the previously successful update data is returned on an update failure. But only if the timestamp of the data is less than 2 hours old. Otherwise the regular exception will be raised as you’re seeing today.
When there is an error the error message is saved. I plan on exposing that in HA. Also a counter is increased by one to indicate cached data returned. The counter is reset on a successful update.
Quick clarification. The 2 hours is based on time that Environment Canada returns as the time the conditions are created. Also seen as a sensor already in HA.
Logging an error to HA if the timestamp exceeds 2 hours is a good solution in my view. I’d also like to see a time stamp entity that could be added to a dashboard. That entity should identified the date/time of the last “good” set of values.
As to the timestamp, it already exists and represents the time of the current conditions. I’m planning on using that timestamp when deciding to reuse existing conditions and forecast.
So it does, I was looking in the wrong place for it!
I have a set of scripts that pull data from Environment Canada and other sensors into a sensor that’s used for a display. I was looking at results of the script, not the EV sensor when I replied earlier. Thanks for the reminder. I’ll be adding that to my script.
Please reply on this thread if the fix is working for you.
What will not be in that release is a new sensor indicating cached data was returned and the last error message string. Since that is a feature it cannot go in a fix release. I will create a second PR for the new sensor. I hope to get it done in time to make the 2025.5.0 release.
You are a rock star, thank you so much for your work on this. Finally got the error last night at the prescribed time in my logs… it’s not consistant, but it is annoying.
