Z-Wave Alliance Announces Z-Wave Source Code Project Now Open and Available(z-wavealliance.org) |
Z-Wave Alliance Announces Z-Wave Source Code Project Now Open and Available(z-wavealliance.org) |
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 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.
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.
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.
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.
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.
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.
No it's not perfect but agree with others that the S2 seems to be way better.
Also bandwidth as a metric to aim for seems like a bad choice for IoT to me.
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.
What "Source Code Project" supposed to even mean? Any source code is part of some project(s).
See: https://z-wavealliance.org/matter-1-0-is-here-and-z-wave-is-...
Also: https://www.silabs.com/blog/bridging-non-matter-devices-to-a...
I don't agree, I think Z-wave will work with Matter using bridging.
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!
This open source project reportedly will start allowing more chip vendor as well, so it will be interesting how that affects the ecosystem.
* 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.
"Z-Wave Alliance Announces Z-Wave Source Code Project is Complete, Now Open and Widely Available to Members"
The three last words are the key.
I was getting excited as well, but looks like Z-Wave is still going to a closed group thing.
"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."
https://z-wavealliance.org/z-wave-alliance-completes-z-wave-...
> 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 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.
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.
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.
With the investment into Thread (still sharing frequency with 2.4 GHz WiFi) I could see this changing.
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).
Meanwhile, this HN discussion has people telling others to never use battery-powered Z-Wave devices, or it'll be laggy...
Matter and Thread can work with Z-Wave devices with the help of a bridge, so it's not as bad as you might think.
But yes, this is an attempt to compete with Zigbee.
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.
Zigbee allows using multiple vendors with ease, not tied to just one manufacturer.
Again, no internet connection required.
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.
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.
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?
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.
[1]: https://www.theverge.com/2022/12/12/23505097/matter-eve-firm...
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?
I'm sure this is all in the docs somewhere.
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.
[1]: https://www.iana.org/assignments/ipv6-address-space/ipv6-add...
[2]: https://openthread.io/guides/thread-primer/ipv6-addressing
All ipv6 addresses are routeable but that doesn't mean reachable. Link local and Unique local addresses are examples of non-global ipv6 addresses.
Matter is a communication protocol built on top of IP, with a special blessing to Ethernet, Wifi, BLE, and Thread.
Signify (née Philips Lighting) has got Matter certification for their Hue hub.
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.
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.
Edit: I stand corrected by the comment below.
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.
I'm really glad I went Zigbee as its been almost completely pain free even with third party non cloud software.
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.
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.
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.
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.
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.
We have well over 100 Z-Wave devices spread over 4000 sqft.
My house was 1200 sq ft, with a little over 200 devices.
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.
Hmm..
> 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.
[0] https://www.the-ambient.com/guides/matter-smart-home-explain...
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.
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.
How do you like it compared to zigbee and wifi?
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.
> One of the biggest issues with Zigbee is vendors selling devices that only work with their gateway.
Sold as such, but work as generic devices just fine, no issues. You just need a Zigbee dongle and ZHA, Zigbee2MQTT or deCONZ.
I also have things like humidity -> fan, I just do other things for the sensor network.
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.
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.
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.
Zwave is still strong in the commercial space
ZigBee is strong in the consumer space, especially light bulbs that commercial systems do not want to use.
I'm thinking it'll be longer before zwave dies for real vs zigbee, but it will only live on the back of the big slow commercial entities that back it.
Hue has always been all-in on Zigbee. (incl the new 3.0 standard - https://developers.meethue.com/zigbee-3-0-support-in-hue-eco...)
Ikea has gone basically all-in on Zigbee (https://www.wired.co.uk/article/ikea-smart-home-kit-reviewed...)
Amazon is embedding it their devices (At least 4 different models include a zigbee hub: https://developer.amazon.com/en-US/docs/alexa/smarthome/zigb...)
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).
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.
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.
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.
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.
Home assistant docs because I can't find a better description: https://www.home-assistant.io/integrations/zha/#binding-and-...
I've fallen back to physical switches that can be relay controlled.
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.
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.
The advertisements are captured by Avahi on my router... so they are on my existing IP home network.
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.
I've found that the color changing is cute for awhile and then I revert to "on/off" (and have actually decommissioned some of my Hues)
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.