Reliability issues and firmware updates

If I can give a shout-out to the Hubitat team, I am continually impressed by the design of this system. Distributed systems (which a smart home is, by definition) are HARD. And not hard in the sense of "oh, they just need to be clever enough", but hard in the sense of "the CAP Theorem fundamentally limits the guarantees that can be made by ANY distributed system, and there will always be times where you must choose between consistency and availability."

And when I say that Hubitat gives us enough rope to hang ourselves, that's actually high praise. That's the reason I'm invested in Hubitat, and not just pairing lights that "Works with Alexa".

1 Like

Regarding browser being left open and the recent change - what about dashboards? Do they slow down the hub?

If you have 200 outlets all doing power monitoring, yeah, that will grind...
A normal dashboard, no shouldn't slow the hub.

2 Likes

But only if you're actively looking at the dashboard that has the 200 things?

If it's running in a window somewhere, doesn't matter if it's being actively looked at or not.

4 Likes

@mike.maxwell

That's the Hubitat/Dashboard version of - "If a tree falls in a forest and no one is around to hear it, does it make a sound?"

4 Likes

I think what @brianwilson meant was,

2 Likes

That would certainly freak me the heck out; if I looked at the dashboard and everything slowed down. 'cause either I have become one with the machines or they have become sentient.

2 Likes

Not only sentient but also very self conscious. "Don't look at me while i'm energy monitoring!!!" LMAO :rofl:

2 Likes

Omg I just laughed out loud. You are killing me Ryan.

1 Like

This was my case too, for this reason I created a second z wave mesh with a couple of iris plugs z wave repeaters and the locks. The same iris plugs are connected to my other hub in zigbee... the lock sometimes gets out of sync( maybe once in 2-3 weeks) but usually is fine.

Every once in a while I come up with a good one.

3 Likes

15 posts were split to a new topic: Why Hub Link

Hub Link was developed originally, as @Cobra and @Ken_Fraleigh point out, to provide a way to integrate devices on ST hubs into Hubitat. This is something I did during my own transition from ST to Hubitat (pre Hub Link), in days when we didn't have drivers for many Zigbee devices. It wasn't embodied as Hub Link and the ST version of Link to Hub until we'd had considerable experience with how to do it. Moving Link to Hub to the Hubitat side came later, sort of as a "why not?" thing. Later still, we added the ability to control devices in both directions.

We have been looking at better ways to link multiple hubs, to make such linkages more efficient. Mike figured out pretty early on that ZLL bulbs were hurting his Zigbee network. We had encountered these issues from the very beginning of Hubitat's existence, but it took time to fully understand the problem. The idea of segregating bulbs to a dedicated hub came later, and proved to be a good path to resolve those issues.

There are other issues that are clearer now too: A cloud based HA system effectively has unlimited resources, or at least appears to have and designs assume that. A local CPU based HA system has finite resources. Attempting to put the former onto the latter is bound to break at some point. So, thoughtful design of a local HA system is required. Running automations off of thousands of events and pushing logs to other systems (including the cloud) is bound to not work very well. There is a class of such misfit ideas that should be recognized as paths not to go down, or at the very least as paths to go down with your eyes wide open about the possible consequences.

I have said now many times that the key to success with home automation is to follow the KISS principle. Many users are not satisfied with that approach, and seek something complex. As we design and install HA systems ourselves, our objective is to elevate the living environment where the system is installed. Such designs do not require complexity.

HA systems are each unique. The RF environment is unique. The mix of devices and the mesh networks are unique. A device that works perfectly in one location may not work at all in another location. A device that works in one system may not work in a different system. The discussions that have the predicate: the device works fine on X but not on Hubitat, therefore Hubitat is the problem, are pointless. The opposite is true in many cases as well, that users whose systems on X didn't work, work great on Hubitat (my own home being a case in point, where my WAF was in the "rip it out please" zone before Hubitat, and now is in the "I love it" zone). We aren't here to deny responsibility for problems that exist, nor to accept blame for them either. We are diligent engineers applying ourselves as best we can to the problems we are aware of. It's our human fallibility that we will make mistakes, or say things that don't prove to be 100% right.

Thanks for all of the support you guys give us. We struggle with the criticisms and complaints, as anyone would. Onwards!

34 Likes

Well said. Look at it this way. Complaints show you have lots of interested customers and shows a healthy business. Us complainers are the few compared to the many but a forum with activity is always a good sign of life.

3 Likes

Thanks Bruce for adding clarity.

Yes yes!

4 Likes

Probably this is why my system works, I don't do this...

6 Likes

A post was split to a new topic: Driver needed for Aeotec Z-Wave Plus Reperaters