We were discussing in another topic about Z-Wave and why we like and dislike it. Seems that this may be a game changer? It’s something that we will likely be supporting. I’d like to know your thoughts on this.
What is Z-Wave Long Range and How Does it Differ from Z-Wave? - Z-Wave Alliance (z-wavealliance.org)
Longer range. No mesh. It sounds promising.
Hopefully they can make it reliable and fast. Options are good.
I can’t say I’ll invest anytime soon. For me zwave has a lot to prove. I’m genuinely curious how well it will work on the cc.
My 2 cents.
I love the idea that the Core becomes the one hub to rule them all (over time), supporting as many different protocols as possible. As per the comment above, options are good!
Most problems with Z-Wave stem from the implementation of the controller stack (software) and device firmware not from the protocol.
Which systems… err… “hubs” is your Z-Wave experiences based on? I know you ran HE which is a terrible representation of quality Z-Wave.
And yet I’ve had no problems with it.
This
I’ve seen posts from a few that have no problems. I’ve also seen LOTS that do.
With devices other than locks? I’ve seen tons of problems with locks but I don’t recall many others. I’ve had some finicky devices during inclusion but they’ve been solid since and I attribute the issue to Aeotec, not the protocol. But 
As I originally said. Problems stem from the implementation whether it’s the software stack in the controller or the device firmware. It’s not the protocol that’s the problem or that is “slow”.
I’ve never really cared for Aeotec devices.
ZWave is dead only because I like ZigBee.
A lot really depends on device availability.
In general, I tend to think a purpose-built protocol is better than twisting something like WiFi into a home automation tool.
However, when you step up a layer or two, some of the TCP/IP concepts aren’t all bad.
My concern is that Google and Amazon are current powerhouses. And, they find WiFi to be more ubiquitous. And, the device manufacturers find Google and Amazon to be more ubiquitous as well.
Given limited functionality, mixed with simplicity. I see a rush to dumbing things down. Sadly.
But, I’m hoping there will be enough market for functional devices.½
I think there’ll always be "easy’. But, in my perspective it needs to be there. Google and Amazon are gateway drugs to more complicated home automation. I feel like having the protocols there opens up the ability to “use what you know”. Then, it’s a community like this that helps people discover what you can really do with what you have. Then a true addict is born. There are things with the CC that will keep the user safe by default, but it doesn’t mean that it can’t be changed by the user. Or, that they won’t integrate other environments. Even though there are several ways to do things, they’ll only do what they know. And if that’s the long way around the tree, then it is. In the end, if these “easy” things aren’t there, many would give up before they start.
IMHO
This is because people don’t post ‘My z-wave on HE is fantastic’. (Which mine is BTW but I only have half a dozen devices as I prefer the speed of zigbee).
If people have problems, they post, so I’m not sure this is really representative.
Better zwave protection built into the hub to protect devices from being affected by another defective device would go along way or at least a way to quickly identify a faulty device.
Such as an individual device alert for abnormal reporting or errors occurring in the logs.
optional auto disable any suspect devices.
These may not be 100% effective but would help.
With my HE C3 I had a defective GE zwave switch that when physically pushed would temporarily make my Schlage zwave lock stop responding. For the longest time I blamed the lock.
Recently I had my HE C7 entire zwave network fail (with only 13 zwave devices on it) due to a faulty Aeon siren transmitting a signal every 1 second or less.
At first it appeared as if the hub zwave had failed.
In both cases once dealing with these faulty devices the zwave network was fine.
Will see how long range zwave preforms and if it connects directly to the hub how many devices we are able to connect.
But I also find zigbee to respond slightly faster than zwave or zwave plus.
As a test I programmed one of my Xbee3 to transmit every 1 second (not that I would recommend it for normal operations) and I never had any issues with my zigbee network.
As another test I left the faulty Aeon siren on my C7 hub but disabled it in the device page and added 3 chatty Aeotec zwave plus multisensors (for extra load on the zwave network to speed up the test) to see if just disabling the faulty device would fix the issue.
If so then adding an optional auto disable any suspect devices may also improve hub reliability.
So far I have not had any problems with my Zwave network.
I like the sound of that. (If it is possible of course).
Also send a notification that it has auto-disabled a device to save time in chasing why a rule/piston/automation (depends on what it is called) has stopped working.
Mind you if we keep requesting features then the release date will keep slipping as the OLL team implement them. 
Well there are these things little called software updates should you guys think up something we haven’t or don’t have time to implement before production 
, we can also use it to rollout advanced/specialty features. Unlike some our platform is designed with the future and expand-ability in mind 
Besides right now I’d be far more concerned with the potential of the industry wide supply and distribution problems holding things up than with us having to delay to add things
Now that you’ve brought the subject up… 
exactly and would save a lot of time and bad PR when new users have issues they can’t say it is due to the hub but point to a specific device issue.
Maybe even with a saved log capture of the last 10-30 minutes prior to when that device is automatically disabled.
This would speed up trouble shooting.
Often when a device or system fails people are not home to dig through the logs and all past logs are over written.
There may be instances when you do not want auto disable like for new devices just released and custom DH being used.
So allowing it to be individually selected per device would be better.
It is representative when you work with numerous z-wave implementations and one has a significantly higher amount of problems versus the others.