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!
