I installed Z-Wave all over my house. Replaced all the switches, got the sensors, light bulbs where necessary, everything was Z-Wave... and it was a nightmare.
I ended up selling the house with everything Z-Wave still in it, and the new owners were happy to have a "Smart Home" capable home, but I will never again touch Z-Wave.
Once your Z-Wave network grows past a certain number of devices it becomes too chatty and devices will be unable to communicate data. That led to motion sensors being incredibly slow and or not triggering when needed. Light bulbs wouldn't change colors until seconds or sometimes minutes later when the network was freed up enough to send the commands.
These days I have three systems: Zigbee (through Ikea TRADFRI and Philips Hue), Lutron (Caseta wireless), and Thread (through HomeKit).
I have a bunch of sensors on both Zigbee and Thread and they fire in HomeKit and HomeKit takes actions to turn on/off lights as necessary.
Lights turn on/off almost instantly, motion sensors just work (the Thread ones especially are incredibly fast), I've got temperature sensors/lightbulbs on Thread as well.
I am looking forward to seeing what Matter/Thread bring next as that is definitely where I will be concentrating my purchases. Z-Wave had a chance, and unfortunately it did not seem architected/high bandwidth enough for the amount of devices I ended up having on my Z-Wave network (~200 devices)...
I have ~65 Z-Wave devices around my house, and I definitely notice lag from time to time. Recent versions of Z-Wave seem to be significantly faster and I've noticed it less.
I can't say I _love_ dealing with Z-Wave. But I do like having a single protocol throughout my house. At the very least, any issues I have tend to be consistent. I'd say in this past 6-months, I've practically had zero problems. I blame that overall improvement on ZwaveJs, because some of these devices are at least 5 years old and they're just cranking away without issue right along side my more recent Zooz and Inovelli devices.
That said, I've been strongly considering multiple Z-wave hubs, each running zwave2mqtt with a central mqtt server just to keep everything as fast as possible.
The single protocol throughout my house was my primary goal too, just to reduce complexity of having to deal with multiple hubs and integrations... but with my new house I did away with that.
Lutron Caseta for physical in-wall switches, IKEA Tradfri for cheap motion sensors/lighs, Philips Hue for more expensive motion sensors/lights, and a whole slew of Thread enabled devices, all controlled from HomeKit.
I don't really notice that its a bunch of different protocols/wireless standards underneath. I can control it from a single location which also makes it easier for guests/people visiting. Hand them an iPad with the Home app and they can control the house, or add them a Guest to my home on their own iOS devices.
I do miss some of the more advanced Home Assistant stuff I was doing, but overall the experience has been much cleaner, and with almost 0 lag.
Sounds like you had some non-zwave+ devices or you were using a lot of s0 encryption. Both are known to slow down the network. Like everything it’s gotten better over time. The 700 series stuff is pretty quick.
I was an early adopter for sure. This was back in 2016ish when I installed all of the devices. All of the devices were Z-Wave+ (specifically bought for that) but many of them did not support the newer encryption, and it ended up being a mixed network of devices for sure. Only the last few devices I bought supported the new encryption standard that was being rolled out at the time. I ended up getting a new Z-Wave hub that supported it to be able to securely enroll my new devices... but all it did was destabilize the network further.
It just left a horrible taste in my mouth, and once bitten, twice shy is definitely the case here.
The other thing that made things slow was sleepy devices that would wake up to report status. Things like motion sensors that also reported humidity, light levels, temperature and more (I do wish I could find a sensor like that for Zigbee/Thread... the multiple things in one was kinda nice). Every time they would wake up to report it would flood the network with traffic. And with each additional sensor I would have to tweak how often that would happen (and thus how accurate the data was over time) to reduce the amount of chatter on the network.
Ok yeah I only have 16 devices but I have 188 entities - I haven’t had any issues with sensors except with a power mains reader that didn’t support zwave+. After I removed that everything has been great. I also have a Zigbee network of about the same size which has also been pretty solid. One tip I didn’t know about at first is that you should have your transceiver plugged in to a usb extension cord and not directly into your pi/whatever.
I'm also running a Zwave network and it's highly responsive with around 50 devices. A friend of mine is running a few hundred devices and I haven't heard him complain much about it, all of his actions/triggers/etc seem to execute pretty much instantly. I'm going to guess that his network topology has a lot devices that are only accessible by repeaters, or aren't using Zwave+. Zwave is pretty much _the standard_ for large professional smart home installations and scales pretty well if implemented properly.
All the devices were Z-Wave+, it was the one thing I was buying for. Not all of them supported the new encryption standard which started rolling out after I deployed most of my switches.
This was in a ~1400 sq ft house, with a little over 200 devices (motion sensors/lights/switches/smart plugs/humidity sensors/weather sensors). The network had a few repeaters the longest hop was 2 hops from the controller to the end device.
This was your problem. I've been using Z-Wave in my house since, I think, around 2010. I had major major issues with it at first exactly like what you describe. I "fixed" them by doing two things.
A) Banished all battery powered devices from the network. Seriously. I have one in a hall closest I haven't gotten around to getting rid of, yet. The network seems fine-ish with only that sensor but large volumes of battery powered mostly asleep devices, it falls over.
B) Abolished any notion of using my Z-Wave network for sensor reporting. No tracking humidity or weather or power with my Z-Wave network because, as you mention, the Z-Wave network completely falls over when you have volumes of sensor traffic on it.
Want to have one humidity sensor which reports hourly? Sure that's fine.
Want to have a humidity sensor in every room which reports every time there is a 1% change in humidity? lol no, your network will fall over.
My Z-Wave networks are quite large at this point, 200-300 devices, and consist of Jasco/GE switches, Jasco/GE fan controls, Jasco/GE smart outlets.
Removing sensor traffic and battery powered devices from my Z-Wave network has made it extremely reliable for me. Unscientifically I would say 99% of Z-Wave control commands execute in <1s.
Jasco/GE switches is what I used throughout my house... but the whole point to me was to have a smart home.
So when humidity goes up in the bathroom, the controller would kick on the exhaust fan.
When temperature drops in a room that is active below a set point, the fan is kicked on for the forced air to start circulating + heat would get kicked on if necessary.
The whole point of having a smart home is to have a smart home that does stuff for you. Walking into a room and having lights turn on is the best thing EVER. I don't want to touch a switch if I can avoid it.
If sensor traffic is not meant to go on a Z-Wave network then they shouldn't allow those device classes to exist on the Z-Wave network.
On the sensors I had I cranked up the change required before it would report, but it also did periodic reports. I had to also update those so that the network wouldn't get flooded.
Sleepy devices/battery powered devices on the Z-Wave network for things like window sensors/door sensors is kind of the norm. It's hard to run power for all those things, and those sorts of security sensors are handy for not just automation but also for peace of mind!
The thing is that I have a similar setup now with Zigbee/Thread devices... and everything just works. In fact due to not having motion sensors that also act as humidity/temperature/light sensors I end up having more sensors on the network, yet it is far more stable.
Yeah, I used virtually all Z-Wave switches and dimmers in our new house (and motion sensors, temp sensors, etc) and haven't had an issue. The one time things seemed a bit laggy I had to "optimize" the network, which I realized I had NEVER done until that point. All issues went away.
We have well over 100 Z-Wave devices spread over 4000 sqft.
The Z-Wave network, while being a mesh network, is not a dynamic mesh. Nodes follow a precomputed path from themselves to the controller (with backup paths -- it's based on a node having a predefined list of adjacencies). You need to regularly poll each node in the system and determine it's optimal path from controller->node and node->controller and redefine it's adjacency list.
This process is entirely automated but does take some time. It's absolutely critical to do this when adding a new device (both for the new device, as well as the overall network) but I found that just doing it regularly works great. I have all my networks configured to do this at 4AM daily since the network is unusable for the few minutes it takes.
What you described is exactly why I'm waiting to install more automation in my home. I think Matter + Homekit (assuming Apple continues to work on Homekit as it's still pretty clunky for me UX-wise) will eventually be the solution for me as I'm already so deep in that Apple ecosystem.
If you've watched Linus Tech Tips videos recently, there's hours of content covering his Z-Wave woes. It's funny, his house is supposed to be automated but it ends up eating significantly more of his time in debugging than a manual house would.
If you have good wifi, you don't need to wait. I have a two story house and the floor plan looks like a T-shape, so I basically have 6 different zones. I pulled Cat6 everywhere for decent AP coverage. Right now I have about 80 Meross light switches and dimmers, 6 wifi blinds, wifi garage openers, Ecobee thermostats, multiple Apple TVs, ton of personal devices - easily over 200 devices on the LAN, most of them connected to HomeAssistant. Instant status updates with no problems except for the occasional need to reboot a wall switch due to power issues. Meross has a tiny hidden button at the bottom of each switch that instantly reboots the switch.
I bought Meross products off Amazon in bulk and absolutely love them. I have single pole switches, 3 way switches, single pole dimmers, 3 way dimmers, and a few smart plugs, power strips, and RGB bulbs.
PS: I even have a few Z-Wave devices and bought Zooz Hub ZST10-700 to work with HomeAssistant. I use these to measure power consumption on a garage freezer and a space heater. As long as the Z-Wave devices are close to the hub, there's no issue. But oddly enough they sometimes send negative power usage data which HA complains about.
The funniest part is he have to use two smart thermostat in each room and he realize that one smart thermostat heat up the other one and fucked up the temperature reading.
I have about 40 Zigbee devices connected to Zigbee2mqtt. Everything has worked since I started 3 years ago. Its only gone wrong when I mess an upgrade up (once).
I like that my smart home is not a full time job. It's nice being set it and forget it. Heck I've spent more weekends stopping Windows breaking my NVR recording system then Zigbee. It's great.
Zwave talks on 800-900MhZ and doesn't share medium with ethernet frames, so there isn't a concept of VLANs. Each Device meshes with anything and everything in its immediate broadcast range to provide some elasticity to the network. I can imagine at some high point of devices that the medium could become saturated
As the other commenter said it's not a LAN issue. Z-Wave is a mesh radio protocol totally independent of the LAN. There are in fact issues with older Z-Wave specs and versions bogging down due to congestion.
It's not that the Z-Wave stick falls behind, when a Z-Wave device is broadcasting everything else has to go quiet (nature of RF), but the transmission speed is just very low, so when chatty devices (think sensors that report multiple bits of information such as humidity, temperature, light level, UV level, and more) are sending data you can't also turn on a light.
When you have a lot of those devices on the Z-Wave network (multiple motion sensors in a room to do more accurate presence detection and the like) those chatty devices slow down the network tremendously.
I see a lot of confusion in the thread regarding IoT, and to clear up some of that, IoT operates across multiple different layers of the OSI model: PHY, Network, Application. PHY is how data is modulated (think radios, etc), Network is how data is shared / routed (think WiFi), Application is the contents of the data across the network (ie, Light: Off)
IEEE 802.15.4 - a PHY standard, equivalent to 802.11 standards that WiFi is built on top of.
Z-Wave - a recently acquired technology that vertically slices the entire OSI model, defining PHY interaction, network communication, and application. SiLabs recently acquired it, but it has always only offered chips from a single company.
Zigbee - multiple versions of several standards: the most popular used the 802.15.4 standard for the PHY, but used custom networking and custom application layers.
Thread - a 6LoWPan mesh network protocol, built on top of 802.15.4. It provides the Networking layer, but does not define application layers. Allows for IPv6 traffic. It also defines some security and BLE interop. Lots of companies make Thread chips and offer their own Thread stacks
Matter - an Application layer standard that defines the shape and behavior of messages sent across a variety of different networking technologies: Thread, WiFi, etc. Requires IPv6, and potentially border routers to translate the PHY differences.
The title is confusing and sounds like just PR. I thought they mean "Z-Wave project is Open Source now" but looks like source code is still in private github repository and you need to be a "member" to get access.
What "Source Code Project" supposed to even mean? Any source code is part of some project(s).
"The goal of the source code project is to provide a rich development environment containing relevant source code and sample applications under BSD 3 License."
> The goal of the source code project is to provide a rich development environment containing relevant source code and sample applications under BSD 3 License. The Z-Wave source code project will enable members to contribute code to the project under the supervision of the new OS Work Group (OSWG).
Which doesn't clarify at all. Is OS "open source" or "operating system", or something?
Is the relevant source code also BSD licensed? What does it include?
My guess is that this is a teaser article for an event that happened last month, and the repo is open now (or they forgot to open it).
Anyway, I came here to figure out what Z-Wave is, and why it is better than other smart home networks. Any ideas?
z-wave is kind of competing with zigbee for low power mid-range wireless standard for smart home or smart building since like 20 years ago? then we have low power bluetooth and low-power wifi joined the party.
z-wave was proprietary which did not help its deployments, but still I recall it was the most deployed low power wireless devices for IoT. I worked on zigbee and never liked it. I wish z-wave was more open back in time.
Did not track what's going on these days for low power mid-range wireless, general feeling is that zigbee did not take off, zwave is used as before(you license it and put it to your sensors), and more and more are using low-power wifi and even bluetooth instead.
Personally - I got kinda the other feel. Seems like Z-Wave is slowly dying in favor of zigbee devices.
I can't really even find z-wave bulbs right now. And basically any device I might want (curtains, alarms, sensors, lights, motors, thermostats, etc) comes in a zigbee form.
I agree that Z-Wave did the better standards enforcement, but Zigbee went with the age old route to success: manage to be cheaper.
Throw in that the two most common automation situations tend to be either:
1. Upstream cloud service
2. Local management engine (ex: HomeAssistant, OpenHab, etc)
And it just doesn't really matter all that much how compatible devices are in terms of point to point control. I can just route the message through HA and take the action I want - mixing and matching as needed.
Plus - Alexa pro ships a directly integrated zigbee hub now, which got a lot of devices moving that direction, and Ikea makes some great super cheap zigbee devices.
Bluetooth and Wifi devices are the worst of both worlds, in my opinion. Wifi usually needs integration with an upstream service which is a non-starter for me, and bluetooth is just really limited on total device count. Both also eat through a lot of power compared to z-wave/zigbee.
It's pretty cool that several recent zigbee switches are completely battery/wire free. They literally use the energy you expend to push to the button to send the signal.
> I can't really even find z-wave bulbs right now. And
Even though you can find a Z-Wave bulb, it defeats the purpose of Z-Wave. Z-Wave isn't for consumables like bulbs, it works best for hard-wiring electrical devices into your home that will be permanently installed in a professional installation. I wouldn't feel comfortable putting a Zigbee switch in the wall since it's likely to become obsolete, whereas I'd be confident Z-Wave will still be around and supported in 10 or 15 years.
I don't really see Zigbee dying right now. Hell - I used it before home automation was really a thing back in college almost 15 years ago now, and it's going strong today.
Wifi is basically a non-starter for any real automation since it takes a boat load of power, and requires a non-local server (at least without some serious work on your part). It's a great intro spot for consumers who want to try a color changing bulb they can control with their phone, since the initial buy in cost is lower with no hub - but it's not really the same.
For z-wave on the other hand... I literally cannot find a place to buy a-19 standard socket bulbs that support it right now. Lots of "controller kits" but no bulbs.
Same for thermostats - there's like 3 z-wave thermostats on amazon right now. There are dozens of zigbee models.
Honestly - on Amazon at least, a lot of searches for "z-wave [device]" end up returning mostly zigbee results.
Ex: Go search Amazon for "Z-wave plug": Row 3 starts to return zigbee devices.
Go search again for "Zigbee plug": It's zigbee devices all the way down the page (one early result does both zigbee and z-wave, but otherwise you have scroll waaay down to see any overlap)
Basically - Having both Ikea and Amazon go in on Zigbee has radically shifted the market from where it was 3 years ago (when I would have probably agreed that z-wave was the better pick).
It's a very different experience if you go to Walmart and try to find smart devices.
ZigBee devices are still available, but companies I've seen that used to have them almost exclusively swapped to WiFi over time.
Hue is still ZigBee for example, but the old generic bulbs at home Depot? Gone. Liquidated. Nobody understands smart hubs. Everyone understands their app.
Bulbs, plugs, sockets, even thermostats. What do you think is the ratio of nest thermostats vs zigbee?
Big business buys thermostats from big retailers who sell in batches of hundreds. My dad's home, built a year or two ago, is wired up with zwave.
You don't see bulbs because the companies who set up zwave almost exclusively stick the switches in the wall and leave the lights dumb. Built to work for decades without configuration sort of thing.
My thinking is that the wifi stuff is going to eat ZigBees lunch, although your point about battery life is a very good one.
Zwave, in the space it's in, seems more durable to me. One day lights will go out and replaced with wifi bulbs that everyone can use, but the companies using zwave are way more picky and will not want to go wifi.
that's new to me, did not track this field for a few years. zigbee protocol was too complex in the past for me on resource restricted devices, while zwave is so much light-weight, then that's just the technical side.
maybe that's why z-wave now opens up, it's forced to do so or it dies.
Zigbee was bigger in Europe, Z-Wave in the US. Or at least that was what I always read ;)
Philips Hue was always the big "Zigbee? Never heard of that" Zigbee producer, nowadays, there are also good and cost-effective things from Sonoff and Aqara, and cheap but hit-or-miss devices by tuya (heavily white labeled)
Z-Wave's primary advantage is, ironically, the openness of the ecosystem. Due to the lack of a stringent certification process Zigbee vendors can (and routinely do) lock devices to their proprietary hub. I'm guessing that is one main motivator for its failure. Though, keep in mind that Hue (one of the most successful IoT vendors) is all open Zigbee.
Zigbee's main advantage is that it's cheap.
Thread (the new standard to fix the old standards) is apparently just "Zigbee, the good parts". We will see if vendors drive it into uselessness like before.
Yep, Z-Wave's advantage is that they enforce the standards. They require that an end device from one manufacturer can work with any other manufacturer's controller.
That was a bigger deal when controllers were stand-alone electronics products, though. Being in the cloud, a controller like SmartThings can add one-off support for non-standard end devices at any time, so there's less need for everything to be on one standard.
thread is zigbee but more IPv6 friendly, they both run at 2.4Ghz like wifi and bluetooth do, which could be crowded and in short distance.
zwave by default is at 900Mhz so it goes much further than 2.4Ghz and it even has a long-range version(for a few km), that's another advantage of zwave.
all of them are low-power, all of them need a gateway or hub to talk to wifi and the internet, other than zwave is strictly co-operatable, zwave is also *much much* simpler, if zwave truly opens up, it could take over the competitors IMO.
My house is standardized on Z-wave because I can afford a bit extra $ for each device in exchange for reliability. I can also add Zigbee if I need to, since my hub can do both. I just haven't needed to yet. Everything is available in both Zigbee and Z-wave versions, so I choose to pay the extra for added reliability.
I haven't had much luck with Bluetooth and Wifi IoT devices. They tend to last a couple of years and then die. They also are more hassle to set up, and use more power. I don't need more hassle in my life. Z-wave and Zigbee are both more reliable, with Z-wave taking the slight edge over Zigbee.
What's happening now is Thread (Matter) is coming. Thread is basically Zigbee Mark II. Thread is on par with Z-wave, but it supposed will retain its edge in cost benefit. I may start buying Thread stuff as it becomes available, but the problem is my mesh is solidly Z-wave. It doesn't seem worthwhile to start replacing stuff that works perfectly fine.
Z-Wave also supports device associations which Zigbee doesn't. You can permanently associate devices together (i.e. switches) to create a virtual 3-way switch that will work even if the "smart home hub" is down. Which, from a reliability perspective is a much better design if you're installing something commercially.
I wish Z-wave or something would support some form of physical connection instead of relying on wireless. I'd be perfectly happy running CAT-5 to every damn switch in the house if I could get reliability from it.
I've fallen back to physical switches that can be relay controlled.
Z-Wave stands out because many of this devices can act as repeaters and extend your range. They also offer security which others do not. They also work really well but can get really expensive.
You're looking at 2-5x the cost of a Zigbee device. Zigbee is not without it's problems but I've been able to solve mine with $14 repeaters while my Z-Wave problems have complicated solutions and still might be solvable.
Z-Wave differentiates itself from other IoT networks in that it's a closed proprietary network that you access by purchasing their proprietary hardware. This offers network stability and complete interoperability between devices because it's all controlled by a single vendor. Z-Wave device manufacturers interface with the proprietary hardware to provide state and receive command.
Many vendors make USB dongles with Z-Wave Controller interfaces hanging off of them that you can interface using a terminal. These dongles allow anyone to make their own Gateway for controlling other Z-Wave devices.
Because the interface is completely controlled and locked down, it means vendors can't embrace/extend Z-Wave or lock their devices down to their own proprietary controller.
There are some downsides to this setup, like distributing updated firmware for devices is challenging. No one wants to hand their blobs over to opensource projects to allow them to push updates.
Now that Matter and Thread are finally starting to roll out, is there really any good reason for new products to still use Z-Wave? Or am I just crazy to see this as Z-Wave trying to continue a format war (first started with Zigbee) that they're almost certainly going to lose?
Z-Wave devices are almost universally better (longer battery life, longer range, more reliable, etc.) than Zigbee (I have both). Not sure if this is based on price (Z-Wave devices being more expensive), certification, different radio frequency, or something else.
With the investment into Thread (still sharing frequency with 2.4 GHz WiFi) I could see this changing.
I don't own ZWave devices, but comments here seem to question their superiority.
The range and battery life is likely due to the lower-frequency it uses, which is less congested and longer range. Typically, this will translate to a lower power usage (better battery life).
> I can't fault it but I do worry about future security updates should something be discovered in Zigbees stack.
I agree it’ll likely be few devices that’s ever see an update but I think theoretically Zigbee proton supports OTA from the hubs. I know home assistant supports automatic OTAs from a handful of brands.
Thread is a mesh protocol on 6LoWPAN, which in turn is based on the same underlying 802.11.4 as Zigbee in the 2.4 Ghz spectrum.
Its claims to fame is having reasonable response times/batteru life and being based on IPv6. Being based on IP allows devices to talk to one another, and for bridging those devices to the broader network and potentially to the internet with clear layer separation.
Matter is a IP-based IoT discovery and use standard. Devices advertise Thread and/or Wifi support for wireless support. It also standardizes onboarding (I know BLE is an option there) and the underlying security, and mandates certain capabilities such as supporting multiple 'admin' software at once.
Devices using other wireless tech can also theoretically work with Matter with a gateway that does protocol translation, supports device onboarding, and then exposes them onto the network.
Thread is a mesh IPv6 based network that operates over the 2.4 GHz ISM band but is not WiFi. Matter is a communication protocol built on top of Thread, WiFi, and BLE (and potentially others in the future).
Thread and ZigBee operate in the 2.4 Ghz and also 833/915 Mhz although in practice I've never seen any devices that explicitly claim to be using the sub Ghz bands. It's not WiFi, it's IEEE 802.15.4. Matter supports devices connected through WiFi, Thread and Ethernet with BT provisioning.
I'm using no cloud Zigbee home automation. Seems to be very reliable and has really great range thanks to the mesh networking. It's also really simple.
Zigbee allows using multiple vendors with ease, not tied to just one manufacturer.
I'm using Insteon personally, which is mesh networked but relatively similar to Z-Wave. (And it's entirely proprietary still.)
It's not just about cloud connectivity though: I don't want my home automation hardware speaking IP or anything like it. Nor do I want them to need a complicated enough protocol to justify requirements like firmware updates. All of this introduces opportunities for security flaws and the ability to create botnets.
Home automation hardware should be simple, take simple instructions over local communication bands, and then a single central controller should bring the greater intelligence and access.
I think my Insteon thermostat is nearly the ideal smarthome product: It's a thermostat, and can work entirely standalone as just that. It cannot be updated or reprogrammed. But it will accept commands (no different than button presses on the front of it) over the RF protocol, and of course, send its sensor data and operating status.
Things like incidents where Nests had software updates that let everyone freeze or whatever in the winter just... isn't really a concern with a good design like this.
> I'm using Insteon personally, which is mesh networked but relatively similar to Z-Wave. (And it's entirely proprietary still.)
One of the benefits of non-proprietary (especially IP based) is that you're more immune to company failures, like when Insteon shut down.
> I don't want my home automation hardware speaking IP or anything like it
Why? Its just a protocol? It doesn't mean a cloud is involved, it doesn't even have to be networked to your main LAN.
> Home automation hardware should be simple, take simple instructions over local communication bands, and then a single central controller should bring the greater intelligence and access.
IP seems the simplest option. Even though its more layers than a binary protocol, the interoperability and easy ability for most software people to create IP software means longer future.
> It cannot be updated or reprogrammed. But it will accept commands (no different than button presses on the front of it) over the RF protocol, and of course, send its sensor data and operating status.
What was your plan when Insteon went belly up? The lack of ability to reprogram means you couldn't update it to work with a newer hub/protocol.
Agreed, though I am not reliant on the Insteon company for anything but parts, since it's an entirely local protocol. And they're producing new parts again! I was also in a bit lucky of a position: I had plenty of spare hardware on hand while the company was shut down.
> IP seems the simplest option
If security is unimportant, sure. Insteon hardware has been around for three decades, but nobody in their right mind would be using network hardware from back then. This is a case of where complexity kills. Home hardware needs to work for decades.
> Plan when Insteon went belly up
I use their PLM interface which is just a COM port on my PC. The company's existence has no impact on my ability to connect it to newer things.
> If security is unimportant, sure. Insteon hardware has been around for three decades, but nobody in their right mind would be using network hardware from back then.
Sure to hardware but we’re all still using IP protocols. Countless companies have risen and fallen and that hasn’t changed. Networking equipment if kept LAN only should still work fine after 3 decades.
> which is just a COM port on my PC. The company's existence has no impact on my ability to connect it to newer things.
This sounds just as complex and risky as any modern protocol, just more obscure. If you need a PC for newer devices then it’s all the same anyways.
Most people aren't equipped to ensure their IP devices can only talk to other LAN devices (I am, my cameras live on a VLAN that can't route to the web). Combine IP capability with the possibility for software updates, and you have botnet fuel. It's why IP cameras are a leading source of botnet participants: Long-lasting IP hardware often managed by users without VLAN segmentation.
I agree that segmenting VLANs and stuff aren’t accessible to average people, but there are accessible alternatives. I recently upgraded to Google WiFi pucks after babysitting a ubiquiti installation for almost half a decade, and you can “disable internet” on devices without disabling LAN. You’d have to trust the device to be friendly on the LAN but it’s good balance for consumers. After Eufys whole security meltdown I updated a bunch of IOT junk to lose internet access. I saw a lot of tech site’s recommend this, and it’s definitely “easy enough for the parents to do”.
That's a single proprietary option from a single vendor with its own storied history of both poor privacy and poor long-term hardware support. (I believe they've effectively bricked the first generation of their routers already!)
It's so much smarter to just not have smarthome devices on the network, and have a single interface or bridge which acts as a security barrier.
I think many routers have a simple feature to restrict internet access for a device on the network. I simply highlighted a consumer product (highly recommended by tech sites) that many average consumers may have.
This is not a realistic view. Most users do not mess with the settings on their router. Most, do not have this feature either. This isn't a good or practical assumption to make of most home networks.
As an aside I have some Best Buy "HomeKit" compatible switches, and they shut down the app long ago (and gave me gift cards for the price I paid for the switches) - but they're still working with HomeKit and if that were to fail they'd still be a switch.
AIUI, Z-Wave means interoperability at device level, without even a controller or a compatibility shim, across a variety of manufacturers. Niche devices can exist because it's easy for a niche manufacturer to integrate. And if my Internet connection is down, or even the controller is down, the system still functions with graceful degradation only.
With Zigbee, AIUI you get a mostly closed system locked in to whichever Zigbee vendor you chose. Interoperability only occurs at a higher level in a much more error-prone and lowest common denominator fashion.
> With Zigbee, AIUI you get a mostly closed system locked in to whichever Zigbee vendor you chose.
No, all devices should work with other vendors. Some vendors don't play as nice, however. The Zigbee light-link spec should allow all lights to work with all light controllers (eg zigged remotes on the wall). Any "true" hub should work with all zigged devices too. Some minor company's hub may not support all products, but thats if they don't comply with the protocol - ZWave theoretically has that problem.
Zigbee is probably more "open" since the protocol has less certification requirements. The only main bifurcation is that "Zigbee" and "Zigbee Light Link" are slightly different and you may end up with a "ZLL" hub that doesn't support non-light devices.
> And if my Internet connection is down, or even the controller is down, the system still functions with graceful degradation only.
Zigbee supports this behavior. You can pair lights/remotes for example with no hub required. Its usually advertised as a graceful upgrade path instead of a degradation path.
Based on what others have also said, it sounds like you're describing interoperability in Zigbee in theory, whereas I described interoperability in Z-Wave in practice.
The problem with Z-Wave is the price and consistency. I bought an extender so it worked in the garage but it never worked. I've spent hours/days trying to get them to work by closely following instructions and buying dongles to better manage nodes. Still, I never got my lock and switch to work. I'll likely just end up replacing them with wifi devices at a fraction of the cost.
The new Thread protocol (part of Matter) is basically Zigbee on steroids which gets it up to parity with Z-wave. The reason to choose Z-wave over Thread is that Z-wave works now and has many devices available to buy, while Thread works in theory and the devices are very few in number. Thread devices are due out in force next year. So this actually is perfect timing for Z-wave to make this move now, right as the first wave of Thread devices are approaching.
There were a bunch of missed opportunities for Zigbee to become enshrined in the home.
For example, the first and second-gen Nest thermostats had a Zigbee radio built-in. At acquisition by Google, Nest heavily leaned into the wifi/cloud side for control and the Zigbee radio was squandered, other than for some esoteric “Works with Nest” protocol that maybe 2 other third-party devices supported.
It's definitely not as proprietary, which is probably relevant to a lot of potential implementers. There's close to no public information about Zigbee implementations while Google invites people to implement Thread through OpenThread.
Thread likely has more features with some pretty fully featured networking support, which some may consider positive, but some negative.
> Matter started life in 2019 as Project CHIP (Connected Home over IP), a collaboration between some of the biggest players in tech; Apple, Google, Amazon, Samsung, the Zigbee Alliance, and various other tech brands, which aimed to create a unified smart home standard. [0]
Ahh, that explains it. I bought most of my devices a few years before this existed, and having those companies involved pretty much guarantees people expecting this to succeed over anything else.
Honestly though, Google and Amazon being involved make me less interested in it. It pretty much guarantees requiring a cloud connection.
> Honestly though, Google and Amazon being involved make me less interested in it. It pretty much guarantees requiring a cloud connection.
1. Except the spec says otherwise...
Matter is basically a reworked Zigbee-over-IP with a special "we think you should use Thread" push. The spec (which is public), requires devices to work over LAN, but provides an escape for devices to have extra proprietary functionalities that aren't in spec. It doesn't require LAN-only, but it is "at least LAN".
The spec is based off HomeKit's networking model (IP based + mDNS discovery) with a data model closer to Zigbee's (binary format, device node/trait/tree). Its design-by-committee so you have lots of features, some of which expect a cloud (ability for devices to upload logs) and some which don't (general device control). Almost none should require a specific cloud (eg. OTAs can come from any hub, signed by manufacturer, logs can be uploaded to any hub's cloud).
You should be able to run any hub/voice-assistant/controller you want. Apple HomePods should allow most cloud-free control for a major company's product, while something like HomeAssistant will allow complete OS self-hosted control.
2. Google and Amazon obviously have cloud interfaces, but both also already allow LAN-control of smarthome devices already, and that will accelerate as they push into matter.
This will help them lower cloud hosting costs themselves (which is a major expense, see Alexa layoffs). Amazon seems less committed to Matter, but Google was one of the major matter contributors (along with Apple), and "donated" a bunch of IP to get it working (eg thread). Most companies will probably push for LAN control due to latency/UX impacts, especially since the can still gather out-of-band performance metrics via hubs.
Alexa and Google Assistant are starting to move to on-device NLU and processing, so cloud-phobia or aversion is likely not going to be a major problem in a few years.
Any reasoning why? My home automation is 95%+ Zigbee, and I don't see any issues. Mesh networking works very nicely, reaching far corners of the house.
Z-Wave's mesh networking was a giant pain to get functioning correctly, and good luck if devices were multiple hops away... things would just randomly fall off the network.
With Zigbee (IKEA TRADFRI and Philips Hue) I haven' had any of those issues, nor with any of my Thread devices.
I have some zigbee stuff with HA, and I have made some custom sensors with esphome. I'd like to try some thread stuff.
How are you currently using thread/what are you using it with? Do you have any recommendations for how to get started with it now - I've been rather confused as it feels like its in limbo right now.
My Thread devices are all HomeKit devices, and they work incredibly well. Once they are joined to the Thread network they show up as IPv6 devices in mDNS and just work.
I have a ton of Thread enabled lightbulbs, smart outlets, and sensors on Thread, and I haven't had any issues.
They seem to mesh really well, store and forward for devices that are sleepy just works, but sleepy devices waking up and sending traffic is almost instant.
I do not own any devices that use WiFi, other than my Ecobee thermostat. So I can't compare against that. I would put the Thread devices up there alongside the Zigbee devices in terms of reliability, if not more resilient since I have multiple thread border router capable devices (multiple HomePod mini's and Apple TV's with Thread) so a device getting restarted (unlike a Zigbee hub like Hue/IKEA TRADFRI) won't affect the network/ability for the devices to trigger responses.
> Once they are joined to the Thread network they show up as IPv6 devices in mDNS and just work.
I don't have any thread devices but I've been eyeing them.
Do they show up to your router/networking gear as IP6 devices? I know that this is the underlying tech, and use mDNS, and thread routers are IP routers, but I always assumed they wouldn't integrate with existing IP home networks.
I see mDNS advertisements with my devices in them (such as Nanoleaf bulbs/Eve Thread devices), with a custom IPv6 prefix from the ULA, I assume assigned by my Thread border router.
The advertisements are captured by Avahi on my router... so they are on my existing IP home network.
AFAIK the majority of Zigbee products only act as end device nodes and don't act as routers. So they won't actually be doing anything to extend the mesh.
The main benefits of ZWave over Zigbee is superior penetration, improved interoperability, and reduced interference with WiFi devices.
One of the biggest issues with Zigbee is vendors selling devices that only work with their gateway. As a consumer it sucks because it's rare for a single vendor to excel or even offer devices in every product category.
Firmware for Matter is going to be enormous, zwave is a lot simpler. Lots of pessimism in the market about the interoperability of Matter. No mfgr is going to be motivated to encourage their customers to interoperate with a competitors gadget. My prediction is everything will ship with a "matter" icon on it, but support will only be vertical silo, maybe even worse than things are now.
Thread is basically a full wifi-ish TCP/IPv6 stack, so, again, pretty huge compared to a tiny little zwave firmware.
Interesting angle to think about: Is the middle or end of a chip shortage the worst possible time to ship a HUGE new standard, or is it the best possible time because there's no stockpile of smaller memory smaller CPU legacy microcontrollers?
> My prediction is everything will ship with a "matter" icon on it, but support will only be vertical silo, maybe even worse than things are now.
There's already available evidence that contradicts that prediction. Eve[1] is rolling out a firmware update for Matter support that makes their devices usable across all Matter supported platforms. There are some features that aren't yet available at the Matter level so those will remain in their own app for now. Despite being iOS-only previously with Matter support they're now also reaching Android devices and are working on an Android app for it too to cover the missing features in Matter.
Agree with you, the first company to defect from interop will have a higher financial report then mgmt will demand engineering implement prevention-of-interop features or at least ignore the issue.
Yeah,it's going to be tough. However, the one good thing about Z-Wave (even relative to zigbee) is interoperability - devices pretty much work for the most part, even with generic drivers.
At some point there'll be a matter/thread bridge to z-wave.
The big question about matter/thread devices is cost.
The second is going to be security. If they're IPv6 then they're globally addressable, which is bad bad bad. How is that going to be mitigated? Is the hub going to be the router for those devices and block all incoming connections?
> If they're IPv6 then they're globally addressable, which is bad bad bad. How is that going to be mitigated?
I think you need to read up on IPv6 a bit. There are whole IPv6 ranges set aside that are not globally routable / part of the global unicast range[1].
Thread has link-local and mesh-local addresses. The global is only gained through SLAAC/DHCP or manual configuration by an administrator so by default no, your devices aren't accessible to the outside world. And if you do have routable IPv6 in your network, you should already have a firewall on your network edge for this because all your existing devices would already be exposed. The addressing primer[2] for Thread also applies to Matter for further details.
Everybody here keeps talking about how reliable Z-Wave is, and I absolutely HATE mine, and was telling someone last week that I would never recommend them to anyone. Have I just had a bad experience? I have 3 Z-wave switches, and once a month at least one of them needs to be reset. They just stop responding until the air gap switch is pulled. I hate them and I can't rely on them at all.
Conversely, I have 30+ Zigbee switches, and they are quite reliable.
The only reason that I have the 3 Z-wave switches is that I needed paddle switch fan controllers with an almond color, and I could only find them in Z-wave by Enbrighten. (Side note: why are almost ALL the smart switches only available in white?)
Of course, as I type this, my RPi with HomeAssistant got bricked with the latest update, so now my SmartHouse is not merely dumb, it's stubborn!
I had a regular resetting problem with a switch once. Bugged me for months. Turned out the button switch would occasionally get stuck in the pressed position and cause the reset. Bad design, but wasn't the protocol/firmware's fault.
One thing i have read but not seen brought up here yet is that zwave has so far only have one hardware soc vendor (silicon labs). This would seem like how they have been able to enforce certification compliance. And it’s probably leads to higher cost (hardware and software?) and thus lower adoption.
This open source project reportedly will start allowing more chip vendor as well, so it will be interesting how that affects the ecosystem.
Z-wave uses lower frequencies compared to something like Matter so it you can use a lower power or get more range. One competing 802 standard is 802.11ah, or WiFi HaLoW which barely exists right now but should be the best thing available.
First, there was X10. There was appetite for something better. There were several candidate replacements, including:
* UPB - Universal Powerline Bus (powerline)
* Insteon (powerline + wireless)
* Z-Wave (wireless)
* Zigbee (wireless)
Of these, Zigbee seems to be in the best position these days.
Z-Wave is/was a closed system - you had to get compatibility testing/certification in order to sell products using the tech. It's fairly lightweight, reliable, and well respected by users.
I ended up selling the house with everything Z-Wave still in it, and the new owners were happy to have a "Smart Home" capable home, but I will never again touch Z-Wave.
Once your Z-Wave network grows past a certain number of devices it becomes too chatty and devices will be unable to communicate data. That led to motion sensors being incredibly slow and or not triggering when needed. Light bulbs wouldn't change colors until seconds or sometimes minutes later when the network was freed up enough to send the commands.
These days I have three systems: Zigbee (through Ikea TRADFRI and Philips Hue), Lutron (Caseta wireless), and Thread (through HomeKit).
I have a bunch of sensors on both Zigbee and Thread and they fire in HomeKit and HomeKit takes actions to turn on/off lights as necessary.
Lights turn on/off almost instantly, motion sensors just work (the Thread ones especially are incredibly fast), I've got temperature sensors/lightbulbs on Thread as well.
I am looking forward to seeing what Matter/Thread bring next as that is definitely where I will be concentrating my purchases. Z-Wave had a chance, and unfortunately it did not seem architected/high bandwidth enough for the amount of devices I ended up having on my Z-Wave network (~200 devices)...