
Automations are the heart of Home Assistant. It is what makes Home Assistant a home automation platform. It is the glue that binds all the other integrations together, and it is what makes your home smart and comfortable.
Non-working automations, however, are a source of frustration. And sometimes, it can take you a bit to notice there is an issue with an automation. Spook enhances the automation integration of Home Assistant by raising repairs issues in case it detects something is wrong with an automation.

Figure 1:Spook found an issue with an automation that is using non-existing entities.
Devices & entities¶
Spook does not provide any new devices or entities for this integration.
Actions¶
Spook adds the following new actions to your Home Assistant instance:
Snooze¶
Turns an automation off for a while, and turns it back on when the time is up.
Action properties | |
|---|---|
Automation: Snooze 👻 | |
| |
Yes, | |
No response | |
Newly added action | |
Action data parameters | |||
|---|---|---|---|
Attribute | Type | Required | Default / Example |
| Yes |
|
Turning an automation off is the only way to make it stop for an hour, and an automation turned off stays off: past the restart, past the weekend, until somebody notices. The usual way around that is a helper entity and a second automation to turn the first one back on, which is two moving parts for something that should be one.
This is that, in one action. It survives a restart of Home Assistant, because the time it is due back is written down rather than left in a timer that dies with the process.
The other way round, holding one on for a while, is Turn on for.
Turning the automation back on yourself cancels the snooze. Saying so is a clearer statement of what you want than a wake-up time set earlier, so Spook takes it that way and forgets the rest.
Example actions in YAML
Quiet the doorbell for an hour:
1 2 3 4 5action: automation.snooze target: entity_id: automation.doorbell_announce data: duration: "01:00:00"
Everything in the bedroom, until the morning:
1 2 3 4 5action: automation.snooze target: area_id: bedroom data: duration: "08:00:00"
Known limitations
An automation that is already off is left alone, and Spook says so in the log. Waking it would turn on something you turned off, which is not what snoozing asks for.
Snoozing one that is already asleep moves its wake-up time rather than starting a second one.
The automation is off while it sleeps, so anything reading its state sees exactly that. There is no third state between on and off.
Turn on for¶
Turns an automation on for a while, and turns it back off when the time is up.
Action properties | |
|---|---|
Automation: Turn on for 👻 | |
| |
Yes, | |
No response | |
Newly added action | |
Action data parameters | |||
|---|---|---|---|
Attribute | Type | Required | Default / Example |
| Yes |
|
The other way round from Snooze, and the same trap in reverse: an automation turned on stays on, so “just for tonight” needs somebody to remember. Guest mode you switch on in December and find again in March, holiday lighting that outlives the holiday, a debug automation left running.
This is that, in one action, and it survives a restart of Home Assistant for the same reason: the time it is due back off is written down rather than left in a timer that dies with the process.
Turning the automation off yourself cancels the run, the same way turning one on cancels a snooze.
Example actions in YAML
Guest mode, for the weekend:
1 2 3 4 5action: automation.turn_on_for target: entity_id: automation.guest_mode data: duration: "48:00:00"
The party lighting, until the party is over:
1 2 3 4 5action: automation.turn_on_for target: entity_id: automation.disco_floor data: duration: "04:00:00"
Known limitations
An automation that is already on is left alone, and Spook says so in the log. Turning it off later would switch off something you switched on, which is not what this asks for.
Asking again for one already running moves the time it goes off rather than starting a second one.
The automation is on while it runs, so anything reading its state sees exactly that. There is no third state between on and off.
Repairs¶
While Spook is floating around in your Home Assistant instance, it will raise repairs issues if it has found something that is not right.
Unknown referenced areas¶
Automations are inspected for the use of areas. If an automation is targeting an area in one of its actions that do not exist, Spook will raise a repair issue. The repairs issue raised will contain the name of the automation and the area that is referenced but not found.

