I down graded to 1.1.2 and ALL my devices are working like a charm. No degrade on my end.
Opening any does not fix it.
I had to open all sunset/sunrise rules to get them all working.
That’s what it says. Open any rule that uses sunrise/sunset and hit done for it to work properly.
It doesn’t say that by opening one rule and hitting done, you will fix all rules that use sunrise/sunset.
Edit: I suppose they could have said “every rule” and it would have been a bit clearer.
1 Like
Any means any one by even rule standards. It's worded wrong.
1 Like
"Any rule that uses this feature must be updated."
"Every rule that uses this feature must be updated."
Is there really a difference in meaning?
The original wording implied if you open and saved ANY sunset/sunrise rule it would fix all.
Is that better ?
One reading of it perhaps, but I think it actually had the meaning in the above post. But, perhaps it was ambiguous, open to misinterpretation -- well, open to a different understanding than the author intended.
2 Likes
I disagree.
The original wording said that you must open any rule that uses sunset/sunrise and hit done for it to work properly.
You inferred a meaning that wasn’t there.
4 Likes
Ah, the interpretations of the English language !
Does it not boil down to the fact that the User is in control regarding whether to update or not ?
Some good information has come out of this painful discovery but from what I’ve read, we as users have a choice over FW and OS versions (didn’t know that). That’s awesome visibility that’s rarely provided these days and I’ve found support and the community are super responsive.
1 Like
Just to clarify somethings.
The backups are just the database on the hub. You can backup and restore this at any point and the hub stores 5 backups, which are taken daily or on reboot for that day.
Firmware is the software running on the hub. You can roll back to the previous firmware via http://hub ip:8081
Backups are somewhat tied to firmware, but in most cases, restoring a backup to a newer firmware should be fine. Restoring a newer backup to older firmware could cause problems.
We are looking at ways we can make firmware roll back more obvious of a choice to help with this confusion. One idea is to provide a link to the rollback tool (port 8081) on the backup and restore page itself.
We appreciate everyone's feedback as we continue to improve and expand Hubitat Elevation.
5 Likes
That sounds like a good idea.
2 Likes
How about making it possible to roll back to any firmware version? This will hopefully satisfy new users that come in at version levels that seem to be troublesome and want to roll back earlier versions that long time users are suggesting to be more stable.
Sure. there might be other reasons that are actually the cause for the issues that they experience, but at least they can roll back to the earlier version and see for themselves that it does or does not resolve anything, and that might help to further their own troubleshooting efforts.
It would also be great to have a link to release notes, accessible right next to the version number, for each version made available. That way users could see what limitations they face, should they decide to roll back to a previous version.
This doesn't actually make sense. First of all, it is not a steady state condition that there are "bad builds" and "good builds". There are issues in 1.1.2 that we are well aware of, and that are soon to be resolved. Those issues carried over into 1.1.3, which didn't actually deal with those issues. There could be problems putting a newer database on an older build, and users don't know when this might be an issue. So rolling back to arbitrary prior versions is not a viable plan.
1 Like
I think rollback is fraught with pitfalls, I think you open yourself up to a massive DB corruption for which the answer is "reset to factory." Clearly the Hubitat team has done a remarkable job of protecting the DB integrity. I've read of so many that have downgraded, upgraded, downgraded, without ill effects. But the DB is a "living, breathing" thing, It grows not only by what we do, but by the Firmware version too. I happen to think of the DB that I affect as altering the "length." I add/change/delete and the DB length keeps up. But the Firmware can alter the "width" and a new Firmware release might populate new "width" with default values. A downgrade would work, probably, because it's not likely to alter the DB "width" it doesn't know about. Now add in some add/change/delete and then an upgrade and now the DB is going to have the new "width" peppered with defaults and nulls. That might be called a corruption. If true, recovery may involve restoring to a DB backup from before the first upgrade. That might be a lot of add/change/delete that gets lost.
(And yes, I'm talking about schema changes for those that know the terminology. With the caveat that I don't know anything about the internals of Hubitat beyond what you know, and potentially less. 
)
Just advice, with grains of salt: Avoid every downgrade you possibly can. 
3 Likes
I was worried about this and the changes the latest brought before begging to role back to 1.119. That said, if I hadn't, the hub would have been pulled and ST reinstated. Rolling back was my saviour and at least things started working again.
This goes completely against what I would have to do in the working world, and agree the DB should always fit the version or you're dealing with an unsupportable product.
"... possibly can" <-- my weasel words to cover that situation
1 Like
OK. That makes sense to me, but that's not to say that it can't happen already, or does it? We already have the ability to roll back to a few versions at a time. Are there limits to how far back we're allowed to go when the result might be database conflicts?
Just for clarity, I don't think that there are "bad builds" or "good builds" either. I didn't write that, I'm not implying it, nor do I recall ever doing so. I was merely suggesting an idea to address the desire that others have expressed. I'm also not making reference to either the current or previous version. Perhaps you're addressing someone else? I'm satisfied with the way my hub is working. The interface is a bit slow, but the actual hub and device performance is not. I see that you are planning to address that, but I haven't complained about it. I'm pleased to hear that you seem to have found a solution. 
I must confess that I have moved all my stuff back to ST (everything was moved off of ST to HE) because everything slowed down and some things stopped working or were very sluggish.
That being said, I have moved a very simple cupboard light back to HE and I am monitoring the speed and reliability of the rule.
I DO want HE to work for me as I like the concept of local processing and the choice of when I want to do an upgrade. As it happens I've had some internet downtime over the past couple of days, (very rare for me) which only reinforces my need for HE to work for me.
I won't give up on HE but I also realise that as a product it is still in its infancy and the speed of development has been very positive.
So for me at the moment its a bit of a watch and see.
EDIT: What the hell that has to do with backups I suppose is rolling back to get everything to work.
1 Like
