This isn't a rant so much as a 'I wish my hub ...'.
My number one feeling about my hub after the years I've toyed with it - stability.
To me, a hub should be focused on that first, dashboards and external connectivity have no important to me personally. The sales point 'keep it local' seems to really not be important anymore.
Towards stability - I know exactly what is about to come my way comment wise - doesn't change a thing for me. Towards that end - wouldn't it be nice to have:
a HUB provided inactivity monitor?
A report that says 'this device has poor communications - you should consider blah blah.
a report that says 'these devices are HE drivers - so we really got them handled - these other devices are relying on 3rd party drivers - your risk blah blah.
autosensing devices that had died too many times. if some device has fallen and had to be re-added 5 times in 6 times, flagged.
a cleaned up 're - add devices'. Adding devices that are already on your network still are hokey in the 'discovered existing device' screen.
This is what I think should be obvious stuff - but thats just opinion. What did I want for $99? but still - my feeling is apps are user supplied - and they evolve etc but they aren't core. the inconsistencies of devs has gotten too wide - No standardization.
Eg; I have at least 6 device drivers that have 6 different 'warn, debug, info, text, decription, timeout' toggles. every dev does it different. and a few HE devices drivers arent' any more consistent.
a clearer path to tracking sources of troubles. being told 'send logs' may work on one-off's but the general steps to locating a problem are as varied as the numerous driver logging toggles.
I know there is no simple way to approach much of this, but the farther this goes on, the worse its' getting and the feeling of DIY is growing not, disappearing. There. I said my piece.
That has been and will always be the top priority of our engineers, period!
On the contrary, we are glad to see that more companies realized that keeping it local, cloud free, is the best way to deliver a reliable smart home experience. Our belief is that cloud independence is the only way to ensure unparalleled privacy, reliability and performance. With that being said, some users need to be able to control devices remotely, and for that, we offer free cloud interface to allow users to access devices, rules and dashboards remotely.
Your wish list is nice to have, I admit, but think about it for a moment. Without centralizing data from all users to be able to identify those patterns, and to screen each hub for those patterns, it is impossible to build that knowledge base. And data centralization goes againt the privacy of our users that most of us desire so much.
Hhmm. Not sure about that.
If I have things running via the internet and I lose internet connectivity, then things would be screwed up.
I want things to keep working so for me keeping things local is vitally important.
Obviously this is my requirement and others may see things differently.
Had an Xfinity outage the other day....a boat load of pre-dawn automations just churned along as necessary. God how I appreciate that where plant and animal are concerned.
As far as stability, I'm scared to death to leave one C-5 that has been operating like it doesn't seem to know that it lives in hellish conditions.
My experience across a wide wide variety of devices is that "keep it local" is absolutely necessary for the stability and performance you crave.
No outside software system or vendor has proven itself to me, and none of them can be trusted when their quarterly earnings statements are on the line. Not even the richest companies in the world: Amazon, Apple, and Google have all failed on me, with no recourse but to just wait and see if it works again the next day. Alexa sometimes decides that it only understands my fans in terms of percents, but the rest of the time, it only understands them in terms of "high, medium, low, off". Why does it occasionally do that? No way to know. Google sometimes decides that my Chromecast devices exist but every request times out. Why? No way to know. My Apple home stuff is maybe the most reliable of the three, but it occasionally decides that I am leaving and re-entering my home geofence 120 times per minute. I assure you, I was not!
Local is the way to go. It's the core ingredient of stability and performance.
This statement conflicts with itself. External Connectivity has no importance, but keep it Local isn't important either? What are you, railroad manager? If you prioritize everything (or prioritize it all the same) then you get the least desirable result. FWIW , I think external connectivity (while in some instance is necessary) adds to instability. To that end, that is why I keep all the cloud dependent devices on their own separate hub,
What Hub does any of this out of the box? Maybe HA, with of a lot of tweaking and coding.
On this one in particular, there are a number of devices where the 3rd party drivers (often supplied by the manufacturer) are superior to the HE drivers (Zooz and Inovelli come to mind)
Primarily. I do have some cloud stuff, Ecobee, Rachio, Tesla, and they are all kept on a separate hub from my local devices and processing. The vast majority is local, and I tend to focus on local first when looking at new devices. My priorities are Stability and Privacy. Stability is enhanced by using known stable devices that work well together and not mixing a lot of different manufacturers. Seems a lot of people want to try a little bit of everything, then get concerned when things start to go wonky.
Generally Speaking, I have A LOT of Zooz, Ring, and Inovelli. I'm phasing out Hue, Innr and Sengled (notice a pattern here? Zigbee is going away). I have Nanoleaf (Matter over thread) and Aqara in beta testing. Nanoleaf is doing well after a rough start. Aqara is doing ok for the Camera (though not exactly habitat related), not thrilled with the motion sensor. I've done some experiments with Aeotec, they are charging for a name, as none of those devices I had worked worth a darn.
For you or do you think that as a whole? Just curious. That said For me Hue has always been stable with the bridge. I have some go lights I absolutely love. At this point my system is is 1/3rd z-wave, 1/3rd zigbee and 1/3rd clear connect. I have a smattering of wifi stuff (nanoleaf, rachio, weatherflow) but that's about it. Aside from having to replace the occasional battery, things have always been stable for me. And boy do I like to play with the odd piece..lol
Oh, very definitely for me. I have the same opinion of Zigbee than many have of Z-wave. it has always been flakey for me. I managed to find some stuff that works ok (thats what I have left now), but it's gotten to the point that the mesh is so small I would need to buy more devices to support it (specifically my furthest out Hue Motion Sensors). If I need to my more devices, then I figure I should just go ahead and replace them with Zwave LR sensors . Now that I have had the Hue in service for a while as well as Zooz, I don't find the Hue to be much if any faster than the Zooz sensors. In fact, my Hue outdoor sensor frequently has a substantial delay or fails to trigger all together. The plan is to replace that with a Zooz ZSE70, replace the Hue Indoor with a Zooz ZSE18 and eventually replace the 3 innr Light bulbs with Nanoleaf Elements. The Innr bulbs are the most reliable Zigbee device I have had, since they are all together in one lamp and fairly close to the hub they really don't need a mesh per se.
I do have a Hue hub, and for a while I had to run the sensor through there until I figured out you had to add them to the hub before any Zigbee 3.0 devices (the innr bulbs). Essentially build the mesh backward in my case. I didn't have that problem on the C7. When I first started with Hue I got a bad sensor and they tried to get out of the warranty claiming it was damaged by pairing it directly to Hubitat. They eventually did honor the warranty (about three months later), but that kind of put a bad taste in my mouth for their products. When they changed and started requiring a Hue cloud account to use the hub and connected devices, that sealed the deal for me to push them out. I had bought a hub just to prove to them the sensor was indeed bad. It has been disconnected for at least six months, probably longer.
As far as Zigbee going away as a whole, I don't know. My causal observation, and honestly I haven't looked super deeply into it, is that it seems a lot of manufactures are just slowly dropping Zigbee in favor of matter. It's quite possible I'm mistaken on that though. Since I'm moving away from Zigbee I'm not following it too closely either.
I would say right now, I'm about 2/3 Z-wave, and the rest a mixture of Zigbee, matter, Wi-Fi, and cloud based. I think the only Wi-Fi stuff i have left is my Ecowitt weather stuff. I tried Lifx and Shelly, I wasn't happy with either one. Lifx was the better of the two, shelly was just a hot mess, constantly had to go in and rediscover those. The Lifx bulb I was testing tended to drop off and disappear if it wasnt used on a regular basis. where they shelly would do that as soon as you turned it off.
It seemed clear enough to me that he wants stability and local control. He’s concerned that Hubitat has lost that focus over time.
I completely disagree with the OP that they do not sufficiently prioritize stability and local control, but it is an internally consistent viewpoint to have.
Humm I'll look at it again. I read it to mean that local control was no longer as important to HIM. It is quite possible I misconstrued his meaning. I agree with the sentiment that stability should be a top priority. There is no reason you would have to sacrifice stability for local control. in fact, I would think local control should inherently make things more stable to begin with.
I would agree with you. Given that it is a constantly evolving platform there is bound to be a degree of added instability as things change, features are added, updated, deprecated, etc. and that is not a situation unique to Hubitat. Seeing all that happens in the beta group, and how much work goes on behind the scenes before something is officially released made me appreciate how stable the final release really is. I also recognize that everyone has a different and unique system, operating environment and set of needs and wants. There is just no conceivable way that every error, mistake, etc. could be caught in beta before public release.
Do I think the focus on local has waned? No. but I do think the Hubitat user base has changed over time as systems like Wink effectively died off, or Smart things made changes that ran people off. People came to Hubitat and want to still be able to use their existing devices, many of which are cloud dependent. They have simply, necessarily responded to market conditions, while I believe, staying true to their core value of local first. They easily could have done what others before them did and embraced the cloud/data mining model. It surely would have been more profitable. I have not seen anything where anyone is forced into any kind of non-local use situation. If you don't want to use Remote Admin you don't have to. There are some compelling reasons to use it, but there are ways around most of it. For instance, I only use it on one of three hubs. The one with my local devices so I can get the Z-wave radio cloud back-up. I don't even use it to access the hub, I still do that with Wireguard. All my other hubs I just use Wireguard for remote access and local backups.
If Hubitat was a bigger company I might share the OP's thoughts, but given the size of the organization, there is simply no way they could meet all the needs and wants of their user base and still focus on stability. I find the community developed apps to be one of the convincing arguments for the platform. They are mostly well done and well supported. I do agree standardization would be nice to have, but not everyone thinks in the same logic. My fear is that official standardization could have the effect of pushing developers away if they can't do it how they see appropriate (an actual developer might be able to speak to that better than me). Maybe things have evolved to the point where it's necessary? I don't have an answer for that.
The downside of community developed code (to use a generic all-encompassing phrase) is when someone moves on, and they either pull their code (which honestly, I have rarely seen happen) or they leave it behind no longer supported, and people are still using them. I have seen that happen and it is always a risk you take using community developed code. I myself have avoided some apps and stopped using others for this reason. You can't force someone to stay and support something if they don't want to (If @thebearmay leaves, we'll need to send out mercs to drag him back!). I know there have been a few where the original developer moved on, but they handed it over to someone who is still here or opened it up and someone from the community ran with it. Hubitat Package Manger and @sburke781 's Ecowitt Drivers are two examples that come to mind.
Would be great if a mis-behaving device was auto excluded in some way / some how.
Like if it is "spamming the network" or acting up. < HE would auto disable it.
Before it could / would take down the hole network. ( seen a few people say this happens. )
Hubitat cannot disable a device at the network level. Disabling the device on the hub disables driver code from running, but it has no control over what it does on the network. Z-Wave generally requires a manual exclusion process to be physically initiated on the device, and some Zigbee devices also require manual reset, to name a couple complications with this idea (beyond the fact that these heuristics better be accurate or no one will like a device randomly disappearing).
This statement incorrect .. I am sorry to say ..
HE has this bult in ... there is clearly a disable button on the devices table.
bad device HE checks it. < seems kinda simple.
The Disable column on Devices 'jams a wedge' between the driver and the Z-chip (or wan/lan) such that the hub does not respond. It has zero effect on the Z-device to Z-radio traffic.
Devices table shows the drivers associated with physical devices. A mesh device communicates with the chip, then the chip communicates with the hub via drivers. Disabling devices on Devices table stops the communication between the hub and the driver, but it doesn't stop the communication between phisical device and the chip.
I take it you are a "local-focused" user, which is good.
