Home Assistant vs Hubitat When the Mesh Misbehaves: Local Automations That Still Call Home

The last time the Zigbee mesh sulked, I had two dashboards that still said the hallway motion rule was local. Home Assistant’s automation had no cloud action in the YAML. Hubitat’s Rule Machine had no cloud action in the rule. The hallway still took four seconds, and both phones had already talked to someone else’s server before the light agreed to move.

That is the comparison I care about. Not “which hub is more open.” Not a feature matrix that ends with HACS versus Hubitat Package Manager. When the mesh misbehaves — a starved router, a USB 3 week, a coordinator swap, a floor that never healed — which box lets you see it, and which of your “local” automations were already phoning home for weather, presence, or a push notification.

What each box actually is

Hubitat Elevation is a small appliance with radios on the board. Zigbee and Z-Wave are not add-ons. Rule Machine, Room Lighting, and Maker API live on the hub. The pitch, which is mostly true, is that a motion lighting rule can fire if your internet dies. I have pulled the WAN cable on a C-8 and watched Innr bulbs still follow a Hue-quality dimmer because the rule and the radios were in the same plastic.

Home Assistant is a computer you already had, plus a radio you bought, plus whatever you allowed into the integrations list. ZHA or Zigbee2MQTT, Z-Wave JS UI, Matter, a dozen Wi-Fi ESPHome nodes. The pitch, which is also mostly true, is that you can see everything and fix everything. I have pulled the WAN cable on a Mini PC and watched the same motion rule fail because the trigger was a person entity that comes from the Companion App, and the Companion App had decided the phone was away until it could see Nabu Casa again.

Both pitches omit the mesh. A local rule cannot turn on a bulb that cannot hear the coordinator. Hubitat will look calmer while that happens. HA will look louder. Neither is a protocol engineer in a box.

When the mesh is the patient

On Home Assistant I debug a sick Zigbee network in Zigbee2MQTT’s map and logs, or in ZHA diagnostics. I can see that the coordinator’s children are three IKEA bulbs in a metal cabinet. I can see a Xiaomi button that refuses to use a router. I can change a channel, I can move a stick, I can watch LQI after I unplug a USB 3 dock. That visibility is why I still run HA for the houses that have seventy devices and a junk drawer of brands.

Hubitat’s Zigbee logging exists. It is not Z2M. The Z-Wave side is closer to what people remember from SmartThings: a heal, a repair, a device that is “a poor repeater.” When the mesh is Z-Wave-heavy, I have had better weeks on Hubitat than on a neglected Z-Wave JS install I never opened. When the mesh is Zigbee-heavy and mixed Chinese brands, I want Z2M’s interview logs more than I want Rule Machine’s cleanliness.

Device-to-device bindings are the other local story. A Philips dimmer bound to a bulb still works if both hubs are dead. Hubitat’s community has been binding-first for years because the hub used to reboot more than people liked. ZHA bindings exist now and I use them for the hallway that must work during an HA update. I do not pretend every Tuya switch supports bind. The mesh misbehavior that bindings fix is “hub is restarting.” The mesh misbehavior they do not fix is “radio is jammed.”

Thread and Matter make this comparison sloppier. HA will ingest a Thread border router and fifty Wi-Fi Matter plugs. Hubitat’s Matter support is real and smaller. If your “mesh” is actually a Thread partition plus Zigbee plus a Nest that still wants Google, HA is the box that will hold the mess. Hubitat is the box that will refuse some of it, which is sometimes the correct product decision.

The automations that call home anyway

I keep a list on the fridge of rules I have called local and then caught in a DNS log.

Weather as a condition. HA’s Met.no or OpenWeather, Hubitat’s weather drivers. A “if rain, skip the sprinkler” rule is not local. When the API is slow, the rule is slow. When I am debugging a mesh, I do not want that latency in the same trace as a bulb that is genuinely retrying.

Presence. HA person entities from the Companion App, Life360, router device-tracker, Bluetooth proxies. The phone-based ones go through Apple, Google, or Nabu Casa. Hubitat’s presence is often Life360, or a phone on the LAN, or a fob. I have had a “local” goodnight scene wait on a phone that was at 30 percent battery and not reporting. The Zigbee sensors were fine. The hub was fine. The WAN was fine. The phone was napping.

