With ZWave it’s very common since many people will unplug the stick, move it to the device to perform inclusion (the most common stick has an internal battery to support this function).
1 Like
Then it might make sense to keep the workaround in place and keep answering threads about discovery issues and how to configure EXTRA_JAVA_OPTS until the workaround is removed in OH3 and everyone is using that. 
Thx for clarification. So setting serial devices in EXTRA_JAVA_OPTS is only necessary for z-wave and/or zigbee binding? An other thing i didn’t know/realize up to now.
To stay where we are ATM for oh2 means, you may not be able to run z-wave and zigbee(2mqtt) in some combinations of controllers. Or even other bindings using serial devices. Is this correct?
@yab no problem, everything is fine, my EXTRA_JAVA_OPTS were still not optimal 
@chris mentioned:
So I don’t necessarily have this problem, but I do believe that one or the other does, whatever.
What can someone like me do in this case? use an old Zwave binding? who knows when OH3 will come and whether it will get better then. I would like to try or test something, but don´t know what
I just remembered that there are still a few of other bindings for which it’s required to add non-standard ports to EXTRA_JAVA_OPTS.
That is because they are not (yet) using the openHAB serial transport, see openhab-addons#7573:
- cm11a
- knx
- modbus
- oceanic
- pentair
If you don’t use certain ports with openHAB bindings there is no need to add them to EXTRA_JAVA_OPTS. That may prevent the ports from being blocked when used by other applications.
1 Like
I believe the current documentation says it’s required to add this - if you are saying it’s not required, it might be worth updating the docs so that people know when/if they need to add this?
Personally, I’m not familiar with when this is needed. You seem to indicate above that it’s not needed if they OH serial transport is used -:
However the ZWave and ZigBee bindings have used this for a long time, so I guess it’s not as simple as you say here? 
That’s true, but at least for me that only applied when I was starting with openHAB/zwave and was building my network and buying new devices. It is an extremely handy feature as I have quite a few “fixed” devices like light switches you cannot easily bring close to the system running openHAB.
But since I now have all devices I need up and running for several months now, I don’t think I’ve ever unplugged the stick. And so would be happy with the “workaround” of shutting down openHAB before pulling the stick and starting it back up afterwards. But that’s just me.
Another workaround would be not to use the zwave binding at all. One could use OpenZwave in combination with zwave2mqtt, those are out there and work pretty much the same as zigbee2mqtt. That way, one would feed and pull data from openHAB via mqtt, an additional middleman. But due to the fact that in contrast to zigbee zwave stores the included devices on the stick itself, one would not even need to repair them. I don’t know how stable OpenZwave/zwave2mqtt are, though, and how well they perform.
I don’t think that will work. For one, I had a lot of trouble pairing and using devices with the zigbee binding, which was why I moved to zigbee2mqtt. That was with the CC2531 coordinator, which is supported by the binding. According to the documentation, the CC2652RB is not. I think it’s also quite new, and the zigbee2mqtt-maintainer only recently was able to support it.
Sure - but in the past this caused a lot of people to complain that OH didn’t react well. Saying that this is something that only matters when you’re starting out is a bit strange - it might be fine for you, but effectively you’re saying we shouldn’t care so much about newcomers…
This is of course up to you - there are many ways to do things.
It’s unfortunate that there are these bugs in the serial driver, and also that we can’t update the OH core any more because the other option is to change to use the serial driver that has resolved this problem, then we could remove the workaround.
I’m sorry, I totally did not mean that we should not care about newcomers. I apologize if my reply sounded like that.
I was just evaluating impacts of the two options. And I totally see that there are probably not so many people who use zwave AND zigbee, and probably a lot fewer people who do not use the CC2531 coordinator.
Because of that bug/workaround/whatever I currently still use the CC2531, but that is knowingly lacking in the power department, which means that some of my sensors only have a very weak link and occasionally drop out altogether. I was hoping to fix that with a better and stronger coordinator.
Don’t get me wrong, the zwave binding is working really well for me and does everything I want from it. That’s why I’d hate to go without it and am still hoping for a solution…
1 Like
I do use a pi3 + razberry + TelegesisETRX + RFXtrx. I plan to move to a pi + strompi3 + batpack + Aeotec Gen5 + (Telegesis or Stick with Ember chip). I am using z-wave + zigbee bindings currently and don’t plan to change this. But i am interested in zigbee2mqtt. This is why i joined this thread. Hopefully i won’t see the problems you do.^^
Sorry - probably just my misunderstanding 
I guess it’s a problem that doesn’t impact everyone for some reason - I use both here, and do not see any such problems.
Serial ports in Java are really a bit of a pain. There are a number of libraries out there, but none are really ideal unfortunately 
It would need to be very old. I forget when these features were added - maybe a year or two ago. Certainly it’s not a recent change.
You could try 2.4 to see if that works (that is nearly 2 years old) but of course you will also have a very old database of devices…
It was so that you would have to uninstall the current one via paperui and then insert the old one in the addons folder, right?
PS: is there Any Chance to only remove temporarily the above mentioned workaround from this binding locally and manually?
Yes, that’s correct. You should also use the Karaf console to check that the binding is removed/added - sometimes manually installing bindings like this can lead to multiple bindings running.
If you wanted to compile your own version of the binding this is of course possible.
So what should I say. After Downgrading the Zwave-Binding from 2.5.7 to 2.4.0-RC1 the problem, which was covered in this topic is initially solved. The CC2652RB now works flawlessly in parallel with the Aeoteck Gen5 Zstick and running Zwave-Binding.
I would have one last please, however, as I am not that firm now, @chris could you give me some instructions, if time allows, how I can compile the Zwave 2.5.7 Binding without (presumably) the mentioned workaround ?
All Zwave-Devices are working now, except the Swipe Function of my Wallmote Quad (Aeotec). This was solved in a later Release of the Zwave-Binding, so that I nevertheless need the actuall Binding (excerpt workaround).
In any case, I am very happy actually
1 Like
Thanks for the feedback @bifi2090.
The change that was made is here -:
You might try forking the current code and reversing some of these changes - probably the lines close to where I’ve set the marker in the link above.
OK. Thx. I will come back, when i have done this succesfully.
2 Likes
@chris chris I forked, and changed the marked lines as you said (hopefully, I´m an absolut newbie on github, sry)
after git clone and “mvn package” I get this error:
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /home/ich/org.openhab.binding.zwave/src/main/java/org/openhab/binding/zwave/handler/ZWaveSerialHandler.java:[83,3136] The @NonNull field portId may not have been initialized
[ERROR] /home/ich/org.openhab.binding.zwave/src/main/java/org/openhab/binding/zwave/handler/ZWaveSerialHandler.java:[169,6465] Null type mismatch (type annotations): required '@NonNull SerialPortEventListener' but this expression has type 'ZWaveSerialHandler.@Nullable ZWaveReceiveThread'
[ERROR] /home/ich/org.openhab.binding.zwave/src/main/java/org/openhab/binding/zwave/handler/ZWaveSerialHandler.java:[474,19113] Illegal redefinition of parameter serialMessage, inherited method from ZWaveIoHandler does not constrain this parameter
the underlying repository: