Apparently the Zwave binding blocks the / dev / ttyUSB0 port in Combination with a CC2652RB Zigbee2mqtt Dongle

Just FYI, while zwave2mqtt works great, getting OpenHAB to receive and send the correct values and interpret them correctly is really tiresome. Needs a lot of tweaking with map-files and I still don’t understand why the two won’t cooperate on simple integers (dimmer settings). So I’ve given up on this for now, but am certainly very interested in the modified version of the zwave binding.

A little Update from my side. The CC2652RB is still working although i used the 2.5.0-RC1 and actually the newer 2.5.0 Zwave-Binding. I think this thing works, because the commit mentioned

was merged on 04 Jan ´20 and therefore first used in 2.5.1.

1 Like

For everyone who is interested, the CC2652RB is working now flawlessly in parallel to the actual Zwave-Binding (2.5.7 …). i´ve merged the newer commit below (remove serial reconnection workaround)

into actually 2.5.x-Repo. So if someone´s interested, here is the link:

So now that´s the solution. Thx to @chris and @wborn for pointing me to the corresponding issues and commits.

Best regards

4 Likes

Thanks, Gustav, I’ll certainly look into it this weekend.
Did you happen to pack it into a jar somewhere?
(Maybe I’m just missing it)

@Tron you aren´t missing anything :slight_smile:. You have to compile the .jar for yourself:

  • Click on the second Link from my last Post
  • Click on the green “Code”-Button
  • Click “Download Zip”
  • Put the .zip somewhere on your Raspi (I thought your using a Raspi …), for example in /opt/maven_packages (mkdir /opt/mvn_packages)
  • if you haven’t already done it, install “maven” with
    apt install maven
  • unzip the .jar file and cd into the unzipped directory
  • now compile the package with
    mvn package
    (the first time it took a while), when it has succesfully finshed, the output gives something like “… Build succesful”
  • cd into /opt/mvn_packages/<package>/target, where you can find the (most likely called) org.openhab.binding.zwave-2.5.8-SNAPSHOT.jar

That´s the normal way to compile a package/binding.
To make it work on your openhabian, do the following steps:

  1. Uninstall Zwave-Binding within PaperUI (do not be afraid, the settings and Devices will remain)
  2. ssh into karaf-console:
    ssh -p 8101 openhab@localhost
  3. look, if the Zwave Binding is allready uninstalled:
    bundle:list | grep Z
    if there is a output pointing to the Zwave-Binding with a package ID/Number (e.g. 203) >
    bundle:uninstall 203
  4. now logout from karaf-console:
    logout
  5. now do:
    service zigbee2mqtt stop && service mosquitto stop && service openhab2 stop
  6. Clear tmp & cache:
    rm -rf $OPENHAB_USERDATA/{cache,tmp}/*
  7. put the compiled .jar file into
    $OPENHAB_HOME/addons/
    (cd $OPENHAB_HOME/addons/)
  8. reboot

First reboot takes a while. I hope that was detailed enough :wink:.
Best regards

3 Likes

Thanks for the extended howto.
(I’m not on a Raspi but a “regular” Debian box, but no matter)

Build went fine, however openHAB does not seem to like my package:
17:19:46.745 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.zwave-2.5.8-SNAPSHOT.jar org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [281]
Unresolved requirement: Import-Package: org.eclipse.smarthome.io.transport.serial

Looks like I’m missing a dependency here somewhere…
bundle:dynamic-import does not seem to do it here.

Hi @Tron!

You can install the serial transport bundle following this steps:

  1. ssh into karaf-console: ssh -p 8101 openhab@localhost
  2. Execute this command: feature:install openhab-transport-serial

That should be enough :wink:

@riturrioz
Thanks, I’ll try that tomorrow!

Ok, I’ve got the new/modified zwave binding working:

293 │ Active │ 80 │ 2.5.8.202008192232 │ openHAB Add-ons :: Bundles :: ZWave Binding

However, the problem persists. With deactivated zwave controller, the CC2652RB stick works, but not together with it, so the zwave-binding still hogs the USB port.

Did you Compiled the 2.5.7-no-reconn-workaround or the Standard repo 2.5.x?
Otherwise use this. jar

It’s the binding i use.

I already thought I used the wrong version, but I double-checked and I did a “git clone” on your modified repository: “https://github.com/bifi2090/org.openhab.binding.zwave.git” and compiled it. That is the 2.5.7-no-reconn-workaround, isnt’ it?

But thanks for the jar-file via dropbox, I will try that one tonight.

Ok. I’m not that expert, but i think “git clone” pulls the default repo. That is in this case the 2.5.x Version. You have to click on " download.zip" in the 2.5.7-no-reconn-workaround repo.

Or you can download the 2.5.7-no-reconn-workaround Release AT the releases tab

That might be it. I’ll try again tonight with the src-zip or directly with the jar.

Hi @Tron!

If you are using git to download @bifi2090’s repo, you have to change the branch before executing the maven commands. The command to change the branch is called checkout and is followed by the name of the branch. In your case, you should type:

git checkout 2.5.7-no-reconn-workaround

If you have any question, just ask! Good luck!

Using the compiled jar file, it’s working now!
Hope it keeps working with the manual binding until openHAB 3.0 :wink:

I put the the .jar now under Relaese 2.5.7-no.reconn-workaround. See below:

I think if the pull request below

is merged into the official branch, we can go back to this and use Zwave-Binding via PaperUI.

Best regards

1 Like

Hi guys!

Yes, @bifi2090, that PR will fix the problems you are seeing, but… it won’t be merged until OH3, so we have to wait a little bit. :wink:

Ok good to know.

Maybe offtopic, but you can follow the development here: http://next.openhab.org/

1 Like

Pulling this up as there now is a milestone version of openhab3 available, which (according to reports) is running quite nicely.

Does anyone know if the Zigbee-Sticks using USB0 still have an issue with the zwave binding? I would assume not, as that incompatibility came from a workaround in the 2.x zwave binding, but I have yet to get confirmation.