Frustration with hub inconsistencies

[mik3]

@bravenel

We have an approaching-an-asymptote sort of performance thing when dealing with CPU speed. 8x the cpu speed will move you further out on the curve, no doubt, but is it worth it? We think not, by a long shot.

Sure, I agree especially if this substantially raises the price of the hub while only targeting a small group of power users.

However, this doesn’t explain the inconsistencies. Meaning motion lighting works well and averages around 350-450ms to all of sudden 1-2 full seconds for no apparent reason randomly throughout the day.

Also, the needed random hub reboots to keep things working well.

I’m sorry, I’m tired of all the time spent trying to sort out motion lighting, and the causes of slow downs.

All I know, pull all apps off the hub and do the logic else where, and things run smooth and consistent.

Lastly, I disagree with the KISS examples. I feel like this is just telling the end user to work around the hubs limitations. Obviously people can construct botched rules, and maybe some people need to see these examples, but why give us the ability to break it so easily. Maybe add some smarts to rule creations? A check system perhaps? Something that checks the logic. I don’t even know if this is possible...

My thought is this, we should only have the flexibility to do what the hub can allow without bringing it to its knees. This could be a bad and a good thing depending on how you look at it.

At the end of the day, what I can say is this. A rule, rules, or apps are the cause of my slow downs. Once I remove them, things run great.

Believe me, I wanted Hubitat logic to work for me, I’ve spent a year at it. I can deal with 350ms motion lighting, but the inconsistency and required hub reboots have drove me nuts!!!!

Examples:

Walk into a room, 350ms motion lighting, I’m happy. Walk into another room 600ms, walk into another room, 350ms, and walk back into the original room 500ms.... hub slows down after 24 hours and calls for a reboot. Walk into a room 2 seconds, walk out and back in 5 minutes later 350 ms.

Looking at logs, errors. Soft reset and things are good. Continue down the path of inconsistent motion lighting, and all of a sudden more errors are found in the logs.

This just goes on and on and on. This has been my experience with the product.

Pulling all apps and using as a gateway, things run good! For the first time in 15 months I got 3 weeks of uptime! That’s amazing! Sadly, as I said before, no apps or logic is being done on the hub to achieve that.

[Angus_M]

Very similar experience here and in the process of moving at least all the motion lighting logic off-hub.

[bravenel]

@mik3

Lastly, I disagree with the KISS examples. I feel like this is just telling the end user to work around the hubs limitations.

These two are completely unrelated. For one, I don't and most users don't experience any of the slowdowns that a small number of power users report, so this is not really on my mind most of the time. And KISS is a meaningless thing to suggest to a power user, isn't it?

The reason for KISS has to do with everyone else, not power users. It has to do with getting basic things to work, to understanding how every day automations should work.

@mik3

we should only have the flexibility to do what the hub can allow without bringing it to its knees.

Whoa, this is a very odd concept. You have a computer with finite resources, but a full Turing Machine nonetheless. There are many ways you can exhaust those resources. What, do you want us to do, just castrate it to protect you from yourself?

@mik3

I can deal with 350ms motion lighting, but the inconsistency and required hub reboots have drove me nuts!!!!

This is not normal. I don't have your hub, or know what you have running on it. I have 25 Motion Lighting instances running for the past 3-1/2 years and this is not my experience (and my home hub is my main development machine at the same time). There are moments every now and then when a light is slow to come on, but very infrequently. This could happen perhaps if the hub was doing garbage collection at that instant. This a not a usual occurrence. I don't have experience with required reboots. Now, I'm not dismissing your statements as being anything but real issues; we are constantly looking to find explanations for your experience. The one thing I can tell you is that it is very elusive because we have been unable to reproduce this behavior ourselves, and you'll have to take my word for it that we have and continue to try to reproduce it and identify potential causes.

There is a mismatch going on between power users' expectations and what Hubitat Elevation delivers, evidently. We didn't set out to create a platform for power users. But, we did set out to create a flexible platform that allows innovation and self authoring of apps and drivers. For goodness sake, every built-in app and driver was developed on Hubitat Elevation itself -- so that speaks to the objective we had. That people can come up with objectives that go far beyond that does suggest that it would be very cool if our software would run on a powerful machine. Problem is, that isn't a viable business model for us.

