ZWave binding migration to development version

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…

I believe so…

1 Like

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:

  1. Will there soon be a new Z-wave Binding V2.4 that will be installed from the Paper ui/Bindings?
  2. Will this be available in an upgrade of OH 2.3 or first in a new version of OH?
  3. 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 -:

  1. Backup.
  2. 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.
  3. If you are not already running 2.4 snapshots, then upgrade OH using the procedure for your platform.
  4. 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.
  5. 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.
  6. Install the Zwave binding through PaperUI or the Karaf console.
  7. Go to the Inbox and scan for Zwave devices.
  8. Accept the nodes as they appear.
  9. 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.

5 Likes

Looks good, Chris.

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.

Thanks Mark. I’ve updated the blurb above as I’ll copy this into a new post once merged.

Any further comments welcome :slight_smile:

Known Issues

This one affects me the most, but is actually a feature request to add polling of the SCENE_ACTIVATION CC… [DEV] VRMX1 (and others) never update scene_number channel.

This one, Habmin displays associations incorrectly, always confuses people.

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.

I’m tempted to close most of these as most are very old and I’ve no idea if they still exist.

There’s not a lot I can do about this - the widget seems to be broken and it is no longer supported.

Will there be a new features list for those of us who haven’t kept up with the development thread?

My understanding this includes a whole bunch of new goodness beyond just the security command class.

Yes - it’s basically the list from first message in this post…

1 Like

Now merged -:

1 Like

Maybe you should remove the market place dev binding. At least it happened to me that i accidentality installed that version because of the “Security” appendix … :sunglasses:

2 Likes

Thanks - it’s now gone…

I successfully securely included 2 BE469 locks and an NGD00Z. One included the first try. The others took multiple attempts. The NGD00Z was the fiestiest. I think it took at least 15 tries! So, secure inclusion is definitely still working in the latest version, but it can be stubborn. I’ll put the logs in a ticket.

2 Likes

Thanks a lot Chris, the new version is a very nice improvement!

One small issue though… After upgrading I’m getting three battery channels with the same name for my Fibaro radiator thermostat (FGT-001) and it prevents me from modifying its properties. I’ve tried removing and adding again, removing xml and binding etc. so perhaps there’s something with the device DB?

This one appears 3 times:

2018-09-14 13:36:42.771 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 77: Initialising cmd channel zwave:device:512:node77:battery-level for PercentType

I think it should be zwave:device:512:node77:battery-level, zwave:device:512:node77:battery-level1 and zwave:device:512:node77:battery-level2.

I’ve a problem here.

I’m using a /dev/zwave_controller serial port where is connected my zwave key.
When I start searching for new devices, the controller goes offline saying “Serial Error: Port {0} does not exist”, and when I look at the properties of the controller I see /dev/ttyUSB0 and not /dev/zwave_controller. Changing the name, the controller goes up, but I’m not able to import correctly my devices.

How to solve it? Do you need a specific log for that? In case, how to collect?

Thanks
Andrea

Had the same error here. A simple reboot fixed it for me. But you might want to check if the serial port still has the group “dialout” and that openhab user is part of that group.

it seems it works only if you use the default port (ttyUSB0 or ttyACM0). I’ve solved pointing to one of those (depending on the controller)