REQUEST: "Slight" Change To Hubitat Policy

Yes that included the 5 previous days and 13 downloaded "myself" ones that I save offline BEFORE each update.

Here are the release notes prior to my update the only "Warning" did not pertain to me as I had no RM rules that had delays.

Prior to this I observed and reported this issue.

So I performed the update, 5 hours later (when the timestamp bug finally caught up to the ACTUAL time) hub is locked up completely. no reset ability, no restore, ability, nothing, Having all those database backups was a waste of time in this scenario.

Dont know if it's been written up before. A nice article detailing when we should consider soft or hard resets, backup restore, etc and methods would be appreciated.

I'm even more confused to why a platform version would be rolled back and NOT the database to match with it......I don't understand the purpose for separating out this "restore" capability. Hopefully documentation could explain that as well.

Suppose you install a hot fix and it breaks something you use. You could roll back to the prior release (same major release version) with no need at all to change your database. Needing to roll back the database is rare in these circumstances. This is used, for example, by our beta testers, where it is known that not every release is going to be bug free. The whole reason there are hot fix releases is because of bugs we didn't catch during testing. As for major releases, the same logic applies except in those instances where we explicitly warn about the need to roll back the database if the platform is rolled back (due to incompatible changes). These instances are rare.

In my own experience, I don't think I've ever had to roll back a database coincident with rolling back the platform software. I've rolled back the platform software when a release has broken something I need, or creates a nuisance I don't want to work around. Then I wait for that problem to be fixed. I can't say that I roll back the platform very often, but it has happened. Most of these instances occur during alpha and beta testing of platform updates.

1 Like

@waynespringer79 I honestly want to say that I’m sorry you’re have trouble right now. That sucks when you decide to do an upgrade and it doesn’t turn out as expected. Worse when the rollback doesn’t work as expected. I’ve been down that road far to many times with just about everything electronic that had such capability.

Having said this, I’m enjoying the most stable hub I’ve in quite some time and I’m on .122
Chromecast Integration (beta), @dan.t ‘s Homebridge support and Cast-Web API are installed. I would have suspected one or all of those previously. It really does seem the database issue has been resolved. So I hope you get up and running soon, then find what the cause was. It doesn’t seem to be Hub platform related, at least not for me.

3 Likes

There were specific issues in 2.1.1 releases prior to build 122 that in very rare circumstances could lead to the problems the @waynespringer79 experienced. To the best of our knowledge only 2 hubs had this problem, and it arose from a perfect storm sort of circumstance. These issues have now been fully resolved.

See this post: Update to 2.1.1.122 Important

4 Likes

This coincides with my experiences also, I keep several backups of my DB, usually anytime I've made substantial changes to my rules and/or added or removed devices. With the exception of the bug prior .120 that was causing the "soft reset" I think I have restored my DB maybe 3 or 4 times in over a year (and I'm a beta tester and have been known to find a lot of bugs due to my "complex'" rules.

I have done platform rollbacks more frequently, usually during beta builds, and then generally only if I can't workaround whatever issue the current build may have. The HE team is VERY quick to respond to build problems, the only one I can remember taking a "long time" to fix was the issue with "cancel on truth change" in the early build of RM 3.0. It took longer than normal to "pin down" the actual cause of the problem, but once Bruce figured it out it was resolved very quickly.

In comparison with other home automation platforms that I've used the development cycle of HE is crazy fast, so fast that I find that I'm never really done tinkering with automations since new features are introduced that give me new ideas on ways to refine and improve rules.

I think the fact of the matter is that HE while being quite NOOB friendly also allows extremely advanced and complex automations, along with user code/apps, all of which can cause unforeseen issues. A good rule of thumb is to try to make changes "gracefully" and create backups frequently, that way if a problem manifests, you will know what caused it and recover easily.

Keep up the good work HE team, we love you!

1 Like

What doesn't make sense here is "IF" you discover a problem that you would need to roll back to the previous platform, say the problem is created by something the "new" platform allows, Say you discover this problem by using a "rule", This could be days after a release and many devies/rules created afterwards. Rolling back the platform only leaves the rule still there without the platform that supports it, without rolling back the database to match the platform.

Am I wrong on this?

I would think it would be the reverse rolling back a platform WITHOUT the database being restored to match would be the "rare" occurrence?

So is this method ONLY to be used with "hotfixes" and NOT "normal updates" because hotifxes are usually targeted to a specific single problem?

