Obviously I did mean to run the same setup. Not literally the same hardware. 
Regards,
Sebastian
Who do you know running Windows 3 as their regular OS then?
The corrigator that I work on sometimes runs windows 3.11. Old siemens s5 unsupported.
1 Like
That is my point you are not running Windows 3.11 on new hardware.
1 Like
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.
It did and still does, doesn’t it.
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.
3 Likes
Hi Markus,
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.
Regards,
Sebastian
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 handmade sendmail.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.
1 Like
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.
1 Like
Docker? You would need to create the image yourself though.
Official containers started at 2.2.0-snapshot 3 years ago
off topic -
You’ve no idea what the military do 
Unfortunately, WE as taxpayers end up paying for the support too 
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.
1 Like
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).
1 Like
Next step is for the medium to crumble physically
You can still find these downloads here:
https://dl.bintray.com/openhab/mvn/org/openhab/distribution/1.8.3/
There’s also a Docker image for 1.8.3 you can use (even an ARM64 one), see:
2 Likes
I’m not going to address most of what has already been addressed. But I will answer the “What are you doing?” part.
-
I don’t expect software to remain static. I expect it to be constantly changing and many of those changes are going to be breaking.
-
openHAB integrates with a lot of external stuff that might change without our even being involved. APIs close down or modified. Recently Amazon changed something for Alexa that uncovered a memory leak in OH code.
-
The comparison of openHAB configs to sendmail configs is not an apt one. When you configure openHAB you are building software. You are not turning on/off some configuratio switches, you are building a fully fledged application. As such, see the first bullet, software is always changing.
-
It is dangerous to continue to run old software. There are many many known vulnerabilities in all old software. This forces you to remain vulnerable or upgrade.
-
If you upgrade early and often, the amount of work gets spread out over time to the point where it becomes almost nothing. For example, if one sticks with the milestone releases once a month, there might be 10 minutes worth of work if there is a minor breaking change. However, if you wait years between upgrades, you are likely going to have to all but start over from scratch. So I upgrade very frequently. Most of the time nothing goes wrong and and all is good. Rarely just one thing will go wrong and its relatively easy to research and solve it. If I wait a long time to upgrade though, there will be so many changes and so many breaking changes that it becomes a herculean effort to figure out what changed and how to fix it.
So in short, I don’t have unrealistic expectations from any software based device. Most especially not for software built and maintained by volunteers. The choice is either never change anything (moving to a new machine is a change, as is updating the OS or JVM or anything else) in which case you are better off using microcontrollers instead of openHAB, or understand that the openHAB system is going to take some maintenance time constantly and forever. There really is no middle ground. And the same applies for commercial home automation systems like SmartThings as well.
3 Likes
I stand corrected. Thanks.
Well, thanks all for your thoughts. Obviously, my expectations didn’t match with the scope of this project. I wasn’t aware, that the approach of most of you is indeed to regulary keep the software updated and fix minor issues caused by the update immediately. My approach was to set this thing up once and run it untouched as long as it fits the needs. Of course I didn’t expect new features or bindings to be backported to outdated versions, but keeping the old versions running. Thought wrong. I will reconsider my options in migrating to OH2 or OH3 or give the docker thing a try (Thank you very much for this hint, I didn’t see it while searching for LXC solutions :-/ ).
Nevertheless thank you very much for the work on this project. It did its job very well over the years and I’m sure I find a solution to continue using it in the future. With adjusted expectations to backwards compatibility 
Regards,
Sebastian
2 Likes