If someone has a valid reason they need to downgrade to a version that is not on the list of previously installed updates, they can PM me or email to support@hubitat.com and we would be glad to provide a path. The latest version is always the most stable version released to date.
5 Likes
It seems to me that you're convinced that the z-wave issues you've encountered are caused by a particular platform version. And are unwilling to consider any alternative possibilities. Which is unfortunate.
FWIW, I had z-wave issues way back with platform 2.0.9 (caused by stranded z-wave devices) that would pop up now and again with with platform upgrades. Resolving those issues required getting rid of the stranded devices - but it took me over 6 months to accept that possibility. It would been smarter to have considered it sooner.
5 Likes
I'm not quite sure where you're getting that? I'm not the OP, and I'm not having zwave issues. I have been repeatedly affected by the random bugs that pop up with new releases. These do get fixed with hotfixes over the course of the following month after a major release, but I want a way to do targeted updates on my own timeline-- once 2.4.0 is out, I want to be able to update to the latest 2.3.x release once I choose to do so.
My bad - I thought you were the OP.
1 Like
Sounds like something they could do but if they allowed all of us to select which version we run, I think it would be a support nightmare. The only way it would work is for them to charge 10x more for a hub and I would be forced to go back to ST. That, I hope will never happen. I know never say never...
I just have to think with a lot of options we have to upgrade we all can find a path that works. Keep an open mind and we all do better.
1 Like
Oh, I remember those Friday nights when SmartThings would push updates with no way for me to prevent them to do it, or to go back to a previous version, if something went wrong with their update.
7 Likes
First of all, posting my exact device mix is irrelevant to the feature request here.
The premises of my request are:
- Core functionality should always work. As a specific example, I believe adding a z-wave node to Hubitat should be considered core functionality.
- There are many point releases that the changelogs show bugs being introduced to core functionality and not caught before full release. Over the past 60 days there are several specific examples of releases that do not add z-wave nodes correctly.
- While there may be an existing alpha/beta/stable process as pointed out in this thread, there appears to be a gap in that process that needs to be addressed.
- Therefore, an improvement to the current process should be made to increase the desired end-user outcomes: stability/reliability/assurance of quality.
As this thread has progressed, several other tenets are worth discussing as well.
As user statements:
-
A Hubitat user should expect more stability/reliability than alternative platforms
-
A Hubitat user should not be afraid to upgrade
-
A Hubitat user expects the hub to work for the user, not the other way around
-
A Hubitat user expects deep control/capabilities; ease-of use is key.
(i.e., Hubitat should put the power in the hands of the user, but provide an approachable platform for the prosumer market. The user experience should invite new smarthome users in, while at the same time allow exploration and maturation of the experience as user's needs become more advanced.).
My personal thoughts on reasons these should be true:
Most of the current Hubitat user base are likely either coming from other platforms where local control was a deciding factor in their switch and/or likely could roll their own from FOSS projects / others if they chose to, but selected Hubitat with an expectation of an improvement over those other alternatives. I propose selecting Hubitat indicates the user has an expectation of greater performance / greater reliability, among other reasons (e.g., privacy, etc.). I suggest Hubitat fits well as a "prosumer" device when compared to alternatives. Additionally, if Hubitat seeks greater market adoption, the more this market fit is embraced, the broader the total addressable market for this product.
As my own personal anecdote, while I already run many workloads across several homeservers and have spare Raspberry Pis lying around that I could convert to a smarthome hub, I selected Hubitat because I did not want to constantly intervene to maintain reliability of my smarthome. Having intermittent hiccups on other workloads where I am the primary or only user may be annoying, but there is near zero tolerance for any failures in my smarthome as the rest of my family has to interact with it on a daily basis.
Regarding the multiple comments on trailing by a major release, user-selectable target versions for upgrades, my own comment on a Stable channel, etc. Why should a user be expected to figure out which of these versions is stable, which one to use, which to roll back to, whether or not a given version is the cause of their current issue, whether a rollback runs the risk of an incompatible database or other issue, etc.? Does Hubitat's homepage promise of "Experience
Home Automation that is Local, Reliable, Fast, and Private" mean reliability is solely defined as compared to a cloud connected platform, or does it / should it mean reliability for all aspects of the platform? If I wanted to track to every single change on the git repo's 'release' tag, I'd go to a FOSS project. At least then I could evaluate the code first, if I chose to. The reason I'm here is because I don't want to spend all my time troubleshooting my smarthome. My smarthome should work for me. My smarthome hub is the focal point for delivering that promise.
The more the smarthome gets out of the way of the user and the gap between a thought like "wouldn't it be nice if..." or "I wish I didn't have to do this every day..." and making that automation a reality in the shortest amount of time possible should be the goal. Any distraction from that in the user experience inevitably will slow or halt adoption.
To answer the specific device questions anyways:
Z-Wave (54 devices):
45 Inovelli Switch Red Series LZW30-SN
2 Inovelli Fan + Light LZW36
2 Leviton DZ6HD Dimmer
2 Leviton ZW4SF Fan Controller
3 Yale Locks YRD226
Other:
2 Ecobee Thermostat
6 Ecobee Remote Occupancy and Temperature Sensor
5 TP-Link Kasa Plug Switch
4 TP-Link Kasa Outdoor Multi-Plugs
Pending another 15 Inovelli Switch Red Series LZW30-SN if I can actually add them to Hubitat without more issues.
Additional Z-Wave info:
24 devices with direct connections to hub
Neighbors range from 15-49
11 devices with unknown RSSI at the moment
RSSI ranges from -10 dB - 37 dB
RTT Avg: 50 devices at 0-100ms, 4 devices at 100-500ms
RTT StdDev: 0-50ms - 47 devices, 50-500ms - 4 devices, 500-1000ms 2 - devices, >1000ms - 1 device
Again, this is not what I'm talking about. On all the releases I named, there are issues adding z-wave devices to the mesh. This type of issue should never make it to a release considered stable.
This is exactly in line with my point. +1
Now how should we avoid that sentiment altogether?
3 Likes
So glad I’m 99% Zigbee 
1 Like
This presumption is incorrect. Because your assumption is that platform updates break zwave functionality, which isn’t true.
4 Likes
Thank you for the feedback. I will be sure to share your message with the team. If you have specific questions about an item on the release notes, please create a topic for that item. There have been no known bugs introduced in the core Z-Wave functionality that had to be remedied immediately after a release, via a hot fix.
Casting a wide net of assumptions invalidates your otherwise reasonable argument for greater flexibilty and more stable releases. Also your argument poses a detriment to those who have enjoyed rapid development of Hubitat platform, that has been on a fast track of improvement since four years ago when it launched.
8 Likes
