I am in the same boat as @lcw731. I have over 118 devices, 41 of which are zwave, 20 are zigbee, and the rest are a combination of virtual, wifi, and devices feed from node-red. The zwave devices work pretty darn flawlessly. You do have to be careful of ghosts and adress them quickly, but they all work great. The big thing with either zigbee or zwave is to make sure you build a good mesh.
I think this is a good point. Most of my stuff is Ring Gen 2 gear and Zooz gear.
Building a good mesh on either technology will make things alot better.
Every environment is different - so many factors to consider. Here are some fun ones based on my experiences:
User created rules potentially conflicting or having bugs or unanticipated consequences.
Types of devices used can impact the mesh including faulty or older specd devices.
Placement of devices and hub - too spread out or in a signal unfriendly area (like a metal electrical box) and signal struggles to get through causing routing errors, sporadic functioning / potential delays and battery drain.
Custom apps/drivers chewing up hub resources or bugs impacting device operations.
Local area network / Firewall settings blocking certain functions including cloud services,
Device firmware issues.
Quirkiness of signal propagation due to layout and types of building materials at the location.
Signal Interference from other sources - WiFi router etc.
Temperature in area around hub and devices.
Stable and proper power for hub / devices - easy to overload certain smart switches / plugs if not careful (always check the specs!), Power backups for hubs etc.
The per spec mesh routing rules inherent to the protocol and chipsets. Z-Wave seems to have the most weirdness here BUT due to enforced spec requirements ZW devices are usually more compatible than Zigbee.
It's a hard lesson that there is a lot of trial and error involved in implementing a moderate to large personalized solution. The above is true for ANY home automation solution not just HE though.
@goldbond1 what is your uptime? A pic of the app stats / device stats will tell us this. I found that my hub (loaded with automations, but mostly zigbee or LAN) performed worse after a couple of days of uptime.
Then i found this Hub Rebooter app. It greatly increased my Hub's performance. You might want to try it out:
I am sorry for the delay on responding but quite busy with work and other.
On the reboot question: Isn't there a reboot after every HE upgrade? There have been a number over the past month and I ensure these are applied as needed. I have done a periodic main breaker power off to recycle zwave mesh.
Again, the issue seems to focus on simply trying to turn on a handful of zwave light switches at once based on a rule. (intruder at night..) . The HE seems to puke. I validated recently no rogue devices on my network spewing traffic. But, I do get the occasional drop requiring reset of Inovelli light switches, (pull jumper) in particular. These drop off and aren't spamming.
I like the idea above of perhaps putting a wait on each switch/device . Maybe that would help. But, I really don't feel I should have to do that. And, I need to review how this is done.
Re. 3rd party integration.
I have HA (Home Assistant API) connectivity for a dashboard only. No logic.
Blue Iris (BI Controls) connectivity with 4 cameras. Only used for motion/trigger.
Google Home - 6 devices
Life360 for 6 users
Ecobee 3 thermostats
Let me reiterate that ALL devices independently turn off instantly including my new Aqara which were just recently added. HE has been FAR better than ST ever was. This is ONLY about triggering events that have a number of actions consecutively and it only seems to be ~5 before the HE pukes. It will turn 4 outside zwave lights on for TOD (Sunset) no problem. I
Still working on log analysis. Will try a few other things..
With current firmware on hub and zwave metering is not needed, in fact it was removed from the new RL app. I have been using it for larger groups with no metering and it works well. As the devs explained it, metering was a band-aid to work around a problem with the zwave SDK which has since been fixed by SiLabs.
I've definitely found Zigbee mesh to be more robust and faster in general. Makes sense given the higher bandwidth available. Have also experienced devices dropping off the mesh as well, much more frequently than ZW.
OTOH working Z-Wave devices tend to stay that way - like my closet light switches and contact sensors (Aeotec recessed door sensors) and exterior lighting. Also most every device labelled Z-Wave will pair with the hub. Having said that the routes can sometimes get weird and devices remain in the DB and it's hard to recover..
I had such an issue before. Have you tried changing your zigbee channel? I installed a wifi analyzer app on my phone, looked at the most prominent channels, then set my zigbee channel to a channel far from those (in my case 15).
My test is simple. If I have to go to a customers house after the installation then I consider that an issue. If I can fix it remotely or if it does not break at all then I consider it a successful installation. I have yet to have a single Z-wave installation that did not require my onsite assistance but I have never had an issue with Zigbee (GE Switches) or Lutron Caseta or RA2 select.
Z-Wave S0 is security, and in nearly every way (amount of traffic required, actual security provided), it's worse than S2. I do suspect that some S2 devices were not as well tested with S2 versus no security so may exhibit some firmware oddities if paired that way, but for S0, it's generally recommended to avoid it whenever you can unless it's the only option (e..g, older Z-Wave locks that don't support S2, where secure pairing is still required).
One could probably argue that ZWave's S2 enhancement was to permit a like-for-like checkmark in a feature table vs Zigbee, which had this level of encryption included and mandatory. That probably explains why SiLabs wants to make it hard to include S0 only devices as "S-none".
All of the encryption methods increase the count of packets vs no encryption. ZWave or Zigbee, but with Zigbee, there's no None available, and the communication speed is more than double (100k vs 250k) to compensate.
S0 has a single Key per controller for all devices and thus is not much of a security benefit in 2020+. S2 has a key per device and thus security is better, but still an impact on performance vs "S-none".
As @nibyak mentioned I would put your lights to turn on in your rule (the On: list) into a group. Add the "Groups and Scenes" app, and maintain your list of lights there. Then update your rule to On the new "group device." This has the side benefit of only having 1 place to edit your devices and any rules using them will automatically be updated.
Re. Groups: I'll give it a go. Likely easier to maintain as I have multiple kick offs depending TOD and mode.
I will say reading discussion: I am not happy with anything beyond first gen Inovelli. 2 (both S2 RED) started flooding my network over the past year and I eventually pulled them. I was all in at one point. I have since moved to Zooz and have had less issue. Fans are all GE.
I have a bunch of red series switches and dimmers all on S2. Turning down (or off) the power reporting is all I did to keep the mesh healthy.
All my S2 capable devices are using S2 - mostly because I'm lazy and I use the barcode smart start include method. I don't see any major issues or unexplained delays. The only real annoyance I have is when doing a firmware update on an S2 included device, it takes 20x longer to update.
That sounds like a good rule of thumb. Do you find this to be true with the Zigbee switches? I agree that Lutron stuff is off the charts reliable but a lot of my clients do not like the Caseta look and the cost of the Ra2 (or Homeworks!) is very prohibitive relative to Z-Wave and even Zigbee except maybe for new builds..
Usually a call-back for me involves something the electrician did and every once in a while a faulty device. Once the initial chaos of the installation is done then things pretty settle down. I always allow for a few return visits even if everything is okay. Have been able to generate additional business that way.
Believe it or not I have actually had some Lutron switches fail - in a client's garage, no leak damage or anything. Another was inside a client's house on a second floor hallway. My electrician was just as mystified both times. Has not happened nearly as often as Z-Wave though. I suspect things will improve even more once Z-Wave LR comes out if it ever does but in my experience ZW+ has been reliable enough provided you are consistent with the devices you use etc..
I do have to admit that I have had two Lutron switch failures in my career. Both of them I had to come in and replace. I have never had to reprogram a Lutron or Zigbee switch or re-ad it as I have done many times with Z-wave switches. I use simple Zigbee GE switches; not fancy but people like them because they look like their old switch. They always work and rarely fail. For motions I just use cheap no-name Zigbee motions and have never had an issue.
I do suspect that some S2 devices were not as well tested with S2 versus no security so may exhibit some firmware oddities if paired that way, but for S0, it's generally recommended to avoid it whenever you can unless it's the only option (e..g, older Z-Wave locks that don't support S2, where secure pairing is still required).