If what you need is to use Hubitat Elevation as a gateway connected to another system in order to get what you need from it, at least we made that possible for you. For the vast majority of our customers, that isn't what is needed.

[mik3]

@bravenel

These two are completely unrelated. For one, I don't and most users don't experience any of the slowdowns that a small number of power users report, so this is not really on my mind most of the time.

I wouldn’t just say power users.

@bravenel

Whoa, this is a very odd concept. You have a computer with finite resources, but a full Turing Machine nonetheless. There are many ways you can exhaust those resources. What, do you want us to do, just castrate it to protect you from yourself?

Let’s not generalize all computers. This is purely a suggestion. Is there a way to help put in safe guards when constructing rules? Maybe something to consider is all.

@bravenel

This is not normal. I don't have your hub, or know what you have running on it. I have 25 Motion Lighting instances running for the past 3-1/2 years and this is not my experience (and my home hub is my main development machine at the same time). There are moments every now and then when a light is slow to come on, but very infrequently. This could happen perhaps if the hub was doing garbage collection at that instant. This a not a usual occurrence. I don't have experience with required reboots. Now, I'm not dismissing your statements as being anything but real issues; we are constantly looking to find explanations for your experience. The one thing I can tell you is that it is very elusive because we have been unable to reproduce this behavior ourselves, and you'll have to take my word for it that we have and continue to try to reproduce it and identify potential causes.

I can help in this department. I’d be willing to ship my device to you directly to evaluate. I’ve gone through hoops with the help desk.

@bravenel

There is a mismatch going on between power users' expectations and what Hubitat Elevation delivers, evidently. We didn't set out to create a platform for power users.

Where is that exact division? What makes a normal user a power user ?

@bravenel

f what you need is to use Hubitat Elevation as a gateway connected to another system in order to get what you need from it, at least we made that possible for you.

Absolutely, and I have said on many accounts including other social media sites it’s a great product and recommend it.

But again, at the end of the day, Hubitat runs great with no logic serving as a gateway only.

I’m fed up and nobody including yourself can discredit the hub slow downs. I’ve rebuilt it from ground up multiple times following all your suggestions! I even wrote my own groovy applications in attempt to fix it.

For all I know, it’s my hub (over heating?). I would love to try another one to see! I tried to get a replacement a year ago with no luck. I was told there was no hardware issues.

[MRobi]

@bravenel

There is a mismatch going on between power users' expectations and what Hubitat Elevation delivers, evidently. We didn't set out to create a platform for power users. But, we did set out to create a flexible platform that allows innovation and self authoring of apps and drivers. For goodness sake, every built-in app and driver was developed on Hubitat Elevation itself -- so that speaks to the objective we had. That people can come up with objectives that go far beyond that does suggest that it would be very cool if our software would run on a powerful machine. Problem is, that isn't a viable business model for us.

One of the challenges the power users face when dealing with a local hub is the limited amount of resources. Coming from a platform like smartthings which is hosted in the cloud with an unlimited amount of resources. I'm sure this is why the question of "more power" keeps coming up.

I also understand that from a business stand point, investing 10's of thousands in development and production costs to build that more powerful model to sell maybe 100 hubs doesn't make a lot of sense. Although I think there may be more sales in this model than expected. A lot of consumers shop wanting nothing but the top of line model, whether they need it or not.

I do wonder if it'd be possible to sell a software license for these power users to allow them to run HE on their own system. Then if somebody wants more power, they can do it. It could be a support nightmare, but if it's designed for power users with a disclaimer at time of purchase that staff will not provide individualized system support when going this route, then the user would know what they're getting into.

[mik3]

@frmWink2Hubitat

I agree. Hubitat is better than every other “hub”. I mentioned home assistant to my mom “you trynna kill me, I got diabetes, raspberry pie will kill me”

So it’s wink, hubitat, or st and I’d say hubitat is the superior product

All of those solutions require babysitting. Which for me, is what the root cause of my anger stems from. I want a reliable system I can walk away from.

I've wasted to many hours on this.