Notifications. HA notify via the Companion App, Telegram, ntfy. Hubitat’s built-in notifications and community push. A lighting rule that ends in “and text me” is a lighting rule that can stall on a cloud. I split them. Lights first, notify in a second automation that I am allowed to fail. I learned that after a Pushover outage made a hallway feel “broken” because I had stacked the actions.

Voice. Alexa and Google are not local, even if the skill talks to a local Maker API or Nabu Casa. The utterance left the house. If the mesh is sick, shouting at an Echo tells you nothing about LQI. I still do it. I just stop calling it a local test.

Hubitat’s own remote access — their cloud dashboard, remote admin — is a call home you opt into for convenience. Nabu Casa is the same shape with a different invoice and a better HomeKit story. I pay for Nabu Casa on the house I travel from. I do not point the hallway motion at it.

Cloud devices wearing a local hub

Tuya, some newer “Matter” plugs that still phone a vendor, Ring, ecobee, Hue remote API if you were lazy, Spotify in a morning alarm. Both hubs will let you put those in a rule that looks like the Innr bulb rule. When the mesh misbehaves you will waste an hour on Zigbee while the actual delay is Tuya’s cloud in another country.

My rule: if I cannot turn it on after pulling WAN, it does not get to live in the “mesh is sick” debug path. I name those entities with a cloud_ prefix in HA. On Hubitat I put them in a room I named Cloud So I Remember. It looks childish. I still put a cloud RGB strip in a local scene last winter.

Hue is the confusing one. A Bridge on the LAN is local enough for lights. Hue’s account features are not. Hubitat and HA both talk to the Bridge locally if you set them up that way. If you used the cloud integration because it was the first tile, you bought a WAN dependency for a $12 bulb.

Which hub I reach for when the floor is ugly

If I am still adding cheap sensors and I need to know why an Aqara skipped a hop, I want Home Assistant plus Zigbee2MQTT, a coordinator on a cable, and a weekend. Hubitat will run the house in the meantime if I already have it, but I will not debug a starved mesh from Rule Machine’s logs alone.

If the house is a small Z-Wave set, a few Zigbee repeaters, and a person who will not babysit YAML, Hubitat is the calmer computer. Updates are an appliance. The radios are not a Compose file. The failure mode is “hub is weird,” not “which of the fourteen containers is restarting.” When that hub is weird, you reboot it. When HA is weird, you can reboot it too, and you can also spend three hours in a template.

I have run both in parallel. Maker API and HA’s Hubitat integration exist. Parallel is how you migrate, not how you live. Two brains deciding the same bulb is how you get a strobe and a blame loop. During a mesh incident I pick one writer.

Updates, lock-in, and the week after a move

HA OS updates have broken Z-Wave JS and a supervisor pin more than once in my notes. Hubitat platform updates have broken a community driver more than once too. The difference is surface area. HA’s surface is the entire integration list you clicked yes on. Hubitat’s surface is the drivers you installed. After a move, HA is better at absorbing a new Thread border router and a new VLAN. Hubitat is better at being the same plastic in a new apartment if you did not change brands.

Lock-in: Hubitat rules do not export into HA automations in a way I trust. HA automations do not become Rule Machine. Bindings survive a hub swap better than rules do. If I am scared of a move, I bind the hall and the bedside and I treat everything else as disposable code.

What I tell people who want “local”

Local is a property of a device plus a rule plus a notification path, not a logo on a hub. Hubitat is the tighter default for that property if you stay on its radios and you do not add weather. Home Assistant is the tighter default for seeing a mesh lie to you, and the looser default for calling home, because it makes calling home so easy.

When the mesh misbehaves, I stop looking at automations first. I look at whether a mains bulb can hear the coordinator with WAN unplugged. If yes, I look at which trigger in the “local” rule is a phone, a forecast, or a push. If no, I look at USB 3, channel, and routers — on whichever box will show me that picture. Today that picture is clearer in Zigbee2MQTT than in Hubitat. The hallway light does not care which dashboard I was proud of.