There’s something causing you to need a reboot. What is it? Just saying it’s the platform is not based on evidence of an issue you or anyone has found with the platform. If it had been found it would be fixed. You are witness to the result of a problem that rebooting corrects. That is not that same thing as identifying the cause.
1 Like
The reboot is needed to correct/reset the system as my devices react differently because of the system - the longer its been running.
The issue is the longer the systems been running the slower devices react/work.
Didnt say I knew the cause, just said I didnt want to reboot my hub everyday for it to work in a manner I deemed/see as reliable.
*I would say .117 was the last update where my hub actually worked in the background and i didnt even notice it. Motion worked, groups fired quickly, I literally keep running notes everytime I touch the system/run an update so I can look back if I have made changes to undo them if an error occurs and I need to backstep. Very minimal notes for .117 from my experience.
Last 2 updates things have been getting slower and slower to the point now im being told if I want my system to operate "normally" I need to have it reboot everyday.
Like I said, maybe im asking too much of a $160 hub.
I agree with @SmartHomePrimer. Though I must say I too thought at first it must be the system. But after all this time and reading all different messages about what might be the cause and might not be. And also stories of people solving it. I'm starting to think it could be anything (even a mesh error, since nobody reboots all devices in their mesh while the hub is offline).
Why do I start to think that it can be anything because (at least in my situation) the speed at which it progresses is different every time after a reboot. I used to do a nightly reboot until I though that that wouldn't help me find the cause. So I stopped doing that and went back to manual reboots. And since that time I had two events happening (two z-wave devices just suddenly dropped of the mesh, had to do a include again for the hub to see them, a lock and a siren) (and the second event was a update from 115 to 117 with a reboot). But since those events I haven't had any slowdowns anymore (about 8 days now). Which doesn't say it's solved, but it could be that the two devices caused something for a while that screwed with the hub before totally dropping of. Or something else which takes longer to happen, hence the longer period I'm waiting now.
What I'm trying to say is that we are all looking at a cause in the hub, while it might just be outside of it.
2 Likes
so would it not be better if we stated our system number, model number, devices and community apps to see a pattern ?
1 Like
I was looking at the bottom of my Devices tab when I noted that some Devices were assigned to Apps or Rules that I knew they weren’t being used in.
When I looked at the apps or rules, sure enough those Devices were NOT listed or visible. But the Devices tab said they were being used by them.
I’ve since deleted what I think are all these “peculiarities”.
Just something to check.
Did you look in the app properties or just in the app itself? If it's not listed on the app properties, then it shouldn't be in-use-by.
Slowdown issue still affecting me even after updating to 2.1.9.117. I have to reboot every couple days otherwise everything slows to a crawl. Even opening the login page takes quite a while when the hub gets into slowdown mode.
I did not have this issue several versions back, and I haven't made any changes recently since the slowdowns started happening. There was clearly some bug introduced in a recent version that causes some thread to runaway and eat resources.
2 Likes
There was a thread recently where app were hanging on to devices say if you swapped a sensor for another
1 Like
Since that has been around forever and the only symptom is a false "in-use-by", I would be very, VERY surprised if this had anything to do with hub slow-downs.
1 Like
So I just had a good experience following the advice on this thread:
I bought the UZB stick and installed the software and was able to identify a flaky Nano switch that was bogging down my main hub Z-Wave network. Highly recommend.. it's fairly simple in terms of setup and execution.
8 Likes
Very nice!
1 Like
I have never had slowdown issues on my four C4 hubs, But I use very little Z-Wave or ZigBee - a sprinkling of devices on each so I've long thought issues on these networks might be the elusive culprit for slow downs.
Whilst I partially agree with our 'Ambassador' @SmartHomePrimer in his defence of not being a Hubitat defect persay I do think if this issue is contributory then HE could do a bit more to identify and alleveiate it and warn the user that this is causing issues. Maybe monitoring any Z reponses, timing them and alerting the user as well as isolating HE's overall performance hit from such scenarios, assuming such is possible.
I do believe that an 'automation controller' that you purchase for your home should be near 100% reliable and dependable both in terms of what it does and how quickly it reacts - to the best of it's abilities being dependent on external network frailties.
Rebooting is a plaster for a wound that masks an underlying issue.. somewhere. An automation controller should never require this to ongoingly function. I could not depend on such a controller.
3 Likes
It would be the first ever if they could somehow pull that off. 
2 Likes
I agree but there is no reason it shouldn't get so much better than experience shows here... unless..... the external interfaces break...
i.e.
Z-Wave and/or ZigBee are not tameable in this way
(which is always a worry with radio based systems)
To a lesser extent WiFi ?
Internet fails
Your Intranet fails
A device physically fails
.. and I use 'unless' to mean the latter three really - are Z networks fundamentally flawed in this respect, except the obvious flaw of being radio based ?
P.S. You might get the impression I'm very sceptical about the capabilities of 'Z' and other low power home control networks in more challenging environments - I'm an RF engineer - you'd be right.
You and I are more in agreement here than debating
Evidence that I see shows Hubitat is headed in that direction. The timelines for updates, fixes and improvements is faster than any home automation platform I have experience with.
As for low power radio protocols, well yeah, but what would it look like to launch a hub that doesn't support what the industry has delivered? I mean, these guys didn't invent the protocols the hub is using, nor did they make the decision that the majority of the home automation devices for sale should use them. Perhaps a vision of Hubitat in the distant future might include them creating a new protocol. Reality today is, they are a small startup, and not in the position to call those kind of shots like Google or Amazon has tried and are still trying to do.
They're making great strides with what the industry had given them to work with, and breaking ground that no one has broken with a consumer home automation hub to date. I applaud their efforts and intend to keep supporting them by staying calm and not extending a finger at them every time I encounter an issue, rather than figuring out what the problem is (present company excluded of course ).
No doubt someone who fails to completely read my post or understand what I'm referring to will automatically reply with something like "it never happened before the latest firmware update". But responses like that just completely discount the idea that a device can start causing issues at any time. Just because they notice the issue following a hub update, doesn't mean there's instant proof that it's to blame. I've been in that software update blame trap many times in my life and pretty well always have nice big plate of crow in the end. 
Time and time again, those like @frits that eventually discover what device(s) in their system was causing the issue, quickly realize that the hub platform, while not at some euphoric state of perfection (that doesn't actually exist anywhere, with anything) is actually quite stable and fast once the problem devices are found.
Rome wasn't built in a day! 
5 Likes
I shouldn't have said anything. I jinx it. Tonight (my local time) I had a slow reaction of a motion light again. But I'm pretty sure it wasn't the hub because a different light with a different motion sensor did work on time right before it happened. And as soon as I pushed a button for another light the light in question also went on. The odd thing though was that the first light (zigbee smart light with z-wave motion sensor) worked as expected. Though the next light (zigbee smart light with zigbee motion and zigbee contact sensor) didn't work. And as soon as I hit the button (zigbee hue dimmer button and zigbee smart light) not only that light went on, but the one not working also went on. It was like the zigbee mesh on HE ( because all zigbee light are on their own mesh on the hue bridge) was asleep until I hit that button.
This may be a delay that happens within the Hue API. I occasionally get a delay on certain lights (all Hue) attached to my Hue bridge, but similar to what you’re describing, on the second press they work right away. I have actually had this happen when using the Hue app too. Never have figured that one out, but it’s minor and very seldom. I have a lot of other stuff that’s IP connected that I really need, so that’s an issue that I’m not that concerned about. It is nothing like the slowdowns that eventually occur if I don’t reboot daily. That’s a problem I would like to find, but I’m too busy right now. Happy with the automatic reboots overnight for now to keep the WAF at a high level.
1 Like
Same here. All was fine before the updates. Now it’s requiring reboots and my Schlage locks are dropping.
If you really suspect that’s the problem, why not roll back?
4 Likes
I’ll be doing that tomorrow. It just locked up again. WAF declining 
