I have a bedtime automation that when we give a command, all the lights in the house turn off, locks lock, garage door closes, alarm arms, mode changes to night, etc. All of my lights are controlled by z-wave switches. When I built the rule, I just checked off all the switches that I wanted to turn off. However, I've noticed that when that rule is triggered, the hub bogs down and other automations become very slow. I'm wondering if it would be any more efficient on the hub to group all the lights I would want to turn off into a group and just have that group turn off? Or is it no different then checking off all the lights I want to turn off in the actions part of the rule?
Most likely it's 6 of one - a half dozen of the other. It's not the hub that bogs down, it's your Z-Wave mesh. Z-Wave is not a fast network, so those actions get queued waiting to fire. All I can suggest is to try both approaches.
1 Like
Makes sense! Would it help to put a pause in between every x amount of actions so that there is less being 'queued'?
I have a somewhat similar situation, that I can't understand.
My automation says: when Switch X is turned on, turn on 3 other switches. And, when switch X is turned off, turn off those 3 other switches. All switches are physically in the same room. All switches are Leviton zwave plus.
Why is the automation to turn on done in around 2 seconds, and the one that turns off done in 12 seconds? 12 seconds for such a simple automation is just too slow!
Does anyone have any ideas why this happens?
P.S. It's not a RM, it's a simple lighting rule. Here is a screen shot:
1 Like
I have struggled with the same thing. I have a rule for goodnight that turns off about 60 z wave "things" and about another 40 zigbee things. Most zigbee devices are on a separate hub. I have played with breaking things up and adding delays but the same results ~ about 60 seconds for everything to turn off. What is interesting is I have similar rules to turn on 25 z wave things at sunset and they all turn on within a couple seconds. The delay always comes down to the same few z wave devices and if I put them first in the rule they still take the longest to turn off. When you look at the log files, each device will show multiple commands (I assume because of the mesh traffic and the device not responding).
1 Like
If you’re able to use z-wave associations with the main switch, you can turn on and off 5 z-wave devices this way, bypassing the hub. I do this with my outside lights.
1 Like
I have a similar rule that fires when I press a bedside Pico button. I was working with @bobbyD on another issue several months ago and he mentioned locks especially big down the Zwave mesh because of their secure pairing. He suggested putting a delay for the lock so you either lock it first and then delay for switches or switches first with a short delay for the lock. I have since implemented this in my rule and it has helped. Still not immediate but definitely faster.
2 Likes
I think that I shouldn't have to use association to get reasonable response.
Does this mean that Hubitat is i\o bound?
My understanding is that Z-wave is a slow protocol for home automation and it is z-wave that is i/o bound due to slow transmission rate and commands end up waiting in the queue to be sent. Most of my devices are zigbee for this reason. The hub can send one zigbee command and turn on or off a zigbee group instantaneously. Z-wave doesn’t have anything like this to my knowledge. I do have z-wave plus switches and dimmers for places where this is not as noticeable. Where it’s convenient I use double tap associations (group 3, but one could use group 2 to follow the master switch) to turn a group of lights on or off. The hub is bypassed so automations are faster since they go directly to the switch(es) being controlled, but this is still slower than zigbee.
1 Like
Interesting. I'll try putting the locks at the end after a bit of a delay and see if there is much of an improvement or not.
It appears from my reading of many, many notes that there may be some sort of an issue with the hub slowing down under certain circumstances. It also appears that the hub is not CPU bound. Perhaps it is memory bound?
In general, in the computer business, we throw hardware at problems that perhaps could be solved in software, just because it's easier and faster.
An appeal to the bosses at Hubitat:
@bravenel @mike.maxwell @chuck.schwer (and anyone else that I've neglected to mention)
If you were to come out with a different Hubitat model: bigger, faster, with more memory, etc., at a higher price: I (and many like me), would buy it!
I think that you have a great system, if you want us to pay more for a "bigger" box, no problem!
1 Like
We've been down this path, and don't think it is a good idea. We have run the hub software on faster hardware, much faster and much more expensive. Guess what: automations run at the same speed. Why is this? A faster CPU does not increase the speeds of Z-Wave and Zigbee networks, or the Lutron main repeater or SmartBridge and ClearConnect radios. So you could pay a lot more for more CPU and not have a very satisfying increase is overall system performance. This is independent of the issue that some users have reported about hub slowdowns, which is not a hardware issue.
So our conclusion was, while they are certainly people like yourself who would pay more for a bigger/faster hub, it just doesn't seem like a good plan unless there were some markedly different overall system performance that resulted from this.
1 Like
Is it just CPU?
That is, did you try with a model of increased memory, other resources?
Oh sure. All of it. Your hub is not running out of RAM or disk space, and its not CPU bound for the most part. Please think about the absolute traffic rate presenting itself to the hub from devices in your system.
OK.
Back to the drawing board...
Unfortunately, this has got to be done the hard way...
Turning off stuff, one by one. Patiently looking at logs, doing tests, etc.
I was just trying to suggest "an easy way out".
Unfortunately, it doesn't look like there is one!
There is some art to designing automations, and even more so to doing an overall automation design. There's no magic bullet.
More hubs equals better radio to device ratio which would equal faster as long as your setup can be divided up and still have a solid mesh.
I asked earlier for a bigger Hubitat.
I understand that would not alleviate many "slowdown" situations.
So, perhaps your approach of "more than one hub" is somewhat equivalent to "throwing hardware at the problem".
I have a mixed home setup, so it may be fairly easy to divide up Zwave on one side, and everything else (Zigbee, Lutron, a few cloud stuff (Life360, Ecobee, MyQ, etc.)) on the other.
Anyone have a suggestions on how to divide up between hubs?
Update: I put the lock commands at the end of my actions after a 30 second delay and so far I have noticed that the rest of the commands seem to happen quicker. Haven't noticed yet how it affects other automations. For example I had previously noticed that motion lighting didn't work when the big nighttime routine was being processed. I'll update this once I've observed whether there was any change in that regard or not.
2 Likes
