Wind mill fighting with people not open minded enough

62

The challenge with this is if this advisor is smart enough to identify all of this, it’s going to be smart enough to fix most of it by itself. And that’s exactly what the upgradeTool does now. For those things that it can identify that must be changed it just goes ahead and does it. The amount of things it can do on its own right now is relatively small but its capabilities are growing with every release.

It’s one of the many things that the developers have done and continue to do to improve the upgrade process.

As another example, the new YAML format is versioned. What this means is if anything is changed to the format in the future, the old files will continue to work. You won’t have to change anything at all just because the file format changed, or a new feature was added.

Obviously, we have a ways to go, but the developers are paying attention to this.

63

A more general issue is that there is a pervasive experience of auto-update that users encounter every day. Phone apps, OS’s, watch’s, cars, appliances…you name it. And while those absolutely do break sometimes, the average user (because humans simply have no innate instinct for statistics) is fairly easily trained that this must be an acceptable idea.

People always ask me why I don’t auto-update any of my phone apps. I’ve had different answers over the years. Right now, my answer is, “Do you have any SONOS speakers?” or “Yeah, because an update has never knocked out half the global internet.” Sure, my blanket policy is overkill, but it’s also not a huge ask for me to actually just quick check the app page for notes and current reviews when the app needs an update.

It seems to me The @bandit7311’s frustration, although very understandable and relatable, derives from two things: this mindset that auto-update is pervasive and safe without the important distinction the whether the service is critical or not, and the fact that OH is in an interesting position where for many users it morphs from experimental/curiosity level service to more critical with continued use.

Because the entry to self-hosting has been lowered so much in recent years, it’s probably a really good idea to have general docs page on the responsibility of a “sysadmin”. But, this should go beyond update strategy and include fail-safes and internet best practices (how many OH installs does shodan currently find?).

As freely offered software with the standard legal protections of no liability OH doesn’t have to provide training in these ares, but it would be a big improvement to the user experience for some users.

64

Thanks for sharing. I’m on docker, so your exact script won’t work, but I like the idea. OpenHAB is one of the few programs I view as critical, so I definitely freeze it at a specific build. But then I get several builds behind because I don’t check. So I think I’ll make my own script that checks for updates. (Or, as someone pointed out, I could just subscribe to Github notifications…that’s easier, but not as fun.)

65

omg, offtopic and so many replies, I am impressed.

Fun fact 1

Who picked the previous title for this thread: “Auto-Update Openhab” ?

I didnt !! Because there was much more then just “Auto-Update” which I wanted to say with all the words I had written.

Fun Fact 2:

Did I post it in Offtopic?

No I didnt. It was important to me and it was about the major upgrade to OH 5.0, in my eyes it is in Offtopic so people will not think about it any further.

Fun Fact 3:

Was it my intension to speak bad about development / maintaining?

No it wasnt, my intensions were good and I wanted to help and fix things for the future, and the fact of an auto-update was just a side part. But I was either just misunderstood or even purposely not understood. I think people at some point didnt even listen.and repeated themself over and over and over:”Do not upgrade automatically and previously read the release notes!”
Anyway, would I write so much and so specifically if I just would have wanted to throw dirt at people? No I wouldnt!

Fun fact 4:

Did maybe some people understand why I was complaining?

I have received several private messages, which instantly told me that they knew already in what direction “Openhab Support Team” would push the result to and they knew already way before, that it will not have a good ending.

Fun Fact 5:

When I have searched for a few maintainer / developer names from here, I instantly found threads where they also were confronted by other users with “Why are you being so rude?”

Final word:

I really hoped that maintainers / developers / foundation members after what I have written, would step out of their own shows and try to slip into the pure user shoes and look at everything out of a different angle. Out of a different mind set. But I failed poorly.

Openhab and its invention seems to be like a street with very deep broken in roads, even if you try to turn to the left or to the right, the car will still carry on going straight. Sad!

Solong

B

66

You keep saying ‘so long’, as if you’re leaving. But you keep coming back…?

67

I’ve published a rule template that checks daily and updates three Items which can be used to get a notification when an upgrade is available.

Create two String Items, one each for the current OH version and the latest published version. Also create a Switch Item which will be true when the two versions are different. You can use these Items for display on a UI or to trigger a rule to send a notification.

68

Thanks for your detailed post. I have to say, your assumptions and tone don’t leave me indifferent. Reading your message, I actually see we’re aiming for the same thing: a better experience for users. But the way we approach it is quite different.

In this thread, I see several users offering concrete suggestions — which is great and aligns with the earlier call for constructive input. Your posts, especially the last one, come across as quite confrontational. Personally, that makes it harder to engage openly.

If you’re open to it, I’d like to set those emotions aside for a moment and focus on the content.

