Fair warning if you’re a frequent visitor to the community and saw the announcement, but not for anyone else.
I sometimes wonder if we should have an opt-in mailing list that’s solely for admins to announce new releases and provide updates on myopenhab outages. I don’t think casual users should be expected to check the community regularly to keep up on things like Bintray going away.
@Artyom_Syomushkin, I’d suggest uprading to 2.5.12, so that you’re on the last fully functional release of OH2. I agree that there’s no need to move to OH3 if you’re happy with what you’ve got. There are a lot of improvements, but those only matter if you’re interested in them.
Second - even if repo disappeared I still don’t really follow why there is no archive with old/obsolete release distributions. Keeping this would allow me to install the binding manually and I would not ask this question. I still prefer to stay on 2.4.0. Could anyone share openHAB Cloud Connector addon binary for Raspberry Pi to close the topic?
Is migrating from 2.4.0 to 2.5.12 less painful than from 1.X to 2.X? That was a bit of pain - I had to redon all my items and things basically from scratch and use MQTT event bus binding from 1.X because 2.X version wasn’t available at that time.
How long 2.5.12 is going to be supported?
Not exactly your answer but I would buess moving from 2.4.- to 2.5.12 might be slightly less painful than moving to OH3 (3.1.0 gets released next week)…
With OH2.5 there were quite a few breaking changes as OH started untangling fro Eclipse SmartHome and the build system was redesigned. OH3 finished that split and removed all OH1 bindings.
If you use OH1 bindings you can use the remoteopenhab binding on OH3 to get your Items into OH3. I doubt that binding was tested with 2.4, but that might be a migration path to OH3 if the binding works against the 2.4 REST API.
Maybe you’re lucky but I wouldn’t think so.
You cannot have it all, current functionality inside an ancient installation so even if you did get hold of such a binary it would not be tested and probably not working right with the up to date code in the myopenhab cloud server.
It’s asked too much from an Open Source project (or any commercial, FWIW) to support each and every older version, particularly so for online functionality like this which is a moving target. As you called it yourself, any 2.4 distribution is obsolete so if you insist to continue running it you have to take care yourself.
I, too, would migrate to 2.5.12. If you apply the usual caution (backup, fallback path etc.) you should not encounter many issues in doing so.
Okay, if we don’t ask for support of each and every older version, can we ask then to support at least one long-living stable release? I thought that 2.4 will be that one, as was mentioned somewhere couple of years ago. Now it seems it is not. Then which one should I choose? 2.5.12, 3.x?
Anyway if myOpenhab is a moving target it makes much less sense to use it, if every time it gets updated the compatibility with older OH versions becomes broken. At least for me. I better use third party cloud with standard protocol, like MQTT, for example.
Not really, remember this is an Open Source project so someone must be willing to donate his time to this, for free.
To the best of my knowledge, there was no announcement or other reason to believe it was a LTS (long term support) version. As said there are no distinct LTS versions but the one that comes closest to this is latest before 3.x, i.e. 2.5.12.
Btw 2.4 is ~3 yrs old. Even commercial (paid) support will often cease earlier.
Any cloud service is a moving target by its nature. Home Automation itself is.
And claiming “breaks every time it gets updated” is definitely way overdone as a statement.
Note I don’t even know if it would work with 2.4. Just saying you must not expect it to.
There’s limits for technical reasons, at some stage it does not make sense to keep maintaining compatibility, and I’d say that a 3yr difference is way beyond what you may reasonably expect to work.
Note: changing to MQTT or whatever presumably ever-stable interface won’t make this problem go away. You just lift it from the protocol/syntax layer onto the semantic layer.
This is not about compatibility. The whole idea of introducing new versions is to make changes, and while it is “nice” to avoid breaking changes it is not always possible.
So we should not expect 2.5 cloud connector to work on 2.4 base. It might, it might not - have you tried yet?
You yourself have decided to change your 2.4 installation. You are quite right that you could in theory carry on using 2.4 for a long time, in the interests of stability. All good.
But now you want to change it - add a new feature. The problem is that time has marched on, the package of add-ons for 2.4 is no longer available. It probably would have remained available had not a hosting change been forced for other reasons. If only you’d downloaded it when it was current … but that’s hindsight, and doesn’t help now.
It’s a bit like expecting Ford to provide roof-bar add on accessories for older models (which is not the same “support” issue as parts that wear out).
Someone somewhere may have 2.4 addons.kar file they could share with you. I’ve just looked because I used to have it - I’ve never trusted ‘online update’ philosophy much so tend to download the whole set of offline support packages - but I’m sorry, I have no 2.4 versions at all.
It is also in interest of developers. Stable LTS release is good, when you want to start using something new for you without checking all bug reports first. Especially if this software intended to do something really serious and not just for game playing.
I would not mix terms “released” and “got useful”. My migration to 2.4 is quite well documented here: Migration from 1.8 to newest(stable) OpenHAB release
It was August 2019 - and 2.4 was latest stable release at that time and I still had to use 1.X MQTT binding. Not sure if it’s better now.
Nevertheless I don’t ask supporters to donate their time for free. There is an Openhab Foundation to which at least I donate some money every month as long as I use OpenHAB. I thought one of the tasks of the Foundation is to maintain release binaries, as providedhere in third bullet point. But it looks like that this goal is forgotten together with bintray.com link…
Not exactly. The foundation pays for the hosting and build infrastructure but they cannot pay any people in addition to that to provide this huge amount of support you are expecting.
FWIW for what the foundation provides you for free, others charge you 5,-€ a month.
The page you quote doesn’t state that “goal” or your interpretation. And the foundation delivers on its promises: it does not only provide the current (3.0) version but also the last major version (2.5).
It does nowhere promise to provide all releases for all times, does it?
And 2.5 is compatible with 2.4 so no reason to insist on staying with and getting support for 2.4.
You deliberately decided to stay on a 3 (not 4, sorry typo) yr old software without keeping a copy of the binaries, now come on you must not blame anyone else but yourself for not keeping/providing them.
And if there hadn’t been this unfortunate bintray disaster, older binaries would still have been available, too.
No, but neither the phrase “Maintaining the build server and the repositories of release binaries” promises what you say - binaries for current release and binaries for last major version. Why not just last stable release?
So basically it is the question of interpretation, right? Or how it better sounds for developer depending on current situation, right? If bintray would still be there, you would say - “Look, foundation delivers on its promises and provides you binaries for releases 3.0, 2.5, 2.4, 1.9 etc. But you stayed on 1.8. So it’s your problem”.
Yes, sure. I blame myself too and next time will do it differently. But I’m also leading a FW developer team and in this situation I would not protect myself and say that “user is stupid, cause he was sitting on 3 year old SW and did not keep the copy of binaries”, while this requirement wasn’t mentioned anywhere in the documentation and my binary server just died and I did nothing about it.
Oh come on, you’re a professional. Need to be told?
Falling in this hole makes you unlucky, not an idiot.
That didn’t happen. It did happen all in a rush, could have been better planned, but a conscious decision was made to limit replacement provision to last OH2 version.
The decision was to your disadvantage.
“You didn’t complain at the time!” would be just as silly a position for everyone else to take.
Again, your 2.4 installation is not out of service or at risk of total loss - you do take backups, right?
Your problem is that you now wish to change it, enhance it.
It is what it is, you’ve a number of paths forward from here.