Use beta version of Open Z Wave (OZW)

The current release of OZW does not have barrier support. There is a long thread on installing the beta version here. Linear NGDZ00-4 Garage Door I was running hassbain and have just now switched to Looks like we need to be on 1.5.
I am really new to Hass.IO and docker. I can learn fast, but for now I may not only need help understanding but will need help with terminology.

1 Like

I recently moved from a manual installation of HA on gentoo to Hass.IO on RPI3. Previously I was able to manually copy a device support file for a newer Z-wave devices from OZW upstream (e.g. GE Z-Wave Plus Smart Motion Switch). I can’t do this now with Hass.IO, so I can’t configure this particular device through the web interface.

I was only patching a single device into 1.4 - I wonder what else is involved if we were to move the whole OZW codebase to 1.5.

Anyone figure out how to update OZW to the current beta or version 1.5? I tried running the service zwave.update_config but it looks like I’m still on version 1.4.3254. Using a raspberry pi3 with the Hassio install and an Aeotec Stick gen5

zwave.update_config does not update the version of OZW. It merely downloads a newer edition of OZW’s database of known devices.

As far as I know, there’s no facility for upgrading OZW’s code to a newer version. For a while I did run HA with a newer OZW version than what it was shipping with. It required a custom build.

how do I confirm that the database was successfully downloaded if the version won’t change in my OZW log?

Assuming that it did update correctly after running zwave.update_config is the only thing I need to do:

  1. stop the HA server
  2. delete zwcfg_xxx.xml
  3. restart HA so that zwcfg_xxx.xml is rebuilt using the new database

In my case, the difference was that devices that were recognized as generic ZWave devices would get their proper manufacturer and model numbers after the update, or the configuration parameters that would be missing before the update, were present after the update. This was evidence that the download worked, so I did not seek other evidence.

As I recall, I did not delete the whole zwcfg_xxx.xml file but just removed those entries for the devices I knew should be updated. The documentation says “delete the relevant entries”.

ok thanks. So it sounds like there is a difference between updating my version of OpenZwave (currently 1.4.3254) and updating my specific devices with the latest manufacturer information / config parameters available through the OpenZwave GitHub?

I’m still struggling to find a walkthrough of how to do either/both which is geared towards the more technologically challenged folk (me).

I have a Rpi3 with an Aeotec Gen5 stick and used the Hassio install about a year ago (I forget what the HA version was at that time). I see lots of people talking about adding branches and forks to their configs and I’m definitely new at using GitHub but I’m at a total loss where to start.

Its a bit of a brute force approach, but given that you probably only have 1-2 of these devices, you can stop HA, and the manually edit the zwcfg…xml file for those devices to add the requisite updates for the latest manufacturer xml file. I suspect that would be easier than some of the options.

That sounds like and excellent idea because yes, I only have about 4 different types of zwave devices. The code section for my lock that is currently in my zwcfg…xml is vastly different and much longer that what I’m finding on the OpenZwave Gitub. Are there other files/databases/folders I need to be adding somehow?

  	<Node id="6" name="" location="" basic="4" generic="64" specific="3" type="Secure Keypad Door Lock" listening="false" frequentListening="true" beaming="true" routing="true" max_baud_rate="40000" version="4" secured="true" query_stage="Complete">
  		<Manufacturer id="3b" name="Schlage">
  			<Product type="6341" id="5044" name="BE469 Touchscreen Deadbolt" />
  			<CommandClass id="32" name="COMMAND_CLASS_BASIC" version="1" request_flags="4" issecured="true" mapping="98">

… etc etc etc. This goes on for another 174 lines and defines multiple different Command Classes. The version here only defines 1 command class and is 150 lines in total. Is there something I’m missing or the new code is just different and more succinct?

I assumed I was supposed to REPLACE the old code with the new code. It just occurred to me that maybe I am supposed to UPDATE the old code with the new code by replacing Command Class id-112?

In general, I just UPDATED the existing entries for my devices to add/modify the command class entries sothat all of the options are listed. In my case, (for some newer GE outlets), I upated the product name, id, type, etc as well so that the device no longer showed up as unidentified.

1 Like