Why didn't I think of that? Lol
1 Like
I’ve been installing them as soon as they are posted. Occasionally there is an issue but it gets corrected quickly.
1 Like
I install right away but more recently these updates are taking away features that once existed. One example is that back in August there was a new HE release that would no longer allow you to add z-wave security with "none". Instead you can only add with S2 unauthenticated which I believe is not the same thing.
Yeah I’m going to go ahead and say that’s not accurate.
Yeah this is inaccurate. The prompt changed, but you can still click skip and a S2 device will join without security. I just joined 2 devices last week utilizing the skip button.
3 Likes
This in fact did happen in a release and you can refer to this thread/post if you want to read about it:
Maybe it was reintroduced in a later release but that doesn't help me for devices that I've already added when adding with no security was not available at that point in time.
This is behavior for a single device, whether a device firmware bug or an issue on the Hubitat side I can’t say. But that isn’t an example of a feature being removed.
In fact, you’ll notice I commented multiple times in that thread.
Here are two.
Here’s another where staff mentioned looking into it as a bug.
Like I said, I’ve joined multiple device, utilizing no security and the skip button successfully over the last couple of months. In fact, I just joined a zen26 last weekend without security. So pretty good sign the feature still exists.
My goal isn’t to argue with you, you are stating something that isn’t accurate and I just want to correct that for anyone who might read this thread.
1 Like
Whether by design or due to a bug I'm not able to utilize a feature for my Zooz devices.
Since the update I recently (September I believe) added two zen 27s and was not able to add with no security. So the feature is not available to me.
This was not YMMV before the firmware update and now it is. I'm just pointing out why it may not be a good idea to update right away which is what the OP is asking about.
That’s fine to watch out for bugs and I think it’s reasonable to wait some amount of time before updating, but what you’re saying is at odds with your original statement. A bug, regardless of who is at fault, is not an example of a feature being removed. Further, you’re suggesting multiple features have been removed in your original message, but you certainly haven’t provided examples.
Either way, I don’t have anything further to add. I’ve provided enough clarification and detail for those who follow to make up their own mind. Good luck!
3 Likes
As someone who was over 100 smart devices (zwave, zigbee, Lutron, Hubduino) and also has over 40 RM rules, 5-10 simple automations, button controllers, and dashboards. Plus a variety of other apps (both built in and custom), I have never had an update break any functionality of my HE.
The way I figure it, there is probably around a million things that could go wrong in an update, on average they find only 2-5 things that go wrong. My hub probably only uses 10 000 out of the million different ways a device or automation could be structured. Odds are that any given update will have no effect on my hub (other then providing me with new and improved software to create automations, while all my existing stuff still works). But eventually I imagine I will have one or two rules or devices stop working after an update, no big deal as these are typically fixed within a few days.
I update as soon as I see an update available.
2 Likes
I think we're starting to get into semantics here. First of all I never used the word "removed". When I said an update was "taking away features" I mean that the capabilty is no longer available. The only thing I care about is that I'm not able to do what I did before.
I'll update my statement to "took away a feature" (singular form). Or for better clarification an update "made a feature incapable of working as intended for my device and is currently being investigated so that it can be fully functional in a future update ".
First, I don’t have this device, and haven’t added any device in months, so I don’t know if the inclusion feature you need has changed or not.
However, to address your stated need, you should be able to roll back to firmware 2.2.8.156, the release that was out in September, do the inclusion, then roll forward to the current release (2.2.9.131) that may be missing the inclusion menu you want.
I've been updating the betas with no problems, knock on wood.
I have a feeling that there could be problems if you wait too long to update.
A perfect example of the process -
Even back in the ‘90s when I was working on PCs, if a BIOS update was available, I’d grab it. Same with any software or firmware upgrade. It’s not like these were tested for a few hours then we are the guinea pigs to sort it out. Hardly. Beta testers go through these updates first. There will be some updates for the update, but with HE that is rare.
Consider Apple iOS 15, 15.0.1 and 15.0.2 and this is from one of the largest companies in the world. Their updates are tested by thousands before being release to the general public and they still have issues.
I have yet to experience any issues after an update with my two main hair pulling systems, Hubitat Elevation and Wyze but I don’t go deep into everything HE can do. Mostly simple rules and automations.
I actually bought a Zstick which I believe is capable of adding devices with no security. But if that doesn't work I will probably try exactly what you've suggested.
So I tried adding via the normal pairing process and it looks like the issue was fixed in a subsequent firmware update.
I wait when a new release comes out. After a few hot fixes I read what kind of issues people are having and if not too severe or I dont believe it will effect me ... I update..
After many hotfixes are out I update pretty regularly for the house I am in. For the other house that is empty I don't update that regularly in case I run into issues.
@TomG I have to disagree. As a young man, there WERE tests done by true 'beta' test sites before anything went out. as the speed of development accelerated, the user community BECAME the guinea pig. And they liked it. Guys signed up for being beta testers to get new code as quickly as possible. and as thing continued to evolve, the internal test groups died and external tests became the norm. now, at the push of a button you just say 'yea, I'd like to test the beta code' and viola. you work for them. And Apple is completely reliant on the community. Heck. lets just be honest - even HE is currently, actively looking for free labor ala 'beta testers'. Oink.
1 Like
Who’s not being honest?
Companies like apple and Hubitat offer public beta versions of their software, and people who love being on the bleeding edge happily agree to use it and report on their experiences (as you yourself pointed out).
3 Likes
I manage all the betas for my software company that a couple hundred thousand clinicians use every day. As you can imagine, pushing out any functionality to non technical users can be a challenge and we definitely wouldn't have made it this far if we were relying on end users to be guinea pigs.
I don't see anything different with Hubitat's beta than what we do except perception.
Clarity from the organization can reaffirm confidence in betas and the product overall by dispelling myths/perceptions about what is/isn't tested and how.
We have a dedicated QA team that does manual and automated smoke testing.
Solutions are Alpha tested in house by our own BAs and QAs. Unfortunately, depending on the solution, Alpha testing will only get you so far in fake environments with fake data and sometimes the only way to TRULY test it is on a live connection.
Solutions are presented for beta and we ask for volunteers (if we don't already have a list of volunteers clamoring for it for the last year)
We enable features in their environments and let them beat on it for up to 90 days.
If no showstopping issues, proceed to general availability as scheduled. Report bugs/fixes as needed. Not all bugs will be resolved at go live. Some will still be on the backlog or will be in the process of being worked or deemed too unimportant.
When we go GA there will ALWAYS be bugs that we didn't find in beta.
This is where end-users can feel like THEY are the guinea pigs. If you did all this testing, why are there bugs? Did you not test this in real world scenarios? Do you not have quality people?
The reality is every customer's environment is configured differently and has different workflows as a result. Because of these variances, it can be difficult to pick up on all the bugs in beta.
Who helps the most:
Our bread and butter beta partners that raise their hand on everything, give great feedback, and identify bugs before we do. Sometimes they are large enough to have their own IT resources. Without these people, our product would have WAY more bugs at go-live. To me, that sounds like the people in this thread who are the early adopters, gluttons for punishment, and want the new new all the time.
Larger volume customers: because of size, they can often detect problems before smaller customers because it impacts them faster. They also have organizational workflows/challenges that we simply can't account for in every testing scenario.
So perceptually, yes I can see how it looks from the casual end user, but I'm sure there's a lot more going on behind the scenes.
If hubitat could post even just a PPT slide with a basic flowchart (without getting into the weeds) of basic steps functionality and releases go through from a process perspective, it can help provide clarity and give confidence to users who see multiple updates or have apprehensions about a bad release (bad releases happen even for my company).
Once customers became actively engaged with our beta process and knew what to expect we suddenly had a greater volume of quality volunteers. We have to turn folks away on every beta because there's just so many volunteers it becomes unmanageable and unscalable for our lean and mean company. This visibility can help with customer sentiment, not just for beta partners but for those end users who find a bug 6 months from now and say "didn't you test this?"
Edit:
One thing I forgot to mention. We release every single month. THAT release is not beta tested. It is QA tested and certain features or functionality in the release may have been beta tested but we simply don't have the time to beta test every release with 4-5 week dev cycles.
The exception is to our mobile app. We DO grant a test flight version of our mobile application to users who want it up to 6 days prior to release. The reality is, most end users don't want it because they are afraid of new bugs. We force customers off anything older than 2 versions behind to keep QA overhead lower.
3 Likes
