Upgrade of old install 2.4 ----> 2.5

Hi all,
I have one massive deployment that is still running 2.4 (if it ain’t broken do not touch it, approach)
But now I need to integrate to it some LoRa devices that have confusing MQTT API and I desperately need to do transformationPatternOut= in the thing setup.

I found out somewhere here that it is only supported from 2.5 onwards.

I’m not ready to upgrade that to 3.xx as probably that would cause massive problems with all the rules. but an upgrade to the 2.5 should be quite smooth. should it?

That is and Openhabian install running on the Ubuntu and the repos that it used are not there anymore.
What would be the way to do that upgrade manualy? can someone give me a hint on how to procede?


Are you using the mqtt2 Binding yet? I’m pretty sure that’s required (more than upgrading to 2.5 completely).

The upgrade should not be too hard, but the only option is 2.5.12, no other version is available anymore.

Please be aware that OH3 is about to be cut off, the successor will be OH4.0 (maybe next month?), then there will be no chance to do an upgrade to OH3 any longer and you will face even more problems while upgrade.

As I myself had some hard time by getting from OH1 to OH2 and after some struggling a relative flawless upgrade from OH2 to OH3 (I first got rid of all OH1 bindings, even http - there was a http2 Binding at some point as a beta version)… don’t wait too long.
Rules are easy to convert after getting some basics about Joda Time vs. JavaTime. That’s more or less the only complex part about upgrade from OH2 to OH3 (and you can use search & exchange for some parts)

Thank you for your input. I have a number of the OH installs that I manage and they are in versions ranging from 2.4 to 3.4 for many reasons. My house is on 2.4 as I have 60 lights based on the Tinkerforge relays/sensors that ended development on the OH1 binding.

I have university campus running 2.5 as they have super complicated auto generated thermostat rules (over 60kb of file) that probably would break after 3.x and will take 2 weeks to debug, and noone is willing to pay for that… :slight_smile:

One think that troubles me is that you are planning to disable the option to upgrade to 3.x as a part of 4.x rollout. Since so many of the OH system are built once and forgotten until 5y later they break. A solid repo with all the old versions and ability to do step by step upgrades would be most welcome if not a requirement for a wider adoption of the OH.


1 Like

2.4 actually is kind of broken, and has been for over two years. Same goes for 2.5.

Fixes were only applied to OH3. I’d guess that your 2.x installations should be relatively safe if they can’t connect to the Internet, but I’d be concerned about something critical to a university having a known exploit.

I’m actually a bit surprised that a university allowed a relatively unstable open-source software to be used in such a way–the university I work at would deem it to be far too risky.

End users assume all responsibility for the OH systems they deploy. So, I think it’s the administrator’s responsibility to proactively maintain the system and not forget about it for five years. Otherwise, things like the log4j2 vulnerability go unnoticed.

At the same time, I understand that there are competing priorities. That’s why I mention the log4j2 vulnerability whenever someone says they’re still on OH2–I’m just giving a reason for the upgrade to be worth the effort.

I don’t know what it takes to build and maintain repos, so I can’t comment on that.

I will note that “wider adoption” isn’t a strong motivation, because we’re not competing with anyone. It’s open-source software maintained by volunteers, not a commercial business.

1 Like

Well that’s not quite right, you will keep having access to OH3 binaries so you will still be able to upgrade 2.x → 3.
Maybe that takes away your worries.

Generally speaking, however,
That’s only a wish risen every now and then (mostly when there’s new major releases) from people that are affected but those already are OH users. And no this would not help OH adoption.
Maintaining old code including distribution mechanics is just major efforts that the volunteers of the OH project cannot provide. Besides it’s anyone’s own responsibility to keep copies of the software they’re using available for replacement, maintenance etc.
As it’s anyone’s own responsibility to upgrade in time if they want to keep benefitting from ongoing OH development.
So even if there had been a need to migrate, expecting users to do a major upgrade by the time the next major release is due available is already a fairly generous approach, with OH 3/4 that was about 2,5 years. Don’t expect unpaid volunteers to keep maintaining software that’s older than this.