REQUEST: "Slight" Change To Hubitat Policy

Never is possible and will be the options I take going further until some "preventive measures" changes.

You must have missed the one that covers this, "his platform restore" function may/may not have worked I was unaware of this option.....But I CAN state that "restoring the database" was NOT AN OPTION, with this error from the update as it would NOT restore ANY database, and performing a "factory reset" blue lighted the hub making it unusable.

Are you "sure" you read the posts in THIS thread? Nowhere was this ever mentioned as being any sort of issue?

Factory resetting always gives the hub a blue light. You had some further specific problem that I'm not personally familiar with. A factory reset removes the hub platform software, which is the source of the green LED. One should not do a factory reset unless instructed to do so by support. In the circumstance you described with a failed database restore, a soft reset would be the normal action, to remove the database. Then the database can be restored from a backup. But, as I said, I don't know the specifics in your case.

Does that include one you backed up and downloaded yourself, then tried to restore via upload?

Yes, the implication is that I was guessing at your actual problem since updates are 100% under your control. That guess was not correct, then.

PS - Waiting is certainly a viable update strategy--I've done it on one of my hubs when I wasn't sure of some platform changes in one version. "Never" theoretically is too, but from what I've seen in the past, unless you don't like something in the release notes, you'll usually be good after a few days. :slight_smile: I'd recommend updating at least once in a while when you feel comfortable since there are likely undocumented security fixes (the firmware appears to be Linux-based) and if you use custom code, many authors only test on recent versions (though of course there's no reason to update that either if it works).

After 15 hours of being completely down with almost no responding from support (I get it I know and UNDERSTAND......that HE has a limited staff, which is WHY I'm asking for a way that WE users can assist YOU in how we perform updates), AND after performing a soft reset probably a minimum of 15 times BECAUSE NO database would restore after the soft resets, Under those circumstances I had no other choice then to do a factory reset, as the system either needs to A-Be working OR B-Go back to pre-automation......Odd that factory resets are ONLY to be performed when directed, I myself would have assumed that performing a factory reset would restore the HUB back to the same condition it was in when you received it from the factory.....I.E. working.

In the long run it will reduce need for your support resources as some of us will ONLY do the updates we feel comfortable with, instead of doing them just thinking everything was "fixed" nothing to worry about and then you now have to devote your resources to my case, at which I'm stating how this could have been prevented (at least in my case) and have seen others ask for the same request.

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