Hubitat slowing down after a few days

Lol this happened to me a couple of weeks ago. Completely locked up the hub for a few minutes!

1 Like

Guess Iā€™m in good company then!

2 Likes

Thanks for your story.

I also have the same disease, and it could be the same cause.

I am trying to pinpoint the culprit (the screwed up device), by zniffering.
However, there is just so much traffic that appears to be normal, finding the one device that is screwed up is proving to be difficult. Also, if you have many zwave devices, this can just take forever. I had in the mid 60's, but have now pruned that to 55 zwave devices.

It takes a lot of effort and time to pinpoint the device.
If anyone knows of any shortcuts (with zniffering), I'd be interested in hearing about it.

I think this is one of the fundamental issues with no clear solution - how does someone especially a non-technical person easily isolate an erratic device like this?

It's one thing if you only have 10 devices but if you have 60, 100 or more then things become problematic.

Also I suspect just disabling the device won't always help as it is still connected to and can potentially influence the mesh network.

Don't envy the crew at HE at all having to figure these kinds of things out,

1 Like

I must also say, that in despair (because I've been looking at this for a while, with no success), I've even tried to replace many zwave plus devices with zigbee devices.
For example, I originally had a number of zwave (not plus) outlets. So, I bought myself a whole bunch of Dome zwave plus plugs.
Unfortunately, that move didn't get me any closer.
So, I replaced all of those plugs with zigbee plugs.
That didn't get me any closer either.

I don't view this issue as Hubitat's issue. I view it as my issue. My mesh, my home, my automations. This is something that I alone will have to fix.

If I ever find out that this whole issue was a "resource leak" on the hub, I will be very upset.

2 Likes

Since you bring up offloading the performance just to another device :rofl:...the interesting thing I've seen (again, not as a programmer, just using automation as a side hobby and learning by doing and watching what others do) is how often the conversation has been coming up lately about hub performance and frustration with it. At least it seems more common lately (granted I've only been using HE for 2 years). Getting off topic of my own question (which again, seriously guys, thank you for the quick responses and awesome feedback) I haven't noticed any impact myself other than the occasional one-off that I don't consider serious enough to track down, but I also don't consider myself a power user (only 29 rules in RM, 1 in simple automation, and 77 devices).

Looking at this post, this one, or even this post (that frankly devolved into lunacy IMHO from a previous post), it seems pretty clear that performance is a serious issue for various users. That being said, I think staff has made it pretty clear that the expectation is not to have 'one hub to rule them all', but to serve the general mass market. It's like that one person walking up to the pharmacy saying "generic synthroid doesn't work for me". Well, it works for the other 200 million people on it, so the option is go big and pay for the big name, or stick with what works for the vast majority (and in the case of HE works well I think), realizing that it may not meet 100% of your needs/expectations. Go ahead and write the company that you want them to change a multi-million dollar production line for one individual. Can't wait for the answer :laughing:.

Something I've learned just watching the forums, and feel free to correct me if I'm wrong, but I feel that preventing issues before they have an opportunity to potentially impact hub performance is better than trying to figure it out after the fact, and as such I generally stick to my own rules as far as:

  • Stick with 'mature' systems (Phillips Hue, Lutron Caseta) to handle lighting and offload those devices from the hub if possible (letting the native bridge handle the actual control, HE just sends commands). I don't add switches or lights outside of Hue or Lutron Caseta.

  • Zigbee seems to be a little iffy, depending on the device and what you read, so I focused on building a robust z-wave mesh for anything outside of lighting (outlets, motion sensors, contact sensors, etc.).

  • Limit non-native apps, remove those that are not used.

  • I try to keep rules simple, but still have several pretty 'heavy' rules that are mostly dealing with what to do when someone arrives (thermostat scheduling, lights on or off depending on mode and time of day, HSM arm/disarm, etc.). Hence my interest in NR; a common theme lately seems to be offload what you can onto something else to do the processing, let HE do what it does best as a device handler/coordinator. Since I happen to have a Synology NAS that is probably better and handling complex processes and was designed for that...makes sense to move some rules over.

There's a few other minor items (turning off logging, dashboard efficiency,etc.) that I've seen, but the point is that if users would just take the time and patience to read the forums, ask rational and detailed questions (rather than just vent frustrations at the staff), most problems can be solved. The solution may not be 100% perfect, but from what I've seen here it's exponentially better than you get from Samsung or other big name companies.

5 Likes

For the people having "the issue".. call it name-du-jour... it's serious for them. Frustrating mostly, which devolves into anger and worse.

I get that, and yet I can't entirely relate... I don't have THAT problem. My Hubitat hubs run fine. My non-Hubitat-hubs (ST, Node-Red, Homebridge) all run fine.

Frustrated people don't seem to appreciate my "works for me" or "Well, it works for the other 200 million people " and I get that too.. but NOT having those comments in those threads (because of lashing out) means those topics appear far more common than they are.

But I'm one that's been doing multiple hubs years before Hubitat was born. Today's set is NOTHING like my previous set. It's a different set, but a better set than I had before discovering Hubitat.

I 'discovered' Node-Red in 2016 I think, before it was the useful thing it's become.

4 Likes

@csteele @erktrek totally agree - I'll +1 the hub issues and performance problems havee grown enough that I've pretty much decided to take the plunge into node red too. It's increasingly clear power users can't rely on the hub by itself.

I think the danger for hubitat is we're (techincal folks) are the ideal early adopter audience and they don't really cater to us with the response about hub issues, if I were the leadership I'd be looking seriously at adding more power to the hub, they say that's not the problem but whatever resource is missing, is affecting power users. I'm not sure I'd recommend the hub to friends any longer - someone who can live without the power can also live with the smart things outages. Anyone who wants that power wouldn't want to find their hub randomly crash and no real way to troubleshoot.

