Direct answer: A SwitchBot Hub is not required for Home Assistant’s SwitchBot Bluetooth integration. If a device is missing, verify working Bluetooth coverage and check whether the Home Assistant Bluetooth adapter is in Active or Passive mode. Active mode supports local discovery; Passive mode requires synchronizing nearby devices through the SwitchBot account. Trigger pairing advertisements safely, confirm the device is not connected to another app, and use account import for encrypted-device keys when required.
Last reviewed: September 15, 2026. Applies to current Home Assistant installations using the official integration named below; menus can vary slightly by release and installation type.
Symptoms and scope
The device may never appear in discovered integrations, appear only intermittently, expose sensors but not controls, or remain unavailable after moving Home Assistant. Multiple identical models can also be confused if their Bluetooth addresses were not recorded. Discovery failure is not proof that a cloud hub is required.
Prerequisites and evidence to preserve
Identify the exact model, firmware, Bluetooth address when available, distance and obstructions to the nearest Home Assistant Bluetooth adapter or proxy, and whether the device is already linked to a SwitchBot account. Confirm Home Assistant’s Bluetooth integration itself is healthy before diagnosing one product.
Likely causes
1. No working Bluetooth adapter or proxy can hear the device reliably.
2. The device is not advertising until a button press or power cycle.
3. Home Assistant’s Bluetooth adapter is configured in Passive mode, which requires SwitchBot account synchronization instead of local discovery.
4. Encrypted device data requires a key imported from the account or entered securely.
5. The device is connected to another app, or two same-model devices were confused because their Bluetooth addresses were not verified.
Least-destructive diagnostic sequence
Step 1: Open the Bluetooth integration and verify at least one active adapter or proxy. Confirm other nearby Bluetooth devices are being received. If all Bluetooth devices disappeared together, repair the shared adapter path first.
Step 2: Move temporarily within reasonable range without permanently relocating equipment. Bluetooth uses low power and walls, metal enclosures, appliances, and USB interference can matter. A brief close-range discovery test distinguishes coverage from configuration.
Step 3: For devices with a physical button, follow the documented hold action to enter pairing mode. For devices without a button, power-cycle once to trigger advertising. Avoid repeated resets; advertising and factory reset are different operations.
Step 4: Wait through a realistic discovery interval and check discovered integrations. Record the Bluetooth address so identical devices can be distinguished. Do not add whichever same-model entry appears first without verification.
Step 5: Check the Bluetooth adapter’s Add mode. In Active mode, devices are normally discovered locally; if one remains missing, verify it is powered, in range, and not connected to another app. In Passive mode, local scanning cannot add devices directly, so synchronize nearby devices through the SwitchBot account.
Step 6: For encrypted models, use the supported account-import method where possible, or enter the key ID and encryption key only in Home Assistant’s secure setup interface. Never paste encryption keys into forums, screenshots, or chat.
Step 7: If using account synchronization, understand that SSO accounts such as Login with Google are not supported by the integration’s username-and-password flow according to the documentation. Do not weaken account security or reuse passwords to work around that limitation.
Step 8: After addition, verify several state updates and one safe command if the device supports control. Then move back to the intended location and confirm the signal path remains reliable.
Diagnostic asset: choose the next branch
Discovery decision tree: no Bluetooth devices visible means repair the adapter or proxy; an Active-mode adapter with only this device missing means trigger advertising, confirm support, and disconnect other apps; a Passive-mode adapter means synchronize the SwitchBot account; encrypted data without usable entities means import the correct key securely; discovery only at close range means improve Bluetooth proxy placement rather than resetting.
Deeper checks when the first sequence does not solve it
Begin with observation rather than removal. In Settings, Devices & services, open the integration entry and compare the integration status with individual entity states. Write down exactly what is unavailable, what remains responsive, and when the change began. This boundary prevents a narrow entity problem from being treated as a complete integration failure.
Check Settings, System, Repairs before changing configuration. A repair notice can describe a migration, deprecated behavior, reauthentication requirement, or duplicate-device correction more accurately than a generic entity state. Read the notice fully and record its wording before dismissing or applying it.
Use the device’s own local controls or official app as a comparison, but interpret that test carefully. A working vendor app may use a cloud path while Home Assistant uses the local network; conversely, a local device may work while its cloud account is unavailable. The comparison narrows the path but does not by itself identify the fault.
Build a short timeline from router events, Home Assistant updates, integration reloads, firmware changes, power interruptions, account changes, and the first failed automation. Correlation is not proof, but a reliable timeline tells you which evidence to inspect and which unrelated changes to leave alone.
Inspect diagnostics without publishing secrets. Useful evidence includes exact timestamps, sanitized error classes, addresses within your private network when appropriate, firmware versions, integration versions, and whether failures are continuous or intermittent. Remove tokens, cookies, serial numbers, email addresses, coordinates, and encryption material.
Change one variable at a time. After each change, repeat the same test and record the result. Simultaneously restarting the router, Home Assistant, bridges, and devices destroys the evidence needed to learn which action mattered and makes recurrence harder to prevent.
Prefer reload over restart when the integration supports it. Prefer reconfigure over delete-and-add when the host or account changed. Prefer a DHCP reservation over hard-coding addresses independently in several places. These choices preserve registry relationships and provide a simpler rollback.
Treat factory reset as recovery, not diagnosis. Before any reset, document pairings, automations, scenes, dashboards, entity IDs, network assignments, encryption keys, and manufacturer-specific recovery requirements. If those cannot be preserved, escalate before resetting.
When service returns, verify both directions: Home Assistant should read fresh state from the device, and a safe command from Home Assistant should be reflected by the device. Also confirm that a physical or vendor-app change is reported back to Home Assistant.
Test the real workflow, not only the device page. Trigger a representative automation in a controlled way, inspect its trace, confirm conditions and targets, and restore the previous state. A device can be healthy while an automation still points to an old entity.
Check recurrence across a normal operating period. Include at least one integration refresh, a DHCP lease check, or the next expected sensor update. For battery equipment, allow for its documented reporting interval instead of assuming silence means failure.
Create a rollback note containing the former value, new value, change time, and verification result. If the change worsens availability or creates duplicate entities, restore the known-good value before trying the next hypothesis.
Escalate with a compact evidence bundle when the problem survives safe local checks: model, firmware, Home Assistant version, integration name, sanitized first error, network topology relevant to the path, steps already attempted, and the smallest reliable reproduction. This gives maintainers actionable information without exposing the household.
Prevent recurrence by documenting address reservations, account ownership, update practices, backup location, integration-specific dependencies, and recovery contacts. Review these notes after router, firmware, or Home Assistant changes rather than waiting for the next outage.
Avoid unsupported certainty. An unavailable state describes a communication result, not necessarily a failed device. Power, privacy controls, address changes, authentication, sleeping behavior, rate limits, firmware, and network policy can create similar symptoms, so evidence must select the branch.
If the problem began immediately after an update, read the official integration documentation and current release notes before downgrading. A migration or renamed entity may be expected. Downgrades can introduce database incompatibility and should never be the first response to a single unavailable entity.
If several unrelated integrations fail together, stop device-specific troubleshooting. Check Home Assistant host health, DNS, time synchronization, network interfaces, Bluetooth or radio adapters, and upstream internet only where the affected integrations require it. Shared failures usually have a shared dependency.
If only one entity fails while sibling entities from the same device remain current, inspect whether it is disabled, unsupported, conditionally exposed, asleep, or dependent on a specific feature. Re-pairing the entire device is disproportionate until those possibilities are excluded.
Verification checklist
Confirm the integration reports loaded, the affected entities have current timestamps, state changes travel in both directions, and the original automation or dashboard works with the expected entity. Repeat the test after a normal reload. Do not declare success from a single momentary update.
Check that no duplicate device or replacement entity appeared. If a new entity ID was created, compare it with automations, scripts, scenes, dashboards, voice-assistant exposure, and history before removing or renaming anything.
Rollback and recovery
If the latest change made the system worse, restore the recorded prior address, option, entity reference, or integration configuration. Reload once and retest. If rollback cannot restore the known-good state, stop making changes, preserve logs, and use the evidence bundle described above.
Safety and privacy warning
Do not disassemble mains-powered SwitchBot products, defeat locks, or repeatedly operate motors against an obstruction. Account synchronization may share device identifiers and encryption material with Home Assistant; protect backups and diagnostic exports accordingly.
Prevention
Keep Home Assistant, the official integration, and device firmware within supported versions, but avoid changing all layers on the same day. Maintain a current backup, reserve stable network addresses where appropriate, label devices by MAC address, and review logs after planned maintenance.
Related Troubliq guides
Start with the Smart-Home Diagnostic Decision Tree, visit the category hub, and compare these related guides: esphome offline still on wifi, matter device unavailable home assistant, homekit device already paired home assistant.
Sources
Primary source: Home Assistant SwitchBot Bluetooth integration documentation. This guide synthesizes the official behavior into a conservative diagnostic order; it does not claim hands-on testing of every model or network.
Frequently asked diagnostic questions
Is a SwitchBot Hub required?
No. Home Assistant’s official SwitchBot Bluetooth documentation explicitly states that a hub is not required. What is required is working Bluetooth coverage from Home Assistant or a suitable proxy.
Why does power cycling sometimes help discovery?
Some devices advertise more actively after a button action or power cycle. This is different from factory reset and can make the device visible without erasing configuration.
What is passive mode?
Passive mode is a Home Assistant Bluetooth adapter setting, not a SwitchBot product type. With the adapter in Passive mode, devices cannot be added through local Bluetooth scanning and must be synchronized through the SwitchBot account while they are within Bluetooth range.
Why would an encryption key be needed?
Some SwitchBot device types encrypt Bluetooth data. Home Assistant needs the correct key ID and encryption key, imported through the supported account route or entered securely.
Can I use Login with Google for synchronization?
The documented integration login flow does not support SSO accounts such as Login with Google. Do not weaken security or share credentials to work around it.
How do I distinguish two identical devices?
Record and compare their Bluetooth MAC addresses, trigger one device at a time, and verify a physical state change. Names and model numbers alone are not sufficient.
Final verification record
Record the date, Home Assistant version, device firmware, integration status, entity IDs checked, commands tested, state-update interval observed, and any network or account change that solved the failure. This record turns today’s repair into a faster and safer response if the symptom returns.
What not to do
Do not respond to an unavailable state by deleting every related device, clearing registries, changing several network rules, or restoring an old backup without first proving the scope. Those actions can create duplicate entities, break historical continuity, invalidate automation targets, and erase the best evidence. Do not follow screenshots from older releases when the current official integration flow differs.
Avoid disabling firewalls, privacy controls, encryption, account protections, or electrical safety features as a test. A safer test is narrow, timed, documented, and reversible. If a proposed action cannot be rolled back or its effect is unclear, collect diagnostics and escalate instead of experimenting on a live household system.
Maintenance check after recovery
One day after recovery, review entity history for another unavailable period, confirm the router or account still shows the expected relationship, and inspect the automation trace from a normal run. Remove temporary diagnostic logging so secrets and storage use do not accumulate, but keep a sanitized summary of the cause and verified fix.