When your smart home has a bad day

1 Choose your protection tier

How much of your home survives a dead server is decided long before the server dies. The difference between the tiers is one question: does anything irreplaceable live on the machine that runs Home Assistant?

Getting to Gold

1. Open the CHAP protection panel on your server page. The badge (Protected / At risk) and the detail line under it tell you exactly which item is holding you back; the health report scores radio readiness in depth.
2. Anchor the tunnel off the HA machine — a GL.iNet travel router (we preconfigure them), your own OpenWrt router, or the adaptor from procedure 2.
3. Move the radio coordinator off the HA machine: repurpose your old Pi (procedure 2), or swap to an Ethernet coordinator (SLZB-06 or similar — a fixed-price job if you'd like it done for you).
4. Make sure the coordinator's own memory — the network key and device table — is being backed up; it's what makes stick replacement possible without re-pairing. ZHA and a Zigbee2MQTT add-on keep these snapshots inside your normal Home Assistant backups automatically. If your coordinator runs on the adaptor instead, ask support to enable coordinator snapshots there — the portal panel for this is on its way.
5. Check backup freshness on the dashboard. If your box sleeps at night and backups keep missing, move the backup window.
6. Get the backups out of the house. Linking already sends a rescue copy to Vome; the off-site backup plan (server page → Off-site backups, from 19 kr/month — included with CHAP standby) keeps timestamped generations, encrypted and stored away from the hardware they protect, restorable any time. For end-to-end encryption set a backup password in HA itself (Settings → System → Backups).
7. Finish with a drill (procedure 8) so the first takeover you see is one that doesn't matter.

Thread/Matter and Bluetooth: a Thread border router and BLE proxies must stay physically in the home — ESPHome Bluetooth proxies cost a few pounds and survive server failures by design. Matter-over-WiFi devices behave like any other IP device and need nothing special.

2 Give your old Pi a new job (the adaptor)

When you move your Home Assistant into VomeHome, the Pi or NUC it used to run on doesn't retire — it becomes your home anchor: the tunnel endpoint and the bridge that connects your Zigbee/Z-Wave radios to your hosted instance. Same hardware, smaller job, and it's the piece that makes failover survivable.

1. Run the migration import first (your server page → Import a backup). Your install is captured, restored into your hosted instance, and verified — entity, device and automation counts compared against the original before you switch anything off. The pre-flight check flags any USB radio sticks, because those need the steps below.
2. When the verification report is green, give the Pi a fresh card or a clean OS (keep the original card untouched — it's your fallback) and install the Vome anchor agent on it — a small service that heartbeats home and watches your local network. Support sends the installer with your migration; a flashable ready-made image is on the roadmap.
3. Leave the radio stick(s) plugged into the Pi. Everything dials out to your hosted instance — no router changes, no port forwarding, CGNAT is fine.
4. Run the radio bridge beside the agent: Zigbee2MQTT on the adaptor is the recommended mode for Zigbee (pairing and timing stay local — Silabs/EZSP sticks in particular dislike long links), Z-Wave JS UI likewise for Z-Wave, or plain serial-over-network for unusual sticks. The migration ticket includes the right config for your stick.
5. Watch the device list on your hosted instance come back to life. Mains-powered devices reappear within minutes; battery devices as they next wake.
6. Confirm the CHAP protection badge shows Protected, then run a drill (procedure 8).

This door swings both ways. The same backup-and-verify machinery moves you back to self-hosting whenever you like (procedure 7). You're a customer, not a hostage.

3 What happens in a failover

Your adaptor sends a heartbeat every minute and quietly probes your local Home Assistant alongside it. When HA stops answering but the home itself is clearly alive, that's the failover case.

1. Detection. HA must be missing for five consecutive minutes while the anchor keeps answering — a reboot or a brief blip never triggers anything.
2. Your policy decides what happens next. Notify me only (default) or notify with a one-click boot action — both put the decision in your hands. Fully automatic action is a separate per-case toggle (classic outage, power-returned-but-HA-didn't, blind boot), each off by default and unlocked only by a passed drill (procedure 8).
3. Boot. Your standby starts from the latest verified backup — or, on the hot-standby tier, it has already absorbed every backup as it arrived, so takeover is attach-and-go. Either way nothing was answering for your home before this moment — there is never a second copy idling live in the background.
4. Radio reattach. The adaptor switches its radio bridge to the hosted instance. The single-active rule is enforced by the adaptor itself: it serves exactly one brain at a time, so even a half-repaired local box can't cause a fight (procedure 7 covers giving control back).
5. Verification. The same report a drill produces: entities, devices, automations and integrations compared against expectations, with anything pending listed by name.
6. Expect the mesh to take a few minutes. Mains-powered Zigbee/Z-Wave devices re-route quickly; battery devices report in on their own schedule — a sensor that checks in hourly will look "offline" for up to an hour. That's the device saving its battery, not a fault.

Away from home? Everything above works from a phone. If you'd rather have hands on it, open a support ticket — you can grant us time-boxed access and approve a fixed quote from the same screen.

4 Rescue: the box died with the radios plugged in

The good news first: your paired devices live inside the stick, not the dead computer. The network key and device table are stored in the coordinator's own memory, so moving the stick moves the mesh.

1. Take over now, mesh later. Trigger the failover (procedure 3). Dashboards, history, automations and every WiFi/cloud device come back immediately; Zigbee/Z-Wave entities show unavailable until the stick moves.
2. Unplug the radio stick from the dead machine. If two sticks look alike, the portal's device page shows the USB IDs to tell them apart.
3. Plug it into your adaptor (procedure 2) — or, if you don't have one yet, into any always-on Linux box or a GL.iNet router; the portal walks you through a minimal bridge install for whatever you choose.
4. The hosted instance picks up the bridge and your mesh devices return — mains-powered ones in minutes, battery ones on their next wake.
5. Re-check your tier (procedure 1): you're now effectively Gold. When you repair or replace the local box, decide between failing back (procedure 7) and staying hosted.

No adaptor, no spare box at all? We can still boot your standby "blind": dashboards, history, cloud integrations and notifications work; the mesh waits for hardware. It proves your backup is good and keeps the non-radio half of your home running while a replacement ships.

5 Replace a dead or lost radio stick

If coordinator backups were being taken (procedure 1, step 4), a replacement stick becomes a clone of the old one — no re-pairing. If not, it's a re-pair job: tedious, bounded, and your automations and dashboards are all preserved.

With a coordinator backup

1. Order a compatible replacement — like-for-like is safest; same-family chips restore cleanly. Not sure what you had? Ask support; the model is in your instance's records.
2. Plug the new stick into your adaptor (or wherever the old one lived).
3. Restore the coordinator backup onto it: Zigbee2MQTT does this automatically on first start when it finds a backup beside a fresh stick; ZHA offers Migrate radio under its settings. Either way the saved network key and device table are written into the new stick. Support walks you through it from the ticket if you'd rather not solo it.
4. Devices reconnect on their own — mains-powered first, battery devices as they wake. Give battery sensors a day before declaring any of them missing.
5. A fresh coordinator backup is taken automatically once the restore settles.

Without a backup

1. Pair the new stick as a new network, then re-pair devices room by room — nearest the coordinator first, so the mesh builds outward.
2. As each device returns, rename it to its old entity ID when prompted; automations and dashboards then pick it up unchanged.
3. Make coordinator backups part of the new network from day one (procedure 1, step 4), so this is the last time.
4. If the job is bigger than you fancy, support can quote it — re-pairs are a fixed-price favourite.

6 The whole home is offline

Power cut, ISP outage, or a tripped breaker. This is the one scenario where failover deliberately does not happen — and that's a feature.

1. Why no takeover: your devices and radios are exactly as offline as Home Assistant is. A hosted standby would control an unreachable home, and when power returned your own box and the standby would wake up fighting. The both-down rule blocks it.
2. Check the status page (portal → your server). Two heartbeats: anchor and Home Assistant. Both red = home offline (this procedure). Anchor green, HA red = a real failover case → procedure 3. Anchor red, HA green = your protection is degraded — the tunnel or adaptor needs attention even though HA feels fine; bridged radios are offline until it's fixed.
3. Wait it out watched. We keep probing and notify you the moment the anchor reappears, with a fresh health check on whether HA came back with it.
4. If the home returns but HA doesn't, you've just become the simple case → procedure 3. There's a policy toggle for exactly this ("after a whole-home outage — power returns but HA does not") if you'd like it handled automatically; like all automatic actions it unlocks after a passed drill.
5. If outages are a recurring theme: a small UPS on the adaptor and router keeps the anchor (and your visibility) alive through short cuts — and means a takeover is possible while the lights are out, since the mesh stays powered.

7 Failing back after a repair

Your local box is repaired or replaced and you want to go home — or you've decided hosted suits you. Either way the rule is the same: one brain at a time, and the handover is ordered.

1. Don't restore anything onto the local box yet — keep it a blank slate until the sequence says go. If the repaired box powers up still holding its old install, the adaptor refuses it radio access (the lease is with the hosted instance) and the portal flags the conflict rather than letting two brains fight.
2. In the CHAP panel choose Prepare handback. Everything you changed while failed over — new automations, device renames — is captured in a final backup of the hosted standby; restore that backup onto your local box.
3. Then End failover (hand back): the hosted instance is stopped first, and only then does your local instance become the active one.
4. The adaptor's radio lease flips back to the local instance, and verification runs against it — same report as a drill.
5. Your account returns to standby mode: hosted copy dormant, backups syncing, protection badge back to Protected.
6. Or stay. Skip the restore and keep running hosted — your old box becomes a spare adaptor or a doorstop, and your monthly drill (procedure 8) now tests the opposite direction.

8 Run a failover drill

A drill is a real takeover with the danger removed: your standby boots from the latest backup on an isolated network — no tunnel attach, no radio handover, no messages to your devices — and reports what it found.

1. On your server page, in the CHAP protection panel, choose Run isolated drill. Your live home is untouched throughout — the standby is cut off from the outside world (no MQTT, no device clouds, no notifications) and the isolation lifts itself when the check settles. You can run one over breakfast.
2. The standby boots from your latest backup exactly as a real failover would.
3. The verification suite compares entities, devices, automations and integrations against your live instance's last-known state.
4. Read the report. Green: your bad day is already handled. Amber items name anything that wouldn't come back cleanly — a stale backup, a radio backup that's missing, an integration that needs a re-login after restore — each with its fix linked.
5. The drill tears itself down and files the report in the CHAP panel's event history.
6. Do it quarterly (there's a reminder setting in the failover policy) and after any big change — a new integration, a coordinator swap, a major HA upgrade.

A passed drill is also the key that unlocks the automatic-action toggles (procedure 3, step 2) — the system won't act on its own until it has proven to you, on your own backups, exactly what it would do.

9 Home Assistant is up, but broken

Loads, but misbehaves — usually after an update, a new integration, or one config edit too many at midnight. The hardware is fine, so this isn't a failover; it's a restore or a repair.

1. Check the obvious first: Settings → System → Logs for red errors, and Settings → System → Repairs for anything HA has already diagnosed for you.
2. If it broke after a change, restore. Pick the backup from just before the change (portal → Backups) and restore it to your local box. Ten minutes, and the midnight edit never happened.
3. Not sure when it broke? Boot your hosted copy in isolation (same machinery as a drill, procedure 8) from a backup you suspect was healthy, and compare it side by side with the live instance — without your home noticing either of them.
4. Suspect deeper rot — a flapping device eating CPU, a bloated database, integrations erroring quietly? Run a Health check from your server page: the scan is free and shows the top findings straight away; the full report with every finding and its fix list is a one-off unlock (495 SEK).
5. Want it handled? Open a ticket. You grant time-boxed access from the ticket itself, complex work gets a fixed quote or an estimate before anything starts, and every action we take inside your instance is logged where you can read it.

10 Remote access: friendly domains, the HA app and webhooks

A friendly domain (like myhome.home.vome.io) forwards your browser to your own Home Assistant over the same outbound tunnel the assistant uses — no open ports, no dynamic DNS, Vome handles TLS. This section explains who can reach that address, what the two optional access modes change, and how to switch everything off.

The default: locked to your Vome sign-in

1. Out of the box, every request to your friendly domain must carry a short-lived access pass that only the Vome portal can mint — and it only mints one for you, signed in, with an active subscription for that home.
2. No pass means the visitor is bounced to the Vome sign-in; they never see your Home Assistant at all. Behind that gate you still sign in to HA as normal — two locks, in series.
3. On top of this, forwarding itself is opt-in inside your own HA (Vome integration → Configure → Allow full-UI forwarding). If that's off, nothing is forwarded regardless of any setting on vome.io.

Optional mode: permit webhook deliveries

1. Webhooks are how outside services (Shelly buttons, IFTTT, payment confirmations, GPS trackers…) push events into HA. They can't sign in to Vome, so by default they can't reach a friendly domain.
2. Switching on Permit webhook deliveries (server page → Remote access tile) opens exactly one door: URLs of the form /api/webhook/<id>. Nothing else — no dashboard, no API, no login page.
3. This matches how Home Assistant itself treats webhooks: the long random ID in the URL is the secret. Use the IDs HA generates (Settings → Automations → your webhook trigger), never guessable ones like doorbell.
4. Treat a webhook URL like a password: share it only with the service that needs it, and regenerate it if it leaks (a webhook can also be set to local only in HA if it should never be reachable remotely).

Optional mode: permit Home Assistant app access

1. The official HA companion app can't perform the Vome sign-in dance, so with the default gate it can't use a friendly domain as its server address.
2. Switching on Permit Home Assistant app access removes the Vome gate for this address. Your HA login becomes the only lock — the same trust model as Nabu Casa Remote UI or any self-hosted HA on the public internet.
3. Before enabling it: turn on multi-factor authentication in Home Assistant (Profile → Security → Multi-factor authentication), make sure every user account has a strong password, and remove accounts you don't recognise.
4. Then put https://<your-slug>.home.vome.io into the app as the external URL. HA's own protections (login throttling, IP banning) apply as normal.

Switching it all off

1. Each mode has its own switch on the server page — turning one off closes that path within about 30 seconds.
2. Cancelling the friendly domain, unlinking the HA, or letting the subscription lapse closes everything at that address immediately — the modes only ever apply to an active, paid domain that is still linked to your account.
3. Belt and braces: switching off Allow full-UI forwarding inside your own HA stops all forwarding at the source, whatever any Vome setting says.

Design note: both modes are off by default, are honoured only while the platform feature is enabled, and every check fails towards "sign-in required". If anything looks wrong, turn the switch off and tell support — include the address and roughly when you saw it.