Each time OpenHab does a version release we seem to have at least one user come on the forum and post dissatisfaction or frustration around the release and how they did not expect it to occur, or they did not take time to review the change before applying it to their environment and as a result some function stopped working the same as it previously worked. Each time that post is made many folks reply and the discussion devolves to the poster ends up feeling attacked and backs off.
The input I will add to the conversation is this.
An update is not the same as an upgrade.
You update the state of a variable or item. (status change)
You upgrade the version of binding or even the entire application. (a code change that results in a different behavior of some portion of the component or application then previous version)
That is a huge difference and as such you have to approach each activity with a different mindset.
You can automate a update of a state or value whether if be an item and not be bothered about it (the reason you automated it initially) or even a signature file such as the ones many security softwareâs push multiple times a day think A/V and or malware pattern files.
You do not upgrade the entire OS or application without user confirmation (even winders and MSFT learned that lesson the hard and painful way think win7 to win 10 and all the bad press it brought them.)
Portainer and other tools that automate the deployment of an entire image are great they help every IT admin manage the activity and provide many features to improve consistency and advance notifications of new images availability.
However, a few things need to be accounted for when using those types of tools within your environment and even on a application basis.
Example is OpenHab only releases new base images when a version Upgrade is made available.
So does it make sense to use portainer or any other deployment tool to push those upgrades into your critical environment without doing some base testing or change review? (That is of course up to the admin of your environment.)
No change comes without some trade off so doing due diligence before triggering a upgrade is just good basic stability practice.
one last update to my post.
I would think about changing the title of this discussion from auto-update OH to auto-upgrade OH to more clearly reflect what this discussion is really about.
This is an important observation. And in a lot of the back and forth, it seems to me that the most cogent points have been buried a little:
This is not a bad strategy, but should include an expectation of at least some additional work.
This is really the only point that is drawing the commentary. This expectation simply does not match the OPs desired outcome. The entire point of major releases is to signal to the user to expect some breaking changes. A simple modification to the expectation (and therefor Portainerâs behavior) to upgrade patch releases (and maybe minor releases), but not major releases automatically will lead to a substantially better user experience in this case.
Thatâs not a feature of those packages (just as breaking changes in a major release is not a failure of OH), that just means youâve gotten lucky up to this point and donât use any of the features of those programs that have been the subject of breaking changes. The best course of action here is to learn from the experience with OH and also set those packages to not do unsupervised upgrades of major releases before the same thing happens with one of them.
Because you will read the announcements and see if there are any breaking changes. You will watch and make sure everything comes up again and works properly.
If you donât do that then no, there is no difference. Similarly, you should never upgrade either of thatâs your manual approach to upgrades.
If OH is working properly, what are you missing out on? You donât need to do these updates if every thing is working.
But here there is a way to have your cake and eat it too. The third point level updates almost never have breaking changes. There are so few changes in those that blindle upgrading to those poses a low risk. So change the image from openhab/openhab:latest to openhab/openhab:4.3. That will only upgrade to the latest 4.3.x meaning you will get all those low risk point updates but wonât automatically upgrade to 4.4 or 5. Note that when that first number changes, there will be breaking changes guaranteed. Rarely there will be breaking changes when the second number changes.
So by seeing the image version you will tell Portainer, upgrade up to this and no further. When you are ready change to the next version and attend to the upgrade, didnât just let it happen and wait for stuff to break.
Or just watch the logs during that first startup. If there is something wrong there will be errors in the log. If you see errors, address them based on the announcement or back out to the previous version until you have time to address them.
The fact that you have to wait a day for stuff not to work is a side affect of doing unattended upgrades.
No, just watch the logs for errors and test one or two things. Also check you Things are online.
And what we are trying to say is you donât have to hope and pray if you take just a minimum amount of effort before and during the upgrades, which you cannot do if you just blindly do upgrades unattended.
edited by original poster, sorry for the disturbing
For me at least I do not consider any thread more or less important.
If anything, I would look at from a different perspective your concerns are so important and valid it was given its own thread to give more attention to it.
I also do not think anything about your concerns are âStupidâ.
There are likely many other users who do not camp on the forum and basically set up the system got it working the way they want and move on with life.
What is being conveyed here is thought processes that should be taken into consideration when initiating a change to your environment.
I will also say this these threads stay around long after the initial discussion and many times are referenced days months even years later so perhaps the discussion for you now is not as beneficial but for other users later it may help them make different decisions on how they approach upgrades to the application.
There were no changes to OH related to Voice between those versions so 
. No idea what could have caused the problem but it likely wasnât the update. Without logs we will never know. Perhaps all you needed to do was restart OH again after the upgrade.
Indeed, the work is going to have to be done. You can either do the work in little bits each time you upgrade or do a lot of work later on when you finally do an update. But itâs never going to be the case that thereâs no work to do ever.
Thatâs the unreasonable part. You are trying to get the latest without doing the work necessary.
Ultimately we are trying to get you to a place where you have a better experience over all with OH. Right now you blindly upgrade and itâs a roll of the dice as to whether something goes wrong or not.
We are trying to show you how you can improve that experience. But itâs never going to be something that OH is going to be able to solve for you. There will be breaking changes. Sometimes they are deliberate, sometimes they are by accident. But breaking changes can occur at any time.
You have three options to choose from:
-
Continue on as you have with the understanding that some updates will break your home automation. You wonât know how or when but it will happen. And if you donât do attended upgrades it will always be a surprise.
-
Donât upgrade at all, or do so infrequently and when you have time to monitor the upgrade and deal with breaking changes that occur. The only way OH can guarantee it will never introduce breaking changes is to cease development entirely. You can simulate that by ceasing upgrades. Or at least wait until you have a need to upgrade (something outside OH broke OH integration, you want some new feature). It will be more work all at once to upgrade from an old version to a new version but you get to control when you do that work. There are people still running OH 1.6 without problem so you can go a decade before you need to do anything.
-
Upgrade more frequently but monitor the upgrade by watching the logs for errors, make sure your Things go online, and test one or two automations. Most of the time the upgrade will go smoothly. Occasionally something will break. Then you can fix what broke or back out the upgrade until such time you have the time and willingness to address what broke. Because you are dealing with fewer changes than 2, the amount of effort and time will be much lower.
Not all problems after an upgrade are caused by the upgrade. Often timing gets messed up after that first start after the upgrade because OH has so much to do. So itâs a good idea to give OH a few minutes to settle and then restart it again. Much of the time this will clear many of the errors and warnings that appear after an upgrade. Much work on this front had been done and will continue to be done.
When you do 3, whether the upgrade broke your home automation or not will never be a surprise. You will know within minutes if something is wrong and you can restore or forge ahead as you choose.
Itâs worth mentioning the release cycle for OH.
Snapshots are released nearly every day. This has the absolute latest code merged into OH.
Milestones are released once a month.
Releases occur every six months.
Major version releases where breaking changes are guaranteed to be included occur every two years or so. These are not really planned and they correspond with a need it desire to move to a new version of the JDK. Deliberate breaking changes are reserved for these.
Patch releases occur when a few bugs are discovered that impact the older version. If you are not affected by the bugs listed, thereâs no compelling reason to upgrade to the patch releases. But these releases have very few changes so upgrading to them are very low risk.
I moved this as a moderation action because A) the whole discussion was off-topic for the thread you started it in and B) I was asked by users to move it.
There is no such thing as more or less important threads.
Before you form any further pictures in your head please remember a few points:
- It is in the best interests of everyone on this forum to keep and encourage OH users.
- Everyone on this forum attempting to help others is a volunteer, which means that they are doing this out of a sincere desire to help and see other OH users have the best user experience possible.
Next time you think you are being personally put down, or that your forum posts are being down-graded, or that your contributions are being ridiculed, think back on those two points and realize that in fact what is going on is just miscommunication.
You indicated that you are not enjoying your user experience with OH. You explained that your negative experience comes from the fact you are hoping to get three things out of OH:
- Latest version of OH releases
- Unattended upgrades
- 100% system reliability
Volunteers who wanted to help improve you user experience have now tried to explain not that you or your problem are stupid, but that the problem is simply that those 3 criteria cannot all be satisfied at once. You can easily satisfy any one of them. And with a little work, you can satisfy most combinations of two of those. The choice is yours and one simply of personal priority, there is no right or wrong selection.
NOT upgrading can also be risky. While it means that openhab itself remains the same, the external API may change or discontinued, causing things that used to work to no longer be working. Such is life in the software world.
Nooneâs advocating not to upgrade.
But there has to be a good reason for it, and it has to be executed with attention and care.
Every single time.
Amen, think this will be the best for the OP. Obviously OP has to make his own choices, but the expectations are IMO not aligned with what we can offer.
In my opinion, there are some interesting aspects of this discussion that Iâd like to provocatively highlight:
a) Development is voluntary and unpaid. One shouldnât set expectations too high.
b) Updating/installing the software requires a professional approach.
Do we all do this for fun? To promote ourselves? For the joy of the smart home? For the joy of openHAB? What for?
Whether you simply update/install something or read the release notes beforehand, the end result is the same. With âbreaking changesâ in the software, youâll probably have to do some work. If youâve read the release notes, youâll know roughly where to look (weâre not all professionals). If not, youâll read them after installation.
In the worst case, youâll have to get to work either way.
In this context, Iâd like to point out that I donât think itâs a good idea to update OH via apt/openhabian-config at the same time as all other updates. I want to keep my operating system and OH up to date. Unfortunately, openHABian no longer supports this. Itâs intended for laypeople.
Perhaps some of the developers, maintainers, supporters, etc., who are active here in the forum should lower their expectations of OH users here in the forum.
Breaking changes are, unfortunately, impossible to avoid. With 400+ add-ons, constantly evolving APIs, protocols, and user requirements, itâs simply unrealistic to expect a system like openHAB to never introduce them. I think we can all agree on that.
Thereâs another category of breaking changes, though â those that are not strictly forced by external factors but result from a conscious decision for a higher goal. These are the ones where we, as maintainers, weigh stability against long-term improvement. Looking at the state of openHAB over the past few years, especially compared to 3.0 and earlier, I believe weâve made significant progress in keeping things stable. Still, I understand that this remains an important and sometimes frustrating topic for users.
At the end of the day, when a major release comes out, itâs the responsibility of each user to review the release notes and assess the impact before upgrading. Silent upgrades that result in breakage can be frustrating, but they also highlight the importance of understanding whatâs changing.
If anyone believes that a specific decision by one of the maintainers led to an unnecessary breaking change, I invite them to bring it up in a constructive way. I, and Iâm sure my fellow maintainers as well, are open to feedback and always looking for ways to improve.
Simply complaining about parts of a setup breaking after an unattended major upgrade, in my view, lacks the necessary self-reflection.
We all want the same thing: an openHAB that keeps evolving while remaining as stable as possible.
edited by original poster, sorry for the disturbing
What solutions would you propose to your observations?
Regarding the RPI 4 that is already 8year on the market. Costs about 45 euro. I agree we have a different view on that subject. We did not take that decision lightly, but we did. If you want more insights please ask.
Your comment reminds me again that clear communication for such changes are key. Compared to many other open source projects Iâm proud on the way we do things, but there is obvious always room for improvement
I donât know what this has to do with reading the release notes nor what it has to do with unattended upgrades. Either your hardware is adequate to run OH or it isnât. The hardware requirements for OH are relatively modest but the RAM requirements in particular has grown over the years.
There is always a section of the release notes written in prose explaining âthis changed and that is what you need to do to your config as a result.â For example, from the most recent 5.0 release notes:
Semantic Tags: Some Point tags reclassified as Properties; list of Point / Property / Equipment tags increased (so custom tags may now be semantic); tag validation is stricter. You may see validation warnings in the log, Items moved to another place in the UI, or other unexpected behavior.
and this for the MQTT binding
Thing types and channel IDs for things created prior to 4.3.0 have been significantly restructured and simplified. Items will need to be re-linked. Delete and re-create your Things to also have a simplified Thing Type ID in your Thing IDs.
Hereâs a good one from the 4.3 release:
The DateTimeType methods toZone(zone), toLocaleZone() and getZonedDateTime() have been deprecated. They will be removed in a future version. In DSL rules, please use getZonedDateTime(ZoneId) as replacement for getZonedDateTime(), for example getZonedDateTime(ZoneId.systemDefault()) to use system time-zone.
Note, per @lsiepelâs post above, this is one that I brought up in GitHub as an unnecessary breaking change and was very much against the change. I did not win that argument and thatâs OK. They did hear me out and thatâs all I can ask.
The reason I post these examples is to show that the breaking changes section of the release notes is usually clear and easy to follow. If you donât use MQTT, then you know you can ignore that breaking change. Donât use semantic tags or Rules DSL, you know these breaking changes do not apply to you. But if you do use any of these, the release notes tell you exactly what to expect and exactly what you need to do to adjust.
And as OH has matured, the breaking changes sections of the release notes has gotten shorter and shorter (OH 5 has only 2 listed for core and none for MainUI compared to OH 4 which had five listed for core and OH 3 which had eight, and that doesnât take into account the relative impacts of those breaking changes as the ones for OH 5 are pretty low impact).
This is always going to be true. No volunteer who contributes to OH has every device ever made that works with OH. But there is a pretty long testing period that anyone in the community can contribute to by running snapshots or milestone releases and reporting bugs and problems on the forum and in GitHub. There are many of us who do and we can always use more.
Thatâs just the way it is, and itâs a strong argument for doing attended upgrades and against unattended upgrades because the likelihood that anyone has tested openHAB in exactly the same configuration as your setup is pretty much 0.
Anyone who has used openHAB for more than a couple versions knows the answer to this. Compare the user experience from OH 1 to 2, 2 to 3, 3 to 4 and now 4 to 5, and itâs clear the developers of OH have gone to great lengths to produce a home automation platform that is approachable by more than mere developers, to improve the overall stability, and reduce the number and severity of breaking changes.
But, given the nature of what openHAB is, it is impossible to reach your desire to be able to upgrade unattended in perpetuity without ever needing to adjust your config. Something is going to break, and you will have to do something about it. But if you do unattended upgrades, you wonât even know something broke until a day or more later.
To be fair to that developer, a Raspberry Pi 2 has been far beneath the minimum recommended hardware requirements for at least five years now, if not more (Iâd have to go back and check to get the exact number of years). And even back as far as OH 2.0 an RPi 2 was only just barely able to run OH. Over time, due to decisions made upstream (i.e. not by openHAB itself) and decisions made here, the amount of RAM required to run OH has increased. It is what it is.
But again, this has nothing to do with unattended upgrades, unless itâs a reason to choose not to upgrade, which is a valid choice made by many. Itâs not a free choice as has been mentioned and likely just delays the work youâll eventually need to do when something finally does break, but no choice comes without costs.
I do want to make something perfectly clear by just flat out stating it. All of my replies are attempts to show you a better way you could be handling your upgrades right now to give you a better overall experience.
Your current approach is giving you a horrible user experience and there is almost nothing that OH as a project can do beyond what itâs already doing to make it a better experience. We cannot promise there will never be a breaking change ever again. Itâs simply an impossibility.
However, there are things you can do to make your experience better. And that means you need to attend to the upgrades. Watch the logs. Read through the list of breaking changes to see if any apply to you. And make sure everything came up after the upgrade as itâs supposed to. If the upgrade failed you need to spend the time to figure out why and fix it, or back out the upgrade until you do have the time to figure it out.
If thatâs something you canât do or wonât do then openHAB may not be the platform for you. Thereâs nothing wrong with making that choice either. Though your alternatives may be pretty limited. Many users come to OH because HA makes breaking changes far more frequently than OH does and even commercial offerings like Samsungâs SmartThings breaks things with some regularity.
edited by original poster, sorry for the disturbing
Could you explain, I donât get your point.
That would be sad, Iâve already got beer and chips