I have a 3-Way switch setup with two Inovelli Dimmer Red LZW31-SNs using Hubitat. The primary switch reacts very is fast (almost real-time), but the secondary switch is much slower - it takes 7-12 seconds to fire the rule. I’ve tried the setup using Hubitat Simple Lighting, the rule wizard and mirroring. All methods have the same result. Sometimes the first command on the secondary control is nearly as fast as the primary switch, but it’s mostly 7-12 second delay. I've repaired the network several times, and still no success.
Maybe related... I've also noticed a rule that turns off every light in the house exhibits a popcorn effect, where the lights slowly turn off over a period of 10 seconds. I have 12 Inovelli dimmers and 3 on/off switches, with plans to add 20 more dimmers.
Maybe related... I also have a rule that sends notifications to 5 of the dimmer switches when the power draw on the motion detector in my back yard exceeds a specific value and it turns on another outside light. This rule can take 2-5 seconds before turning on the other light and displaying the status notifications on the dimmers.
Any ideas why there is such a delay? The whole purpose of me going with Hubitat was to eliminate delays related to cloud services... so this is quite frustrating!
Turning off every light in the house without using the groups app to optimize will flood any Z-Wave network and cause delays. You either need to put all of those switches in a group and turn on optimization or you need to check each in a condition before you turn it off.
Having any rule perform too many un-optimized actions can drop your mesh.
Great advice @codahq. I'll definitely try that to get rid of the popcorn effect. I'll provide an update once I've had the opportunity to set this up. Thank you!
@codahq, do you know if you can have a mixture of zigbee bulbs, zigbee switches, z-wave switches all in a group and use the on/off optimization button? Or should it only be used when all of the switches being controlled are of the same protocol? I.e. all zigbee, or all z-wave.
Based on the explanation of the on/off optimization feature, it seems it only checks if a switch/bulb is off already before sending an off command so in theory it shouldn't matter if there is a mix of protocols in the group, correct?
Also, check if on/off commands sent to these lamps directly from their device pages are snappy or also slow. If they are also slow then your hub is running slow and may need a reboot. Many of us still find a regular reboot keeps the hub running smoothly. If they activate fast from the devices page then it suggest you have a slow automation/rule. Certainly use a group for lamps you want to operate together without the popcorn effect.
I'm not sure on that one. I don't have any of my Zigbee and Z-Wave devices in the same groups. There is an additionally a Zigbee feature you can enable for group messaging. I don't know how any of the optimization or group messaging features work in mixed company. Sounds like a question for the documentation. I only have Zigbee bulbs in one room and they aren't in any of my main groups because they are treated differently. (They're in a theater room. No automations, Scenes only.)
Yes, you can have any mix you want. As for the on/off optimization option, you just have to experiment a little to see if it makes any difference or not. Some people think it helps to not try to turn off devices that are already off, makes the Group faster. There is no hard and fast rule about this.
Last night I tried creating a group for all of my lights to use in my bedtime routine. It's a mix of z-wave and zigbee bulbs (paired to my hue hub). I found the lights went out much quicker when I hit the bedtime routine. More importantly, when I walked into the bathroom, the z-wave switch turned the lights on instantly when the z-wave motion sensor sensed my motion. Before, after hitting the bedtime routine and then headding to the washroom, there would be a delay with the light coming on when I walked into the bathroom, presumably because the z-wave mesh was flooded with commands.
As a side note, the other configuration that made a big difference in not bogging down the z-wave mesh network was using @jwetzel1492 's Lockdown App, to send lock commands to my 3 z-wave locks, and putting this at the end of my bedtime routine after a short delay after turning off all z-wave switches so that the secure lock commands weren't sent while trying to turn off a bunch of z-wave lights.
Mine was running really slow and rebooting it every couple of days would fix it.
But I got fed up doing that and cleaned up unused apps such as nest integration and the dashboard.
Since then it has been running fine.... suspect it was dashboard in my case will report back in a couple of days if still running ok ( running 2.1.9.114 )
But so far three days no issues used to be every two days it would slow right down.
I've tried repairing the z-wave network and creating a group that controls all switches/dimmers at once, but I'm still getting the same results. I thought Hubitat was supposed to be very fast considering it is local and not cloud-based. I've invested a considerable amount in this system, and having delays of 7-12 seconds when clicking a switch is completely unacceptable.
It sounds like a driver or device issue, although there will always be popcorning with z-wave since there is no z-wave group messaging (only zigbee has this). For turning on/off the entire group, you could create a new group of just a few devices, make sure they turn on/off quickly, then add devices to the group one at a time until you get to the device causing the delay. When that happens, remove the device from the group and continue adding devices, making sure that no other device is also causing delay. Whatever device(s) caused the delay, add to an on/off rule after the group device (you may have to add a small delay to the device).
You may not like what I'm about to say but I'm doing it anyway because your tone seems to have changed to be a little accusatory towards the Hubitat hub. Blame what you want but I think it's extremely premature.
Expect to spend a considerable amount of time in this system or ANY system that uses Z-Wave with any significant amount of devices. Z-Wave repair is not a catchall fix for everything. It doesn't remove broken nodes immediately. Per the Z-Wave spec only time can. If you added devices to your mesh out of order (using distance or RSSI from the hub) Z-Wave repair may never even fix the routing table on its own.
You could still have any number of issues on the hub that are all in your control to fix and all consequences of your actions.
Have you tried the suggestion of trying to toggle individual devices and roughly benchmark each device's performance? Chances are... if it were even possible to move your exact same mesh to another platform, you would have the same problems there. Do all devices behave on their own?
Have you tried setting up a dashboard or having multiple device pages open and tried changing many devices' toggle?
Did you understand the statement that turning on or turning off any significant number of devices at the same time could still, even in the best circumstances, overload Z-Wave on any hub/platform?
Did you setup your groups correctly? Optimization is turned on? Are there other devices that aren't Z-Wave+ in the groups? Or none Z-Wave?
Do you have a lot of other traffic going on from the switches? Like... meter reports? Do you have any other devices talking too often?
I’m waiting the reported 3 days that many are claiming (I am actually going to wait for a week), but so far the latest hub platform is not slower, in fact it’s faster because last night, I did not see the slow downs at 2 AM that I normally experience.
Take this all with a grain of salt as you should, because it’s been less than 24 hours since I made this change. I’ve been a long time hold out on upgrading, and I’ve made this move many times, just to go back. In all honesty, it was normally because I just wanted the old rule machine 3 and button controller app back.
Over the last few months I’ve been working to make myself be more comfortable with Rule Machine 4, create masters if I really want to create a RM 3 rule, and just plain “get over it” and move forward. Unless I can find a major issue, I intend to stay put on the current build and not bounce back to 2.1.3.x
I’ve tested everything I have in my home, and all of it has continued to work so far without fail or delay. One thing that has been very apparent that I didn’t really think so deeply about before was how much of my set up is distributed and actually IP connected. This has turned out to be a very good way to go because I have experienced that if I ever am forced to move to a different hub, how it will be quite painless. The major disadvantage in all of it will be the four Z-Wave devices I have. So in essence, it will really not be that big a deal should I ever have to, or want to completely switch to a newer HE hub.