I've found a prodcut which also includes it's own share of problems, but appears to be a hell of a lot more stable. Is that due to hardware? Who knows, all I know is I can finally FINALLY walk away from the system and not be like, oh wth, why did that take 2 seconds to turn on, oh wth why didn't that rule run right, oh wth, why is there errors in the logs again! etc, etc, etc....

Now maybe I'm giving to much credit to the product I'm using now, but it's soooooooooooooo nice to just walk away, and have a life!

[JasonJoel]

@mik3

Now maybe I'm giving to much credit to the product I'm using now,

As many of us have used, and do use, that product all I can say is - you'll see.... I have used that product for 5+ years.

If that system were so perfect and reliable, everyone would be using it in spite of price.

[mik3]

@JasonJoel

As many of us have used, and do use, that product all I can say is - you'll see.... I have used that product for 5+ years.

If that system were so perfect and reliable, everyone would be using it in spite of price.

I guess time will tell.

Put it this way, with the amount of effort that goes into maintaining such a system, expecially with a small family. I may just scrap the whole thing in the near future if it continues to require daily maintenance.

[JasonJoel]

Obviously that is a decision only you can make.

I would say VERY, VERY few people require daily maintenance on their Hubitat systems and that is not the norm.

[mik3]

@JasonJoel

I would say VERY, VERY few people require daily maintenance on their Hubitat systems and that is not the norm.

That hasn't been me for the most part. I guess it depends on if I care to look at why motion lighting was slow yet again. Did the rule fire, did it not, and why didn't the porch lights come on, was it a rule issue for me? etc, etc...

I honestly wouldn't be suprised, if my hub has hardware issues. With the amount of people that state, my hub doesn't do that makes me believe it's a hardware issue.

At this point in time, with 12+ months of working on this damn thing, there's always something to be repaired or looked at....

I have no patience anymore! I've reconstructed all my rules based off suggestions from Bruce and the community, and moved things over to built in apps, etc. I've done every damn possible suggestion out there! Have I made things better, yes, but not good enough where I can just forget about it and let it run.

It's become so bad that I dream about the damn hub! I'm so tired of it and struggling to break the habbits of constantly thinking about it now. lol! I find I need to actually put in effort to think about something else, something that actually matters!

For now, I run with no logic and apps, and let the other product manage all that. And you know what, it runs! It actually freaking runs and does a good job at it, and I'm lost because I don't know what to do if I'm not fixing or looking at this thing daily.

I wish I could get my hands on another hub that supposdly just works. Then again, I'm rebuilding once again!

[tja]

Reading this discussion people seem a little too focused on the network requests. The overhead from sending a very small payload over an already established LAN websocket connection (as in one of the tests) should be completely negligible. We're talking sub or single digit milliseconds (including serialization and parsing) at the most.

Basically, in most home automation situations sending data over local ethernet has little to no performance impact. Level of comfort, consistency, reliability and number of moving parts are way more interesting to look at. As a user, using NR instead of the built in apps is a perfectly fine way of doing stuff if you like it. It's the power of not relying on the cloud.

[mik3]

@MRobi

While sending over lan shouldn't introduce much delay, it should still be slower than not sending anything over the lan. Simply because that extra step of sending over lan does add ms to the whole process. BUT the opposite is happening. It's faster. So why?

Only the Hubitat team can accurately answer this.

[mik3]

@LosinIt

Why the code speak? What product?

Homeseer. I don’t want to market another product but since it’s been mentioned numerous times, I guess it doesn’t matter.

[plantucha]

@mik3

@bravenel

The one thing I can tell you is that it is very elusive because we have been unable to reproduce this behavior ourselves, and you'll have to take my word for it that we have and continue to try to reproduce it and identify potential causes.

I can help in this department. I’d be willing to ship my device to you directly to evaluate. I’ve gone through hoops with the help desk.

that seems to be a fair offer,
@mik3 just you can't expect that @bravenel will fix it for you
Hubitat isn't a repair shop, you have to understand that from 100 hubs sent like that probably just 5 gonna have legitimate slowdown issue, rest will be user error caused.
If you sending it back, make sure that is for research purposes, not to fix it.

[mik3]

@plantucha

that seems to be a fair offer,
@mik3 just you can't expect that @bravenel will fix it for you
Hubitat isn't a repair shop, you have to understand that from 100 hubs sent like that probably just 5 gonna have legitimate slowdown issue, rest will be user error caused.
If you sending it back, make sure that is for research purposes, not to fix it.

