I’ll follow along, I’m about to do the same thing.
What’s confuse me is the Backup of all my Things in 2.5, a backup for me is the system right?
If I restore my backup… won’t I reload all my 2.5 system?
Pascal
A good idea but not strictly necessary. Moving the stick from one machine to the next is low risk.
Note this only captures the OH configs. It does not capture the Grafana and InfluxDB configs and data.
No, you can only restore a config to the same version of OH. So initially install 2.5, restore, then upgrade to 3.4.
Note, you’re looking at over two years worth of development on OH. You will have to make changes to your config after the upgrade. There were many breaking changes.
Yes, most of the information is on the stick itself. However, if you need to delete and recreate the Things for some reason, make note of the inclusion security key and set it to the same or else you’ll need to securely reinclude your devices that were securely included in the first place.
No, any changes you’ve made to the system outside of openHAB is not captured given the steps you’ve outlined above. You’ll have to move those over yourself.
No, that’s part of the openHAB config that was captured in the backup.
Probably, but there are options in openHABian for that. But you’ll lose all your old data and configs. If you want to keep those you’ll have to look at how to do that for those services specifically.
Most who migrated successfully even between 2.5 to 3.0 ended up doing it little by little instead of all at once. In the long run, you will probably have an easier time of it and spend less time in the long run if you move things over to the new RPi little by little. It’s a whole lot easier to debug a single binding or a single rule than everything going wrong all at once.
It probably too late to consider but OH3 has the remote server option that allows for the suggested approach. Basically 1) install a fresh OH3 on the Rpi4. 2) Install the remote server binding to the 2.5 instance 3) copy all the items exactly from the 2.5.12 instance to the 3.4.2 instance. 4) link all the remote server channels to the OH3.4.2 items. Now you have two nearly identical instances. At your convenience you can set up charts, and familiarize yourself with OH3, migrate rules (only have one running at the same time), set-up persistence, etc. Once you are satisfied you can move the z-stick as described above to the new instance. You will have to link all the channels of the OH3 things and remove the remote server links.
For me, I originally intended to retire the RPi3, but now have both running at opposite corners of the house for zwave responsiveness (and some testing). Did buy a new zstick. All the rules, cameras binding, charts and 35+ zwave nodes are on the Rpi4. I almost exclusively use the Rpi4 UI. The Rpi3 just has about 25 zwave nodes connected via the remote server (but I did upgrade to 3.x along the way)
I’m on OH 2.5.12 too. As I understood it is not possible to backup OH 2.5.12 install OH 3.4.2 and restore the data. Only way to update is an inplace update using the normal update method for Linux or Windows.
If I do that inplace update:
I need to update java to version 11.
I need to fix breaking changes in DSL rules (mostly the date/time syntax change)
All former installed bindings will be installed automatically and existing config of each binding will be used
All things definition should be there after update?
This means z-ware things definition are there too and no need to enter security key for USB-Stick again?
All configuration made inside of the z-ware things are there again (configuration parameters, device command poll period, …)
Sorry for asking this, at the moment I have a very stable OH 2.5.12 and need to update due to new z-ware devices not supported by 2.5.12.
Hmm, sounds complicated anyway. If I could compromise on HABPanel and my Matrix Theme and take Grafana and InfluxDB out of the scope… than
If I could
keep OH2 running on the old RPi
establish completely new Openhab server on RPi4 (from scratch)
switch Aeotec Zwave Stick between Oh2 and Oh3 (for stepwise migration process)
would all stored Things be recognised in a new OH3? I assume yes.
in this case i could:
Create a new haus structure (map)
Assign recognised things to the new haus structure
Create/copy all necessary/old rules
slowly bring up a new OH3 on the RPi4
It would have few advantages (beside learning experience), i could have clear, nice ready for further development home automation system.
Working with OH3 and than switching ZWave Stick between OH2 and OH3 shall not disturb running OH2 system right?
I can always come back to OH2 with the stick and everything works, fine. Or is there anything in the configuration of the Oh3 that would influence ZWave network and missfunction the OH2 system?
Unless you have 1.x version bindings in which case you’ll need to migrate those configs to the 2.x/3.x version of the binding that uses Things.
Yes, but check the breaking changes for each individual binding. Some require the deletion and recreation of Things.
Correct, unless you need to recreate those Things. I don’t remember if that was one of the bindings that required that. It’s been over two years since I migrated and even now I’m already on OH 4.
Yes, same as above.
I don’t know what this means.
I’ll say it again. You cannot restore a 2.5 backup on a 3.x server. So what “stored Things” are you talking about here?
Note, the vast majority of Things are automatically discovered and created. So it’s often easiest to just rediscover the Things on the new OH 3 instance than it is to try to copy from the 2.5 to the 3.x. In the rest of the case, check the breaking changes for the binding in question to see if the old Things are compatible with OH 3. Or just recreate those Things in OH 3.
Well, you probably don’t want to yank the stick from OH 2 while OH 2 is running. But otherwise, those Things will just be OFFLINE in 2.5 when the stick isn’t present. Nothing gets changed on the stick by the binding as far as I know.
I was not precise. “stored things” I ment all of the z-wave components in 2.5 system. Since they are “stored” on the ZWave stick the new OH3 shall see them when the stick is connected to the new RPi.
So when I configure fresh and new PRi with Oh3 and connect my Zwave USB stick (controller), openhabian will see them on the list. I can add one after another and configure step-wise new OH3.
Any time i can shutdown RP4 and connect ZWave controller back to the old Oh2 having full functionality.
Things are a concept that only exists in openHAB. There is no such thing as a Thing in Zwave. The Zwave controller stores a bunch of information about the Zwave network and it’s nodes and when auto-discovery takes place, OH creates Things based on that information.
ahhhh! First problems.
I use AEOTEC USB Z-wave stick 5Gen and it is not being recognised by the OH3 on RPi 4. I read this post and find out there are problems with the compatibility
it is not even recognised after connecting to the usb slot so i assume it needs to be connected over the hub. I do not want to go this way. It means I have to migrate with every singe z-wave node to the new system.
How you plug in the zwave controller changes nothing. Either you’d have to do this anyway no matter what, or you never have to. All the USB hub provides is cleaner power to the controller.
I am afraid your are right. I do not want to have usb hub as of now. for me it is important to have clean, stable and reliable home automation system. With OH2 I have been learning. With OH3 I need to clean up this what was not properly done before.
I created new post to gather user experience.
Replace your Z-Wave controller (note that series 700 Z-Wave controllers are not supported by the Z-Wave Binding, series 700 Z-Wave devices (i.e. non-controllers) are supported).
Not an expert, but I have always seen the aeotec come up as ttyACM0 on both Rpi3 and Rpi4. Usually ttyAMA0 means there is a problem. Should be a quick try. Just change the port and wait 30 seconds. If not, then it is something else.
