I mean I get that I could tear down the entire setup and add things back 24-hours-at-a-time, taking weeks and months to rebuild, but why is it that other ecosystems don't have the same problem? I never had an inkling of a similar problem on ST, with the same exact sensors. Even a few months back, my HE was running fine.
Surely there's a way to troubleshoot the mesh, or CPU issues without starting from scratch and taking months to build back up. If not, that's just insane.
You don't have to REMOVE devices, just temporarily deactivate them (and maybe apps too at some point).
If you use list view instead of grid view (upper right corner) in devices tab, you can deactivate individual devices without removing them.
To me it sounds like some Z-wave device (specifically a powered one) is dropping off the network and breaking the battery powered device connections.
You don't have anything silly like a Z-wave dimmer after a normal light switch or something? A user a week or two ago wanted to do this and it would be a horrible idea because it would break things exactly like this.
You can see individual device activity in the devices tab, choose your device, then to to "events" in the upper left corner. See if something stands out in the events.
I dont mean to jump on the bandwagon with this one, But im having similar issues with zigbee devices. I have 4 zigbee repeaters and 8 motion sensors, 4 contact sensors. I did have 1 ikea zigbee bulb directly connected and 4 wemo bulbs. I removed the ikea bulb and got lots better performance. But this morning woke up and 4 of the motion sensors are sensing (green motion light triggers) but they arent firing the motion lighting rules to turn the lights on. They arent reporting motion to HE but they are showing as bouncing off the repeaters on the table.
Last night I walked around and every sensor was working and reporting, but wake up this morning and - issues.
Iris V2 motion sensors
ST contact sensors 2018
I need to remove the wemos from direct connection, but from the table none of my sensors are repeating off that.
What are you using as repeaters ?
I've got Iris v2 Motions repeating through these guys without issue (currently)
yep - thats what im using. 4 of them in a 200sqm home. No brick/steel - all timber construction.
only have 2 orbi APs, only 1 other SSD shows up in my house thats not mine (not overcrowded).
I have 2 wemo bulbs to cut out of the system tonight, other than that - I have nfi why its unstable.
Yeah that's roughly the experience I'm having. Recommendation from support again is to basically remove all network based integrations, third party apps, and third party drivers.
If I lose hubconnect then I no longer have control of my Arlos via ST. That would sure be a headache. That's the only reason I have it installed. If that doesn't work, and hubconnect destroys these hubs, what's the recommended solution for that?
I'm also told the Chromecast integration is really flaky and takes down the hub, but it seems like that wouldn't impact sensors going stale like we are seeing. Also, if that official integration doesn't work, what's the alternative?
Not to remove, but to disable. HubConnect works well for many people and so does Chromecast Integration (beta). The reason behind disabling apps and drivers is to stabilize your hub, and identify the root cause of the problem, which allows you to work on fixing whatever the problem may be.
ah, so it's something specific to my HubConnect+Arlo? I actually didn't know you could 'disable' integrations without removing them. I'll look at that. It is always a bit of work to rebuild all this stuff over and over again.
@bobbyD do you think it's enough to disable any network-based devices as well, that are separate from any apps? (versus removing)
We understand the effort it takes to set up apps and drivers, that is why we offer the possibility of temporarily disabling both. That way, you can "rebuild" them with a click of a button. See this post for more details on how to disable apps and/or drivers:
Nice! I just went through and disabled every single network automation except Hue, and my Hubitat app. I'd be shocked if that was causing sensors to become unresponsive or draining their batteries, but I'll give it a shot. It's basically how I ran it for a week, a week ago. I just now added back my apps, but the sensor issues never faded. Seems unrelated to apps.
The good news is I haven't had any hub slowness or crashes since adding back my network stuff. The only two I had not put back were Echo Speaks (seems to be problematic I guess?) and Harmony.
Assuming you're using my Harmony Hub integration...
I'd be surprised if it was my Harmony Hub driver causing the problems... I released that driver to the community ~9 months ago, and no one has reported any hub stability/performance issues as a result. If you do determine an issue with Harmony, please let me know and I will be happy to investigate.
AFAIK there's never been an issue with it. Although I am thinking that maybe the hub was trying to talk to my HE after killing the apps... I keep getting errors in my global logs that local device was trying to ping an app id that did not exist.
Received local request for App 1449 that does not exist, path: /ping
I was not getting this before deleting all my apps the other week. Not sure what could be causing this. Was thinking maybe local network device that still wanted to chat with my HE hub.
I guess that I'm also having the same issues.
Some of my zwave devices are just not responding.
I go to the device page, hit the on button, and nothing happens,
I have just done a shutdown, and a zwave repair.
In addition, because I thought it was a specific device problem, I removed the device from the mesh, and did a factory reset, and then added it back. No change.
I am using the standard zwave smart dimmer driver.
Is there something going on with the latest upgrade?
Many people seem to be having the same issues.
Hmmm... 
The Harmony Hub webSockets interface does use a "Ping/Pong" set of messages to keep the connection alive. However, the error message specifically refers to an APP, not a device. My Harmony Hub integration does not use an App, only Devices/Drivers.
My guess is those errors are coming from a HubConnect App running on another hub/platform, trying to still connect to your Hubitat hub.
Are you running the Z-Wave Poller? If so, try disabling it as it is known to put too much of a load on the Z-Wave network if too many devices are added to it. I used to poll some old devices and experienced laggy performance when I had too many switches being polled.
I personally grew tired of Z-Wave issues as I had a bunch of really old GE/Jasco Z-Wave (non-plus) switches and dimmers. Even on SmartThings these were temperamental and would require re-pairing frequently. I have since ripped them all out and replaced them with Lutron Caseta switches, dimmers, fan controllers, and pico remotes. I am amazed at how much better the Lutron equipment works in terms of reliability and performance. I do still have an Aeon HEM v1 Z-Wave device working happily, though.
For sensors, I prefer Zigbee contact, motion, and leak sensors. These all report status instantly with no lag whatsoever. I use Lowes Iris 3210-L outlets throughout the house to act as Zigbee repeaters (they are Z-wave repeaters as well!) I also only use Sengled Zigbee bulbs as they are not repeaters like most other Zigbee bulbs.
This configuration has been incredibly reliably and performance is great for me.
I'm going through the "disable" process.
First non Hubitat apps, then non Hubitat devices.
Back to the drawing board!
Question: Is it my imagination, or is the ST Hub better able to withstand aberrant events due to it's allegedly more powerful hardware?
Please do not misconstrue this as a criticism of the Hubitat design - it's far superior. However, we used to have a saying "throw hardware at it" - which would absolve us of a lot of software issues.
Yeah as cool AF as the platform is, it does seem that ST has some sort of 'resiliency' built in that somehow prevents these hang-ups. I suppose that's just part of their secret-sauce, and any newer platform will have its growing pains. I'm definitely not throwing up my hands and tossing in the towel, just curious what methods ST uses and if that can somehow be implemented here. 
One has to remember that SmartThings runs almost everything within the Amazon Web Services cloud. These are massive server farms with amazing CPU and Memory capabilities. Poorly written or CPU intense code on that platform has very little impact as it can be simply absorbed.
The SmartThings hub is really just a bridge between the devices and the ST Cloud. Not much CPU load on the actual ST hub. The ST v3 hub actually has half of the CPU and RAM resources of the ST v2 hub. Samsung is not investing in local processing as a long term strategy.
The Hubitat Elevation hub uses the same Zigbee and Z-Wave radio chips that are found in most all consumer grade home automation hubs. Hubitat also packs into that tiny box a quad-core CPU, memory, and flash storage. It has to run everything locally, and thus drivers and apps need to be written efficiently and error-free to keep things running smoothly.
Oh yeah I get all that. The hard part for some of us is having zero visibility into that for troubleshooting purposes. Fingers crossed that it's on a wish-list somewhere to give us access to those areas.
Something tells me in my case, I really need to reset both of my radios and kill the meshes -- then hopefully change the channel to what works best. (no idea what that is.) Though I will wait for more feedback from Bobby before jumping off into the deep-end.
Download the Hubitat app