2 Likes

For technical people the inability to dig in and see the gory details while simultaneously having a super flexible platform (custom groovy stuff) on the surface is kind of maddening don't you think?

Node-RED offloads more than just processing - it also gives us some semblance of control back - all in an opensource package. I can add as much memory and storage to my server as I want. I can see the stats, run tests etc whatever. Of course if I screw something up then it's on me but I'm okay with that.

HE is an awesome device manager/controller with some cool integrations and that's what I am using it for. I am all in with both HE and NR at this point.

6 Likes

The bigger danger is as more and more people face these issues, and not just power users, they're turning to other avenues like node-red. But node-red could be like a gateway drug. You start by moving your simple things off the hub, then more and more and more and sudenly you're wondering if you really need it at all?

I'm using HE as a device controller, home assistant as a front-end and node-red for all my automations. I'm currently extremely happy. But if things went sour, I am literally 1 usb stick away from eliminating HE completely. I'm not saying that's my plan but if my hub crashed it would be an option.

3 Likes

And that's bad for the consumer how?

HE is a great product with great people behind it. While I may grouse a little at their "proprietary" stuff - the system works, is easy to setup/maintain and is local - pretty much everything I need for myself and possibly my residential clients. If something were to change in the future at the very least I could keep the HE hub the way it is OR thanks to a system like NR swap it out for something else. There is no danger for me..

edit: to be clear I want HE to succeed and make ALL the moneys.. it's just that as a consumer I want to make sure my needs are met and protected too.. :wink:

I would like to think only power users and the curious will face issues (and start tinkering with other alternatives). Most consumers on Smart Things just accept it doesn't work sometimes, as I suspect most people on HE accept that it doesn't work sometimes. We have come to live with this (be it good or bad)

Agreed I find NR flows much easier for complex rules. I'm a visual person, seeing the little blue dot "flow" through my rules is not only exhilarating, it lets me see where things are failing.

Maybe short term (locks your days are number just wait!!), but my wife and I will not tolerate an automation that does not work at least 99.99%. If the power is out, your off the hook, aside from that work, or be replace with what does.

1 Like

It's not bad for the consumer, it's bad for the business. The only current revenue stream for hubitat is selling hubs, so what happens when people start outsourcing everything the hub does? No more hub sales = no more business

I'm not so sure based on the current number of threads about issues with slowdowns, rules not firing, etc.. Many of those exploring are far from power users. In fact I'd say they're right in the target demographic that HE is looking for.

I know I've said it before, but in order to attract the target demographic that HE is looking for, they must cater to the power users. It's the power users that push the platform's capabilities, write new apps and drivers, walk people through how to make rules in RM, etc... If they all leave because the platform simply doesn't perform for them anymore, all of a sudden the capabilities of the hub will diminish and it's suddenly less attractive to the average user.

2 Likes

Node red isn't a replacement for the hub, it's a programming tool providing additional functionality. HE is a simple all in one way to manage devices for most people. And in reality the number of NR users on HE probably forms only a small subset of all HE owners.

TBH I could have also gone Hassio but couldn't bring myself to be constantly amending yaml files.

That's a fair point. However I suspect that HE DOES cater well to the bulk of users as is. No one device is able to cater for every single need but part of the appeal of HE is the willingness of the HE team to assist devs as well as fixing bugs on a very timely basis.

4 Likes

I know NR isn't a replacement for the hub. I think you missed the part above where I said it's like a gateway drug and that I'm now at the point where I am one USB stick away from eliminating HE completely. Hence why these issues can be detrimental to a business that's sole source of income is hardware sales.

HE does very well at catering to the bulk users in it's current form. But what if there were no custom device handlers or apps since 95% of those were created by what we're considering power users? I'm simply making an educated guess here, but I would say well over 50% of HE users are using some form of custom device/app. So if all the power users left since they've "outgrown the platform", how many of the bulk of users would leave with them? It's a very fine line to walk when weighing cost vs return to cater to these power users.

2 Likes

Saw that. :grinning:. But if you are already using Hassio for the front end there really isn't much point to using HE rather than Hassio for device management other than ease of use, isn't it?

I guess the same could probably be said for other platforms like smartthings (and it's still around, of course no doubt in small part because it's Samsung).

HE's real appeal to many is its local control and device handling being similar to smartthings so many devices can be ported over. Even now we are still able to rely on ports from smartthings.

Would they though? Once you've heavily invested in a platform it's still a lot of work to migrate away unless something really newer and shinier comes along.

1 Like

HE in it's current state makes an excellent device controller. It's got good radios and a wide range of supported devices (see note below though)

There's about to be a mass exodus from smartthings when they complete phase 3 and shutdown their groovy ide in favor of a new platform. I think HE will benefit greatly from that since, as you said, we can easily rely on smartthings groovy apps that can be ported.

But who's going to do these ports? The average Joe? No, it's the power users. That's why I say it's a fine line to walk. Lose the power users you lose all the new app/driver development (not quite all, there's lots of talent on staff too). If it weren't for custom drivers, HE wouldn't serve my purposes at all. And I don't feel like I have many "fringe" uncommon devices.

To get away from slowdowns, locked up hubs, rules not firing, etc... yes, I'm certain they will.

2 Likes

TBH I do wonder if this is really that widespread or most users just take it in their stride. I've definitely had the occasional slowdown, unresponsive buttons/Alexa commands and rule misfires too. But for sure, if a better hub comes along I'll look at it.

1 Like

Disagree for many reasons. Suggest to do your own research on this. In my opinion Zigbee > Z-wave. Each to their own of course.