Look, obviously if you install something in build 10 that is not available in build 9, it won't work if you roll back to build 9. But that isn't really the situation being discussed. And even so you don't have to roll the database back. Whatever it is will sit there and not be usable. That would be fairly obvious and you wouldn't expect it to work. Or, you could simply delete whatever it is and still not need to roll back the database. Read @halfrican.ak's post above -- he has a lot of experience with this from his efforts as a beta tester. He has a very good track record of breaking Rule Machine during beta, and even after beta.

I'm not asking if it "would work" like you state that is OBVIOUS.....I'm asking WHY you would have your database IN A STATE to have devices/rules that DO NOT WORK, which is what rolling back a platform without the database to match?

Which is what rolling back the database to match the platform does?

Because you know a fix is coming...

Or, simply delete whatever it is, and do it over with the next release.

Like he states "HE" is a beta tester, this "shouldn't be an issue" for them him and others voluntarily agree to do that.

The purpose for this post was so that some of us who prefer NOT to be beta testers with our production hubs only available aren't forced to do so, with the update process, which a slight warning or eventually an option to choose which update you wish to get allows.

I think with all due respect you've made this point several times. This request would be much more complex than you imagine, and is not likely to become a priority for us in light of other priorities.

It's not complex at all....You click create new topic on this forum and Type in "Release 2.1.1.xxx coming tomorrow." Done.

This ALONE would have saved Hubitat on tying up support, replacing hub, and shipping costs (in my situation)

OK, so after re-reading your original post again, I think I understand your motivation: you want to know when a new build is about to be released because if you're not on the then-latest release (e.g., you're on 2.1.0 but the latest is 2.1.116 and 2.1.119 is about to be released), you'd get the chance to do that before you lose the choice of going to 2.1.116 and are either stuck with 2.1.0 or risking 2.1.119. Or if you're on 2.1.0 but hadn't upgraded to the latest 2.1.0 hotfix and want to stay on that "series" instead after 2.1.1 is released, you lose the ability to upgrade to just that 2.1.0 hotfix. (This is much more understandable than my first example where there is generally little reason to move to a middle hotfix when a newer one is available.)

Perhaps simply making the latest hotfix for your hub firmware version available instead of the next minor platform version upgrade would address what you're asking? I'm sure it wouldn't be a priority for them to add this feature, but it at least seems like something they might consider at some point (assuming it's the second scenario and not the first--I can't see them offering older hotfixes for a current hub firmware version; Bruce summed up this reasoning above). If this happens to describe your situation now, even without such a feature, Support could probably make it available for your hub as-is if you ask nicely.

But in all cases, it's still true that there's no reason to upgrade at all if you're happy with your current version. :slight_smile: If you are looking to be cautious and something like my second 2.1.0 example applies to you, you may have noted there is usually period between hub firmware releases where the hotfixes settle down--the problems people noticed after the initial release that weren't caught in the beta were resolved, and the staff are generally at work creating the next version. That could be a "safe" enough time to try upgrading to the latest build for your version while you still can. If you notice problems, you can still roll back, and if you don't (quite likely won't if you wait that long), you won't have to worry about not being able to get it anymore after the new firmware is released.

Again, just guessing as to what the problem may be, but if this is the case, I think I at least understand where you're coming from. May help someone else understand, too.

1 Like

I know the hubitat team can selectively make builds available to certain hubs. When these situations arise "might" be possible to contact support to ask them to make an older build available.

1 Like

Yes pretty much, It can be also applied even more loosely than the above (by only with "new" updates NOT hotfixes). Say for example You are currently on 2.1.0.123, and an update for 2.1.1.123 comes out without notice, then preceeding "hotfixes" come out for 2.1.1.125, 2.1.1.127, etc.

If I wait staying on 2.1.0.123 until all the "hotfixes" have been resolved, things have been settled down enough that you feel comfortable actually updating to by then 2.1.1.135, Currently there is no notice given that 2.1."2."123 is coming (as they are on average about 2 weeks apart) and when its released you MUST choose 2.1.2.123 "IF you want to update", without any option or warning that it's coming for you to get 2.1.1.135 before the process starts over.

So you must at some point (with the current policy) (IF you do choose to upgrade AT ALL) become an involuntary beta tester, and "IF" you have issues, then use the "platform roll back" feature. Requiring more work for every user for a simple update process, that preventive measures could prevent.

Yes this has stranded off to even more confusing subjects, like if something that is "rarely" used/needed takes up half of the page of the UI screen, and the "common use" for when issues arrive for users to use is in one line of small text with a "click here" link?

This POST is NOT in ANYWAY a criticism of HE, it is merely FEEDBACK for what would help us users, and I would assume help HE support by reducing support tickets.

This is only done in extraordinary circumstances, and will not be supported. This drags critical resources away from more important work. So don't count on this happening.

1 Like

This topic has run its course, and then some.

3 Likes