Until such time as this particular problem is solved, OH 1 would be the one hitting the metal since for zwave it’s the only one that works. Then you can go focus on other stuff, get some wins under your belt and make some progress. Only when you are trying to solve this zwave problem on OH 3 would you need to turn off the OH 1 instance.
Yes, but not a big step. All you’ll have to do is change the links on the Items from the MQTT Things to the Zwave Things. Once it works you can remove the MQTT Things. Or you can have two sets of the Items in OH 3, and once you get it sorted eliminate the MQTT ones. Though that would mean different names which will have impacts on the sitemap and rules and such.
Stage 1 would look something like:
OH 1 continues chugging along with the zwave stuff and anything else you haven’t moved over to OH 3 yet. Then as stuff moves over you remove the links from the Generic MQTT Things and link the Items to the Things from the actual bindings. At that point OH 3 has taken over for OH 1 at that point.
A flow would be something like the following.
- Someone physically flips the zwave switch
- OH 1.x gets that event and updates Item1.
- The MQTT event bus publishes that update to a well known topic for Item1.
- OH 3’s MQTT configuration subscribes to the topic and based on the topic path determines it’s an update (as opposed to a command) for Item1 and updates Item1 accordingly.
Note that step 4 sounds complex but it’s just a few lines of rule code really.
The flow in the other direction would be something like the following.
- In OH 3 something sends a command to Item1
- The MQTT Binding publishes the command to the well known topic for Item1 commands (updates and commands go to different topics).
- The MQTT eventbus config in the MQTT 1 binding sees the command on the topic and commands Item1 with the published command.
This will let you do all sorts of configuration in OH 3 such as creating the UI, porting rules, sitemaps, etc. without needing to take OH 1 offline. OH 1 only needs to be offline when you are testing or migrating a piece of shared hardware to OH 3.
You won’t be able to get away from ever stopping OH, but you will be able to do the bulk of the work while OH 1 continues running.
And while I showed the arrows as two directional, you could make them unidirectional (i.e. OH 3 gets the changes from OH 1 but commands and updates from OH 3 do not go back to OH 1).
And of course, if you need help with any of this sort of stuff, just ask and I or anyone else will be happy to help you debug and get things working.