Troubliq

Smart-home fixes, step by step.

Blog

  • Home Assistant Automation Triggered but Action Did Not Run: Trace the Failure

    Home Assistant Automation Triggered but Action Did Not Run: Trace the Failure

    When a Home Assistant automation appears to trigger but the light, switch, or other device does nothing, the problem is often downstream of the trigger: a condition evaluates to false, the wrong entity is targeted, an action fails, or the integration cannot deliver the command. Diagnose the run before rebuilding the automation.

    1. Confirm that the automation actually ran

    Open Settings → Automations & scenes, select the automation, and inspect its traces. Open the latest trace that matches the time you expected it to run. If there is no trace, check the trigger first: confirm the entity ID, trigger type, required state, and any time or numeric threshold. For a state trigger, remember that the entity must make the configured transition; already being in the target state may not create a new transition.

    Official reference: Home Assistant automation troubleshooting and traces.

    2. Find the first step that did not behave as expected

    • Trigger did not fire: verify the entity ID and the exact state or event in Developer Tools → States and the trace timeline.
    • Condition failed: inspect each condition’s actual values at the time of the run. A time condition, presence condition, or numeric-state condition can block an otherwise valid trigger.
    • Action was skipped: inspect Choose, If/then, Repeat, and Wait steps. A branch may not match, or a wait may time out.
    • Action ran but nothing changed: confirm the target entity and service/action, then test the action manually using the same target.

    3. Test the target separately

    Check that the target entity still exists and is available. An entity renamed during a device or integration change can leave an automation pointing at an old ID. If the action targets a group, area, script, or scene, test that target independently. Avoid deleting and recreating devices until you have confirmed the actual failure.

    4. Check execution mode and overlapping runs

    If an automation is still waiting or running, its mode can affect what happens when another trigger arrives. Review the automation’s mode and any delay, wait, or long-running action. Do not change the mode blindly: single, restart, queued, and parallel have different behavior and the right choice depends on the task.

    5. Use a safe minimal test

    1. Duplicate the automation or save a copy before making major changes.
    2. Temporarily simplify the test to one known trigger and one harmless action.
    3. Run the trigger and inspect the trace.
    4. Add the original conditions and actions back one at a time until the failure returns.

    This isolates the failing step instead of changing several settings at once. If the trace shows that the action completed but the device did not respond, investigate the device integration or network rather than rewriting the trigger.

    Related troubleshooting

    If the automation is not starting at all, see our guide to Home Assistant automations that do not run. If a device is unavailable, use our smart-light disconnection checklist before rebuilding automations.

    Quick checklist

    • Latest trace exists and matches the expected time.
    • Trigger and conditions show the expected values.
    • Target entity exists and is available.
    • Action succeeds when tested independently.
    • Execution mode and waits suit the automation.

    Bottom line: the trace usually tells you whether the failure is the trigger, a condition, a branch, or the action itself. Fix the first failing step and retest before making broader changes.

  • Smart Lights Keep Disconnecting: Wi-Fi, Zigbee, and Matter Checks

    Smart Lights Keep Disconnecting: Wi-Fi, Zigbee, and Matter Checks

    Smart lights that repeatedly go offline may have unstable power, weak wireless coverage, a mesh-routing problem, or a protocol-specific configuration issue. First identify how the bulb connects: Wi-Fi, Zigbee, Matter over Wi-Fi, or Matter over Thread. The correct fix depends on that connection.

    Connected smart-home lighting and devices
    Check the light and its network path before resetting it.

    1. Identify the protocol

    Check the product label, manual, and Home Assistant integration. A Wi-Fi bulb joins your wireless network directly. A Zigbee bulb communicates through a Zigbee coordinator and may rely on other powered Zigbee devices as routers. Matter is an application standard, not a radio by itself: Matter devices can use Wi-Fi or Thread. Thread devices need a working Thread border router and matching network credentials.

    2. Rule out power interruptions

    Make sure a wall switch, smart switch, or power strip is not cutting power to the bulb. A smart bulb generally needs continuous power to remain connected. If several lights in one fixture disconnect together, check the fixture, switch, and circuit before troubleshooting each bulb separately.

    3. Check Wi-Fi lights

    • Check signal strength where the bulb is installed, not beside the router.
    • Verify the bulb’s required Wi-Fi band, security mode, and router settings in its manual.
    • Look for router reboots, DHCP address problems, or access-point roaming events that match the outage.
    • If only distant bulbs fail, improve coverage rather than changing every network setting at once.

    Do not disable router security or split/change network settings blindly. Make one controlled change and test whether it improves stability.

    4. Check Zigbee mesh health

    Confirm the coordinator is online and inspect the device’s availability and link-quality information if your integration provides it. Compatible mains-powered Zigbee plugs and bulbs can route messages, but battery-powered sensors generally do not. Add or reposition routers gradually and allow time for the mesh to settle.

    Some bulbs do not behave well as routers for certain devices. If failures began after adding a new bulb or router, test that change instead of rebuilding the whole network.

    5. Check Matter over Thread

    Confirm the Thread border router is online and that Home Assistant has access to the intended Thread network. Do not assume a Zigbee coordinator extends Thread coverage; Zigbee and Thread use different mesh networks even though both may use 2.4 GHz radio.

    6. Use logs and timing

    Note whether lights disconnect after a router restart, at a certain time, or only when switched off at the wall. Compare that timing with Home Assistant logs, router logs, and integration availability events. Update firmware or integrations only when there is a relevant fix, and change one variable at a time.

    When to re-pair

    Re-pair only after power, coordinator, coverage, and compatibility checks. Before removing a device, record its name and the automations that use it; a replacement entity ID can break routines. If several devices fail simultaneously, troubleshoot the shared router, coordinator, or power source first. For broader diagnostics, use our smart-home device-unavailable decision guide and the Zigbee offline troubleshooting guide.

  • Home Assistant Cannot Find a New Zigbee Device: Step-by-Step Fixes

    Home Assistant Cannot Find a New Zigbee Device: Step-by-Step Fixes

    When a new Zigbee sensor, plug, or switch will not appear in Home Assistant, the cause is usually pairing mode, coordinator connectivity, radio interference, or device compatibility. Work through these checks in order and avoid resetting your entire Zigbee network as a first step.

    Smart-home device used during Zigbee pairing troubleshooting
    Use the device manufacturer’s pairing instructions for the exact model.

    1. Confirm which Zigbee integration is running

    Open Settings → Devices & services and identify whether your network is managed by Zigbee Home Automation (ZHA) or Zigbee2MQTT. Confirm the integration is loaded and its coordinator is available. A device cannot join if the coordinator or add-on is stopped, disconnected, or pointing to the wrong serial device.

    Use one Zigbee network for pairing. Do not try to join the same device through ZHA and Zigbee2MQTT simultaneously; they manage separate networks and coordinators.

    2. Start discovery before activating pairing

    Open the integration’s add-device flow first, then put the device into pairing mode exactly as the manufacturer specifies. Some devices advertise for only a short time. A battery device may need its button held or tapped in a specific sequence; avoid guessing, because reset patterns vary by model.

    3. Pair close to the coordinator

    For initial setup, place the device a few feet from the coordinator if practical. If the coordinator is a USB stick, use a USB extension cable to move it away from the computer, USB 3 ports, external drives, and Wi-Fi access point. Metal cabinets and dense walls can weaken radio communication.

    If close pairing works but the device fails in its final location, investigate coverage and mesh routing rather than repeating factory resets.

    4. Check compatibility and firmware

    Search the official ZHA device database or Zigbee2MQTT supported-device list for the exact model and hardware revision. Some devices need newer integration versions or specific firmware, and some expose only part of their features. Confirm the device uses Zigbee rather than Wi-Fi, Bluetooth, or Thread; similar-looking products can use different protocols.

    5. Read the logs before retrying

    Look at the integration logs at the time of the failed join. A timeout suggests a different problem from a serial-port error or an unsupported-device message. If the coordinator itself is unavailable, solve that first; repeated device resets will not fix a disconnected radio.

    6. Retry safely

    1. Confirm the coordinator is online.
    2. Enable permit-join or start the add-device flow.
    3. Reset only the target device using its manual.
    4. Pair near the coordinator and wait for discovery to finish.
    5. Move the device to its intended location and check signal quality.

    Delete a stale device entry only after confirming it belongs to the device you are repairing. Do not erase coordinator data or rebuild the network unless logs and backups support that decision.

    If it still will not pair

    Record the exact model, integration (ZHA or Zigbee2MQTT), coordinator model and firmware, Home Assistant version, and the relevant log message. Those details are far more useful than a general “device not found” report and help narrow down compatibility, radio, or configuration problems. For related cases, see our ZHA pairing checklist and Zigbee2MQTT interview-failure guide.

  • Home Assistant Automation Does Not Run: Trace Triggers, Conditions, and Actions

    Home Assistant Automation Does Not Run: Trace Triggers, Conditions, and Actions

    A Home Assistant automation can look correct and still fail to run. The quickest way to find the cause is to test the three separate stages: trigger, conditions, and actions. Avoid deleting and recreating the automation until you know which stage is failing.

    1. Confirm the automation is enabled

    Open Settings → Automations & scenes and select the automation. Check that its enable switch is on. If it was recently edited, save it and confirm the displayed configuration reflects the latest changes. Also check whether Home Assistant was restarted or restored from a backup around the time the problem began.

    2. Open Traces before changing anything

    Open the automation and choose Traces. Select the latest run, if one exists. A trace shows which steps executed and where processing stopped. If there is no new trace when you expect the automation to fire, investigate the trigger first. If a trace exists but the sequence stops, inspect the conditions and action steps shown in that run.

    3. Test the trigger independently

    Check the exact entity ID and the event that should start the automation. A state trigger for a light turning on is not the same as a trigger for its brightness changing. Likewise, a numeric-state trigger fires when a value crosses the configured threshold; it does not necessarily fire simply because the entity is already above that value when the automation is loaded.

    • Open the triggering entity and confirm its current state and recent history.
    • Check that the entity ID has not changed after renaming or replacing a device.
    • For event, webhook, or device triggers, confirm the relevant event or device action is actually being received.
    • For time triggers, verify the configured time and Home Assistant’s time zone.

    4. Check every condition

    One false condition can prevent all actions from running even when the trigger worked. Look for conditions involving time windows, presence, numeric thresholds, device states, or templates. Compare the values in the trace with the values you expected at that moment. Pay particular attention to exact entity IDs and capitalization in templates.

    If several conditions are grouped together, remember that an ordinary condition sequence generally requires every condition in that sequence to pass. Test a suspected condition separately rather than removing all safeguards at once.

    5. Run the actions manually—carefully

    Use the automation’s action-run control only when it is safe to execute those actions immediately. Manual execution helps distinguish an action problem from a trigger problem, but it may not reproduce the original trigger variables or event data. A notification action might work manually while a template that depends on trigger data still fails during a real run.

    Check the target entity, service/action name, required fields, and any template output. For physical devices, avoid manually testing actions that could unlock doors, open gates, disable alarms, or operate appliances unsafely.

    6. Check logs and integrations

    If the trace points to an action failure, open Settings → System → Logs and look for errors at the same time. A temporarily unavailable integration, authentication problem, or device that no longer responds can make an action fail even when the automation logic is valid.

    7. Make one change, then retest

    Change only the setting identified by the evidence. Save the automation, reproduce the original trigger, and check the next trace. Changing several triggers and conditions together makes it harder to identify the real cause.

    Quick diagnosis

    • No trace: check enable state, trigger configuration, entity ID, and whether the event occurred.
    • Trace stops at a condition: inspect the condition’s actual inputs and expected values.
    • Action reports an error: inspect logs, target entity availability, and action data.
    • Manual run works but real trigger fails: compare trigger type, trigger variables, and conditions at the real event time.

    The key is to use the trace as evidence. In most cases, identifying the first stage that fails is faster and safer than rebuilding the entire automation.

    Official source: Home Assistant: Troubleshooting automations explains how traces help identify trigger, condition, and action failures.

    \n

    Review note: Checked against official documentation on October 19, 2026. This is a documentation-based guide, not a report of hands-on testing on a specific Home Assistant installation.

    \n

    Image credit: Unsplash, dada design.

  • Home Assistant Zigbee Devices Keep Going Offline After a Router or Wi‑Fi Change: What to Check

    Home Assistant Zigbee Devices Keep Going Offline After a Router or Wi‑Fi Change: What to Check

    Quick answer: A Wi‑Fi or router change can affect Zigbee reliability even though Zigbee and Wi‑Fi are different protocols. They share parts of the 2.4 GHz band, so channel overlap, a moved Home Assistant host, USB interference, or a changed power setup can expose a weak mesh. Diagnose one layer at a time instead of resetting every device.

    Smart home hub and connected home technology
    Image: James Yarema / Unsplash

    1. Identify what changed

    Write down whether the problem began immediately after replacing the router, changing Wi‑Fi channels, moving the Home Assistant computer, changing USB ports, or losing power. Note whether all Zigbee devices fail together or only battery-powered devices in one area. A simultaneous outage points toward the coordinator, integration, host or radio environment; isolated failures more often suggest routing, battery or signal issues.

    2. Check the Zigbee coordinator and integration

    • In Home Assistant, open the relevant integration (ZHA or Zigbee2MQTT) and confirm it is loaded and the coordinator is available.
    • Check the integration logs for serial-port errors, repeated reconnects, adapter resets or MQTT connection failures.
    • If the coordinator is USB-connected, check that its stable device path is still present and that the host has not moved it to a different port.
    • Use a USB extension cable to move the radio away from the computer, USB 3 devices and metal enclosures if interference is plausible.

    3. Consider Wi‑Fi and Zigbee channel overlap

    Do not change channels blindly. First record the current Zigbee channel and the router’s 2.4 GHz channel. Nearby networks, channel width and actual radio conditions matter. If you decide to change the Zigbee channel, check the documentation for your coordinator and integration first: some devices may need special handling or rejoining, and a channel change can create a second problem if done casually.

    4. Check the mesh before re-pairing

    Make sure mains-powered Zigbee routers—such as compatible smart plugs or bulbs—are powered and have had time to rejoin. A powered-off router can strand battery sensors that depended on it. Test a nearby device and a distant device separately. Replace a weak battery only when the evidence points to that device; do not delete devices from the entity registry just because they are temporarily unavailable.

    5. Verify recovery

    1. Make one change at a time.
    2. Watch the integration logs and device availability for several minutes.
    3. Test both a nearby and a distant device.
    4. Record the fix and any channel or coordinator changes.

    When to escalate

    If the coordinator repeatedly disconnects, capture the relevant log lines and identify your integration (ZHA or Zigbee2MQTT), coordinator model, host type and what changed before the outage. Avoid posting network keys or other secrets. Those details make the next diagnostic step much more reliable.

    Related guides: If Zigbee devices were already dropping offline, see the Zigbee offline diagnosis guide. If several kinds of Home Assistant devices are affected, start with the broader offline checklist. If the issue began after a power cut, use the power-outage recovery guide.

    Image credit: James Yarema on Unsplash. This guide is general troubleshooting advice; exact menus and options vary by Home Assistant version and coordinator.

  • Home Assistant Zigbee Devices Keep Dropping Offline: How to Find the Real Cause

    Home Assistant Zigbee Devices Keep Dropping Offline: How to Find the Real Cause

    When Zigbee sensors, plugs, or bulbs repeatedly show as unavailable in Home Assistant, the fastest fix is not always to re-pair everything. First determine whether the problem affects one device, a group of devices, or the entire Zigbee network. That pattern points toward very different causes.

    1. Check the scope before changing anything

    • One battery sensor: check its battery, physical location, and last-seen information.
    • Several devices in one room: suspect weak mesh coverage, interference, or a nearby router/repeater issue.
    • Most or all devices at once: inspect the coordinator, integration, host, and recent power or software changes.

    Write down which devices are affected and when they last responded. Avoid deleting devices or resetting the coordinator until you have this baseline.

    2. Check the integration and coordinator

    Open the relevant integration—ZHA or Zigbee2MQTT—and look for a disconnected coordinator, startup errors, serial-port errors, or repeated reconnects. If the whole network went offline after a Home Assistant restart, USB change, host reboot, or power outage, investigate that event first.

    For a USB coordinator, confirm that it still uses the expected device path. A changing device name can cause the integration to point at the wrong serial device. If you use a USB extension cable, check that the connection is secure and the coordinator is not pressed against the host computer.

    3. Reduce radio interference

    Zigbee operates in the 2.4 GHz band, which is shared with Wi-Fi and other devices. A coordinator plugged directly into a computer or placed beside a Wi-Fi access point, USB 3 device, or metal enclosure can experience interference. Try a good-quality USB extension cable and place the coordinator in open space, away from the host and router.

    Do not change Zigbee and Wi-Fi channels at random. Record the current channel and make one planned change at a time; changing channels can require some devices to reconnect or rebuild routes.

    Separate a radio problem from an integration problem

    If you use ZHA: check the ZHA integration status and its device or coordinator logs in Home Assistant. Confirm the configured radio path is the one currently exposed by your host.

    If you use Zigbee2MQTT: check both the Zigbee2MQTT frontend/log and the MQTT broker connection. A healthy MQTT connection does not prove the Zigbee coordinator is healthy, and a coordinator error is not fixed by changing an entity in Home Assistant.

    If only one device is missing: inspect that device’s battery, last-seen information, location, and recent pairing or reset history before changing the whole network. If many devices disappeared together, start with the coordinator, integration, power, or routers.

    For failures immediately following an outage, use the focused Zigbee power-outage recovery checklist. This article covers recurring dropouts across normal operation, not just post-outage recovery.

    4. Test the mesh before re-pairing

    Mains-powered Zigbee devices such as compatible smart plugs and dedicated repeaters can route traffic; most battery sensors do not. If devices at the edge of the home are unreliable, check whether there is a dependable router between them and the coordinator. Not every bulb is a good repeater, and some devices may behave poorly in mixed-vendor networks.

    Move a suspect battery sensor temporarily closer to the coordinator and allow time for it to wake and report. If it becomes reliable nearby but not in its normal location, coverage or routing is a stronger suspect than the sensor itself.

    5. Check batteries and device-specific behavior

    Battery devices often sleep to conserve power. Their displayed battery percentage may update infrequently, so do not rely on that number alone. Replace a genuinely weak battery with the correct type, inspect contacts, and trigger the device according to its manufacturer’s instructions. Avoid repeatedly pressing pairing or reset buttons unless you intend to rejoin the device.

    6. Use logs and change one variable at a time

    Review Home Assistant and integration logs around the time the device disappeared. Look for coordinator disconnects, failed message delivery, interview failures, or repeated device timeouts. Record the time, affected devices, and any recent changes. Test one adjustment, wait long enough to observe the network, and compare the result.

    When should you re-pair?

    Re-pairing is reasonable when a single device remains unreachable after battery, range, and network checks, or when logs show that it has left the network. Before doing so, confirm that you have any needed device details and understand the steps for your integration. Do not factory-reset the entire Zigbee network to fix one sensor.

    Quick checklist

    1. Determine whether one, nearby, or all devices are affected.
    2. Check coordinator and integration status.
    3. Review recent power, host, USB, and software changes.
    4. Improve coordinator placement and check interference.
    5. Test mesh coverage and the device battery.
    6. Review logs, then make one change at a time.

    Frequently asked questions

    Why do Zigbee devices become unavailable after a restart?

    Some devices need time to wake and report, but widespread failures can indicate a coordinator connection, serial-path, or integration startup problem. Check whether the coordinator is online before resetting devices.

    Should I change the Zigbee channel?

    Only after checking interference and documenting the current configuration. A channel change can have side effects, so follow the instructions for ZHA or Zigbee2MQTT and test deliberately.

    Does an unavailable device mean it is broken?

    No. It can indicate weak coverage, a sleeping battery device, interference, a routing issue, or a coordinator problem. Diagnose the pattern first.

    Image credit: Sebastian Scholz (Nuki) via Unsplash.

  • Home Assistant Devices Keep Going Offline: A Safe Troubleshooting Checklist

    Home Assistant Devices Keep Going Offline: A Safe Troubleshooting Checklist

    Smart home lighting and connected home devices
    Check the network path before resetting smart-home devices.

    If Home Assistant devices repeatedly become unavailable, do not start by deleting and re-pairing them. First find out whether the failure affects one device, one integration, an entire radio network, or Home Assistant itself. That distinction can save hours of rebuilding automations.

    1. Identify the scope of the outage

    • One device: check its battery, power, range, and recent physical changes.
    • Several devices on one protocol: inspect the Zigbee, Z-Wave, Thread, Wi-Fi, or Bluetooth network and its coordinator/router.
    • Devices from several integrations: check Home Assistant host health, network connectivity, and recent restarts.

    Record which entities are unavailable and when the problem began. Compare the timestamps rather than relying on memory.

    2. Check Home Assistant and the integration

    Open Settings → System → Repairs and review notifications. Then open the relevant integration and check whether it reports a setup or connection error. Review the log around the first failure; repeated errors after the outage may be symptoms, not the original cause.

    3. For Zigbee, check the coordinator and mesh

    This broad checklist helps identify which layer is failing; it is not a substitute for a protocol-specific recovery procedure. If the problem is specifically repeated Zigbee dropouts during normal use, follow the Zigbee dropout diagnosis. If the failure began immediately after power returned, use the power-outage recovery guide. Keep this page focused on identifying whether the issue is device-, protocol-, integration-, or host-wide.

    Confirm that the coordinator is powered and that the correct serial path is configured. If you use a USB radio, check whether a host restart changed device access or whether another process has taken control of the port. Powered Zigbee routers help extend the mesh; battery-powered sensors generally do not route traffic. After a power outage, give mains-powered routers time to rejoin before judging every sensor.

    4. For Wi-Fi devices, test the network first

    Check whether the device still appears in the router’s client list and whether its IP address changed. Review Wi-Fi signal, access-point restarts, DHCP reservations, and any recent network-name or password changes. Do not assign a static address inside the DHCP pool.

    5. Make one change at a time

    Restart only the affected integration when its logs point to an integration-level fault. Restarting the whole host can hide the evidence and interrupt unrelated devices. Avoid factory resets until power, connectivity, and integration setup have been checked.

    6. Verify the fix

    Watch the affected entity through several normal update cycles. Test the automation that depends on it, and check the log for fresh errors. If the device returns briefly and drops again, the underlying network or power problem may remain.

    Frequently asked questions

    Should I re-pair every unavailable device?

    No. Re-pair only when the device has genuinely lost its network membership or the integration’s documented recovery steps call for it.

    Why did everything go offline after a restart?

    Possible causes include a coordinator that did not reconnect, a changed device path, network startup timing, or an integration that failed to initialize. The logs and scope of the outage help separate them.

    What information helps diagnose the next step?

    Note the protocol, integration, device model, Home Assistant installation type, first error timestamp, and whether one device or many failed. Remove credentials and other private information before sharing logs.

    Image credit: Unsplash. This is a general troubleshooting guide; menu labels can vary by Home Assistant version and integration.

  • Zigbee Devices Unavailable After a Power Outage: Diagnose Before Re-Pairing

    Zigbee Devices Unavailable After a Power Outage: Diagnose Before Re-Pairing

    A Zigbee device that suddenly shows Unavailable in Home Assistant after a power outage is not necessarily broken. The outage may have restarted the coordinator, router devices, or the integration in a different order. Work through these checks before removing the device or rebuilding your Zigbee network.

    Smart home hub and bridge used in a Zigbee troubleshooting setup
    Start by checking the hub, coordinator, and network status before pairing devices again.

    1. Check whether the coordinator is online

    Open the integration you use—ZHA or Zigbee2MQTT—and confirm that it is loaded and connected. If you use a USB coordinator, check that Home Assistant can still see its serial device. A changed USB path, loose connection, or coordinator that did not restart cleanly can make many devices appear unavailable at once.

    • Check the integration status and its logs.
    • Confirm the coordinator is powered and connected.
    • If using USB, inspect the configured serial path and avoid unplugging it while the integration is running.
    • Do not change the channel or restore a backup as a first step.

    2. Look for a network-wide outage or one missing device

    If many Zigbee devices went unavailable together, investigate the coordinator, integration, or power to Zigbee routers first. If only one battery sensor is missing, its battery or radio link may be the problem. Mains-powered Zigbee bulbs and plugs often act as routers; if several are still off after the outage, battery devices may have lost their usual route through the mesh.

    3. Restore power in a sensible order

    Make sure the coordinator and the Zigbee integration are running, then restore power to any mains-powered Zigbee routers that were switched off. Give the mesh time to settle. Wake a battery-powered sensor using its normal button or wake procedure, if its manufacturer supports one. Avoid repeatedly restarting everything; that makes it harder to tell which change helped.

    4. Check logs before re-pairing

    In ZHA or Zigbee2MQTT, inspect recent logs for coordinator disconnects, serial-port errors, failed interviews, or repeated communication timeouts. These point to different causes. A serial error suggests a coordinator or connection issue; repeated timeouts for one device suggest a range, battery, interference, or routing issue.

    5. When should you re-pair the device?

    Only consider re-pairing after the coordinator is stable, the integration is healthy, the device has power, and the logs suggest that the device itself is no longer communicating. Removing a device too early can discard its entity associations and create unnecessary setup work. If you do need to pair again, follow the device manufacturer’s reset instructions and your integration’s pairing procedure.

    Quick diagnosis

    What you see Check first
    Many devices unavailable Coordinator, integration, and powered Zigbee routers
    One battery sensor unavailable Battery, wake procedure, range, and route
    Serial-port or adapter error USB connection, device path, and coordinator status
    Device returns after waking Battery-saving behavior and mesh reliability

    Frequently asked questions

    Will I lose my Zigbee devices if Home Assistant restarts?

    Usually, a normal restart should not require re-pairing. If devices remain unavailable, diagnose the coordinator, integration, power, and radio path before deleting anything.

    How long should I wait after power is restored?

    Allow the coordinator and integration to become stable and give the mesh a few minutes to recover. Battery-powered devices may need to wake or report in before their status updates.

    Bottom line: after a power outage, check the coordinator first, then the integration, powered routers, and individual devices. Re-pair only after those checks point to a device-specific problem.

  • Home Assistant Time Pattern Runs Every Hour Instead of Every 5 Minutes: Fix 5 vs /5

    Home Assistant Time Pattern Runs Every Hour Instead of Every 5 Minutes: Fix 5 vs /5

    Direct answer: If a Home Assistant Time Pattern automation runs once an hour when you expected it to run every few minutes, the most common mistake is entering a number such as 5 instead of an interval such as /5. In a Time Pattern trigger, 5 means the fifth minute of every hour; /5 means every five minutes.

    Smart home automation dashboard on a device
    Smart home thermostat and automation device

    The key difference: 5 versus /5

    Home Assistant’s Time Pattern trigger uses a slash to express an interval. That distinction is easy to miss in the visual editor and can produce an automation that appears broken even though the YAML is valid.

    Setting What it means Example
    5 A specific minute value Runs at 00:05, 01:05, 02:05…
    /5 Every five minutes Runs at 00:00, 00:05, 00:10…
    10 A specific minute value Runs at 00:10, 01:10, 02:10…
    /10 Every ten minutes Runs at 00:00, 00:10, 00:20…

    The same idea applies to seconds, hours, and days where those Time Pattern fields support a pattern value.

    Why the automation looks like it is “only running once an hour”

    Suppose you want to check a sensor every five minutes. You open the automation editor and set Minutes to 5. Home Assistant accepts the configuration because it is a valid time pattern, but you have told it to react when the clock reaches five minutes past the hour.

    The result is perfectly consistent:

    • 10:05 — runs
    • 11:05 — runs
    • 12:05 — runs
    • 12:10 — does not run
    • 12:15 — does not run

    That can look like a failed automation when the real problem is simply the meaning of the value.

    How to set “every 5 minutes” correctly

    1. Open Settings → Automations & scenes.
    2. Open the automation that is running at the wrong frequency.
    3. Find its Time pattern trigger.
    4. In the Minutes field, use /5, not 5.
    5. Save the automation.
    6. Watch the trigger activity to confirm that it reacts at the expected times.

    Home Assistant’s documentation specifically gives /5 as the pattern for running every five minutes and explains that a value without the slash represents an exact value.

    What if you want every 10 or 15 minutes?

    Use the same pattern:

    • /10 = every 10 minutes
    • /15 = every 15 minutes
    • /30 = every 30 minutes

    For evenly spaced intervals, choose a value that divides the hour cleanly. That makes the schedule predictable and easier to diagnose.

    Don’t confuse “every five minutes” with “at minute five”

    This is the most important distinction in this troubleshooting problem. A Time Pattern trigger is not asking, “How often should I run?” when you enter a plain number. It is matching a clock value.

    Think of it this way:

    5 asks: “Is the minute currently 5?”

    /5 asks: “Is this one of the five-minute intervals?”

    Check the other Time Pattern fields too

    If the automation still behaves incorrectly, inspect Hours, Days, and Seconds as well. A correct /5 minute pattern can still be restricted by another field.

    For example, if you specify an hour value as well as a minute pattern, the automation is no longer simply “every five minutes all day.” The additional time restriction becomes part of the trigger.

    Use traces to prove what happened

    Don’t rely only on whether a light or notification changed. Open the automation’s traces or trigger information and confirm when Home Assistant actually reacted.

    A trace is especially useful when the automation has several triggers or when the action itself has additional conditions. If the time trigger fires but the action does not happen, you may have moved beyond a trigger-frequency problem and into a condition or action problem.

    What if it runs at the right interval but the action still doesn’t happen?

    Then the Time Pattern may already be working correctly. Home Assistant evaluates conditions after a trigger fires. If a condition is false at that moment, the automation can stop before its actions execute.

    For example, an automation could check a temperature every five minutes but only turn on a fan when the temperature is above a threshold. The trigger can fire correctly at 12:00, 12:05, 12:10 and so on while the fan remains off because the condition is not met.

    What if you need to check something continuously?

    A Time Pattern trigger is useful when the requirement is genuinely periodic: check every five minutes, every ten minutes, and so forth.

    But if what you really want is “do something immediately when the value crosses a threshold,” a state or numeric-state trigger may be a better design. Polling every five minutes can introduce a delay and may miss the exact transition you care about.

    Quick diagnostic checklist

    1. Runs once per hour: check for a plain minute value such as 5.
    2. Should run every five minutes: change it to /5.
    3. Still doesn’t perform the action: inspect the trace for conditions that failed.
    4. Trigger never appears: check that the automation is enabled.
    5. Wrong clock time: check Home Assistant’s configured time zone.
    6. Multiple triggers: confirm another trigger is not changing the expected behavior.

    Example: a simple five-minute check

    If your goal is to periodically evaluate a condition, the important part of the automation is the time-pattern trigger. Conceptually, the schedule is:

    minutes: "/5"

    The trigger starts the automation at five-minute intervals. The conditions then decide whether the actions should actually run.

    When you should use a different trigger

    Use a Time Pattern trigger when you intentionally want periodic checks. Use an event, state, numeric-state, device, or other appropriate trigger when the automation should respond to a specific event as it happens.

    For example, “turn the light on when motion is detected” normally does not need a five-minute timer. “Check every five minutes whether the humidity is still above my threshold” is a much better fit for a periodic trigger plus a condition.

    Frequently asked questions

    Why does Home Assistant run my automation at 5 minutes past every hour?

    Check the Time Pattern trigger. A minute value of 5 means the fifth minute of each hour. It is different from /5, which means every five minutes.

    Does /5 mean exactly five minutes after the automation starts?

    No. It follows the clock pattern. It is an interval pattern based on the clock rather than a five-minute countdown that begins when the automation is enabled.

    Can I use /10 or /15?

    Yes. Those patterns represent ten-minute and fifteen-minute intervals respectively.

    Why does the trigger run but my device doesn’t change?

    Check the trace for conditions and actions. A trigger can fire correctly while a condition prevents the action or an action fails.

    Sources and testing note

    This guide was checked against Home Assistant’s current automation documentation on October 8, 2026. It is a documentation-based troubleshooting guide, not a claim of testing on a particular Home Assistant installation.

    Related Troubliq guides

  • Home Assistant Automation Runs Twice: Quick Trigger Checklist

    Home Assistant Automation Runs Twice: Quick Trigger Checklist

    Direct answer: If a Home Assistant automation runs twice, do not assume Home Assistant is randomly duplicating it. The usual causes are two triggers responding to the same event, a state trigger reacting to attribute changes, or a time trigger landing in a repeated clock hour. Start with the automation trace and identify the trigger that created each run before changing the automation. For the full step-by-step diagnosis, see the complete trace-based guide.

    What “runs twice” actually means

    First separate two different symptoms. If you see two traces starting almost together, the automation may have been triggered twice. If you see one run but an action happens twice, inspect the action itself, scripts it calls, or another automation that controls the same device. Those are different problems and need different fixes.

    1. Check the traces before editing anything

    1. Open Settings → Automations & scenes and select the automation.
    2. Open Traces and compare the two runs.
    3. Look at the trigger information and timestamps.
    4. Write down the entity, event, time trigger, or other trigger that started each run.

    Home Assistant’s current troubleshooting documentation recommends using traces to determine why an automation ran. Preserve that evidence before changing the trigger configuration.

    2. Look for two triggers responding to one change

    An automation can contain multiple triggers. Two of them may legitimately react to the same real-world change. For example, a device event can be accompanied by a state change, or two closely related event sources can both call the same automation.

    Compare the trigger that fired in each trace. If both traces point to different triggers, decide whether both are actually required. If only one trigger should start the workflow, remove the redundant trigger rather than adding delays or helpers to hide the duplicate.

    3. Check whether a state trigger is also reacting to attributes

    A state trigger can react when an entity’s attributes change, not only when its main state changes. A light may keep the same on state while brightness changes; a sensor can keep the same state while an attribute updates.

    If the automation should respond only to a particular state transition, make the trigger explicit with the appropriate From and/or To state. Home Assistant documents this as a common reason an automation appears to run more often than the visible state changes.

    4. Check time triggers and daylight-saving transitions

    If the duplicate happens at a clock time rather than immediately after a device change, check the time trigger. Home Assistant documents a special case when clocks move backward: a time that occurs during the repeated hour can occur twice that day.

    That is different from a permanently duplicated automation. If the behavior happens only on the daylight-saving transition, do not rewrite the automation simply to compensate for one repeated clock hour. Choose a time outside the affected hour when the job must occur exactly once.

    5. Check whether another automation or script is doing the same job

    Sometimes the automation is not actually running twice. A second automation, script, blueprint, device routine, or manufacturer cloud rule may control the same light, switch, scene, or notification.

    Search for other automations and scripts that reference the affected entity. Then test the target action with the smallest safe change. A duplicated notification is especially useful evidence: if the automation has one trace but the notification appears twice, the duplication may be downstream.

    6. Do not use the automation mode as the first “fix”

    Automation mode controls what happens when a new run starts while an existing run is still active. It does not, by itself, identify why two triggers occurred.

    • Single: a new run is not started while one is already running.
    • Restart: a new run stops the previous run and starts again.
    • Queued: new runs wait for earlier runs, subject to the configured limit.
    • Parallel: multiple runs can execute at the same time, subject to the configured limit.

    If your traces show two genuine triggers, changing the mode can change the symptom without removing the cause. Diagnose the trigger first.

    A safe diagnostic sequence

    1. Reproduce the duplicate once.
    2. Compare the two traces and record their trigger IDs or trigger descriptions.
    3. Identify whether the triggers are different or the same.
    4. If they are different, inspect whether both are necessary.
    5. If the trigger is a state trigger, check whether attribute changes are involved.
    6. If it is time-based, check the time zone and whether the duplicate matches a daylight-saving transition.
    7. Search for another automation, script, blueprint or device routine acting on the same target.
    8. Make one small change only.
    9. Reproduce the original condition and confirm the trace count and final device behavior.

    How to verify the fix

    Do not stop after seeing one successful run. Recreate the original trigger at least twice under normal conditions. Confirm that the expected automation trace appears once, the intended action happens once, and the target entity reaches the expected state.

    If the original problem was intermittent, leave the configuration unchanged long enough to cover the interval in which the duplicate normally appeared. Remove temporary test helpers or extra logging after the diagnosis.

    When the problem is not an automation duplicate

    If Home Assistant shows one trace but a device changes twice, look downstream. Check scripts called by the automation, scenes, other automations, device-side routines, and integrations that can independently issue commands. If the trace itself shows two starts, stay focused on triggers and timing first.

    Frequently asked questions

    Can a state trigger run twice without the device visibly turning on and off?

    Yes. Attribute changes can cause a state trigger to fire even when the displayed state remains the same, depending on how the trigger is configured.

    Should I change Single to Parallel?

    Not just because an automation appears to run twice. Mode changes affect concurrency; they do not explain the original trigger. Identify the duplicate trigger first.

    Why would a time automation run twice only once a year?

    A daylight-saving clock change can repeat an hour. Home Assistant documents that a time trigger scheduled during the repeated hour can therefore occur twice on that day.

    What is the fastest evidence to collect?

    Capture the two trace timestamps, the trigger that started each run, and the target entity or action that duplicated. That usually separates trigger duplication from downstream duplication quickly.

    Sources and testing note

    This guide was checked against Home Assistant’s current automation troubleshooting documentation on October 3, 2026. It is a documentation-based troubleshooting guide, not a report of hands-on testing on a particular Home Assistant installation.

    Related Troubliq guides