Yes there are some lacking features that are opinions. Like Https config options. Then there are things are facts. Like having the dashboard app installed allows the cloud control endpoint to control any device on the hub regardless the device being included in a dashboard or any dashboards being cloud enabled. While the likelihood of attack can be small any user who ever shares a link to a dashboard is opening up the potential for full device control.
Until you sit down and read through the forums. This really isnāt pointed as as something you shouldnāt do...Because who would share a dashboard with a guest or a contractor or anyone they donāt trust 100%
I have seen these exact zwave issues and have been told my mesh and devices are the problem. It has limited my ability to perform specific automations that require more than 2 zwave devices.
But to say the hub does other things well is not an excuse for these shortcomings, and I feel thatās what the community does best. Rather than hold them accountable and say hey this should be fixed you say āmine worksā and that they canāt be expected to solve all the problems and we want more features not fixes.
Bruce will pop in and tell me that a company that made all the right choices for me to buy the device, should be enough and that fixing my complaints isnāt the right choice to convince the next person to buy a device.
But I will say, itās enough that I donāt recommend them and I donāt plan on buying the C-7 less than a year later to get fixes that shouldnāt have been problems in the first place.
No argument at all. And I agree with the dashboard part - it is an interesting issue. And what it does, is what it does - that is a fact. While I never shared dashboard links (when I was using Hubitat dashboards), I will admit I never appreciated the full potential of doing so either - past access to the page that was intentionally shared.
I do say that often, because if it isn't broken for me of course I would rather them spend engineering time adding new things I will use, rather than fixing issues I don't have. Is that self-serving? You bet! I try to push them to fix things that impact me, same as any other user.
I have spent a good deal of my personal and professional life stating that the common person deserves just as much security and privacy as the techies at the top who know what is happening. Those people are the most vulnerable, and when you have vulnerable people in a share platform, you too can become a target.
Hubitat does remind me of a lot of other projects in that the community has its own attitude. But overall the community is very helpful and the massive amount of community-provided software is wonderful.
I have seen other software projects were I immediately regretted posting anything at all. You'd be told to read the docs, but the docs were years out of date, with the current solution to a major issue being buried on page 203 of a thread with a misleading subject. Pointing this out didn't make you any friends. Thank god, this place is not like that, because the forum seems pretty essential to learning to use your hub.
I hope everyone keeps posting when they can reproduce problems. The squeaky wheel doesn't always get the grease, but ya gotta keep squeaking to have a chance. I appreciate the efforts of our various rabble-rousers.
Aveva does this to me every time I call for support on their TIS/OMM software. I never call unless I have already exhausted my knowledge and documentation, but it's very off-putting. If I had a choice I'd just go with a different software package, but they are so entwined in our business now I couldn't change it at this point if I had a choice.
We haven't forgotten about this issue. It is being worked on. Requires restructuring Dashboard's security design (obviously). I don't have a date yet for when a fix will be released.
I agree. We are working on a number of things to improve various aspects of the hub. At the moment there is a large focus on Z-Wave, and this has been consuming most of our effort for some time. We have made progress recently on overall hub performance, dealing with issues that caused some hub slow-downs, and mobile app functionality and reliability.
There would be no excuse for pretending there aren't areas that need improvement. We do strive to make the hub the best available, but by no means think we're where it needs to be.
This was more a comment on the community not the Hubitat staff.
Any official answer for this particular delayed Ack issue? Would there be a fix for c5 and earlier or is this not a ābugā that would be fixed given the maintenance status of these devices?
This seems to very clearly align with what I'm seeing on my C-7 hub--any time there's more than a tiny number (like 1-5 devices) activated within any less-than-long time period, things simply don't work well (devices don't see their action request, the hub doesn't get the current state back, etc.).
I don't have a "Zniffer"--and it seems less that exciting unless I want to be a full-on Z-Wave developer (I'm way too busy with coding tasks at work for this now!). Thus, I can't actually see the super deep details of what's going on in the mesh.
But, given the number who DO have them, has there been ANY progress in sorting out what might be causing these storms? I keep my fingers crossed that the HE staff will look into and fix this, because this is THE single biggest issue I have right now.
Aside from that, I am incredibly stoked about my C-7 hub and all the cool things it can do.
You know, it is hard to tell. I will say that on my production and development c7 hub I have not been seeing easily reproducible storms. At least not on any kind of regular frequency that makes it easy to troubleshoot. And when I do see them now they are typically short-lived, which also makes it hard to troubleshoot from my end.
I did see them more often (and they didn't always recover on their own) before a release or two ago, though. My guess is that habitat continues to improve the radio or application layer interfacing, which makes it a little better each release. Hard to know for sure though as those type of changes don't make the release notes.
I do believe that they're continuously working on improving radio* stability though, so I expect it will continue to improve over time with future releases.
And before another pedantic person like me chimes in, by radio I really mean radio, application, queuing etc. The whole data chain.
Well. I excluded and re-included nearly all my S2 devices with no authentication and tied the "new" device numbers into all my rules. About 10-12 hour later, I guess I'll see how things work.
I took out most of the extraneous refreshes and delays--so I can see how things do normally.
My "Group" actions certainly seemed more stable this way.
(My door locks are S0 or S2 Access Control; One light is S2 Auth, my Ring G2 "contact sensors" are still S2 Auth--I think that's about it).
Overall, I believe things are markedly improved, but not perfect.
My "group actions" seem to be generally much more successful (although I noticed a few things kicked off during my "wake up and turn things on" scripts that didn't quite work). I think I had one "hub to device" action that failed when I went to bed, then got up, then went to "work mode" and I suspect that there were 2 things that didn't work properly because the hub never received the status update from the devices.
So, yes, I think going to unauthenticated was a notable help--but I may have a bit of additional tweaking to do.
Note: I've got some bodacious RM scripts, so that may be part of the issue. I'm trying to also reduce the number of script actions that are trying to take place simultaneously. I'm shooting in the dark a bit, though, because I don't have tools to point me to what is happening (a bit of trial and error, with some decent progress).
Note 2: When I re-included all those devices, I also REMOVED a number of "refresh" and repeated actions that had been necessary before. I am sure that things are working better than before--because they are working better now without those actions than before.
One big help on my "I'm home, turn things on and such" actions: I was looking through the logs in gory detail and made some significant adjustments to the order I was doing things and added some delays to keep the various actions from all firing at the same time. That was a "busy time" for triggers and events, so I tried to streamline the actions (garage doors open, entry door unlocks, entry door opens, garage doors close, entry door closes, system disarms, lights are all coming on, etc.).
Good to hear. Iām probably reverting back to ST. It was never this slow and now that Iāve switched everything to zwaveplus it should be even better.
I would say wait until 2.2.4 and then see if things still are broken. There are supposedly some large changes and improvements with this upcoming update.
I don't know what the timeline looks like for this update (and I have no inside knowledge) but I suspect it will be out in a couple weeks just going by the past history of updates.
This morning I presumably had a storm after at least a week of no issues other than devices randomly dropping to 9.6kbps. Many FAILED or NOT_RESPONDING devices. Battery powered motion sensors continuously triggering according to logs. I restarted and repaired individual devices. Working OK again. C7.
And I agree with the dashboard part - it is an interesting issue. And what it does, is what it does - that is a fact. While I never shared dashboard links (when I was using Hubitat dashboards), I will admit I never appreciated the full potential of doing so either - past access to the page that was intentionally shared.