Figure 2:Spook found an issue with an automation that is using a non-existing area.
To resolve the raised issue, you can either remove the reference to the non-existing area or fix the referenced area. Spook will automatically remove the repair issue once the issue is fixed.
Unknown referenced devices¶
Automations are inspected for the use of devices. If an automation is using a device that does not exist, Spook will raise a repair issue. The repairs issue raised will contain the name of the automation and the device that is referenced but not found.
Only values shaped like a device ID are considered. Home Assistant hands those out itself and they are always thirty-two hexadecimal characters. Integrations are free to take a field called device_id meaning their own hardware, and some do: RFLink’s device_id is a protocol address. Those are not devices Home Assistant knows about and never will be, so Spook leaves them alone. A real device that was removed still leaves an ID of the right shape behind, so nothing worth finding is given up.

Figure 3:Spook found an issue with an automation that is using a non-existing device.
To resolve the raised issue, you can either remove the reference to the non-existing device or fix the referenced device. Spook will automatically remove the repair issue once the issue is fixed.
Unknown referenced entities¶
Automations are inspected for the use of entities. If an automation is using an entity ID that does not exist, Spook will raise a repair issue. The repairs issue raised will contain the name of the automation and the entity ID that is referenced but not found.

Figure 4:Spook found an issue with an automation that is using non-existing entities.
To resolve the raised issue, you can either remove the reference to the non-existing entity ID or fix the referenced entity ID. Spook will automatically remove the repair issue once the issue is fixed.
Unknown referenced actions¶
Automations are inspected for the use of actions. If an automation is using a action that does not exist, Spook will raise a repair issue. The repairs issue raised will contain the name of the automation and the action that is referenced but not found.
To resolve the raised issue, you can either remove the reference to the non-existing actions. Spook will automatically remove the repair issue once the issue is fixed.
Unknown referenced floors¶
Automations are inspected for the use of floors. If an automation is targeting a floor in one of its actions that does not exist, Spook will raise a repair issue. The repairs issue raised will contain the name of the automation and the floor that is referenced but not found.
To resolve the raised issue, you can either remove the reference to the non-existing floor or fix the referenced floor. Spook will automatically remove the repair issue once the issue is fixed.
Unknown referenced labels¶
Automations are inspected for the use of labels. If an automation is targeting a label that does not exist, Spook will raise a repair issue. The repairs issue raised will contain the name of the automation and the label that is referenced but not found.
To resolve the raised issue, you can either remove the reference to the non-existing label or fix the referenced label. Spook will automatically remove the repair issue once the issue is fixed.
Unknown referenced conditions¶
Automations are inspected for the conditions they use. Conditions are provided by integrations, so a condition that no installed integration can provide cannot be evaluated. An automation like that fails validation outright and becomes unavailable, which is why Spook deliberately inspects unavailable automations: they are the broken ones.
Home Assistant does notice, but it raises a generic issue about the automation. Spook names the exact conditions, which is the part you need in order to fix it.
This usually means the integration that provided the condition was removed. To resolve the raised issue, you can either remove the use of these conditions or restore the integration that provides them. Spook will automatically remove the repair issue once the issue is fixed.
Unknown referenced triggers¶
Automations are inspected for the triggers they use. Like conditions, triggers come from integrations, and if no installed integration can provide a trigger, the whole automation goes down with it: it fails validation and becomes unavailable.
So this is not a silent failure, it is a nameless one. Home Assistant raises a generic issue about the automation without saying which trigger caused it. Spook names the trigger.
To resolve the raised issue, you can either remove the use of these triggers or restore the integration that provides them. Spook will automatically remove the repair issue once the issue is fixed.
Feature requests, ideas, and support¶
If you have an idea on how to further enhance this integration, for example, by adding a new action, entity, or repairs detection; feel free to let us know in our discussion forums.
Are you stuck using these new features? Or maybe you’ve run into a bug? Please check the Support page on where to go for help.