Option to ignore issues from disabled automations and scripts

[Csontikka]

It would be helpful if Spook could offer a configuration option to ignore or skip issues related to disabled automations and scripts.

Many users temporarily disable automations or scripts when devices are offline or integrations are unavailable. In these cases, Spook still reports them as issues, which can be misleading and adds unnecessary noise to the Repairs dashboard.

Having the ability to exclude these from checks (either via a setting or as default behavior) would make it easier to manage temporary or intentional states without triggering unwanted warnings.

[frenck]

disable automations or scripts when devices are offline or integrations are unavailable.

But in that case an automation should still be valid?

I mean, I hear you, but even disabled, Home Assistant still loads and process the automation (it is the reason why they show up, Spook inspects runtime, not YAML files, meaning these are loaded things by Home Assistant).

Just because they are disabled, doesn't mean they shouldn't be valid?

../Frenck

[Csontikka]

Thanks for the response — I totally understand your point, and it makes perfect sense that Home Assistant still loads disabled automations and scripts into memory, so Spook can see and check them accordingly.

However, from a practical perspective, this can still be a bit inconvenient or noisy for users, because it basically leaves three options:

Either ignore the issue (which will eventually come back),

Or completely delete the automation/script — even if it’s only temporarily unused,

Or keep maintaining automations that are actually only meant for testing, development, or future use.

Maybe a compromise would be the introduction of an exclude list or some kind of persistent ignore mechanism. This could distinguish between temporary and permanent ignores — for example: “don’t check this until it’s re-enabled” vs. “I’ve excluded this on purpose.”
Of course, I realize this would require some form of config or management UI to track exclusions and allow reverting them — so it’s definitely not trivial.

Another idea — though this might be more on the HA side — would be to have a valid flag or status that tells Home Assistant not to load a given entity at all (script, automation, etc.).
That would be a much deeper architectural change and maybe not the right direction — just thinking out loud.

Anyway, I totally get your reasoning — just thinking about ways to make the UX a bit smoother for these kinds of edge cases.

And thanks for the super quick response, really appreciate it!

[Millio345]

Same issue here actually. I have quite a few sensors, switches, lights and media_players which are only available in christmas time. The related automations are disabled but spook throws up a lot of warnings; Or if there's another, better way of doing this, I'd love to hear about it as well

[andynash]

Another vote for this feature request, I have similar reasons as above e.g. Christmas, temporarily out of use devices, and another use case is a TV service we are not currently using but are likely to in the future.

I don't want to have to delete the automations that are dedicated to this service, or the triggers, conditions and actions that are included in other automations that are still in use so I have disabled automations, as well as individual triggers, conditions and actions sitting around.

They are correct, but currently out of use, and two settings, ig ore disabled automations, and ignore disabled automation elements (not sure of correct terminology) would prevent Spook repairs from being very noisy.

Most of my repairs at any one time are down to this, and it makes it hard to see the wood for the trees, so the legitimate repairs then also get missed, and therefore accumulate. My repairs section is a hot mess 😂

Otherwise, Spook has been really helpful!

[wolfspirituk]

I also think this would be a good idea - same reason - when I changed electricity supplier - I dropped their integration, but didn't want to lose the cost optimising code in case I go back in the future.