Thats what privacy mode is for lol. I guess what I'm getting at is breaking this monster up into manageable bites will likely end up with a better result. Put them contact/motion sensors to good use and use them to trigger room based actions.
I really wish I could get rid of the refreshes and delays, btw.
If the hub is "choking" on too many z-wave commands at once, it would be VERY helpful if it would meter them out (i.e., if the network is super slammed, pause things for a moment to let it catch a breath) rather than having the commands get lost. This seems even MORE true for group actions, as the hub is able to tell up front how much is needing to be done.
As for splitting this one up, the entire set really is pretty much one, single, set of actions I want done when it runs. Having things run in different rules that might run in parallel would just make things worse. At least this way, I can put in delays to space things out in a methodical manner.
Getting back to encryption: As crappy as my ADT Pulse Hub was, it almost NEVER had a problem with getting all the commands sent to the devices. That part was pretty rock solid. And, when something didn't respond, it actually alerted me separately and explicitly.
I'm guessing they went above and beyond the Z-Wave specs (it was an old, 2010 or earlier hub) to make this happen.
I'm hoping some updates, etc. will get my HE working better.
With group messaging it will ignore redundant commands, but what I'm talking about is not turn on every light in your house at once but rather turn on the lights to the living room when you open your bedroom door. Turn on the lights when you go down into the basement. Disarm in the morning when you go into your closet to get dressed.
I had an ADT hub as well when I first started out as well as all old zwave switches. It worked for me well but it did have quirks. I also had a bunch of cams.
Unfortunately, I'm not that predictable.
I live by myself--and may end up sleeping in various places (why have rooms if I don't use them*).
And, this routine is simply setting up my normal "I'm up and about" lights that I want set on all the time when I'm up and about.
- I have my master bedroom, a room in the cool/dark basement that's great in the summer, and I sometimes crash out in the family room by the fireplace (that was mostly before my pup died earlier this year, so he could snuggle with me on the floor).
In any case, I end up wanting the same thing done in several different situations. I've ordered and spaced out the actions to try to help keep from flooding things.
Also, living by myself, I often have a lot of doors open all/most of the time. The only one that is reliably closed when I sleep is the basement room door when I'm down there (to shut out the furnace and dehumidifier racket).
Jesus that rule man! No wonder your hub is struggling. Making the S0 device to none might help with your network speed, but I think you would be better off with a scene here. You essentially trying to create one each run of the rule and RM isn't quite right for that purpose. So create a scene per scenario if need be then call that scene in RM, I think that might help quite a bit.
Are any of your devices z-wave? Or ZigBee?
Well. About that. Even when I do a "Group" action, I can't get things to behave properly (e.g., "All off" or "All on"). I get about 20-30% failure to act and update. Since there seem to be issues any time I send a bunch of commands into the z-wave mesh, it would seem that using a "Scene" to send them all at once wouldn't work any better.
And, if it weren't for all the refreshes, delays, and splitting up the commands over time, that rule would be WAY more straightforward. It's only grown into its current ugly state as I've sorted out ways to make it work more reliably than it was.
Nearly all my devices are Z-Wave.
I have a Hue gizmo that interfaces via the Phillips integration and a few buttons that are Zigbee, plus my Ring and Chromecast integration.
Note: If you think that rule is insane, you should see my snazzy-dazzy Splunk queries (at work). They make that rule look like a pre-school project. 
Note2: There are other situations that have as many/more actions--and they need to transition from any state into the desired state, with specific timing, and in a specific order. "Scene Transitions" appear to be meant to go from a "Fixed A" to a "Fixed B" with no control over how that happens.
Zwave transfer rate with ideal mesh is 100kbps or about double the speed of a 90's era dial-up modem. You're just doing way too much at once. If you really need your house to turn on everything like that you may have better luck splitting your mesh in two and using hub connect to link then put them on different zwave bands.
3 Likes
I'm trying to spread it out to 1-2 devices per second or less.
There is little difference between what I'm having issues with here--and what I was doing on my 10 year old ADT Pulse iControl hub.
This ran, every time, no problems:
As did these two (simultaneously):
I'm still lost as to why triggering 20-30 devices, 4-6 at a time, over a minute and a half is taxing.
Indeed, that's what I'm trying to sort out.
From some other posts, I am suspicious that it may relate to the fact I now have 36 "S2 Authenticated" devices--and they may create an undue load on things. So, I guess my next major project will be getting them brought in as "Unauthenticated" devices. I'll keep my fingers crossed.
That will take a while to do.
Just to be clear I think you want to try joining them with no security. The phrase unauthenticated is typically associated with S2 as well, it is just of a slightly different S2 tier.
Perhaps you realize that already and I’m nitpicking on phrasing, but just in case, figured I’d call it out before rejoining a bunch of devices still utilizing S2.
1 Like
I guess sorting that out is good to do ahead of time.
I was under the impression that it was the "encryption" part that was possibly creating extra traffic. Would S2's unauthenticated mode resolve that? Or does that still create a lot of extra traffic?
I believe you're talking about the difference between checking an "Unauthenticated" box and unchecking the others--vs just unchecking everything when prompted?
Note: I tried doing a "replace" operation on an S2 device today--and that operation did NOT let me "uncheck" any of the boxes (when I tried, the immediately "re-checked" themselves).
If I don't have to update a dozen or more apps/groups/etc. for each of my 36 devices (to replace the previously included device with the newly included one), that would be very helpful.
Thanks!
I don’t know all the down dirty details of how S2 works, but S2 authenticated vs S2 unauthenticated is still encrypted. If you want absolutely no encryption, you’ll want to uncheck all the grants on that pop up dialog.
I should also mention that S2 is supposed to be pretty efficient in its operation, especially compared to the older S0 encryption. From what I’ve seen mentioned in the past there shouldn’t really be a ton of overhead using S2 on devices. That’s not to dissuade you from testing it, just mentioning it.
2 Likes
Well. With 36 devices involved, I want to test something most likely to work the best.
Maybe @bcopeland will chime in with a recommendation.
A lot of people are having very good luck with the hub now that the worst issues from the initial release have been resolved. So, there seems to be something "special" about the others of us who are having these issues with response times (seemingly, congestion on the mesh).
And, I expect there is a compounding of the issues. Because the mesh is not super reliable, the hub loses track of the status regularly. So, I have to include "refresh commands" on all my devices to fix that before I issue actions--which creates MORE mesh congestion and delays.
If I can resolve those issues, I'll rip out the extraneous "refresh" statements in a heartbeat. 
Put in a bunch of repeaters, then let the mesh settle for a couple of days. I suggest the Ring extender 2, which work well for me.
S2 and unsecure have the same amount of mesh traffic. The difference is how the payload is encrypted (or not), and what keys are used for the encryption.
S0 is the only one to be avoided.
I paired everything S2 capable as S2 (the default check boxes). Not because I think S2 is really necessary (I don't), but I believe in testing/using the defaults when the defaults make sense.
If it is going to be the default, it sure as hell better work pretty flawlessly for pretty much every customer.
3 Likes
I have over 40 line powered switches/dimmers AND a Ring repeater.
In a house where the farthest distance from the hub is <50 feet.
It rarely/never uses the repeater I have but does go through various light switches/dimmers.
I think his issues are mostly due to the rule he is using. I didn't count but there are about a 100 commands in it.
2 Likes
That's not the issue entirely.
A rule with one, single "Group On" that turns on a number of devices also fails.
As I've noted, with my ADT Pulse system, I could turn 20-30 devices on all at the same time--and it NEVER missed a beat. Currently, I have things broken down so they have about 3-5 commands every ~5 seconds.
That big rule runs over the course of about 1.5-2 minutes.
You should have @bobbyD see what's going on with your hub when you run the rule. Some screenshots of your devices in settings, zwave details would be helpful too.
I know there have been some initial forays into that.
I disabled the Chromecast integration (some issue with resources), but that didn't seem to resolve things. That's why I'm now wanting to discuss the inclusion method with the least overhead.
Someone else indicated there still seem to be some issues with the SiLabs firmware that are showing up on many hubs (not just this one).
Got to be honest that I feel I’m in the same boat (c7 hub) - not a ton of devices and struggling to get up to date status. I’ve flipped the zwave to zwave+ to resolve and it kinda helped. So then I killed Chromecast and any other app I really wasn’t using to try and simplify. I also turned off all device reporting where I had just accepted the default but people said was overwhelming the hub. Same for logging. I would argue this part made the biggest difference.
I’m now someone hoping it’s really a mesh issue and adding repeaters and switches where I can. A challenge outdoors for me. It’s getting better and more responsive than my ST but the status of my devices is nowhere near as up to date or reliable as ST.
To be clear the speed is MUCH faster here. Debugging and the zwave mesh though seems harder to build even with supposedly better (zwave+) devices and more of them. The hub is in exactly the same place so I have to believe either the antenna is smaller/weaker and/or the zwave repair process is different.
I will admit I tried to do point to point/hub to device as much as possible before and maybe HE just needs/prefers a true mesh. I’m wrapping my head around that.
1 Like
