Would it make sense to swap these two steps? Deleting Things after the binding is uninstalled is possible, but IIRC, you might need to do an extra step (i.e. force removal) for each Thing deletion. Then again, this might’ve changed at some point, and it might now work like this anymore.
Edit: Also, as a housecleaning step, you could choose to remove the node.xml files from the userdata/zwave directory after uninstalling the binding.
Edit2: Also, should we remind people to (optionally) manually wake up their battery-powered devices in order to speed up the initialization process.
All good suggestions. I’ve never worked with the development version of the binding so I can’t answer what is most appropriate. I’ll make the recommended updates above.
any suggestion for people using openhabian and option 02 (Upgrade system)? From what build release we need to perform what mentioned above (from Rich step n.2)?
@chris: will be available the opportunity to backup the zwave db in the stick?
2.3 should be fine and the process should be the same.
Not through OH at this time, but I don’t see why you need to do this. The stick doesn’t contain much information about devices - the binding will get all this from the devices themselves. The stick only stores a small amount of information, and this will not be touched.
So I’m on 2.4.0 Build #1351, I presume the new binding is already there? Or do I need to do it manually?
About the stick, I was thinking: if my stick fails, do I need to backup something to go back online quickly with a new controller? Never happened before, but I was thinking about …
No - it is not yet merged into master. I’m expecting to do it over the weekend.
Ok, I thought your question was related to the upgrade. Yes, I agree it’s a useful feature and it is on my list of things to do, but at the moment it’s not possible through OH directly.
People looking to upgrade their Z-Wave binding will be using the:
OH stable or milestone release, with the release version of the Z-Wave binding
OH stable or milestone release, with the snapshot version of the Z-Wave binding
OH stable or milestone release, with a manually installed development version of the Z-Wave binding
OH snapshot release, with the snapshot version of the Z-Wave binding
OH snapshot release, with a manually installed development version of the Z-Wave binding
Once made available and everyone has upgraded to the snapshot version of the binding, there will be people using the:
OH stable and milestone releases, with a manually installed snapshot version of the Z-Wave binding
OH snapshot release, with a manually installed snapshot version of the Z-Wave binding
OH snapshot release, with the snapshot version of the Z-Wave binding
There are many different configurations and upgrade paths! If the binding is manually installed, the new snapshot binding will run on an OH stable or milestone release. I see two main paths… upgrade to latest OH snapshot, or perform a manual installation. I would expect there will be a number of people not wanting to upgrade OH to a snapshot (or eventual milestone) build, although this is by far the best way to go, IMO. These steps cover the first, except…
Step 1… specify release or testing version of OH. At first I thought you meant the binding.
Step 2 (backup)… should be first!
Step 4 (delete Things)… If the controller is accidentally deleted, it should be recreated with the same ThingID, so that the channels do not change. This can be found in the channel info of an items file, or in a backup Thing.json file. If Things are manually configured in .thing files, they can be moved to another directory and then moved back to pull in the updated Thing definitions.
Step 5 (uninstall Zwave binding) How to do this depends on how it is currently installed. If manually installed, delete jar, then uninstall through Karaf, if it is still shows up with list -s | grep zwave. If installed through a UI or the console (a jar was never dropped into addons), uninstall though a UI or the console.
Step 6 (remove xmls) This is not necessary, and can cause headaches for people who are currently running the manual install of the dev binding, as all of their devices will need to be identified again. I would leave this one out.
Step 7 (Install the Z-Wave binding)… specify through a UI or the console, in case there’s any confusion about dropping jars in addons.
Step 10 (manual wakeups) should be written as optional, unless someone has a device that has a wakeup interval of 0, like a Minimote.
For a manual installation, you could use my script , but I’ll also update the first post with steps for doing this by hand…
Then delete and rediscover your Z-Wave Things (not controller), or use this rule (I’ll put this into a script too)…
Come on, now that’s not a valid argument.
Anyone to take home automation for serious clearly needs to backup his stick to be prepared for the stick to break down, and potentially even wants to do so after every new device inclusion (as everybody knows of some example where that process was/is that cumbersome that he does not want to repeat that), just like there is a constant need for mesh healing.
Now while it can be done outside OH, that requires to shutdown OH. So any feature to do it inside the binding or habmin while keeping OH running would be highly welcome.
Yes there’s of course more important or more urgent TODOs, but not really that many if you asked me …
EDIT: sorry I didn’t see your next posting to state you misunderstood the OP’s post
Sorry, but as I said above, I thought that the question was related to the migration of the development binding to the new version, and I was responding to that. I said I agree it’s a useful feature, but it’s
Sorry for going slightly off topic here, but would such a feature mean the possibility to backup one controller and restore it to another which is not the same model? I’ve been thinking about replacing my old Z-stick S2 with something newer but the hassle with excluding everything and including it again really scares me off…
My intent was to only cover “those of us who have only ever used the release or snapshot version of the binding” meaning those who have only ever installed though PaperUI or the karaf console. The assumption is that they would continue to do so which eliminates all of the manual install paths. I figure any user who wants to go down that path has already done so and there are lots of users more qualified to write those steps than me. I never intended the steps to be comprehensive.
I’ll update where I can but I really think that the manual add-on procedures should be a separate set of instructions, and I’d push your script as the primary recommended approach.
I have set up a new rpi 3b+ with openHABian 2.3.0-1 on an SSD and nothing else.
My thought is to use z-wave on this, which is new to me and has read this topic but has not understood what will happen with the Binding.
Because I’m a beginner, and I want to make it as easy for me as possible, I have the following questions:
Will there soon be a new Z-wave Binding V2.4 that will be installed from the Paper ui/Bindings?
Will this be available in an upgrade of OH 2.3 or first in a new version of OH?
If it is first available in a new version of OH, is it possible to say how far away it is to be released?
I’ve spent the morning sorting out the merge and it’s now ready to go. Assuming there are no issues, this will be merged into master tomorrow morning (European time) and available via the normal snapshot route if you’re using 2.4 snapshot runtime.
As per the steps above (thanks @rlkoshak and @5iver) a good way forward to upgrade is as follows -:
Backup.
If on the release or testing version of OH and on an apt/yum based install, change to the snapshot release repo as the source.
If you are not already running 2.4 snapshots, then upgrade OH using the procedure for your platform.
Remove all Zwave Things except for the thing representing the Controller. If the controller is accidentally deleted, it should be recreated with the same ThingID, so that the channels do not change. This can be found in the channel info of an items file, or in a backup Thing.json file. If Things are manually configured in .thing files, they can be moved to another directory and then moved back to pull in the updated Thing definitions.
Uninstall the Zwave binding though PaperUI or the Karaf console. How to do this depends on how it is currently installed. If manually installed, delete jar, then uninstall through Karaf, if it is still shows up with list -s | grep zwave . If installed through a UI or the console (a jar was never dropped into addons), uninstall though a UI or the console.
Install the Zwave binding through PaperUI or the Karaf console.
Go to the Inbox and scan for Zwave devices.
Accept the nodes as they appear.
If necessary, perform whatever wake up steps that are necessary for battery powered devices so the binding can figure out what it is.
The last point above is generally optional, however it is worth noting that all devices will initially be unknown as the XML files that the binding uses to persist information about the device will be recreated. Mains devices should reappear pretty quickly, but battery devices will take time - the exact duration will depend on the wakeup interval configured for the device. You can speed this up by manually waking up the devices (check the manual for each device to learn how to do this). There are a few devices that may not wake up at all by themselves (eg Minimote and Minimote) and these must be woken manually for them to be discovered.
Note that some battery devices don’t wake up on their own as their default configuration. Minimote and Wallmote are two that come to mind. Unless you changed the default configuration (which I don’t think is even possible with Minimote), these devices must be woken up in order to complete initialization.
I couldn’t quickly find a reference, but there were several fixes for 500 errors. There were a number of people using 2.3.0 with the dev version reporting them in PaperUI and Habmin when configuring Z-Wave devices. Upgrading to a snapshot build resolved the errors. Considering this, it is probably best to recommend that everyone wanting to use this version of the binding to upgrade OH to a snapshot release. This would eliminate the 2.3.0 stable and current milestone release upgrade paths.
, but I’ll also update the first post with steps for doing this by hand…