I know how to reboot using this method, but I stopped because I was afraid of losing any device info or data? I won't lose anything this way correct?
I did and sent the info to Bobby, but response is a little slow for my liking so I am trying to go to the community to see if others are finding the same problem. I sent Bobby the same screen shot today around 10:00 a.m. and gave hime my Mac Address so support could look at it. I have rebooted for now to pick up the speed, but this is the only hub I am having problems with and I have three of them. So any help is appreciated.
You're far more likely to corrupt data by pulling the power out. Please use the method indicated by @csteele.
Second, as requested by @neonturbo, could you post all the apps and you're currently using.
3 Likes
In general, no.. however, during any boot, the Hub checks the DB. IF it finds a corruption, it rewinds back and THAT DB might be missing some changes you made.
However, if that happens and you DO have a backup pulled off the Hub for safe keeping, you can use the Soft Reset mechanism to get back to where you were at the time of the backup.
So.. the steps are... "UI is starting to feel slow.. better get a backup, and refrain from making big changes."
"UI is too too slow, I need to reboot. I'll use :8081."
"If the reboot takes a very long time, in the 10% - 20% range, the hub is probably rewinding to a better DB. I will think about doing a Soft Reset when the hub is back to speedy."
5 Likes
Thank you for emphasizing the correct way to reboot. I will trust your judgement. I have very few apps on this Hub. It is my Server Hub and the Main App is Hubconnect and the Amazon Skill.
Three suggestions:
- Do not use the "Use all your devices" choice on either of your Dashboards
Only select those devices that you actually use on each of those Dashboards - Since you don't have any rules, remove the Rule Machine app.
- If the slowdowns don't stop, consider rebooting your hub once a week. You can use an app such as Hub Rebooter to do this.
7 Likes
Thank You! I thought I had the "Use all your devices" turned off and when I checked, it was on so thanks for pointing that out. I will follow all the other steps as suggested and monitor this. If I'm still having problems, I will repost on this thread.
The slowdowns are not normal. However, they've been a problem for a very long time. I think it's fair to say there are multiple causes and Hubitat has been swatting them down piece by piece. And there are more to come, I'm sure.
That periodic reboot is a workaround. You should not need it, but if you're affected by one of the remaining mysteries, then it might make things feel better.
I will say I run 4 production hubs and up until early this month I had never had an unknown reboot. Early this month I installed some software on all my Hubs to test and I began a slowdown and daily crash on ONE hub. I removed the software from that ONE Hub a couple weeks ago and I'm back to: never reboot. The other 3 hubs are still running the software for testing and loving it.
My point is.. "slowdown" is a symptom with lots and lots of causes and dependencies. Finding yours might be simple, might not.. we can't tell yet. 
6 Likes
This helps me because everything has been running smooth. Two of my hubs are perfect and this one has been acting up. Obviously when the Hub comes to a halt, none of the Automations work. The rules are on a separate hub but the server hub is at a standstill and nothing happens. I appreciate all your help this late. I usually don't expect a response until the morning.
2 Likes
Many times. Here is a log of my issues and the efforts I've made to fix it (listed about half way down the thread, post 102). Maybe it will give you some insights too.
Thankfully I've always managed to access the hub's admin/reboot page without having to pull the plug. Please really try to avoid that.
1 Like
I have bragged here many times that I have never had a hub issue... Last week I walked into the kitchen where motion picked me up, light took 5 seconds to turn on, confirmed in the logs
With that I opened a support ticket, still waiting for a response
Next, I read an article here where power reporting devices could be hammering the logs and causing issues. I have 8 so I went in and turned on debug logging and started to have a look
Well, talk about the hub coming to a crawl, no response most of the time, pages timed out, couldn't get to :8081... I had one tab open to see logs and thankfully it would refresh from time to time. Nothing showed to be hammering the logs more than every 3-5 seconds so I don't believe I have a device issue
As debug was being turned off automatically for each of my 8 devices, the response finally started to return. Once it did, I rebooted and now everything is normal
Moral to the story, don't do that again
2 Likes
A number of people have said they saw a noticeable performance increase after updating to the latest firmware, so far I'm still on 2.1.9.117 so I cannot confirm.
1 Like
I recently discovered this with my inovelli switches. I had 30+ of them installed and their was a bug in their firmware that didn't disable power reporting. I upgraded the firmware disabled power reporting on all my devices in my home and my z-wave mesh is now sooooooo much more faster thanks to that. I think power reporting should be off by default on these devices.
I don't think that is the issue here.
This hub seems to have so little on it compared to others. 2 other things you can take a look at that I've seen mentioned in the forums,
- Temperature, make sure that its well ventilated.
- The power supply. Some have reported replacing the power supply with something that gives a little more juice and it has solved their issues.
2 Likes
Okay, I have tried all the things recommended in this thread and even referenced other threads to try to identify why the hub is inoperable every 48 hours. None of the suggested fixes worked. I have isolated the problem for now. I removed Hubconnect App and all the Apps and Drivers Code from this Hub (Which is the Server Hub). The Hub is back to normal and operating at the speed and efficiency as it should. All my devices are still paired to the Hub, so I believe it is not a device issue.
I will now begin to add Hubconnect and the drivers back on the Hub. At least I narrowed it down for now. So my conclusion is that,
- I may have created a problem when I installed the Hubconnect APP
- There may be a driver that is causing the problem.
- I installed many of the Hubconnect drivers including those that I don't need yet, so I will only install the drivers that I need.
- Once Hubconnect connects all three hubs again, there could be a problem with a rule that causes the problem when it communicates with the server hub. If this is the problem, then I will disable that hub and see what happens.
- My Server Hub was running hotter than the other two hubs and once I removed Hubconnect and the Apps code and drivers code, it is equal to the temperature of the other hubs.
I'm still replying to this thread until I solve the problem so others can remedy their fix, if they continue to have issues. I'm at least glad that my Hub is working fine and that it is not a faulty Hub. I also recognize that this problem is so difficult to resolve because there are no two home automations set up exactly alike.
- Possible, but unlikely if you mean simply adding the code to the Hub and then selecting it to be installed.
- Just like above, none of the drivers will cause a problem all by themselves.
- You can add as many of the drivers as you wish, unused drivers don't get run, they just occupy some memory waiting for an event that never comes.
- Let's focus on this
- Some people have turned the hub over so the vent holes are UP. But the heat indicates you're CPU is running hard. Which kind of reflects back on 4.
HubConnect's job is to 'mirror events" between hubs. It doesn't interpret Events. It doesn't calculate results. Using EventSocket, the "sending" hub doesn't even use HubConnect code. EventSocket is a feature of the Platform and contains EVERY Event generated by a Hub. HubConnect is bidirectional, so it's difficult to discuss in isolation. But I'll try..
A Remote Client hub has some Events that need to be seen on the Server hub. The Server hub opens a 'permanent' connection to listen to the Remote Client's Event Socket. At that moment, every Event instantly becomes available to the Server hub. As an Event arrives on the Server via the LAN, HubConnect injects the Event into the server's event queue. That's it, HubConnect is done for that Event. (It's bidirectional, so the same thing happens the other direction... the Remote Client listens to the Server's Event Socket and injects Events into the Remote's event queue.)
What does an Event do on any hub? It causes the platform to scan through the list of subscriptions and call each. A Rule would subscribe to the Events of a device. For every Event from a specific device, the Rule gets run. The Rule might end quickly as it detects the Event is for an attribute it doesn't care about. Maybe a Battery Report comes in from a Contact Sensor, and the Rule is for the contact, not battery so the Rule ends. Alternately, if an Event comes in and that requires a large Calculation/response, then the hub would be busier than for a smaller Event. Maybe "Sunrise" event occurs and that requires going out to a weather site, and gathering a fistful of values to calculate the Sprinkler schedule for the day.. obviously that's a lot more work for the Hub than a contact sensor that turns on (or off) a single light. My point is, yes, the rules being run matter. Where they are being run matter too.
I completely agree that disabling HubConnect will restore the hub to a less busy hub, because zero events are hitting the hub. It's what the Events do that are consuming resources, not their existence.
My suggestions are.. ReInstall HubConnect and all the drivers. But you want them disabled. Do that by going into each Hub Device and clicking the Off button. You do that and you will have a chance to let HubConnect run, with zero events arriving. Your hub should remain cool and responsive.
Then, one at a time with significant waiting between, Click those hub devices back On. One of them will cause the Hub to run the large resource drain, and the hub should go unresponsive and heat up. Once again, you can click that specific Hub device to Off and verify the hub's responsiveness returns.. not necessarily immediately, but once the backlog is processed.
Then it's time to start debugging which Event is causing the problem.
Thank you for taking the time to address my trouble spot. I appreciate your thorough explanation of the Hubconnect platform and the effects of the rules. I will definitely take your troubleshooting advice on reinstalling Hubconnect. I tend to agree with you that the problem is no.4. It's a process of elimination to find the problem and I am happy that you are helping me. I'm one of those people that don't give up easily on solving a problem and also feel a sense of accomplishment once I do. I'm not sure what I would do if I don't have conflict in my life. 
2 Likes
I'm still narrowing down the problem that still slows down my hub. I am adding one rule at a time to isolate the problem. I started with adding 5 separate rules first and the hub shut down again once I loaded HubConnect back on the hub. So now I disabled all of them and will begin adding those first 5 rules one at a time.
But I started thinking about my rules and devices working together. Attached is a screenshot of one of my rules. As I study it, I am noticing that many of my devices are labeled in (parenthesis). When I review my rules, there are (parenthesis) that regulate the action of the rule.
Here is my question: Would the devices that are labeled with the (parenthesis) reap havoc on my rules because the ( ) should be used only in the rules and not labeling devices? Could this cause my hub to come to a crawl? If not check my screen shot rule because it was one of the 5 rules that were running
That's a while back and perhaps the platform is trapping really well now...
2 Likes
Yeah I broke a rule yesterday, and now have a persistent globe variable I cannot delete, by using ">" in the GV name. Don't do that.
1 Like
csteele,
Thanks for sticking with me on this fix. I FINALLY SOLVED the problem! Through a process of elimination it was None of the Suggested Solutions above. My Hallway Light Switch Device was the culprit. After adjusting a setting (about the time this all started) it was actually not functioning right. I never noticed it, because it would go on and off properly from the motion sensor trigger.
I set the Device back to factory settings and made sure I removed it from the ZWave network. I installed it back on the Network and the Hub now works just as fast as when I removed Hubconnect.
No Support ticket or anyone else would have been able to pinpoint this problem. I had to troubleshoot and eliminate rules, drivers, and user apps ONE by ONE until I could zero in on the issue. I just wonder if malfunctioning devices are causing so many other hub "slow downs"? Or it would just be a number of things and the only way to figure it out is to start from the beginning or where you left off, before the problem began. Anyway...thanks for all your help!!
3 Likes
