WTH: Does ConfigEntryNotReady and PlatformNotReady not respect the integration quality scale and flood the logs

I love that as a developer we have the option of implementing the retry logic. However also as a developer we all try to abide by the Integration Quality Scale but this one core feature just loves to flood the logs. Why yes I do know my WLED lights are not online, but also the Neato cloud is down so you don’t need to flood me with that :slight_smile: Shouldn’t keeping a device in the unavailable state be good enough here? I know I can’t be the only one thinking this lol.

image

Was hoping this would get more traction :stuck_out_tongue: do people actually like their logs to be flooded? :thinking:

I think maybe the issue is that for a lot of people they only see this message when there’s a real problem so they don’t experience the constant logging problem, they just go to fix the issue when they see it.

I do have an example like yours though, just took me a sec to think of it - Roku. The outlet behind my TV turns on and off based on whether someone is in the room. If I happen to restart HA when the outlet is off then the Roku Integration really doesn’t like this and starts to freak out like what you’re showing. Ironically it doesn’t care if Roku disappears once it is up and running, only if its offline when I restart (and then just until it comes online again).

So yea I see your point here. Maybe there should just be one warning level log entry that the config entry or platform is not ready, one info level one when it is and all the ones in between should be debug level instead of warning level? Or use a persistent_notification to convey this message instead since that’s more visible then the log (plus people can dismiss it if they don’t care).

1 Like

I also very much dislike these errors flooding the logs. I had a WLED string fail, and ended up having to remove the integration until I could get a new string because of all the log spam. That felt like a bit of an extreme solution.

I have recently changed my deConz from using the add-on to running on its own Raspberry Pi. I had to unplug the pi during a thunderstorm recently (haven’t got it moved over to the UPS yet and my log was full of errors then too. Yes, I know it’s offline!

These seem like good ideas…

I just think it should behave like the integrations were designed. Neato for example we only print 1 error if your botvac is offline and then print again once online. There is no need to continue to tell people to plug in a device or remove an integration because HA wants to log all the errors for each and every retry attempt. Imagine having a WLED xmas light that you only plug in a certain time of the year. Do you really want ot pull that light out and connect it to keep the logs happy or to constantly remove it and add it back when you need to? I think that just having the device be unavailable is good enough to tell the user there is something wrong instead of repeated statements.

My point is basically if we expect the integrations to abide by a integration quality scale then core should be held to the same if not higher expectation.

1 Like

We should show the config entry state in the integrations UI and hide this log.

4 Likes