Live data from Hacker News

Z-Wave Alliance Announces Z-Wave Source Code Project Now Open and Available

z-wavealliance.org

91–100 of 125 posts

Re: Z-Wave Alliance Announces Z-Wave Source Code Project Now Open and Available

#91
post #76

Earlier quoted context omitted.

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.

What does optimize mean in this case?

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.

Re: Z-Wave Alliance Announces Z-Wave Source Code Project Now Open and Available

#92

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 d…

Agreed! Messes with Wifi too.

Re: Z-Wave Alliance Announces Z-Wave Source Code Project Now Open and Available

#93
post #56
post #30

Earlier quoted context omitted.

Z-Wave is definitely the better protocol (vs Zigbee), but Matter is partially based on Zigbee so everyone expects Z-Wave to lose. I don't agree, I think Z-wave will work with Matter using bridging.

> so everyone expects 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 involve…

> 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.

Re: Z-Wave Alliance Announces Z-Wave Source Code Project Now Open and Available

#94

Earlier quoted context omitted.

I have nordic dev chips, esp8266's, esp32's, etc. 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?

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…

> 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.

Re: Z-Wave Alliance Announces Z-Wave Source Code Project Now Open and Available

#95
post #5

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).

Re: Z-Wave Alliance Announces Z-Wave Source Code Project Now Open and Available

#96

Earlier quoted context omitted.

Do Matter and Thread use wifi or are they a different radio freq?

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).

> Matter is a communication protocol built on top of...

Matter is a communication protocol built on top of IP, with a special blessing to Ethernet, Wifi, BLE, and Thread.

Re: Z-Wave Alliance Announces Z-Wave Source Code Project Now Open and Available

#97
post #49

Earlier quoted context omitted.

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. Again, no internet connection required.

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 abil…

> 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.

Re: Z-Wave Alliance Announces Z-Wave Source Code Project Now Open and Available

#98
post #34
post #5

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?

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 whicheve…

> 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.

Re: Z-Wave Alliance Announces Z-Wave Source Code Project Now Open and Available

#99

Earlier quoted context omitted.

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…

> 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.

Re: Z-Wave Alliance Announces Z-Wave Source Code Project Now Open and Available

#100

Earlier quoted context omitted.

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…

> humidity sensors/weather sensors/motion sensors 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…

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.

Post reply on HN