The likely hood of Bruce agreeing to this is slim.

My only issue is that I was complaining about this for the last year and had support requests open that demmed the product good, yet no matter what I do, I see constant inconsistencies.

Now I’m outside the warranty and the staff doesn’t believe it’s a hardware issue, there is nothing I can do.

Believe me when I say, I’ve rebuilt everything from the ground up multiple ways taking into account Hubitats recommendations of creating rules and also harnessing built in apps whenever possible

No matter what, inconsistency and slow downs.

So why only some people’s hubs? Like wth! That’s where I’m at.

I almost believe the staff is covering up quality control issues at this point.

So frustrated... urgh

[plantucha]

@mik3

No matter what, inconsistency and slow downs.

So why only some people’s hubs? Like wth! That’s where I’m at.

reason why they cant fix it it because they can reproduce it.
I bet they will love to have "Real" slowdown hub to fix it .

[bravenel]

A couple of things. Sending us your hub would be pretty much pointless since the issue has to do with its functioning within your home, with your devices, mesh networks, etc. There's just no way to replicate that environment.

If you want to rule out the hardware, that will be doable in the not distant future. I'd be willing to send you a replacement hub once the ability to backup/restore the radios is in place. If that fixed your problem, then great. However, I'd predict that this is not a hardware problem, and that moving everything to a new hub would move the problem with it.

I have zero visibility into your situation, so I'm not in a position to give much useful advice. If you have things that are connected by websocket, have you tried disabling those as a diagnostic experiment? If you have custom drivers, same question, have you selectively disabled those?

@mik3

I almost believe the staff is covering up quality control issues at this point.

We aren't covering up anything. But there are limits to what we can do as a practical matter.

[mik3]

@bravenel

If you want to rule out the hardware, that will be doable in the not distant future. I'd be willing to send you a replacement hub once the ability to backup/restore the radios is in place. If that fixed your problem, then great. However, I'd predict that this is not a hardware problem, and that moving everything to a new hub would move the problem with it.

I don't believe it's mesh related. Everything works great when only acting as a gateway. Everything is super responsive. It's when I start installing apps and the hub begins to start processing things is where I start to see hub slow downs and inconsistency.

@bravenel

I have zero visibility into your situation, so I'm not in a position to give much useful advice. If you have things that are connected by websocket, have you tried disabling those as a diagnostic experiment? If you have custom drivers, same question, have you selectively disabled those?

Yes, many times! I've removed all apps and custom drivers a long long time ago, yet still saw issues.

As the hub stands now, I have custom drivers loaded on it, and they run fine. No issues. As I said, I had a 3 week uptime for the first time, ever!

Let me ask this, and you basically answered it already. Motion lighting should be fairly consistent, no? Meaning, 9 out of 10 times the lights should come on around 350 ms. And it should remain this way over weeks of uptime, no? That's definitely not my case.

@bravenel

@mik3

I almost believe the staff is covering up quality control issues at this point.

We aren't covering up anything. But there are limits to what we can do as a practical matter.

After a years time, what am I suppose to think..... honestly, I've done everything recommended and as stated, wiping the hub and building everything from ground up, including using every single built in app where I could, but yet inconsistencies.

I'm so fed up with this, and more fed up when I hear "Oh my hub is fine, I never reboot". That statement on it's own frustrates me to no end!

[plantucha]

@bravenel

. I'd be willing to send you a replacement hub once the ability to backup/restore the radios is in place.

Jeez , man they just offered new piece.
what more you would expect?

[bravenel]

@mik3

I'm so fed up with this, and more fed up when I hear "Oh my hub is fine, I never reboot". That statement on it's own frustrates me to no end!

Look, I'm sorry you have these problems. I don't know what else I can say. If you think it's hardware, I will send you a replacement hub so you can check that out. But, I hate to see you pile on your frustrations by rebuilding your Z-Wave and Zigbee networks (just did this myself recently), only to find that you have the same issue. That would frustrate anyone.

If you wait a month, this can be done much more easily -- or you could join our beta group and try it sooner than that. PM me your hubUID and shipping address, and we can add you to beta and send a replacement hub.