Backups are NOT true backups

🛎️ Get Help
1

I don't know what's going through the code monkeys heads lately but this has to stop.

Last 2 updates has broken so many things it's not funny including waking up to a dead hub again.

And to top it the "backups" are only settings, devices, apps and dh. Firmware is NOT being saved and that is not a good idea.

So even though I'm on the current FW and restore a backup who's to say it's not correct if the FW made changes to our devices and /or apps during the upgrade? And a backup only reverts those changes and now we could have a unstable hub.

Second if the backup is without FW WTF is the backup repairing our devices in the first place ? What is the problem here ?

Test coders ! Don't push FW out only to have hundreds of us thinking of going back to ST.

Get a beta group and test there before you harass us with upgrade blues.

So in short my complaint is this... I upgrade and it breaks my stuff. I restore a backup on same FW and ALL goes back to normal.... this part is a issue that needs to be addressed before I ever upgrade again and before I give your hub the bin toss.

Edit: I'm a code monkey and proud of it. I have coded in linux kernel, apache, sendmail and 1 of the founding fathers of podcasting and podcast receiver apps.

Code monkey is a term of endearment not a insult.

2

The backups are TRUE backups of the database.

To rewind OS level is a different solution.

http://{your hub ip}:8081
will give you a list of saved OS versions on YOUR hub. Pick one to roll back.

Brand new hubs will have no previous OS. Contact Support to get a "roll back" solution for those.

3

I didn't know that the os is on a different port

4

But still does not explain why a backup fixes the upgrade. I can reboot all day and it's broken until I do a restore from a backup.

5

the SQL DB got a record added/changed/deleted... resulting in a BROKEN DB. Reboots don't change that.

Restore of a DB backup from BEFORE the corruption fixes the DB.

6

But why ? It shouldn't be happening in the first place. This needs more testing then to find the step that causes the problem and doing a restore isn't a solution... It's a bandaid.

7

It would be helpful if you would be a bit more specific as to what "broke". We agree with you that an update should not break things, but without specifics there isn't much we can do to figure out any problem.

8

Devices dropped. Hub became unresponsive. I tried until 3am to fix the issue and gave up. Woke up hub was red light and rebooted. Same issue with slow hub. Restored from a good backup but was still sluggish so reverted FW back too 1.1.2.121 and hub is back to normal operation.

9

Have to agree on the sluggishness which I had in the version before too. Support were investigating but that’s all gone quiet and I still have the issues, but worse now.

I have lights triggering after I’ve left the room it’s that slow. Can someone assist me in going back to 1118 or 1119. This was the last stable version for me, yet don’t appear on my hub using the port.

10

119 was a really nice FW but I think that will break Webcore because of changes that came after that FW

11

The latest version of Webcore should work on all fw's up to this point, including 119.

1 Like
12

Good to know as I wasn't sure

13

I have no coding skills at all, but from the perspective of a user, I am not thinking of going back to ST.

Hubitat updates can be downloaded and installed as soon as the user wants, delayed, or even ignored completely.

I’m sure everyone would prefer that any updates don’t break something.

But between the ability to delay updates in the first place (let someone else find out it breaks everything), and the speed with which they do usually address these issues, I’m satisfied.

12 Likes
14

I've seen the same thing, assumed it was a weak zigbee and zwave network.

15

I’ve only just deleted all my devices off ST. It’s quite possible I’ll be booting it back up. I can’t bear this any more.

I’ve been told somethings flooding my network yet found nothing. I’ve been analysing my network now for two weeks and found nothing wrong. Removed Nest, and WebCoRE presence as suggested. Still runs so badly. Every now and again there are moments of brilliance, then back to a snails pace.

As I typed the above......
Mrs has just come in complaining my sons light just turned on 100% (nothing was touched and there’s no automations here), suspect this is yet another massively delayed action. He’s fast asleep. TBH. That’s enough for me. If it can’t pass the wife factor it’s a gonner.

16

Same here.. though tit was the ported ecobee driver. But after removing it the hub only worked for a bit before it got slow again.

I was starting to think it was my wemo switches but I didn't want to uninstall them. Too much to setup again. I reverted back to 1.1.2 and everything works fine.

17

Thanks to Support, as I typed the above, I'd received an email allowing me to downgrade to 1.119. Already seeing an improvement. I'll be monitoring, keeping fingers crossed. All I'd like is stability.

18

I'd like to downgrade too. I received mine last week and 1.1.2 is the only firmware I've had access to. Technically I still don't know what it's like to have "blazing fast" automations.

19

I just hope it stays this way. Contact Support, hopefully they'll organise it for you.

20

My sunset automations did not run tonight with simple lighting, RM is working with doors and lights.