I am sorry to bother you with some general issues I have with openhab. Four years ago, I set up openhab1 on a dedicated PC and connected power meters (directly assembled to the fuse-box), power sockets, about 25 Hue bulbs, Temperature sensors, Multi-Room-Audio, call monitors and 5 wallmounted tablet-computers (to replace(!) physical light switches) and much more to it. I did this with the assumption, that as a home automation solution, this will work stable for literally YEARs.
Four years later, I try to move the openhab (1.8.3) setup to a raspberry pi 4 because of energy savings. And I fail even with downloading the old 1.8.3-Version. APT-repositories are broken. No “old releases” or “Archive”-Section on the download page. No ARM64-Support for old releases. Nothing. I played around with Openhab2 which is - no question - a huge improvement in usability and assisted setup. But it entirely breaks any development, I made against the 1.8-API. Weeks of initial configuration work and years of improving single aspects of the setup are now useless. I have no Option to migrate my openhab1 configuration and item names (and therefore all the API keys which are used in thousands of lines of code in my own scripts) to openhab2 without literally configure it all by hand and manually item by item.
I would consider doing this work, but now I see a openhab3 version announced on the downloads page. May I expect to do all this work again in 3 years?
Why can’t I see anyone having issues with that? Is every openhab user literally all the time working on configuration, updating and playing around with that software? Does nobody consider this piece of software as critical in terms of stable, endurable and operated for years? What, if a non-tech person has to maintain this? I consider openhab as critical as a classical light switch. If it was installed properly, there shoud be no need to reconfigure or upgrade this thing until it gets pulled out of the wall in 30 years. If I decide to change the switch, I should not have to pull all cables out of the wall and rebuild the entire wall because of “we broke all compatibilty with your shit by our new Light switch”-Issues. How do you handle this?
OpenHAB2 had some backward compatibility with OH1 to easy the migration. It is still the current stable version but, as you noticed, the next version will be openHAB3 which is incompatible with v1 bindings.
Any bindings that have not been updated will get dropped from support. Many have been abandoned by their developers.
But aren’t you the one choosing to “reconfigure” and “upgrade” your setup, by moving to a new device? If it ain’t broke, don’t fix it.
The above isn’t very useful to you, I realise. openHAB has moved on a lot since V1 - I’ll be surprised if you get V1 working on a Pi4. However, if you’re worried about having to move to V3, just wait until 2021 when V3 is properly released, then you only need to “upgrade” once.
As @Bruce_Osborne says though: some bindings that your rely on may completely disappear in V3, which may add more pain. Check this issue for more information:
OH3 will be incompatible with OH1 bindings but will include a new binding allowing to easily work with a remote OH2 server. So you will be able to keep a running OH2 server for your old OH1 bindings and control this OH2 server from s new OH3 server.
If you properly search the forum you will find a number of people including myself that had issues - big ones even - when they needed to migrate from OH1 to OH2, and there were quite some discussions with similar questions being asked, see e.g. this thread.
You will be seeing no or just few more users nowadays because they all have migrated since.
The bottom line is a migration is inevitable at some point in time.
You must not expect OH (or any software) on the one hand side to not change any API and on the other hand side to stay up to date with hardware, OS, devices and services that all keep changing in a rapidly changing world.
To answer - and sorry to be straight here - you expect too much. You expect even more from a volunteers-driven OSS than you could reasonably expect to get from commercial software today.
Others had big issues in migrating, too, but they accept this as a matter of fact.
Add to that a kind of unfortunate timing and decision taking: when you started, OH2 had already become available and you could have started with that right away. And I truely wonder why you raise those questions NOW, four years later - that’s four years that you could have been observing openHAB development.
Ask yourself: it’s you who wouldn’t have needed to but wanted to upgrade.
And speaking in general: sorry again for being straight but this is where you are plain wrong.
Software is not hardware. Software keeps changing because it must change. One of the reasons is that the environment changes. To support new devices. Or to reduce energy consumption like you want to. Or to fix problems and security issues.
But some traditionalists (like some electrical engineers) seem to still be fighting with that insight.
There’s breaking changes in every software release (I don’t speak of OH here), and there will be breaking changes in OH3.
Then again those will not be as severe as it was with OH1/2 as the API essentially won’t change.
Take your time to setup a new system in parallel but start today. There is a migration guide from OH1 to OH2 which you should walk through, no matter if you target OH2 or right away OH3.
thanks for your sophisticated reply. I am totally aware, that it is a very difficult task to maintain software over a very long period of time to be stable, compatible and secure but innovative. I wouldn’t expect this from any open source software for “rapidly changing envionments”. But as we talk about home automation systems, which are very deeply integrated within lasting infrastructure by design, I would have expected this aspect to have a higher priority within development.
For Example, take a Mailserver software like Postfix. Mail and SMTP has changed heavily over the last 15, 20 years. Spam-Fighting, Authentication, Encryption, Domain-Keys, SPF and all that are on-top-developments on a protocol, which is 40 (!) years old. But a postfix server configuration from 2008 is still operational on latest hardware and latest operating systems along with the latests Postfix release. And here we talk about software which is exposed to the public internet.
I would have expected - and probably I have expected too much - Openhab development would have taken into consideration, that once a Setup (Software + configuration, not necessarily the hardware) has been deployed, it may be operated for probably decades. I am okay with the issue, that later software releases support newer hardware and newer bindings. But the existing ones should be maintained or even be available for longer than 4 years. I would be happy with a downloadable .DEB-archive of the version 1.8.3, but I cannot find one anywhere. As the software is written in JAVA, I even can’t see an issue with changing environments, as JAVA is available on i386, amd64, armhf and aarch64. It would simply cost an additional download link or trying to keep the package repositories working over the years, which is - by my high expectations - the minimum requirement for software which is that deeply integrated in long-lasting infrastructure like power-sockets, bulbs or metering-hardware.
With rapidly changing standards and technological advances. Feel; free to go back to wax candles for lighting if you want stability
Part of the reason to drop OH1 compatibility was that Kai was the only maintainer because nobody else saw the compatibility layer as a priority. He decided maintenance of that was not worth the future benefit. Users have already had ample time ( 4 years?) to migrate to a newer architecture.
In software major version numbers, many times break backward compatibility. You cannot run the Microsoft Word version for Windows 1.0 natively on Windows 10.
The environment I refer to is not just the building … it’s the building but also the state of arts in server HW, OS, Internet services and IoT components, and that is changing rapidly.
I think your comparison falls short. To stay close, you would rather need to compare the operation of a mail service. And we’ve seen sendmail, qmail, exim, postfix in these years. And you must not compare a single RFC application protocol (or two if you take DNS in, too) to an internal API that needs to work as an abstraction layer to hundreds of protocols. Do you know how many API changes there have been in sendmail alone ? Life is change and progress. You’re talking to someone who built his first mail servers using handmadesendmail.cf.
As I said already you cannot even expect that from commercial software.
Let alone from a community of volunteers to spend their spare time.
Nope. Maintenance is much much more work than just to keep up a download repo (and as an openHABian maintainer I know what I’m talking about).
Current OH can do anything 1.8.3 can so it supports all of your “long-lasting infrastructure”.
That’s not what you want. You want a static API. You want us to forward-port an old API that has been abandoned because it couldn’t serve many modern needs which is why we have a new one. That’s a completely different story both in terms of expectations and efforts involved.
And nowhere near the effort you would need to spend on migration. And yes: been there, done that.
That’s disappointing.
I do sympathise, as I do still tend an OH1 system running a live environment.
Cunningly I have a copy of the download … but I do not think it will help you.
It’s been a while, but I think the operating system changes required changes even for OH2 to run on that platform. Practical deduction, no chance with OH1.
Your alternative is paying for validation costs, as well as redevelopment. That’s not something we do much in home automation. Aircraft industry offers parallels, changing the spec of a half-euro bolt has large knock on costs.
Recently I read about them to exchange some missile control system by a “modern” one that has an USB interface… the old one used 8" floppy disks that had started to crumble mechanically.
(and thinking of SD wearout, now they crumble electrically).
