Is it supposed to be argumentative? Because I don't think you're going to get anyone to argue with you. We all want better tools. Motherhood and apple pie.. it's a given.
Is it supposed to be a threat.. that if you leave, we'll crumble? The Community will be unable to continue? I guess we'll just have to take that risk.
I think it must be rhetorical.. a bit of venting and that mostly, it just needs to be ignored.. The answer has been covered soooooo many times, there's nothing more to say.
This has never been the case. There is a disable button on all apps and devices that allows you to temporarily disable them. You can try turning off one app or device at a time until you find the offending thing. You can also pause rules in RM to see if any one of those is causing issues.
Just because you didn't change anything doesn't mean something didn't change. Devices fail. Databases get corrupted. And so on.
I guess it depends on what you are expecting when you disable a device.. they are still paired and communicate at some level. Also flaky devices can impact the network outside of the hub.
It's just really frustraiting that what was a good reliable system has become unreliable and slow (seemingly without any changes to configuration).
I beleive the problem is more app related than device relate. I say this because opening a device, a switch for example, and clicking on "on" or "off" has an immediate effect but an app opperating the same switch is subject to long delays.
I have tried disabling apps one at a time and this doesn't help, I have tried disabling devices one at a time and does't help either.
Tracking this problem down without some better diagnostic tooling is going to take a lot of time (that I don't have). Could we not have a way of seeing how much processor time each app is using? I have started to move some of my more critical devices over to a Raspberry Pi running python scripts which I have written. Each of my devices / apps on my raspberry report back to me their excecution time which immediatley highlights an issue if something is taking too long and slowing the system down.
I am not trying to be negative and unconstructive, I really love the design and functionality of Hubitat but it needs to be reliable to be of real use
Yes. In the upper corner of the Devices page, you have to click the "list mode" button. You probably are in the "grid mode". Not sure what they are actually called, but whatever. See the picture below. This button, despite being greyed out, will work.
Then click on the red
You can then check off the device beside the device.
So, i have spent the last 2 weeks deleting code, replacing custom apps with RM apps. Moving more complicated apps over to my raspberry. Despite all of this work the hub is getting less and less reliable. I'm pulling my hair out with frustration here.
A few months ago everything was fine and then (with no code change) the hub started slowing down.
Its so annoying that there is no tool available to help me
I agree with you. This is a bit ridiculous making us guess and randomly disable apps until we find the issue.. Why can't we have a tool to identify the slow downs? Why is this ask so unreasonable?
So, I want to never ever experience hub/device slow downs. I'm already using HubConnect, however when running some apps on the hubs with devices, I occasionally see delays of up to 3 seconds for a simple motion rule to run. This does not meet my personal requirements. If I move all of my custom apps to a dedicated/ isolated hub (independent of the device hubs), will this help with device/hub slow downs? I realize this is a theory question, but still need the guidance...
I don't believe there is one right way. The LAN connection is 100x faster than any Z-device. Therefore an Event can make a round trip... Sensor event generated, over the LAN to another Hub, a decision made and sent back over the LAN, to a Hub to implement the result.. with no significant (human detectable) delay.
Where the decision to do something (as a result of a sensor) occurs is moot, in my opinion.
I chose to NOT offload the decisions because I want each Z-device Hub to be standalone. That's just my design preference. I have an Upstairs hub and a Downstairs hub and when I imagine I want to do an upgrade on my Upstairs hub, The choice to have a decision occurring on another hub that can't reach the rebooting hub is indistinguishable to me from having the single hub do it all.
I also have but a single Zigbee mesh. That means Upstairs and Downstairs is Impossible for me. One of the two hubs has the only Zigbee, and it must communicate those events to the other hub. My whole segregation architecture is blown.
It still works wonderfully... exactly as those with another architecture would tout as well... I believe it's because 1) HubConnect is an amazingly Light Weight App for its power. 2) The LAN speed is so many times faster than the results.
Long before HubConnect was imagined, I had 3 hubs interconnected. I did it for that exact reason.. to move Apps that Hubitat were saying were risky to an independent hub. I had a vast improvement BUT I don't attribute it all to moving the apps. I am as lazy as anyone and I didn't want to be moving apps. Where I could, I simply discarded them!! Months later I may have moved some back. One of the big ones in that category was Homebridge. I removed that app at least 3 times, which of course means I installed it three times too. After HubConnect, and especially after the HubConnect version of Homebridge I've never even considered removing it.
This is my downstairs hub.. the list of Apps is tiny...
Upstairs is the same... very tiny list...
(I use ABC -- Advanced Button Controller for my Pico's and that's what's at the top.)
My hub started by slowing down over a few days and a weekly reboot sorted it out. I am now at daily reboots and it still takes multiple seconds for the simplest of RM rule (contact opens then switch on light for example). Devices appear unaffected by the slowdown, only apps. Some RM rules dont execute at all on a random basis, the logs offer no clue. I have spend the last few weeks moving code off hubitat to a python system running mqtt. I have moved my heavier code away. My hub has probably 1/2 the load it once had but things are still getting worse and worse. I have now ordered a zigbee usb card for my raspberry, just need the time to rewite all my automation in python.
Such a shame as Hubitat was great right up until it wasn't
Hello @mhutchy
I'd like to share a few ideas that have helped me get over the infamous "slowdown". I don't mean to sound arrogant or patronizing, but these approaches have really helped me, and they may help others.
Whenever possible, move rules from Rule Machine to: Simple Automation, Notifier, and Motion Lighting. Even if you have to replace 1 RM with several SA, then it's still worth it. The basic reason here is that the price that you pay for the incredible flexibility and power of RM is lack of execution speed.
Concentrate on moving out those rules that are used very frequently, and that require great response time to work (like motion lighting).
(As per my suggestion #1) , use Motion Lighting wherever possible - not a complicated rule in Rule Machine whenever you need fast response to the motion.
Getting an additional Hub will help, but try and keep Simple Automation, Motion Lighting, and Notifications on the same hub as the root devices themselves. Put Rule Machine and other cloud connections on the other hub.
Simplify, Simplify, Simplify....
After you do all of that, and you still have issues, then we start to get "technical":
Eliminate dead zwave nodes (see notes on the use of PC Controller).
Learn how to "zniffer" to keep your transactions fast, and to eliminate problem devices
Investigate Node Mapping software: XCTU (on XBee for Zigbee), and PC Controller (Zwave)
P.S. One more last point:
A large number of users have found that if all else fails, investigate using Node-Red as a replacement for Rule Machine.
I would also say based on my very recent experience a flaky device or two on the network can cause havoc.
Bad Z-wave devices seem to cause major hub slowness and Zigbee devices seem to impact the Zigbee network in odd ways sometimes bringing it offline or causing other devices to disappear. I unfortunately had both..
Also noticed that Groups and Scenes entries can cause issues as well. Had a group of sengled bulbs that just stopped responding. Changed over to the "generic" version of the driver and things appear to be better more responsive.
I'm just waiting for the day. Despite all the slow down and seizure issues I've suffered, my take is this is an emerging technology (hub and devices) and the problems are kinda expected. But if we could throw more grunt at the problem it should help. I would also pay more money for this. Although we'd still be limited by the speed and resilience of the mesh network in many cases.
Months later I may have moved some back. One of the big ones in that category was Homebridge. I removed that app at least 3 times, which of course means I installed it three times too. After HubConnect, and especially after the HubConnect version of Homebridge I've never even considered removing it.
THIS.
