for beer and chips:
you are welcome
Iām just trying to get you to a better experience with OH. If you interpret this as āspeaking down toā that is not my intent. But to get a better experience, you have to change how you approach upgrades.
If changing your approach is something you are not able or willing to do, you will continue to have a bad experience with OH now and forever, and thereās nothing more we can do about it than what we already are. Some other platform will be a better choice for you. OH will never be able to meet your needs.
No, as a participant itās a conflict of interest. You are able to delete your own posts if thatās what you wish.
I did already, I am not wasting any time anymore to fight with wind mills like Don Quijote.
Solong B
@rlkoshak Can you please at least delete my words in between your postings?
Thanks
Thx for the reply, I already thought you are one of those guys. You are now as the first user in 10 years on my ignore list:
No. There is no violation of the siteās terms and conditions in your words. There is no private information revealed. And the quoted text give context to the replies. Without a more compelling reason than ārage quittingā Iām not inclined to edit my posts.
I think the discussion is a good one and there is a lot of good information in all the posts from all the participants.
It is wind mill fighting, somehow people are not capable of listening or are to deep stuck on their tracks just moving forward and not looking left or right.
I can waste my time somewhere else
Solong
B
āIām doing something that makes my upgrade experience horrible. OH should change that.ā
āOH canāt change that, itās the nature of complex software. But here are things you can do to make your experience less horrible.ā
āI donāt wanna.ā
For your position:
I am Foundation member,
have the newest hardware, the newest and uptodate operating system, what do I care about a small user, we make changes however we want, oh and I repeat myself over and over as unattended upgrades are not a good way to go. I understand since you said it the first time, but it would have made no difference as I also would have had to also rollback a day later
Thanks for everything and nothing
Solong
B
Which means I care enough to donate money to the openHAB Foundation to pay for hosting this forum and the myopenhab.org cloud service which the openHAB Foundation offers for free to all users. It means nothing more.
I do not have the newest hardware. I run long term release operating systems which are not cutting edge. I run OH in a VM on Proxmox running on a ten-year-old Intel i3 machine. The newest IoT device in my home is at least three years old.
If I didnāt care I wouldnāt be on this forum, contribute to the foundation, and on Github. I am always standing up for the āaverage userā here and on GitHub. I have argued against breaking changes on many occasions and often am successful. Iām out there actively advocating for you and users like you.
All changes made to OH are done with a lot of deliberation and discussion on the impacts to the end users already. Changes that have a large impact on end users are rejected with some regularity or delayed until there are major version changes where breaking changes are allowed.
The only reason Iām still here on this thread is because I will not have the developers maligned in this way without retort.
You ask the impossible and blame the developers for failing to deliver. And then ignore and reject things you can do to improve your own situation.
The only way to prevent breaking changes to end users is to never change anything. OH would become finished software, frozen in time and never to be changed. Since thatās not the case, there will be breaking changes.
You can freeze OH by never upgrading. There will never be a change, so there will never be a breaking change.
But you canāt get bug fixes, new features, and new add-ons and never face a breaking change. Thatās impossible no matter how much you want it.
But the fact that there was over 20K new lines of code and 251 pull requests just to OH core and only two breaking changes is pretty strong evidence that the developers do a damn fine job of minimizing them. To say they donāt care is slander.
Because that was the topic of the post. And that is the one and only thing that can be done to improve the original issue raised in the original post. Itās impossible to avoid all breaking changes in software development of a system like OH, so I present what you can do to improve things instead of waking up days later to find stuff doesnāt work.
But no, itās the developerās fault that they cannot deliver the impossible.
Of course, if you are unhappy with your purchase, Iāll offer a full refund of the purchase price for OH out of my own pocket.
Why is this thread titled, āWind mill fighting with people not open minded enoughā?
Because someone has his feeling ruffled and the only power he has on driving the conversation at this point is to change the title every time his mood changes.
If he would stop being emotionally offended and simply change it back to the relevant subject OH Auto-upgrade? to reflect what the real intent of the discussion is then it would be a useful thread to follow.
Now however it is just watching someone throw a temper tantrum.
Disappointedly there is in fact a lot of good relevant information around how release work schedules and processes are handled along with ways to contribute to a better release cycle, but emotions have taken over logic and further devolved this thread to a pointless level that most readers will now simply dismiss.
Quite late for the party. I have missed some of stuff, I skipped two screens-long answers which nobody but author will read. Yet I would want to bring attention to a basic fact, that regardless of what have happened each side of conversation deserve respect and an attempt to see a problem like we would be on the other side.
While in this topic we have seen a lot messages defending contributors, I wish also to defend the OPās point. He uses the software and sets expectations for it. He have a right to make these and nobody can deny anyone making its own assumptions.
Now, the question to developers/mods and others involved in the gang is not whether these are āgoodā or ābadā nor āvalidā, because these are quite subjective measurements depending on the side of the argument. The real question is: can this community can even read user complaint properly? Remember about survivorship bias - people who come with little to no disturbance to say āit went fineā are not the ones this community is at risk to loose. We are seeking these with major injuries who struggle because if not this, then maybe next time, we can loose it. Be aware of golden rule of marketing - unhappy user will tell about his experience to 10 other, while happy will rarely advertise a service.
Getting to the point and reading through the complain I can see following:
- Major OH releases tend to break things, more over there is no way for user to asses his system is working fine other than conducting all checks manually.
- Users who decide not to upgrade every 6 months and take risks brought by major releases end up with no support as patch releases for earlier versions are suspended within short time.
These are two which I can read directly and indirectly. Iād welcome others to make an effort to try reading the post again and derive own conclusions of what could be improved to avoid such posts to appear. Simply speaking, having 10 people denying the problem, does not solve this and possibly other users problem.
Cheers,
Åukasz
Against my better judgementā¦
The strength of the OH forum is to solve user problems with data to understand the environment and logs, including debug logs of the binding(s) in question. When posts go off in a philosophical (or user preferences) direction they spin out, like this one did.
This was pretty much a data-free topic. About all I gather on a quick review is OP used Portainer, had some voice command issue between OH4 patch releases and a water heater stopped after OH5. Not sure of the bindings or anything else in the linked guideline for forum questions.
So, my answer is when confronted with a post, try to focus on getting the data to solve the problem. That is what I try to do (except this one 
)
Understood.
Too many words (even though more than half my page long posts are quotes for context).
Donāt try to help users do better with what OH is now.
Mind sharing your cronjob?
Not at all, but mind you that my Linux knowledge is pretty minimal, and was even more limited when I wrote the script. Also, it will probably be frowned upon, as it still relies on automatic upgrading practically everything that is not openHAB.
Because I do follow OPās sentiment that a lot of programs can be upgraded automatically. I just accept that openHAB isnāt one of them. But all the rest, I would just blindly upgrade anyway. Thereās no difference between me manually running apt upgrade -y, or having a cronjob do it.
Important note: I made sure openHAB doesnāt automatically upgrade by running something like sudo apt-mark hold openhab.
#!/bin/bash
apt update
shopt -s nocasematch
UPGRADE=$(apt upgrade -y)
TEZOEKENTEKSTU="openhab"
if [[ "$UPGRADE" =~ "$TEZOEKENTEKSTU" ]]
then
echo "OpenHAB kan bijgewerkt worden. Dat proces wordt het beste handmatig doorgevoerd; een en ander loopt soms fout. Sommige bindings zijn na bijwerken misschien niet meer geĆÆnstalleerd." | mail -s "OpenHAB kan bijgewerkt worden" ErikDB@mailprovider.com
fi
NEEDRESTART=$(needrestart -v)
TEZOEKENTEKSTN="Service restarts being deferred"
if [[ "$NEEDRESTART" =~ "$TEZOEKENTEKSTN" || -f /var/run/reboot-required ]]
then
echo "De computer zou normaal gezien opnieuw opgestart moeten worden." >> /home/erik/Needrestart/opnieuwopstarten.txt
reboot
fi
My, what a storm this has been. Some damage here and there, but nonetheless the rain is good for new grass to grow in the aftermath.
Having skimmed through this topic, my line of thought is that perhaps thereās an opportunity to educate newbies about Change Management. Itās very easy to download some software and just flick the button to auto update, but that is a decision in itself, and it carries consequences. And the road ahead has a lot of similar crossroads.
The IT industry has plenty of Best Practices and Good Practices, standards and certifications for doing this in a controlled, risk-adverse manner where a negative impact can quickly cause expensive losses. Those practices are not really secret, and they are proven over and over again to be the most effective and efficient to achieve a painless change. But, not everyone works in IT, not everyone is ITIL certified, not everyone even is aware that Change Management is a thing.
Plenty of enthusiasts are enjoying the journey of discovering things, but less so when that comes with bumping heads against the consequences of every poorly-researched decision. Theyāre not trained and experienced system administrators, even if running a home automation solution actually puts you into that role whether you understand it or not. Plus, laziness is very very very tempting. (Heck, even me writing all this stuff am blindly updating all Docker containers automatically. Not really eating my own food, am I?) Teaching the basics of long term maintenance would definitely set these enthusiasts on a smoother path.
So, would it make sense to put together a blog post, documentation page, whatever you think would be a good container for publishing an article with good visibility, on the basics of long term maintenance of an openHAB instance? The principles and reasons behind it, the what, why and how, options and consequences, typical watch-outs and such. Not too deep, but also not just assuming people know what theyāre doing when they start running their own server, butt naked. Iād be happy to contribute to such a document, although I migh be a bitā¦ verbose. 
the sentiment of the OP is understandable, but upgrade a whole system with an automatic tool and in a āproductionā environment without test the upgrade in a QA environment before, has no excuses.
what the project team can do to improve the compatibility and to reduce the risk of broken change
is to Test at least the official addons with the new version of OH and do a test of a sort of complex rule in all the language supported
this sure can slowly the delivery of the new release, but guarantee a more compatibility.
in case some broken change is necessary, write to the release note
then nobody can complains if something not work if is specified in the release note.
Sounds like a good first contribution for any volunteer. What ever format makes the most sense to you is fine. A forum posting has the lowest barrier to entry and it can be moved elsewhere (e.g. the docs) once itās done.
We do. Thatās what the snapshot and milestone releases are for. Anyone running these should report any problems they have to the forum and github. And thatās why thereās a feature freeze immediately prior to a release so there are no new features which might introduce new bugs.
But note that itās impossible for any one person or even a small group to test all ~400 add-ons. No one has that many accounts nor all that hardware, not all the services are fee or available world wide, etc. So itās up to the community to help test everything and report problems as they are discovered. Thatās why we have these testing versions in addition to the releases.
This is in addition to the automated testing that occurs on every build.
As a moderate user for some years I do feel the frustration OP might have felt after an automatic upgrade performed. This is a bad practice which is already mentioned in several places.
I do feel however that a āgood upgrade experienceā is something we should help users with even though Iām not sure how attainable that would be.
In general when updating to newer version I read the release notes of course, but also check if my addons are still available or need reconfiguration and if rules would still work(when updating to 4.3 I think some of the rules got updated by framework after opening and saving the rules).
I think that an advisor of sorts would help the average user determine and assess the amount of work needed post-upgrade to get to the same working state as before the upgrade. This could take shape in assessing add-ons(official, market and addons dropped in the addons folder), rules(the release notes contain mentions of changes in methods used), thing and item definitions and maybe UIs. This could then be used to inform user about the changes that need to be done after upgrading. Iām not sure if this is at all feasible and how(Iād guess this would be a function that reads the changes from some sort of release manifest), but if it is it could help all users upgrading their installations.