Still on zwave which works great. Don’t see the point of this standard which runs over an inferior type of networking and is brought to us by the companies that created the interoperability problem in the first place.
Zwave stuff are way overpriced, even comparing to the wifi or zigbee quivalent.
As an examble I get good quality (aka not an unknown chineese brand) Zigbee smart object for 2 to 5 times lower price than what a Zwave equivalent.
Same goes for wifi one, which are roughly the same price as the Zigbee stuff.
The only good aspect of Zwave was the security protocol that was more robust than the Zigbee equivalent (albeit Zigbee 3.0 closed the gap) and more standardized endpoints. Matter objective is to get those two to surpass their ZWave equivalent.
Unfortunately my gateway (which is compatible with both Zigbee 3.0 and ZWave btw) is still waiting for its Matter/Thread upgrade, so I can’t try it yet, but compairing my Zwave objects with my Zigbee ones, I see no point of buying the former over the later.
I once owned a bunch of WiFi connected devices. One day I inspected my router logs and found out that they were all making calls to a bunch of services that weren’t the vendor - things like Google, and Facebook.
WiFi connected devices require connecting to a router; in most homes, this is going to be one that’s also connected to the internet - most people aren’t going to buy a second router just for their smart home, or set up a disconnected second LAN on their one router. And nearly all of these devices come with an app, which talks to the device through an external service (I’m looking at you, Honeywell, and you, Rainbird). This is a privacy shit-show. WiFi is a terrible option for smart home devices.
ZigBee, well, I haven’t had any luck with it - pairing problems which are certainly just a learning curve in my part and not an issue with the protocol. I chose ZWave myself because I read about the size and range limitations of ZigBee technology, versus ZWave, but honestly I could have gone either way. Back then, there was no appreciable price difference in devices. Most hubs support both, though, and I can’t see why I wouldn’t mix them (other than I need to figure out how to get ZigBee to work).
In any case, low-power BT, ZigBee, or Zwave are all options, whereas I will not allow more WiFi smart devices in my house. I’m stuck with Honeywell and Rainbird, for… reasons… but that’s it. I don’t need to be poking more holes in my LAN security.
I had some difficulties too with Zigbee pairing, that’s one of the shortcomings that Matter fixes with their QR Code pairing. On my case it was just about understanding that you have to put both the device and the coordinator in pairing mode for the “interview” to happen. And that is has to be close to any device of the target network that isn’t battery powered (they can do the interview on the coordinator behalf).
I stopped using WiFi devices for the same reason, but found out about Tasmota, an open-source firmware for ESP devices. It requires a local coordinator, but never send anything to Google and the likes. It can be hard to flash, but some vendor, like Nous, offers pre-flashed devices. Some of them are also Matter compatible (if it has recent hardware as old ESP device has too little rom to handle the Matter code).
The only problem I had with my ZigBee network was pairing the lightbulb but that was because the UX to set the bulb in pairing mode required to switch them on and off 5 1/2 time with a too precise timing for a normal human.
This is good information. I had a complete failure with flashing Tasmota once, and bricked a $100 device.
I like the project, though. My biggest complaint is that - at least for what I was trying to flash, the Linux support was iffy. I was trying to flash something for HA, and the instructions assumed I had access to the computer running HA (which is a headless device in a closet in the basement - entirely unpractical for doing fiddly pinning while trying to flash) or using a web browser with webUSB - which Firefox on Linux doesn’t. So eventually I found a completely unrelated set of instructions I could run from the CLI from my desktop over a cable connected to said desktop, and while it appeared successful, the device is bricked. I can’t even get it into flash mode anymore.
I don’t think any of this has to do with Tasmota, except that the Linux tooling seems either weak, or make assumes people are running Chrome; and if you’re security conscious enough to be flashing a device to run Tasmota, you’re not running Chrome.
So I’m not doing that again. It’s a hundred bucks and two days of digging around for tooling and instructions I’d like back.
Again, not Tasmota’s fault, but it’s not super accessible.
I feel your point regarding the WiFi devices and that they shouldn’t be recommended to casual users. But if you just set up an isolated VLAN with its own SSID and use e.g. homeassistant running locally to orchestrate them, then what’s the harm? If your goal is privacy, you need some kind of local “hub” anyway, and to me it makes way more sense to be able to place that machine anywhere, regardless of e.g. bluetooth reception to your smart home devices (since that is taken care of via the additional SSID on your WAPs).
Sure, I could do that, but not everyone can. But you still have the problem that many of these devices don’t function well unless they can phone home; they don’t very firmware upgrades, and they expect to be controlled by a bespoke app. If you filter out all the devices that are HA compatible without running through an external service, you shear the product choices in half.
I would argue you get what you pay for in terms of interoperability and reliability, but I can imagine people willing to trade some of that for a lower price.
Interoperability comes from standardization, which Zigbee sorely lacked. But actors like Tuya or Leroy Merlin built their own standard over Zigbee, which means anything that has “works with Tuya” will work with any Tuya coordinator of any brand (same for Leroy Merlin ecosystem). And even those who don’t usually mostly works.
With that you’d get ZWave reliability, most, if not all, of its security features, with Zigbee lower price. And they still works great with third party coordinator.
But it is true that Z-Wave uses lower frequency than Zigbee (868MHz vs 2.3GHz). It means lower frequency interferences, and better reliability over high distances.
Don’t see the point of this standard which runs over an inferior type of networking
Inferior how? Matter is not comparable to Z-Wave. Z-Wave is a mesh network, Matter is just a standard which would allow Alexa, Siri, Google, etc. to control the same devices. To allow Z-Wave like functionality, Matter is able to work on top of Thread, which is in fact superior to Z-Wave.
is brought to us by the companies that created the interoperability problem in the first place
Of course. You don’t want to be the company known for refusing to participate in an open standard, even if you secretly don’t want it to succeed. Anyways, there’s no reason for companies to not want an open standard for controlling smart devices, since it literally helps everyone support more devices for basically no effort once you add support for Matter.
Matter over Thread is similar to Z-Wave at the user level and supports a lot more device types. The below is from Silicon Labs
• Application layer: Matter is an IP-based application layer protocol that can uses lower layers from other technologies such as Wi-Fi, Ethernet, or Thread. Z-Wave is complete protocol covering physical layer to application layer Its a non-IP MESH protocol that uses sub-GHz ISM bands.
• Device types: Matter supports a broader range of device types than Z-Wave, including cameras, speakers, TVs, and more. Z-Wave focuses on low bandwidth devices that require low power and reliable communication, such as security systems, sensors, switches, and locks.
• Security: Matter provides end-to-end encryption, device certification, and cloud integration, which can enhance the security and privacy of smart home devices. Z-Wave also offers encryption and device authentication, but it does not have a built-in cloud service.
• Compatibility: Matter is compatible with popular voice assistants and other IP-based devices, which can make it easier to integrate with existing smart home ecosystems. Z-Wave requires a Z-Wave specific gateway or hub, but has a large number of compatible devices that work together.
Still on zwave which works great. Don’t see the point of this standard which runs over an inferior type of networking and is brought to us by the companies that created the interoperability problem in the first place.
Zwave stuff are way overpriced, even comparing to the wifi or zigbee quivalent.
As an examble I get good quality (aka not an unknown chineese brand) Zigbee smart object for 2 to 5 times lower price than what a Zwave equivalent.
Same goes for wifi one, which are roughly the same price as the Zigbee stuff.
The only good aspect of Zwave was the security protocol that was more robust than the Zigbee equivalent (albeit Zigbee 3.0 closed the gap) and more standardized endpoints. Matter objective is to get those two to surpass their ZWave equivalent.
Unfortunately my gateway (which is compatible with both Zigbee 3.0 and ZWave btw) is still waiting for its Matter/Thread upgrade, so I can’t try it yet, but compairing my Zwave objects with my Zigbee ones, I see no point of buying the former over the later.
I once owned a bunch of WiFi connected devices. One day I inspected my router logs and found out that they were all making calls to a bunch of services that weren’t the vendor - things like Google, and Facebook.
WiFi connected devices require connecting to a router; in most homes, this is going to be one that’s also connected to the internet - most people aren’t going to buy a second router just for their smart home, or set up a disconnected second LAN on their one router. And nearly all of these devices come with an app, which talks to the device through an external service (I’m looking at you, Honeywell, and you, Rainbird). This is a privacy shit-show. WiFi is a terrible option for smart home devices.
ZigBee, well, I haven’t had any luck with it - pairing problems which are certainly just a learning curve in my part and not an issue with the protocol. I chose ZWave myself because I read about the size and range limitations of ZigBee technology, versus ZWave, but honestly I could have gone either way. Back then, there was no appreciable price difference in devices. Most hubs support both, though, and I can’t see why I wouldn’t mix them (other than I need to figure out how to get ZigBee to work).
In any case, low-power BT, ZigBee, or Zwave are all options, whereas I will not allow more WiFi smart devices in my house. I’m stuck with Honeywell and Rainbird, for… reasons… but that’s it. I don’t need to be poking more holes in my LAN security.
I had some difficulties too with Zigbee pairing, that’s one of the shortcomings that Matter fixes with their QR Code pairing. On my case it was just about understanding that you have to put both the device and the coordinator in pairing mode for the “interview” to happen. And that is has to be close to any device of the target network that isn’t battery powered (they can do the interview on the coordinator behalf).
I stopped using WiFi devices for the same reason, but found out about Tasmota, an open-source firmware for ESP devices. It requires a local coordinator, but never send anything to Google and the likes. It can be hard to flash, but some vendor, like Nous, offers pre-flashed devices. Some of them are also Matter compatible (if it has recent hardware as old ESP device has too little rom to handle the Matter code).
The only problem I had with my ZigBee network was pairing the lightbulb but that was because the UX to set the bulb in pairing mode required to switch them on and off 5 1/2 time with a too precise timing for a normal human.
Mostly an issue with the bulb really.
This is good information. I had a complete failure with flashing Tasmota once, and bricked a $100 device.
I like the project, though. My biggest complaint is that - at least for what I was trying to flash, the Linux support was iffy. I was trying to flash something for HA, and the instructions assumed I had access to the computer running HA (which is a headless device in a closet in the basement - entirely unpractical for doing fiddly pinning while trying to flash) or using a web browser with webUSB - which Firefox on Linux doesn’t. So eventually I found a completely unrelated set of instructions I could run from the CLI from my desktop over a cable connected to said desktop, and while it appeared successful, the device is bricked. I can’t even get it into flash mode anymore.
I don’t think any of this has to do with Tasmota, except that the Linux tooling seems either weak, or make assumes people are running Chrome; and if you’re security conscious enough to be flashing a device to run Tasmota, you’re not running Chrome.
So I’m not doing that again. It’s a hundred bucks and two days of digging around for tooling and instructions I’d like back.
Again, not Tasmota’s fault, but it’s not super accessible.
I feel your point regarding the WiFi devices and that they shouldn’t be recommended to casual users. But if you just set up an isolated VLAN with its own SSID and use e.g. homeassistant running locally to orchestrate them, then what’s the harm? If your goal is privacy, you need some kind of local “hub” anyway, and to me it makes way more sense to be able to place that machine anywhere, regardless of e.g. bluetooth reception to your smart home devices (since that is taken care of via the additional SSID on your WAPs).
Sure, I could do that, but not everyone can. But you still have the problem that many of these devices don’t function well unless they can phone home; they don’t very firmware upgrades, and they expect to be controlled by a bespoke app. If you filter out all the devices that are HA compatible without running through an external service, you shear the product choices in half.
I would argue you get what you pay for in terms of interoperability and reliability, but I can imagine people willing to trade some of that for a lower price.
Interoperability comes from standardization, which Zigbee sorely lacked. But actors like Tuya or Leroy Merlin built their own standard over Zigbee, which means anything that has “works with Tuya” will work with any Tuya coordinator of any brand (same for Leroy Merlin ecosystem). And even those who don’t usually mostly works.
With that you’d get ZWave reliability, most, if not all, of its security features, with Zigbee lower price. And they still works great with third party coordinator.
But it is true that Z-Wave uses lower frequency than Zigbee (868MHz vs 2.3GHz). It means lower frequency interferences, and better reliability over high distances.
Another issue is that zwave isn’t available in all countries (or it is but uses incompatible frequencies) so it’s less useful outside the big markets.
I live in a country with 10 million people and it works here. But yes there are probably some that don’t have the frequencies.
Inferior how? Matter is not comparable to Z-Wave. Z-Wave is a mesh network, Matter is just a standard which would allow Alexa, Siri, Google, etc. to control the same devices. To allow Z-Wave like functionality, Matter is able to work on top of Thread, which is in fact superior to Z-Wave.
Of course. You don’t want to be the company known for refusing to participate in an open standard, even if you secretly don’t want it to succeed. Anyways, there’s no reason for companies to not want an open standard for controlling smart devices, since it literally helps everyone support more devices for basically no effort once you add support for Matter.
Inferior range, potential for interference, power consumption, meshing, and security. Name one area where it’s better.
And I still expect one or more of these companies to break the standard to create their own walled garden.
Matter over Thread is similar to Z-Wave at the user level and supports a lot more device types. The below is from Silicon Labs