I’m in the middle of migrating from OH 2.x to OH 3.x and I’m ready to start the zWave migration.
Both OH versions are running on 2 different platforms and aren’t talking to each at all. I have my zWave stick mirrored to another zWave stick so they are identical.
Can I run both zWave sticks at the same time and will both systems work with the zWave chatter back/forth between all the devices?
I’m not clear if zWave devices work like TCP which handshaking takes places between each broadcast or not? Ideally, I don’t want to have issues with my OH 2.x side of things until 3.x side is fully functionality.
I’m far from expert in Zwave but I would doubt that you can have two primary controllers running on the same network at the same time. There is such a concept of primary and secondary controllers on one network but the two won’t work the same. For example, the secondary controller cannot add devices and the primary controller is the only one allowed to route more than one device directly.
The takeaway here is that you cannot just clone your OH 2’s Zwave controller and have both running at the same time. You’ll need to configure your OH 3 controller as a secondary one and add it as a device to your primary controller.
That might work. But it also might now work because the binding uses information stored on the controller to know which devices are on the mesh network. I don’t know if that information is available on the secondary controller.
Not, it’s UDP like fire and forget. A device broadcasts a message and if it’s not close enough to the controller that message is routed through the mesh of mains powered devices until it reaches the controller. There are no transactions or handshakes or anything like that.
I think your best bet is to do periods or processing. Turn off Zwave on the OH 2 side, move the controller (or use the cloned controller) while developing OH 3. When done for the day, turn it off on OH 3 and reenable the one on OH 2 until you are done.
There is a caveat with securely included devices, though. The key for securing the communication is stored in the configuration of OH, not on the controller. If there are securely included devices, the key needs to be the same in both OH installations.
You will find the key in the configuration parameters of your Z-Wave controller in the GUI as “Network Security Key” (tick the “Show advanced” box to make it visible).
I have a related problem – it matches the topic headline exactly even though the situation is different.
I have built a new bigger house next to my small house. Both houses are staying. The small house uses Z-wave, the main house won’t. (I didn’t know better back then!)
Right now OpenHAB 2.5 is running happily on the old RPi3b controlling things in the small house, while I’m struggling to get OpenHAB 3.x to do anything at all.
In the future, I will be moving more and more things to OH3 which will be running in the new house… but I can’t move the Z-Wave stick because the signal from OH3 in the main house will not reach the Z-wave devices in small house.
I also don’t think it would be a good idea to try to upgrade that system from OH2.5 to OH3 because it seems far too many things have changed under the hood for that to be viable.
I think perhaps it’s best to leave the OH2.5 system alone is it is. There are probably only 10 Z-Wave-based items in the OH2.5 system that I will eventually want to also be able to control from OH3.
So my question is:
What’s the best way to link those OH2.5 Z-wave items into OH3?
Is there an OH specific way to do it? Should I just script and use MQTT? Thoughts?
I’m hearing this is suppose to do what your asking. I personally haven’t used it but others have on the forum.
Agreed with the changes with OH 3.x. Been at it daily since Nov 7th. Getting closer and feeling alot better about OH 3.x everyday. Its diffently a much better platform than 2.x I’m seeing daily.
Almost all of the stuff that has been changed are additions. For the most part OH 3 is just OH 2 with stuff added. The primary exceptions are:
PaperUI is replaced with MainUI
A few breaking changes in rules, namely executeCommandLine and the replacement of Joda DateTime with ZonedDateTime
System started triggered rule won’t run when you merely save a .rules file but only when the system has started (i.e. on a restart of OH).
there are various breaking changes and changes in behavior in individual bindings but not the Zwave binding.
there is a different version of the Helper Libraries that need to be used if rules are written in Jython.
Pretty much everything else that is different is handled by the upgrade script (i.e. apt if running on an RPi). Of course how much the above changes impact you will vary from user to user. Some users won’t notice at all, other will need to modify each and every one of their rules.
Many, if not most of the people who have been around for a bit and are running OH 3 upgraded in this way.
But obviously that means that once upgraded your config won’t take advantage of any of the new OH 3 stuff, but who would expect that in the first place?
This is not to say that I’m advocating that you upgrade, just that the option to upgrade is very feasible and reasonable.
There is a Remote openHAB add-on that will link the two instances.
If you are running a recent milestone of OH 3.2 (M3 or later I think) there is the Marketplace where you can install the MQTT Event Bus rule templates (see Marketplace MQTT Event Bus). Of course you can just use the code to manually create rules also but why go through that if you can just install the template and instantiate the rules, no code involved.
If you have moved to HABApp there is an MQTT Event Bus implementation built on that too, though it looks way more complicated to install and configure.
You can use socat and ser2net to run your zwave controller and connect it to your one OH 3 instance over the network.
Okay, that is interesting. I clonezilla’d my entire RPi3b OH2.5 SSD and then actually did try to upgrade through openhabian-config. I ran into some issues with certificates having expired and missing repositories – I didn’t make a note of the exact messages but I did spend some time googling the error messages and attempted to follow what others had done in response to the same error messages, but realized after a couple of hours that I was in over my head, and restored the image.
I can still try again at some point though (thank god for backups!) but I really like the idea of the Remote openHAB add-on. If that is able to link OH 2.5 items into OH 3.2 then I will probably just keep OH 2.5 as is, since I’m unlikely to add more things to that installation anyway. The only things I’ve added to OH 2.5 lately are things that are really in the new house and really should be in the new OH 3.2 system
I just managed to make a couple of custom widgets!!
That’s probably something that would have been worth mentioning on the forum or filing an issue with openHABian. I personally know fo dozens who have upgrade that way successfully. And given it was certificate problems they might have been intermittent. Also, if you tried to do it while Amazoin had their outage this week you might have run into services that were down because of that.
Without details I can only speculate except to say that it should work and has been known to work.
OK, now the next step which blew my mind away when I started figuring this stuff out (you may have already done this but just in case you haven’t).
Move that widget to a Custom Widget with properties if you haven’t. Then for each of your Items modify the Item’s metadata to use the custom widget as the “Default Standalone Widget” (in this case). Go and create another custom widget for the List Item and set that as the custom widget.
Once you’ve done that every time you add that Item to MainUI in a layout page, it will use your custom widget automatically. If the Item is a part of the semantic model, MainUI will use the default list Item widget to show the Item on the Locations, Equipment, and Properties tabs.
And at least for the semantic model driven parts of MainUI, if you go and change the custom widget, it will change for every Item that is configure to use it automatically. Unfortunately on your layout pages you have to remove and readd the Item to pick up the changes.
One really powerful use of this is to create a complicated custom widget that represents the whole device, for example a Chromecast. That widget will show and allow control of all the various parts of the Chromecast in a unified widget. Now make that unified widget be the Default Standalone Widget for the Equipment Group Item that represents that device. Now you can just drop the whole Equipment on your layout page in one go.
A number of really powerful and well designed widgets like this are available on the Marketplace.
Amazon outage! I didn’t even think to connect the two occurances. You’re totally right, it’s possible this affected it too. I will try it again. I can try on another pi with another SSD and the same clone image I made then.
jwiseman
(Mr. Wiseman (OH 4.2 Snapshot on Pi4))
11
The RING binding was/is affected by this currently.
