I’m a little embarrased. I’ve invested hundreds of hours I think over the years in setting up my OpenHAB installation, which is now consisting of a main server (2.5.12) and 8 Raspberry Pis across the house, garage and garden to provide reasonable Z-Wave experience.
The communication was established through the MQTT protocol using EventBus which made it damn easy to have everything work within a reasonable time.
However, lately one of my Raspberry’s broke and I realize how hard and what a hassle it is to get things set up again with OpenHAB 2. Time back I remember when there were complains on MQTT 2 binding, that the authors were either rather rude or some said “it’ll continue to work as is - don’t worry”. But there was never a sustainable solution which wouldn’t mean I have to reinvest a huge amount of time.
Now it seems that I might have to even switch top OpenHAB 3 in order to be able to have my stuff run the next couple of years. And there’s the crux: if I have to invest a lot of time in order to get to a new version, the hurdle to check other solutions is far lower. And I am tempted to give others a try and especially look at the criteria “backward compatibility” and sustainability. Because the smart home stuff is not a hobby, it’s something I expect to work reliably and for years without the need to touch it every now and then.
Thus my question is: has there been anything in OpenHAB3 incorporated, that works like the old EventBus via MQTT, such that I can slowly start upgrading to OpenHAB3 and can have a heterogeneous landscape of OpenHAB2 and 3 systems?
There is absolutely no reason to be embarrased. If you are talking about such huge amount of time and effort invested in your smart home, so where is your backup ???
If your main raspberry broke, it qould be fairly easy to get a new SD-Card flashed with your backup and you would be up and runnning within minutes.
You don’t have a backup ?. Sorry, but don’t blame openHAB for not taking the time to make a backup.
This remains true.
(of course one day you may want/need to change the “as-is” e.g. add some new hardware.)
Changing versions or products will not fix this difficulty.
@hmerk has identified the obvious solution to the apparent issue - have adequate backups. And to that I suppose we should add, to know how to use them when disaster strikes.
Given your investment of time and large number of systems involved, perhaps the most sensible thing would be to buy another Pi (they’ll stop making that model one day) and practice doing a disaster restore of a ‘real’ system. If you have some kind of master/slave arrangement, do one of each type. If you have vital peripherals (e.g. zwave stick) add that in. Document for yourself what to do. End up with both practice and spare hardware to hand, and a how-to that you understand.
I wholly agree with everything everyone else has said. If you want a home automation system “to work reliably and for years without the need to touch it every now and then” you must have backups and you you must never change anything, "ever*. Not updates. No upgrades to OH nor the operating system. And even that isn’t fool proof since if you rely on anything external that interface may change and break you system without your doing a thing.
And of course you need to somehow mitigate the fact that you will be running outdated, critically venerable, and no longer supported software.
Personally, I think that expectation for any computer based system is unreasonable.
As for the things not addressed in your original post by others.
I’m assuming that you are using the MQTT 1.x binding. No 1.x bindings are supported in OH 3. Ultimately you will have to either stick with OH 2 or move to the newer and still supported MQTT binding.
Assuming all the clients publishing and subscribing to the MQTT EventBus are openHAB instances, the already mentioned Remote openHAB binding is super simple to set up and use.
There is also a way to set up an MQTT EventBus with about a dozen lines of code, and it’s code you don’t even need to write. I was waiting put publish them to the marketplace but if there is a request I can publish them in a day or two. With this there is a little bit of configuration (create a broker thing and a subscription to the root of the EventBus topics) and installation three rules. If all you are using is the EventBus feature of the 1.x binding, this too is super simple to set up though it’s a little complex conceptually to avoid infinite loops.
As for looking elsewhere, I don’t think there are too many options. I know some users move to openHAB because it’s more stable and more backwards compatible than the system they were using. The home automation space is simply too dynamic, full of too many walled gardens, and contains too many continually growing standards to support “set it and forget it”.
That is not an unreasonable idea, none of us here will blame you, report back you findings if you go that route. As Rich said, the other popular choices have a reputation of being even less backwards compatible and break more often.
Well, if that was your expectation when you installed openHAB, maybe you didn’t read the Introduction in the documentation which states
Lastly, be prepared to start a new hobby: home automation.
