Replace RxTx with jSerialComm

[amitjoy]

It would be really nice to use jSerialComm [1] instead of RxTx.

[1] - https://github.com/Fazecast/jSerialComm

[whizzosoftware]

Any particular reason for the suggestion? I did a quick Google search and didn't see any immediately obvious benefits.

[amitjoy]

RxTx requires users to setup their environment to have RxTx system libraries whereas jSerialComm is a platform-independent way to access standard serial ports. Many projects such as j2mod, jamod are currently using jSerialComm for such platform independent access to serial ports.

[whizzosoftware]

This can be done with RxTx as well. Take a look at this project:

https://github.com/whizzosoftware/rxtx-osgi

It's what I'm using for my Hobson IoT platform and doesn't require the user to install anything specific to RxTx. The native libraries are discovered and run from the JAR file same as jSerialComm.

[amitjoy]

I actually didn't know that there already exists an OSGi-fied version of RxTX. I would give it a try. Many thanks for the information though. 👍

[whizzosoftware]

No problem, let me know what you find. I would assume that the JAR structure of the native libraries can carry over to non-OSGi projects verbatim. I've tested it successfully with Windows, Mac and Linux including Debian on both Raspberry Pi 2/3 and Beaglebone Black.

[anton-johansson]

I found this issue and I was going to open up an issue about this here. Then I found this issue!

Seeing as netty is deprecating it (in 4.1.x already), for good reasons too, maybe it's not a bad idea to look for a replacement?

[whizzosoftware]

Thanks for pointing that out. If the Netty team is dropping support for RxTx then it would make sense to move to jSerialComm.

[Ziver]

I've actually been working on a pr for using jSerialComm in WZWave.

I wrote a jSerialComm transport for netty that's available here: https://github.com/Ziver/Netty-Transport-jSerialComm

[anton-johansson]

@Ziver: Cool! For the curious one, is there any place where you can track the progress? I couldn't find a branch for it in your fork.

[Ziver]

Yeah, my WZWave fork is kind of a mess. I'll see if I can clean it up a bit today.

[Ziver]

Here is the cleaned up branch: https://github.com/Ziver/WZWave/tree/jserialcomm

I "think" it is working but I only have a Z-Stick Gen5 so don't really have a functioning environment to test it in, would be good if someone could verify that it actually works before I create a PR.

[anton-johansson]

Nice, looks good!

As @whizzosoftware mentioned in another issue, the code base is easily unit tested (and seems pretty well unit tested already as well). We should add unit tests that verify various devices, to make the transition to jserialcomm easier.

I can also build your code locally just to verify that it works the same for me, but I need to progress with my application a bit more first.

[anton-johansson]

@Ziver, could you rebase your branch with the latest changes and maybe create a pull request for this? I could then try it out with my devices. I only have a couple though, so it'd be nice if @whizzosoftware could try it too. :)

[Ziver]

I've created a PR for it now.

[whizzosoftware]

Thanks, I've merged it into master for testing.

[chrisdutz]

Hi, what's the current status of this? We are currently starting to implement industrial PLC protocols, one of them being Modbus. I bet it would be better to use this option and not start writing code for deprecated components.

Chris

[whizzosoftware]

Hi Chris, At the moment, it needs more people to test it but it is in the master branch. If you are interested in trying it, and need help building, let me know.

[eperott]

I've been trying out this and have some problems with jSerialComm. When starting a simple test application WZWave will initialize and start to interview devices, updates are received and so on.

However, when the main thread return and the application is supposed to exit, it is stuck. A jstack will show one blocked thread:

"pool-1-thread-1" #10 prio=5 os_prio=0 tid=0x0068b420 nid=0x198b runnable [0xab956000]
   java.lang.Thread.State: RUNNABLE
    at com.fazecast.jSerialComm.SerialPort.readBytes(Native Method)
    at com.fazecast.jSerialComm.SerialPort.access$700(SerialPort.java:47)
    at com.fazecast.jSerialComm.SerialPort$SerialPortInputStream.read(SerialPort.java:996)
    at io.netty.buffer.UnpooledHeapByteBuf.setBytes(UnpooledHeapByteBuf.java:249)
    at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:869)
    at io.netty.channel.oio.OioByteStreamChannel.doReadBytes(OioByteStreamChannel.java:110)
    at io.netty.channel.oio.AbstractOioByteChannel.doRead(AbstractOioByteChannel.java:96)
    at io.netty.channel.oio.AbstractOioChannel$1.run(AbstractOioChannel.java:45)
    at io.netty.channel.ThreadPerChannelEventLoop.run(ThreadPerChannelEventLoop.java:53)
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
    at java.lang.Thread.run(Thread.java:744)

When I trigger an update on my Z-wave network it will be received and the thread will unblock:

21:34:38.737 [pool-1-thread-1] DEBUG c.w.wzwave.codec.ZWaveFrameDecoder - RCVD: 0x01 0x0B 0x00 0x04 0x00 0x05 0x03 0x25 
21:34:38.741 [pool-1-thread-1] TRACE c.w.wzwave.codec.ZWaveFrameDecoder - Done processing received data: []
21:34:38.779 [pool-1-thread-1] DEBUG c.w.wzwave.codec.ZWaveFrameDecoder - RCVD: 
21:34:38.782 [pool-1-thread-1] TRACE c.w.wzwave.codec.ZWaveFrameDecoder - Done processing received data: []

I'm running on a RasberryPi with Razzbery controller.

If I revert #27 and run WZWave with RxTx I don't get this behavior.

[Ziver]

This sounds like Serial port is not properly closed, could you provide the code for the simple app?

[eperott]

Here the simplest possible code that will reproduce this. It's compiled with HEAD of master WZWave master branch.

    public static void main(String[] args)
    {
        NettyZWaveController controller = new NettyZWaveController("/dev/ttyAMA0", new File("/home/pi/zwave/zwsimple/data"));
        controller.start();
        System.out.println("Started!");

        // Let WZWave initialize
        try {
            Thread.sleep(30_000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println( "Goodbye zw" );
        controller.stop();
    }

Not sure if its relevant, but the WZWave transaction manager is getting somewhat confused when resolving CC versions of my single binary switch device. As a result, by the time my app calls stop() there is still an ongoing transaction.