Daniel's been thinking about smart locks — and he's coming at it from a very specific place. He's been burned by a rental rigged with Tuya Wi-Fi smart plugs, the kind where every power cycle is a lottery for which lights come on. And now he's looking ahead to when he can actually install proper infrastructure, and he's asking: what's the connectivity backbone that actually works at scale without turning your smart home into a fragile stack of coordinators and clouds? And the deeper question underneath — are smart locks trustworthy enough to stake your front door on?
Oh, this is a good one. Because he's hit on something that most smart home coverage just completely glosses over. The connectivity question isn't just about range or bandwidth — it's about what happens when things go wrong. And with locks, when things go wrong it's not "oh, the bathroom light didn't turn on," it's "I'm standing in the rain at eleven PM and my door won't open.
Which is a very different failure mode. And by the way — today's episode is being written by DeepSeek V four Pro. So if anything sounds unusually coherent, that's why.
So let's start with the core question, because I think it's actually three questions nested inside each other. One, what's the right connectivity network for a serious smart home? Two, how do smart locks handle reliability and failure? And three, does any of this extend to things like smart safes?
And the unspoken fourth question is: after being burned by a cloud-dependent Chinese Wi-Fi system, what's the architecture that doesn't just move the failure point somewhere else?
That's where the KNX conversation we had really matters, because the insight wasn't just "KNX uses a different cable" — it was that the whole design philosophy is different. In a KNX system, a light switch sends a telegram onto the bus, the actuator picks it up, the light turns on. If the controller dies, the lights still work. If the internet goes down, the lights still work. Each component is independently functional.
And most consumer smart home stuff is the opposite. Coupled — sometimes tightly to a cloud service, sometimes to a hub, sometimes to both. And every coupling is a failure point.
When Daniel looks at a smart lock box and sees "Zigbee" printed on it, his instinct is: great, another network, another coordinator, another thing that can break. Is that instinct right?
It's not wrong, but it needs unpacking. In the current market — twenty twenty-six — smart locks use four main connectivity methods. Wi-Fi, which is most common in consumer-grade stuff. Z-Wave, which has been around forever with excellent range and reliability. Zigbee, which Daniel mentioned seeing on boxes. And Thread, part of the Matter ecosystem. Bluetooth is almost always present as a fallback for local setup and direct phone-to-lock communication, but it's not the primary home automation connection.
Four real options. Which one is actually good?
Here's where I want to push back on something Daniel said. He noted Zigbee's range might not be sufficient in bigger places. That's true point-to-point. But Zigbee and Z-Wave are both mesh networks — every mains-powered device acts as a repeater. A Zigbee smart plug in the hallway extends the network to the front door. Wirecutter testing from earlier this year found Z-Wave locks consistently more reliable at range than Wi-Fi locks, specifically because the Z-Wave mesh doesn't depend on a single access point.
Daniel's experience with Zigbee — specifically Tuya Zigbee — was that it was flaky even in a small apartment.
That's the crucial distinction. It's not Zigbee the protocol that was flaky. It was the implementation. Tuya devices, especially the ones that ship in bulk to landlords — those are built to a cost point, not a reliability point. Zigbee as a protocol is solid. It's used in industrial applications and in the Philips Hue ecosystem, which is famously reliable. The problem is that Zigbee has a much looser certification process than Z-Wave. With Z-Wave, every device must pass certification from the Z-Wave Alliance. With Zigbee, you can kind of slap the logo on and ship it.
Daniel's bad experience with Zigbee might actually be a bad experience with Tuya's particular implementation.
I'd bet money on it. If you're choosing a network specifically for security-critical devices like locks, Z-Wave has real advantages. It operates in the sub-gigahertz band, meaning less interference from Wi-Fi and Bluetooth. Better range per hop. And mandatory certification means consistent behavior across brands.
If someone's building a smart home from scratch and wants one network that handles everything including locks, what's the recommendation?
I'm going to sound like I'm dodging, but bear with me. The recommendation is: don't try to put everything on one network.
That sounds like the opposite of what Daniel's asking for.
It is, but here's the thing — the dream of the single unified smart home protocol has been promised for years. Then Z-Wave. Then Thread with Matter. Matter has made real progress, but we're not there yet, and honestly I'm not sure we ever will be for every device category. The fragility doesn't come from having multiple networks — it comes from how those networks are integrated. The problem isn't that you have a Zigbee network and a Z-Wave network and a Wi-Fi network. The problem is when your automations depend on all of them working simultaneously through a single point of integration.
How do you design around that?
Apply the KNX lesson at the software layer. Decouple the critical paths. A smart lock should function as a lock even if Home Assistant is down, even if the internet is down, even if the Zigbee coordinator has crashed. And here's what a lot of people don't realize about Z-Wave locks — they don't need a hub to function as a lock. The Z-Wave radio is for remote control and automation. The lock stores its own PIN codes locally. If your Z-Wave controller goes down, you can still enter your code on the keypad and the lock will open.
That's the kind of decoupling Daniel was talking about. And it's why you recommend Z-Wave for locks specifically, even if the rest of the house is on Zigbee or Thread.
The lock is the one device where you absolutely cannot tolerate a cascade failure.
Let's talk about the key override question, because Daniel mentioned it in passing and I think it's central to the trust question. He assumed these locks come with a key override. Is that universally true?
Most smart locks do have a physical key override — Yale Assure, Schlage Encode, August. But there's a growing category of keyless smart locks with no physical key backup at all. Some have a backup power contact on the outside — you hold a nine-volt battery against two terminals to power the lock enough to enter your code. Others have backup Bluetooth unlock. But you're relying on the lock's internal electronics not being completely dead.
Which is a single point of failure that a physical key doesn't have.
For an exterior door that's your primary entrance, I think a physical key backup is non-negotiable. Not because smart locks are unreliable — the good ones are very reliable — but because the cost of failure is so high. What if the firmware has a bug that manifests after a year? What if a battery leaks and corrodes the contacts? What if a power surge fries the motor? These are edge cases, but a physical key handles them trivially. The key isn't just a backup for battery failure — it's a backup for unknown unknowns.
The industry has been pushing toward keyless designs partly for aesthetics and partly because key cylinders are a mechanical vulnerability. You can bump them, you can pick them. But for most people, the threat model where someone picks your lock is far less likely than the threat model where your smart lock's battery dies while you're out.
Let's talk about installation, because Daniel mentioned being a renter and not being able to do any of this currently. When he does get to the point of installing smart locks, what's actually involved?
The landscape has gotten much better. Most smart locks now are retrofit kits. You remove the interior thumb turn, mount the smart lock over the existing deadbolt mechanism, and don't touch the exterior hardware at all. The August smart lock is the classic example — it just replaces the interior side. Your existing key still works. Your landlord never needs to know. When you move out, you unscrew it and take it with you. But — and this is a big but — it only works if your existing deadbolt is compatible. Some have non-standard spindle shapes. Some are too stiff for the motor to turn reliably. Some doors don't close perfectly, so the deadbolt binds against the strike plate, the motor works harder, and the battery drains faster.
Even the retrofit approach has failure modes that aren't obvious until you try it.
That's what makes smart locks frustrating for people who aren't prepared to debug them. A traditional deadbolt, if it's a little stiff, you just turn harder. A smart lock motor has fixed torque, and if the deadbolt requires more than that, the lock fails. You get an error notification instead of a locked door. A mechanical lock degrades gracefully — it gets stiffer but still works. An electronic lock just stops. I wish manufacturers talked about this more honestly. A smart lock requires the door and frame to be in better adjustment than a manual lock does. If your door swells in summer humidity, a manual lock user pushes harder. A smart lock user gets a jam.
Part of installing a smart lock is making sure the door itself is in good shape — adjusting the strike plate, planing the door edge, maybe replacing weatherstripping.
It's not a huge job, but it's not nothing either.
Let's go back to the network question. Daniel's asking: what's the connectivity network that's viable, reliable, and ideally something the rest of the smart home is already running on?
Here's my actual recommendation. For locks: Z-Wave. Range is excellent — up to a hundred meters in open air, and with mesh repeating it easily covers a large house. Sub-gigahertz means no Wi-Fi competition. Mandatory certification means devices actually work together. Local control means the lock functions without internet. For lighting, sensors, and general automation, Zigbee is fine — especially if you stick with known-good brands like Philips Hue or Aqara rather than no-name Tuya devices. Thread and Matter are the future and getting better every year, but the device ecosystem for locks specifically is still thin.
You're recommending two networks. Zigbee for lighting and sensors, Z-Wave for locks and security.
And I know that sounds like it contradicts the "simplify" instinct, but Home Assistant handles multiple networks seamlessly. You plug in a Zigbee coordinator and a Z-Wave coordinator, and Home Assistant sees both as just devices. The automation engine doesn't care which network a device is on. If one coordinator goes down, the devices on that network stop responding to automations — but the lock still works as a lock. The lights still work from their physical switches if you've wired it that way. The critical paths are decoupled. That's the KNX philosophy applied to consumer hardware.
Daniel mentioned seeing Zigbee on smart lock boxes and feeling a headache coming on. Are those Zigbee locks actually bad products, or is it just that they're being sold into an ecosystem not set up for them?
They're fine products for the right use case. A Zigbee lock on a Philips Hue hub in an apartment where the hub is ten feet away — that'll work great. The problem is when someone buys a Zigbee lock, pairs it to a Tuya hub connected to the Tuya cloud in China, and expects it to be as reliable as a deadbolt. It's always the integration chain, not the lock itself. That's what Daniel learned the hard way with the smart plugs. The plugs probably worked fine in isolation. It was the cloud dependency and the flaky Tuya integration that made the whole system unreliable.
Let's talk about smart safes. Does that category even exist?
It does, but it's much less developed than smart locks. Companies like Vaultek and SentrySafe make them, but they tend to use Bluetooth or Wi-Fi rather than Z-Wave or Zigbee. They're designed for standalone operation with a phone app, not for integration into a home automation system. And there's a reason for that. With a front door, you want remote access — letting in a guest, checking if the door is locked. With a safe, remote access is actually a security liability. You don't want the safe unlockable over the network, because then anyone who compromises your network can open it. So most smart safes use the "smart" features for monitoring and alerts — the safe telling you it was opened or the battery is low — rather than remote unlocking. Unlocking is still done locally, with a keypad, fingerprint reader, or physical key.
If Daniel wants a safe that integrates with his home automation, what's actually available?
Honestly, the integration options are limited. Some Vaultek safes have Wi-Fi that can send alerts, and there are community integrations for Home Assistant that can read those alerts. But you're not going to find a safe with Z-Wave or Zigbee that you can lock and unlock from your automation dashboard. And that's probably by design. With a front door, the threat model is primarily physical. Smart features add convenience without fundamentally compromising security, as long as the lock has good local control. With a safe, the threat model includes network attackers, and the convenience of remote access isn't worth the security tradeoff.
For a safe, the recommendation might actually be: don't make it smart. Or at least, keep the smart features to monitoring only.
I think that's right. Get a good safe with a reliable mechanical or electronic lock, and if you want monitoring, get one that can send alerts. But don't put the unlock mechanism on the network. Sometimes the best smart home solution is to put a sensor on a dumb thing rather than buying a smart thing.
That's probably a whole episode on its own. Let's circle back to the trust question, because I think it's the most interesting part. Daniel framed it as: are you willing to stake the front door being locked on your home automation system? That's about trust in the technology, but also about trust in yourself as the person configuring it.
A traditional deadbolt, you turn the key, it's locked. There's no configuration, no firmware update, no automation that might have a bug where it unlocks the door at three AM because you wrote the wrong condition in Home Assistant. With a smart lock, you're not just trusting the hardware and software — you're trusting your own ability to configure it correctly. And if you've ever written an automation that did something weird because you got the logic backwards — which everyone has — the stakes are just higher when the thing you got wrong is the front door lock.
What's the right way to think about it?
Start from the assumption that the lock should be secure even if the smart features fail completely. That means physical key backup, local PIN storage, no cloud dependency for basic function. Then the smart features are additive — they make things more convenient, but they don't create new failure modes for the core function of locking and unlocking. That principle applies to the whole smart home. The house should still work as a house when the automation is down. In a hotel with KNX, if the central controller fails, the lights still turn on from the switches. The blinds still work from local controls. The system degrades gracefully.
In a consumer smart home, graceful degradation is possible, but it requires intentional design. Most people don't do that. They add devices one at a time, each works in isolation, and then one day the internet goes down and suddenly nothing works.
Because the failure modes are emergent — they come from the interactions between devices, not from any single device. That's what Daniel experienced with the Tuya smart plugs. Each plug probably worked fine on its own. But the system as a whole — the cloud dependency, the Wi-Fi congestion, the power-cycle lottery — that was an emergent property of the integration choices.
If Daniel's building a system from scratch, the advice isn't just "use Z-Wave for locks." It's "design the whole system so that critical functions don't depend on non-critical infrastructure." And test your failure modes. Actually unplug your Home Assistant server and see what still works. Turn off your internet and see what still works. Most people never do this, and then they discover the failure modes at the worst possible moment.
Daniel has been burned. That's why he's asking these questions. He's not being paranoid — he's being rational based on experience.
Let's talk about Matter, since Daniel mentioned it. Where does it fit into the smart lock picture?
Matter is designed to solve exactly the fragmentation problem Daniel's worried about. The promise is that a Matter lock works with any Matter controller — Apple Home, Google Home, Amazon Alexa, Home Assistant — without vendor-specific integrations. Matter runs over Thread, a mesh protocol similar to Zigbee but designed for low-power IoT. In theory, one Matter-over-Thread network for everything. In practice, Matter smart locks are still relatively new. The first ones shipped in late twenty twenty-four, and the ecosystem is growing but not mature. The Yale Assure Lock with Matter is one of the better options, but device selection is a fraction of what's available for Z-Wave. And Thread border routers — you need those to bridge the Thread network to Wi-Fi — are another potential failure point. If your border router goes down, remote access and automations involving non-Thread devices break.
It's another coordinator, effectively. And if you're already running Zigbee and Z-Wave coordinators, adding Thread means three mesh networks — exactly the fragmentation Daniel was worried about.
If Matter eventually subsumes everything, you could consolidate. That's the dream. But I've been in this space long enough to be skeptical of consolidation promises. Each protocol adds something valuable, but none has killed the others. The realistic future is multi-protocol indefinitely. Which brings us back to: embrace the multi-network reality, but design the integration layer to be resilient. Home Assistant is really good at this. It doesn't care that your lock is Z-Wave and your lights are Zigbee and your thermostat is Wi-Fi. The key is making sure no automation can create a security vulnerability if one network goes down.
Concrete example: don't write an automation that unlocks the front door when a Zigbee motion sensor detects someone approaching. Because if the Zigbee network goes haywire and starts sending spurious motion events, your front door unlocks itself.
Unlocking should always be a deliberate action — entering a code, tapping a button, using a fingerprint. Never an automated response to a sensor. Locking is different — automatically locking the door when everyone leaves or at a certain time is fine, because the failure mode is "door stays locked," which is safe. Unlock manually, lock automatically. And the better smart lock systems enforce this at the firmware level. Some locks won't even accept an unlock command over Z-Wave unless it's accompanied by a user code. The lock is the security boundary, not the automation controller. It should be skeptical of commands it receives over the network.
Let's shift to user experience, because there's a dimension here that doesn't get enough attention. Daniel's been living with a flaky system where lights come on randomly after a power cycle. That's annoying for lights. But a smart lock has a different feel — a traditional lock gives you tactile feedback. You feel the key turn, the bolt slide, the click. With a smart lock, you might just hear a motor whir and then nothing tactile. You don't know if it's actually locked unless you check.
Some handle this better than others. Locks with a physical thumb turn on the inside give you that tactile confirmation. Fully motorized ones can leave you wondering. And then there's auto-lock, where the lock locks itself after thirty seconds. That's convenient, but it means you can't leave the door unlocked while bringing in groceries. Most implementations have a way to disable it temporarily, but you have to know how. If you don't, you end up fighting with your own lock — the opposite of what smart home technology is supposed to do. The best smart lock is the one you don't think about. You walk up, enter your code, the door opens, you go inside. You leave, the door locks behind you. It should feel like magic, not a compromise. That's achievable with current hardware, but it requires careful selection and setup — not a "buy it at the hardware store and install it in twenty minutes" thing, despite what the marketing says.
Which brings us back to Daniel's situation. He's not in a position to do any of this yet. He's thinking ahead. What should he be looking for?
First, local control — the lock should work without the cloud. Second, physical key backup. Third, Z-Wave or possibly Thread, with a strong preference for Z-Wave given ecosystem maturity. Fourth, local PIN storage, not in the cloud. Fifth, good battery life — six months to a year, with low-battery warnings well in advance. On the integration side: Home Assistant with a Z-Wave coordinator. Set up the lock in Home Assistant, but don't make it dependent on Home Assistant for basic operation. The PIN codes are in the lock. The key works. Home Assistant adds remote access and automation, but it's not a single point of failure. If the Z-Wave network goes down, the lock still works with PIN codes and the physical key. The failure mode is "I can't check if the door is locked from my phone," not "I can't get into my house.
Daniel also mentioned window and door sensors. How do those fit in?
Sensors are lower stakes than locks because they're monitoring, not controlling. If a sensor goes offline, you lose visibility but not security. They can happily live on Zigbee or Z-Wave. The key is they shouldn't be on Wi-Fi — battery life, mostly. A Zigbee door sensor can run two years on a coin cell. A Wi-Fi sensor might need new batteries every few months, and Wi-Fi sensors are almost always cloud-dependent, adding latency and a failure point. So the sensor network should be local and low-power. Zigbee sensors are cheap and plentiful, especially from Aqara. Z-Wave sensors are more expensive but tend to be more reliable. For most people, a mix is fine — Zigbee for the dozen motion and door sensors scattered around the house, Z-Wave for the locks and maybe a few critical sensors. Home Assistant handles the mix completely transparently.
Let's be explicit about how many networks you can have before the system breaks.
As many as you need, as long as each network is reliable on its own and the integration layer doesn't create cross-network dependencies. The problem isn't the number of networks. The problem is when Network A going down breaks things on Network B. You could have ten networks and a rock-solid system if they're properly decoupled. Or one network and a fragile system if everything depends on a single cloud service. Daniel's Tuya system was one network — Wi-Fi — and it was terrible because everything depended on a cloud service in China. Complexity is not the same as fragility. The goal is robustness, not simplicity for its own sake.
I want to touch on Daniel's instinct that "Zigbee equals flaky" because of his Tuya experience. It's a reasonable heuristic based on his experience, but worth unpacking.
Tuya is a platform company. They make cheap modules that other companies slap into products. Generic firmware, minimal quality control, cloud dependency baked in. A Yale Zigbee lock is a completely different thing — custom firmware, proper testing, local control support, and a company that's been making locks for over a hundred years. The protocol is the same, but the implementation is night and day. A Philips Hue bulb and a no-name Tuya bulb both use Zigbee. One works flawlessly for years. The other drops off the network and needs re-pairing every few months. The smart lock market has consolidated around reputable manufacturers — Yale, Schlage, Kwikset, August, Ultraloq. None are Tuya-based. Daniel's heuristic should be: avoid Tuya, not avoid Zigbee. And honestly, extend that to "avoid anything that depends on a cloud service for basic operation." Whether it's Zigbee, Z-Wave, Wi-Fi, or Thread — if the device stops working when the internet goes down, it doesn't belong in a serious smart home.
Let's talk about the safe question one more time. With a front door lock, smart features add convenience — remote access, auto-locking, guest codes that expire. With a safe, what's the value add? You're not letting guests into your safe. You're not checking if the safe is locked from your phone while on vacation, because if you're on vacation, your passport is in the safe and you can't access it anyway.
The use case for a smart safe is mostly monitoring. You want to know if the safe was opened while you were away. You want to know if someone tried to guess the code and triggered a tamper alert. Those are security features, not convenience features. The "smart" in smart safe is about audit, not access. That's a fundamentally different value proposition. A smart lock is about making access easier and more flexible. A smart safe is about making access more auditable. And the security model is inverted — with a lock, you want remote unlock capability. With a safe, you explicitly don't. Most smart safes don't support remote unlocking at all. The smart features are read-only — status, alerts, access logs. For most people, a traditional safe with a good mechanical or electronic lock is the right answer. The smart features are nice to have, not essential.
Let's zoom out. Daniel started with a bad experience, learned from it, and is now thinking about how to build something better. What's the through line?
The smart home industry sells convenience, but the real value is resilience. A well-designed smart home doesn't just make things easier — it makes things more reliable. It gives you visibility and control you didn't have before. But to get that, you have to think like an engineer, not like a consumer. Think about failure modes. Ask "what happens if this breaks?" for every component and integration. Prefer local control over cloud control. Design automations so the safe failure state is the default. Test your system under adverse conditions. And accept that the "one protocol to rule them all" dream is probably not coming. Multi-protocol is not a problem if the integration layer is solid. Home Assistant has proven that. The problem is when people try to force everything onto one protocol not suited for every use case, or buy into a vendor ecosystem that locks them into a single cloud service.
Daniel's experience was a vendor lock-in problem, not a protocol problem. If those same plugs had been flashed with ESPHome and controlled locally, they probably would have been fine. But that's not something a landlord is going to do. So the lesson for when Daniel is no longer a renter is: invest in infrastructure. Spend more on fewer, better devices. Choose local control. Design for failure. And don't be afraid of multiple networks.
If someone really wants one network? Thread with Matter is the closest thing to a single-network future. But you'd be an early adopter with a limited selection of locks. If you're risk-averse: Z-Wave for locks, Zigbee for sensors, and stop worrying about the network count. It's proven. It's what I'd put in my own house. Specifically, a Z-Wave lock from Yale or Schlage, with a physical key backup, local PIN storage, and a Z-Wave coordinator running on Home Assistant. For the safe: a traditional safe with a good electronic lock and maybe Wi-Fi monitoring if you want alerts. Keep the unlock path entirely local. Or put a door sensor on a dumb safe connected to your alarm system — that gives you monitoring without the security tradeoffs.
Alright, I think we've covered the ground. Connectivity networks, lock reliability, installation, the safe question, and the broader philosophy of designing for resilience. Anything we missed?
One practical note about battery life, because it's the number one support issue. A Z-Wave lock gets six to twelve months on a set of batteries. Wi-Fi might get three to six. The difference is radio power consumption. Good locks report battery level over Z-Wave, and you can set up Home Assistant to notify you below twenty percent — giving you weeks to change batteries. And if you ignore the warnings and the battery dies completely? That's what the physical key is for.
Now: Hilbert's daily fun fact.
Hilbert: In the nineteen twenties, a linguist documenting Tasmanian Aboriginal languages noted that Cantonese speakers learning Hokkien consistently failed to reproduce the seven distinct tonal contours, instead collapsing them into a five-tone system that no native Hokkien speaker would recognize as grammatical — yet the Cantonese speakers remained utterly convinced they were pronouncing everything correctly.
a very specific kind of overconfidence.
Alright, so where does this leave us? The big open question is whether Matter and Thread will eventually make the multi-network approach obsolete. I'm skeptical, but the ecosystem is moving fast, and in five years the recommendation might be completely different.
The principles won't change though. Local control, graceful degradation, physical backup, design for failure. Those apply regardless of the protocol.
Thanks to Hilbert Flumingtop for producing. This has been My Weird Prompts. You can find us at myweirdprompts dot com and on Spotify.
Until next time.
