I'm trying to understand better what stresses the HE system.
If and when HE does become slow, what are the causes and how are they affecting HE technically?
A. Number of devices?
I dont see why this would unless we're taking about devices that constantly poll the HE such as temperature sensors and power meters.. Say i have 500 contact sensors on HE - most of which aren't doing anything at all.. Would that cause HE to slow down? IF SO, why/how?! lol
B. Number of rules?
If the more rules the heavier for HE, then why and how? Similar to above, if I had bunch of rules but they're not all firing at the same time anyway, would that cause HE to slow down? If i had a rule with so many conditions and sub rules and what nots, but that's the only rule HE is processing, why would it slow down?
Or are these rules loaded onto MEMORY and as such even if rules aren't firing memory is already saturated thus causing everything to slow down.
C. Number of DASHBOARDS being used at same time?
D. Other factors worth knowing?
I know it's not one thing but I'm trying to understand what are the major causes and how they affect HE technically in hopes to design the system keeping in mind how things affect HE's performance over-all.
I think you’ve already hit on the right idea. It’s not an absolute numbers game for the most part. It’s when a device or app generates a ton of events that things can get bogged down.
Very frequent (but unimportant) power reporting updates are a common culprit among devices.
For apps, poorly constructed rules that get into some kind of loop, and some LAN or cloud-based integrations can be problematic. With dashboards, include only the devices in the app instance that you intend to use on the dashboard, not all devices.
Always look carefully at community-developed code installed on your hub.
There are a few absolute #s to be aware of, mostly related to the zigbee or z-wave meshes.
Z-wave tops out at 232 devices per mesh, I believe. And your devices can only take a total of four “hops” among repeaters to get a signal to/from the hub.
Zigbee has a limit on the number of devices that can directly connect to the hub. I think it’s 32? Not 100% sure. The total # of devices in the mesh is not limited, as long as you have repeaters in your mesh to overcome that direct connection limit.
@bertabcd1234 can you correct me if any of my #s are wrong?
Currently, my hubs have an uptime of over 60 days. And for at least the last 1.5 years, I have only rebooted when there's a platform update.
However, here are the things I did to my Hubitat C5 that required daily reboots:
Messed up z-wave network with multiple stranded nodes (getting to what @Eric.C.Miller pointed out)
Poorly designed integration on my LAN that crippled the hub with ~50 MakerAPI requests per second. (my design, my fault)
A poorly ported z-wave driver (I ported it, my fault).
Points 2 and 3 kind of get to what @marktheknife pointed out.
And to be clear, since all those three issues were fixed, the only time I have rebooted my hubs were for platform updates, or if there was an extended power outage.
I would also add a faulty devices spamming or clogging up the mesh by being semi-responsive. I had a bad Z-Wave device kill my Zigbee service once. I also shifted to a periodic reboot then multi-hub arrangement way back during the C-4 era when things were a bit less stable but like now constantly improving..
My most recent issue was similar to your #2 my Node-RED stuff spamming the Maker instance with too many requests. Interestingly the hub devices were still mostly responsive but the hub itself kept temporarily dropping off the network. clarification: ... by "dropping off" I mean temporarily unresponsive at least to my ping tests.
Most home control uses surprisingly little processing power (even when controlling many devices at once) - I'd say its highly unlikely you could slow Hubitat down by placing too much processing demand.
The only "major" slowdown that I think I've experienced seems to be a Z-wave issue due to a 700 series firmware bug described here: 10-15 second delay which, from what's posted, may get fixed / ameliorated in the next firmware update. I hope.
I'm running with about 100 z-wave devices and even when I control large groups of devices (all on / all off), the logs show that processing demands as indicated by the logs seem to be a minor blip.
I think the radios in modern Z-wave chipsets (500 series and after) have multiple channels and transmissions can occur in parallel (I think there are 3 channels in the US). So you can actually have 3 transmissions occurring in parallel. So, even at the z-wave level, it can be hard to really saturate the network for more than a very short time.
Yeah but the routing/activity can clog things up on the HE itself.. Those dreaded "network busy" messages. My understanding is this is from the radio chipset itself.
Also I am now in the process of having to completely redo an installation thanks to the old proprietary ZW DB getting corrupted which is not fixable.. That too can slow things down, cause unnecessary routing etc..
I would be interested to hear from the Hubitat engineers on this subject. On the older units, the dongle containing the radio was plugged into a USB port . . .
Yes, of course that part is serial. The air interface is where there are parallel channels. So as I understand it, its a high speed serial (USB) that then converts to a slower parallel air interface.
So far from what I've gathered, it's difficult to over-saturate the radio itself unless you got sooooo many devices being "noisy" at same time. The more common culprit are rules, and 3rd party stuffs. This makes sense because I've seen people with lots of devices added claiming to be smooth sailing, and some with way fewer devices already complaining of lag.
But yah, I too would like to hear from the HE themselves on this matter.
