My C-3 has 57 ZWave, 0 Zigbee, 98 devices total
My C-4 has 25, 23, 69
My C-4 has 0, 0, 160 (This is my HubConnect Server Hub with the radios disabled.)
My C-7 has 13, 0, 18
My C-5 has 1, 1, 9
My C-7 has 2, 0, 10
I have 143 devices on my C-3 hub. 52 Zigbee devices, 7 Z-Wave devices, 54 Lutron devices, and a variety of Hubduino, Alexa TTS, Sonos, and Harmony Hub devices.
@Csteele Is 16 days your longest stretch of uptime? My hub ran 18 days on .145 then needed a reboot. Up until then I could have been convinced that 'the problem' had been solved. My expectations might be a bit out of sync with everyone else's.
Ever? no..
For v2.2.3.148, I think it was released on the 16th. I don't think it's possible to be on .148 and have a longer uptime.
I haven't yet upgraded to that version; will probably do so in the near future.
I have also had performance issues with the C4 on 2.2.3. It was much worse on the earlier builds of 2.2.3 than it is now on the later ones. I was chatting to @gopher.ny about it about a month ago and he offered this:
“ I'll take a closer look at C4 performance once we're done with outright bugs/issues with 2.2.3. In case you're wondering, C4s and earlier hubs run a different version of Linux than C5s and up, and they also run 64-bit JVM vs. 32-bit JVM in C5s+. Trying to come up with settings that would speed up one while at least not harm the other was quite an adventure, and I'm inclined to just have different sets of JVM parameters for different generations of hub at this point.“
3 Likes
Interesting. In spite of the performance hit you'd expect to see due to the 64-bit JVM on the C-3, it seems to actually be running faster during its well-behaved period of uptime than my C-7... and that is with the C-3 running all my normal apps and devices.
Right now i have the C-7 doing nothing but running Hub Watchdog and a handful of Zigbee & Z-Wave devices (no apps other than Watchdog installed). With firmware .145 on both hubs, the min virtual switch delay on the C-7 has been running .052; typically see .035-.04 on the full boat C-3 until it gets tired.
I've just updated both hubs to .148 FWIW.
Me too, mine was yesterday, I noticed some odditys in the morning and when I came home it had turned itself off at about 1pm. Turned out none of the wake up commands had got though and it still thought we were in bed.
Both my C4 Hubs are on .148 and I have not noticed any issues. This is not really surprising for my upstairs hub as I've just migrated all the Z-wave devices over to a C-7. The "main" C-4 hub seems to be functioning properly. The C-7 hub seems a little slow - less responsive with Maker sometimes. Note: I have minimal drivers/apps on everything.
With both hubs (C-3 that runs the house, and a sandbox C-7) running .148 for a day now, I don't see any performance issues on either. But considering that the C-7 is basically doing nothing but running a delay test on three devices every 5 minutes, I'm intrigued by the differences that these stats show:
C-7
Apps: Hub Watchdog. That's all.
Devices: 4 Zigbee, 2 Z-Wave + 1 virtual
@25 hours
Free OS Memory: 279,276
virtual switch delay:
maximumD : 5.126
meanD : 0.345
medianD : 0.078
minimumD : 0.06
C-3
Apps: WebCoRE (97 pistons), 4 Motion Lighting, HubConnect (109 devices mirrored to ST), 44 Simple Automations, Hub Watchdog, 6 Button Controllers, Laundry Monitor, Wink Relay
Devices: 75 (50 Zigbee, 25 Z-Wave) + 54 virtual
@27 hours
Free OS Memory 472,284
virtual switch delay:
maximumD : 0.124
meanD : 0.05
medianD : 0.048
minimumD : 0.029
So I initially reported that both my C-4s were fine. This is no longer true. I kept getting alerted that my Node-RED instance was first unable to connect to my main C-4 HE (I do this via an http request to test connectivity) then almost immediately after was okay.
I logged in and found my Zigbee was offline. Managed to disable/enable and get it working again but then rebooted for giggles. There have been no changes to this hub other than firmware updates. Since I'm running NR there are minimal apps/rules. I do have a diversity of Z-Wave+ & Zigbee devices.
edit: Hub seems a lot snappier after reboot. Contemplating a soft-reset for giggles.
The soft reset would probably be a good idea. Once when upgrading my C-3 to new firmware I noticed that it is normal Watchdog measured switch delay was significantly greater than usual; I did a soft reset and it returned to its faster baseline. I may try that with my C-7 to see if it makes any difference (though with 5 devices and only 1 app running its hard to imagine how its database could be slowing it down).
The reboot seems to have cleared things but the zigbee going offline is worrisome. It happened once before and I thought it was due to an erratic device. I set the response test back to the lower value and will see if the issue returns. If it does then I will soft-reset. I will be moving devices off this hub anyway.
Just an FYI... while all of the Hubitat hubs have 1GB of RAM, the C5/C7 use a lighter weight Linux kernel, which allows for more free RAM by default than the C3/C4. However, I believe the freeMemory report for the C3/C4 includes swap space, whereas the C5/C7 does not. So, the freeMemory report is actually apples to oranges when comparing the two different generations of hubs.
2 Likes
Good to know; that could explain the difference. I'm still surprised that my loaded C-3 seems to be running faster than the nearly idle C-7 (at least by Hub Watchdog's measure) as the 64-bit JVM comes with a significant peformance penalty (managing the larger heap sizes apparently takes its toll).
I'll add myself to the list of those experiencing newer slowdowns with the C4. It also seems like some events that should be scheduled, are simply failing to be. E.g. rule to turn thermostat off via open window after a delay shows up in the log, but never actually carries out the action.
Hub went down again just now. All morning routines seems to fired ok but about an hour later nothing is working. got the hub is not responding message and the diagnostics page won't load either. Power cycled it and all is fine.
Just to eliminate the possibility that it simply got a different DHCP lease and changed IP, the next time it happens, could you check to see if it is reachable at portal.hubitat.com ?
Also, though you might have had no alternative, obviously not good to power cycle without clean shutdown, might damage the database.
My hub is on dhcp reservation. The hub crashed because none of my automations were working.
