An automation can stop behaving after a device rename, a network change, a new integration, a timing adjustment or a sensor state that is no longer available. Recovery is safer when the first goal is to restore a known working path, not to rewrite the whole routine.
This Guide covers backups, rollback notes, staged tests and manual fallbacks for presence, climate and IR/RF workflows in Home Assistant. LinknLink gateways and sensors can be part of the path, but each device and service should be verified separately.
If you need support while recovering an automation, See the LinknLink Help Center for automation recovery steps.
What a Reliable Automation Recovery Plan Contains
Preserve evidence
Capture the last-good automation, entity IDs, logs and recent state changes before editing.
Test one layer
Separate trigger, condition, network and action checks so the actual failure is visible.
Keep control
Maintain a manual fallback and approval step while the automation is being restored.
Recovery is easier when the automation has a known last-good version, clear entity names, a bounded test and a manual path. The plan should identify whether the failure is caused by a trigger, condition, device state, network path or action service.
Before You Start
- Record the automation ID, alias, affected room and last known working time.
- Create or verify a current Home Assistant backup before removing an integration or changing entity IDs.
- List the presence, climate, light, IR and RF entities used by the automation.
- Keep a manual control path for the affected appliance or room.
- Avoid changing several integrations, helpers and delays in the same test.
- Prepare a read-only review or disabled draft before enabling a replacement rule.
Recover a Home Assistant Automation Without Guesswork
1. Describe the symptom
Write what changed, when it started and whether the failure is missing trigger, wrong condition or failed action.
2. Freeze unrelated edits
Pause other changes to the room so a new test can be tied to one known configuration.
3. Save the last-good state
Export or record the automation YAML, entity IDs, helper values and integration versions.
4. Check availability
Look for unavailable sensors, stale entities, renamed devices and missing services before changing logic.
5. Check the trigger
Change or reproduce the trigger with a harmless test and confirm the expected state transition.
6. Check conditions
Review time, area, presence, temperature, humidity, mode and helper conditions one by one.
7. Check the action service
Verify the target entity, service data, IR/RF command or native control path separately.
8. Check network context
Confirm local gateway, MQTT, Wi-Fi, Thread or other integration paths before resetting hardware.
9. Prepare a minimal fix
Ask for a proposed change that touches the smallest number of entities and preserves the old notes.
10. Test in disabled mode
Use traces or a preview to confirm the proposed path before enabling it in a real room.
11. Restore incrementally
Enable one bounded case, observe it through the expected delay and then add the next condition.
12. Document the fallback
Keep the manual action, rollback point and verification result in the automation description.
Example Prompts and What to Review
| Use case | Example request | Review before action |
|---|---|---|
| Missing trigger | The living-room presence automation stopped after a sensor rename. List the checks without deleting the old rule. | Entity ID, availability, area assignment and last-good version |
| IR recovery | The AC scene triggers but the appliance does not change. Prepare a separate trigger test and eRemote HA action test. | Trigger trace, IR target, command and manual remote |
| Rollback | Show the last automation change and prepare a rollback plan that keeps current backups intact. | Backup timestamp, changed fields, rollback file and approval |
| Helper issue | A vacancy helper remains on after the room is clear. Trace its inputs and prepare a disabled correction. | Source entity, delay, helper state and affected actions |
| Gateway check | Home Assistant cannot reach the local gateway. List network and service checks before re-pairing devices. | Gateway state, local address, logs and device availability |
| Manual fallback | Create a short manual-control note for the affected room while the automation is under review. | Switch, remote, scene and recovery owner |
Use Read, Prepare, Approve and Execute Stages
| Stage | Agent task | User control |
|---|---|---|
| Read | Inspect only the permitted source. | Choose the app, date range, room, folder or account. |
| Prepare | Extract entities and build a draft or proposed plan. | Check assumptions, missing information and affected resources. |
| Approve | Present the action and destination. | Confirm or revise before execution. |
| Execute | Run the supported action after approval. | Verify the result and keep a reversal path when possible. |
Review Checklist
- Is the symptom and first failure time recorded before edits?
- Is there a current backup or documented last-good version?
- Are changed entities and services listed by ID rather than only by display name?
- Was the trigger tested separately from the condition and action?
- Was the network or gateway path checked before hardware reset?
- Is the proposed fix limited to the smallest useful change?
- Does the automation remain disabled or reviewable until the test is approved?
- Is a manual fallback and rollback point still available?
Privacy, Permissions and Safer Defaults
Cross-app tasks can touch personal communications, calendars, files, photos, locations and household devices. Grant the smallest useful permission, keep unrelated data out of scope and avoid sharing credentials, passwords, one-time codes or private account details.
Use drafts for messages and attachments. Use scene previews for smart-home changes. Keep purchases, access control, security devices and destructive file actions behind explicit human confirmation.
Troubleshooting
The trace never starts
Check entity availability, trigger state changes and whether the automation is enabled in the expected mode.
The trigger runs but conditions fail
Inspect each condition value at the trigger time, including area, helper, time and presence state.
The action service is missing
Check renamed entities, integration reloads and service registration. Do not rebuild the entire automation first.
The gateway appears offline
Check local network reachability, gateway status, MQTT or integration logs and the manual device path before re-pairing.
Rollback creates duplicate entities
Restore the last-good configuration carefully and compare entity IDs before enabling a second version.
A fix works once but not twice
Observe the full delay and cooldown, then test repeated state transitions instead of relying on one successful run.
Related LinknLink Products
- HomeClaw: a local Home Assistant and AI gateway path.
- eMotion Ultra: 60GHz presence, climate context through its sensor cable, and built-in IR.
- eMotion Pro: 24GHz room presence and supported automation signals.
- eRemote HA: local IR control for compatible appliances in Home Assistant.
- eHome HA: IR/RF control and Home Assistant workflows.
Related LinknLink App and Home Assistant Guides
- LinknLink App Feature Guide
- LinknLink Mobile Agent First Action Guide
- LinknLink App Automation Guide
- LinknLink App Agent+ Diagnostics Guide
- Free Home Assistant Remote Access with the LinknLink App
Frequently Asked Questions
Why should I back up Home Assistant before changing an automation?
A backup provides a known recovery point if an integration, entity map or configuration edit produces a new problem.
What is a manual fallback?
It is a direct control path, such as a physical switch, remote or simple Home Assistant action, that remains available while automation is being repaired.
Should I reset a sensor when an automation fails?
Not immediately. Check state availability, entity IDs, logs, network and the action path first. Reset only when the failure is isolated and recovery is documented.
Can LinknLink gateways be part of a recovery plan?
Yes, when the relevant product and integration are supported. Verify the gateway path, entity state and command separately from the Home Assistant logic.
How can an Agent help with recovery?
A supported Agent workflow can summarize logs or prepare a bounded review. The user should approve configuration changes and keep the rollback path.
When is an automation ready to re-enable?
After the trigger, conditions and action have been tested in a limited case, the result has been verified and a rollback note remains available.
Keep the Last Good Version Visible
Write down the last working trigger, conditions and action before changing anything else. Then test one layer at a time and keep manual control available throughout the recovery.