It all started with the frustration after the (automatic) upgrade. We’ve since shared context on breaking changes and how upgrades are handled in openHAB. Now that we’ve exchanged that info, I’m genuinely curious: can we move from observations to improvement proposals? What would you change, and how?

69

Not to step on @lsiepel ‘s question, but a suggestion for you to consider is to update OH as the milestones are being developed. Since you are using docker it is very easy to change images or revert back.

Of all OH customers I’d guess that only about 1-2% participate (the developer/maintainers and others that want to help) in testing the milestones (so the release is the best possible). With the shear variety of OH installations (IMO it is safe to say no two are the same) that is not enough. Any problems you find will improve the user experience for those that sit back and wait.

70

Screenshot Portainer:

Screenshot_2025-07-30-21-42-40-246_com.android.chrome-edit

71

What about introducing a tag openhab:stable for docker? While currently :latest is correctly pointing to 5.0.0, :stable could still point to 4.3.6 until we reached 5.1.0 or even some later point release.

That way people who want to automate updates in order to keep the installation up-to-date and safe, can use :stable while those that always want the latest release stay with latest. Yes, one could split hairs and claim that 5.0.0 is considered a stable release.

72

That would just delay the problems, not solve anything. The breaking changes are still there. You are just waiting longer before you have to deal with them.

Also, given how OH is developed, there is nothing to say that 5.1 is going to be more stable than 5.0. And there is no guarantee that there will be an X.X.1 release so you can’t really depend on that either.

It also adds confusion because that would be different from all other ways that OH releases are handled.

If you want to have meaningful control over these updates, you must specify the version in the pull and not depend on “latest”.

73

Yeah Sven, it is a good idea (would be) to use a later release as a start into OH5, but as you can see hair are already being split. Banana software will rippen at the customer.

Solong

B

74

I’m running openHAB and Unifi in Proxmox LXC’s and decided to upgrade both systems. I have backups of both LXC’s.

So I’ve done an apt update in both LXC’s. What’s interesting is that the unifi LXC asked me explicit consent to move from 9.1 to 9.3. In openhab’s LXC no question was made, and when I’ve done the apt upgrade OH moved from 4.3.6 to 5.0 (of course I had replaced java17 by java21 previously). Without any problem (this was my easiest OH upgrade ever) but as said previously I could have recovered the entire LXC from last night’s backup.

So apt has means to avoid automatic version upgrades. Would it be possible to implement them in openHAB ?

75

Constructive suggestion! Certainly something to explore, my knowledge is limited to apt scripting, but some maintainers know a lot more about this.

Personally I’m not aware i have ever seen this with other apt packages, would be cool though!

76

I don’t understand your question. What do you want to accomplish and how? Give context.

We’ve already implemented that the openhab apt package refuses to install if none of the recommended java packages is already installed.
But ultimately, ”Automatic version upgrades” (or at least what I understand by that term) is what this whole thread is about.
Emphasis on “automatic” - that was the key problem with the OP’s deployment procedure.
But that’s nothing we can or want to do inside the openHAB package.

77

My understanding is that the requirement for such major upgrades will require manual input (accept/proceed), preferably after reading the breaking changes.

Currently we show the notices after the upgrade procedure started. Many users start apt, see a new version is available, search for release notes, start apt again. I agree that this upgrade experience (even though it is common practice) can be improved, it is not yet sure if that is technically possible, other installation methods may or may not have such features.

I intend to look at a previous PR that was trying to upgrade from main UI. While that did not get merged due to security concerns, i do think that parts of that PR are very useful. Especially the part where a pop-up is shown on a new release (with direct link to release notes). Similar to what ZWave-js UI and pihole offer.

78

@moody_blue is that what you mean?

I’ve just created a PR to change that in openHABian so if you select menu 02 it’ll upgrade all OS package * except * openhab and openhab-addons. Those you have to manually initiate via menu 03 or 4X.

Note that’s something you can do in openHABian but not inside apt so if one doesn’t want to use that, there’s not much we can do about it.

That’s incorrect. openHABian has never supported this. And no, it’s intended for laymen AND experts.

79

Yes, it’s what I mean. It’s great that openhabian allows the separation of updates, if apt could do something similar that would be great.

80

In my memory there was an “update” function which only updated os functions (with openhabian being part of this) and another update function for oh. Just as it will be again. May be technically different, but then …

But you are "MoD” and will know better.

@moody_blue : using apt you may tell it, not to update certain packages.

apt-mark -h

sudo apt-mark hold openhab

sudo apt-mark hold openhab-addons

Be aware that apt ignores every future update of the packages told until you mark thrm “unhold”. If you already knew that, just ignore my post.

81

Well, at least one could set the packets openhab and openhab-addons on hold:

sudo apt-mark hold openhab openhab-addons

to ensure that openhab is not updated.

To allow updates, unhold is the key.