[SOLVED] USB Insteon PLM port not connecting

I am running a newer system now that did not need this, but when I ran OpenHAB on CentOS 5.x, I had to compile my own version of the nrjavaserial and specify a special command line parameter to get it to prefer mine over the bundled one. When I looked into it, the bundled one was calling for many version around what was on CentOS 5, but not the ones that came with CentOS 5. I don’t believe this would be your problem, but if you are running out of options, I can dig out the old startup routine I used and post it.

Daniel and I changed the insteon terminal to text mode by default. The build/run instructions have also been updated (slightly simpler now).

I get an error when starting, but it does start.

Insteon Terminal
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/pi/insteon-terminal/./init.py", line 27
    connectToMySerial()
    ^
IndentationError: unindent does not match any outer indentation level
Python interpreter initialized...
 >>> connectToSerial()
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: connectToSerial() takes exactly 1 argument (0 given)
>>> connectToSerial("/dev/ttyUSB0")
java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path thrown while loading gnu.io.RXTXCommDriver
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/pi/insteon-terminal/./python/commands.py", line 71, in connectToSerial
    insteon.setPort(IOPort(SerialIOStream(dev)))
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857)
        at java.lang.Runtime.loadLibrary0(Runtime.java:870)
        at java.lang.System.loadLibrary(System.java:1119)
        at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:123)
        at us.pfrommer.insteon.cmd.serial.SerialIOStream.open(Unknown Source)
        at us.pfrommer.insteon.cmd.IOPort.open(Unknown Source)
        at us.pfrommer.insteon.cmd.InsteonInterpreter.setPort(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:483)

java.lang.UnsatisfiedLinkError: java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path

Did you install the java rxtx serial package from the apt repository?

Yes, dpkg result:

ii librxtx-java 2.2pre2-11 armhf Full Java CommAPI implementation

Somehow your java version cannot find it. I had to make a special link to get this to work for java 8 oracle. It looks for native libraries in a certain place. From there you need to link to the rxtx library. Example on how to hunt down the location:

which java
/usr/bin/java
ls -la /usr/bin/java
lrwxrwxrwx 1 root root 22 Aug 31 19:48 /usr/bin/java -> /etc/alternatives/java
ls -la /etc/alternatives/java
lrwxrwxrwx 1 root root 39 Aug 31 19:51 /etc/alternatives/java -> /usr/lib/jvm/java-8-oracle/jre/bin/java
ls -la /usr/lib/jvm/java-8-oracle/jre/lib/amd64 | grep -i rxtx
lrwxrwxrwx  1 root root       29 Aug 31 20:07 librxtxSerial.so -> /usr/lib/jni/librxtxSerial.so

This last link I created by hand with ln -s. You may have to create a similar link for your java installation (obviously not under amd64, but whatever your CPU is, probably arm). You can find the location of the rxtx libs like this:

 dpkg-query -L librxtx-java | grep .so

Thank you for your help. I created the link and made some progress. See below:

pi@GLaDOS ~/insteon-terminal $ sudo ./insteon-terminal
Insteon Terminal
RXTX Warning:  Removing stale lock file. /var/lock/LCK..ttyUSB0
Python interpreter initialized...
>>> connectToMySerial()
>>> listDevices()
plmmodem                       34.7a.dc
>>> dmodem.getId()
sent msg: OUT:Cmd:0x62|toAddress:34.7A.DC|messageFlags:0x0F=DIRECT:3:3|command1:0x10|command2:0x00|
>>> id got no reply!

>>> dmodem.getid()
sent msg: OUT:Cmd:0x60|
>>> getid got msg:     IN:Cmd:0x60|IMAddress:34.7A.DC|DeviceCategory:0x03|DeviceSubCategory:0x15|FirmwareVersion:0x9E|ACK/NACK:0x06|
>>> dmodem.getdb()
0000 36.FC.FC                       36.FC.FC  RESP  10100010 group: 01 data: 00 00 00
0000 2D.2B.29                       2D.2B.29  RESP  10100010 group: 01 data: 00 00 00
0000 25.A7.89                       25.A7.89  RESP  10100010 group: 01 data: 00 00 00
0000 2D.51.18                       2D.51.18  RESP  10100010 group: 01 data: 00 00 00
0000 37.01.61                       37.01.61  RESP  10100010 group: 01 data: 00 00 00
0000 36.F7.D1                       36.F7.D1  RESP  10100010 group: 01 data: 00 00 00
Modem Link DB complete

So now what? :smiley:

edit: I also removed the LCK…ttyUSB0 in /var/lock as it wasn’t associated with a running pid

Alright, so everything is working now, even at the java level.
Have you tried running openhab now? Maybe it works now with the link? Long shot.
Second, have you tried running openhab under “strace -f” to see where it’s looking for the *.so native libs, and if it finds them?
@xsnrg, I think your magic startup parameters would come in handy now. Maybe we can get it to use rxtx over nrjavaserial, because rxtx is definitely working now. If not, recompiling nrjavaserial should be straight forward. Figuring out how to smuggle the modified nrjavaserial into openhab is another matter…

Unfortunately no progress with Openhab. Is this the correct entry in my JAVA_ARGS_DEFAULT in /etc/init.d/openhab?

 -Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0 \

Here are some strace results, not sure what I’m looking for. I don’t get results for libNRJavaSerial.so, or anything when using ‘grep *.so’. This is the command I used:

sudo strace -o output1 -f /etc/init.d/openhab start

10653 fchownat(8, "nrjavaserial-3.9.3.jar", 108, 111, AT_SYMLINK_NOFOLLOW) = 0
10655 newfstatat(AT_FDCWD, "nrjavaserial-3.9.3.jar", {st_mode=S_IFREG|0664, st_size=526072, ...}, AT_SYMLINK_NOFOLLOW) = 0
10698 stat64("/var/lib/openhab/workspace/org.eclipse.osgi/bundles/202/2/.cp/lib/nrjavaserial-3.9.3.jar", {st_mode=S_IFREG|0664, st_size=526072, ...}) = 0
10698 fchmodat(AT_FDCWD, "/var/lib/openhab/workspace/org.eclipse.osgi/bundles/202/2/.cp/lib/nrjavaserial-3.9.3.jar", 0644) = 0
10821 stat64("/var/lib/openhab/workspace/org.eclipse.osgi/bundles/202/2/.cp/lib/nrjavaserial-3.9.3.jar", {st_mode=S_IFREG|0644, st_size=526072, ...}) = 0
10821 stat64("/var/lib/openhab/workspace/org.eclipse.osgi/bundles/202/2/.cp/lib/nrjavaserial-3.9.3.jar", {st_mode=S_IFREG|0644, st_size=526072, ...}) = 0

Tried running strace on my intel box. Same: no mention of the opening of the .so files. How is this library mapped without open()??? I do see it opening the devices (I have mine symlinked to /dev/insteon and /dev/urtsi since I’m running two different serial devices on this box):

 grep -i open strace.txt | grep -i "/dev/"
[.... some junk here ....]

28365 open("/dev/urtsi", O_RDONLY|O_NOCTTY|O_NONBLOCK <unfinished ...>
28365 open("/dev/urtsi", O_RDONLY|O_NOCTTY|O_NONBLOCK <unfinished ...>
28365 open("/dev/urtsi", O_RDONLY|O_NOCTTY|O_NONBLOCK <unfinished ...>
28365 open("/dev/urtsi", O_RDWR|O_NOCTTY|O_NONBLOCK <unfinished ...>

28374 open("/dev/insteon", O_RDONLY|O_NOCTTY|O_NONBLOCK <unfinished ...>
28374 open("/dev/insteon", O_RDWR|O_NOCTTY|O_NONBLOCK <unfinished ...>

For sure it’s mapped when openhab runs:

pmap 28236 | grep -i serial
00007f637075d000     56K r-x--  /tmp/libNRJavaSerial_openhab_0/libNRJavaSerial.so
00007f637076b000   2048K -----  /tmp/libNRJavaSerial_openhab_0/libNRJavaSerial.so
00007f637096b000      4K r----  /tmp/libNRJavaSerial_openhab_0/libNRJavaSerial.so
00007f637096c000      4K rw---  /tmp/libNRJavaSerial_openhab_0/libNRJavaSerial.so
00007f63ec01a000      4K r--s-  /usr/local/openhab/rt/server/plugins/org.openhab.io.transport.serial_1.8.0.201510121242.jar
00007f640649b000      8K r--s-  /usr/local/openhab/rt/server/configuration/org.eclipse.osgi/bundles/202/1/.cp/lib/nrjavaserial-3.9.3.jar

See if you get something similar when running pmap on the “java” processes while openhab is running. It’s apparently creating a temp file in /tmp/libNRJavaSerial_openhab_0/ which is then mapped into the process address space. Must’ve shaken off the strace somehow before getting there or we would have seen the open() call.

The only result I get for “serial” is

/usr/share/openhab/server/plugins/org.openhab.io.transport.serial_1.7.1.jar

I’m seeing more *.so files, but no libNRJavaSerial. SHould it be created dynamically after start? I can’t find it on the system either.

Found a post with a startup script that sets something related to rxtx:

The extra args are these:

-Djna.boot.library.path=/usr/lib/jni -Dgnu.io.rxtx.SerialPorts=/dev/ttyAMA0

The surprising thing is that on your pi, the device shows up as /dev/ttyUSB0, whereas usually it shows as /dev/ttyAMA0. Wanna try making a symlink from /dev/ttyAMA0 -> /dev/ttyUSB0, modify the startup script with the args above, change to /dev/ttyAMA0 in openhab.conf, and see what happens? It’s a long shot since you don’t even see the nrjavaserial libs in the pmap.

And I suggest you upgrade to the latest OH 1.8 from the cloudbees nightly build. I don’t think there is any change in syntax for your config files. but maybe there are some fixes that will help. Another long shot.

I upgraded to the 1.8 runtime files and added all of the /addons/ to see if that made a difference. After, I deleted several addons which were throwing errors (ie mogodb), but the good news is that I now have the libNRJavaSerial components. At first insteon was hanging at “activating binding”, but after I removed some of the aforementioned /addons/ that resolved. However, it still will not bind to ttyUSB0. I then changed the /etc/init.d/openhab config ARG to /dev/ttyAMA0, and the openhab.cfg insteon port value as well, but that resulted in the same No Port Found error as USB0.

pi@GLaDOS /var/log/openhab $ sudo pmap 7823|grep -i serial
aa124000     44K r-x--  /tmp/libNRJavaSerialv6_HF_openhab_0/libNRJavaSerialv6_HF.so
aa12f000     32K -----  /tmp/libNRJavaSerialv6_HF_openhab_0/libNRJavaSerialv6_HF.so
aa137000      4K rw---  /tmp/libNRJavaSerialv6_HF_openhab_0/libNRJavaSerialv6_HF.so

I’m thinking I’ll just try an x86 Linux install and see if it’s the Pi at fault here.

On that last experiment, did you also make a symlink /dev/ttyAMA0 -> /dev/ttyUSB0?
Just to make sure it’s not some simple oversight.
Seems like you got really close now, just a bit missing.

But yes, if you have an x86 box available that one should work for sure. All my stuff is running on x86.

Bernd

Sorry for the delay, I had to resurrect the old machine to get the command line option I used.

After compiling my own copy of libNRJavaSerial.so I added this line to the java $prog_args in the startup script:

-DlibNRJavaSerial.userlib=/opt/nrjs/libNRJavaSerial.so \

where /opt/nrjs was just where I had the library sitting to be used.

Like I said, not sure this will help, but in my case it was a version mismatch with what was available to me, and what was being requested by OpenHAB.

Fixed via chmod 666 for /dev/ttyUSB0.

ARE YOU KIDDING ME??? After all that difficult trouble shooting such a simple solution???
How could the Insteon Terminal work? That should have suffered from the same permissions problem!

Oh well, glad you got it working at last on a raspberry pi! Congrats :smile:

Bernd

Yeah, I’m not sure why it worked for one and not the other, both are running as Sudo as well. But I wasn’t getting the java libraries previously, so it was probably a combination of issues.

I’m having this same problem but chmod 666 /dev/ttyUSB0
doesn’t fix mine.

What’s weird is that I can send commands to the insteonplm in python via the following, which uses the same /dev/ttyUSB0 syntax:

# Note: Set PLM to sync mode first followed by device sync
# Commands list: http://www.madreporite.com/insteon/commands.htm

import serial, binascii

ser = serial.Serial(port='/dev/ttyUSB0',
                    baudrate=19200,
                    parity=serial.PARITY_NONE,
                    stopbits=serial.STOPBITS_ONE,
                    bytesize=serial.EIGHTBITS,
                    timeout=0
                    )

ser.flushInput()
ser.flushOutput()
 
message = bytearray()
message.append(0x02) # INSTEON_PLM_START
message.append(0x62) # INSTEON_STANDARD_MESSAGE
 
# device id
message.append(0x1F) # Addr 1
message.append(0x73) # Addr 2
message.append(0x3E) # Addr 3
 
message.append(0x0F) # INSTEON_MESSAGE_FLAG
message.append(0x12) # 0x12 = FAST ON, 0x14 = FAST OFF, 0x19 = STATUS
message.append(0x10) # 0x00 = 0%, 0xFF = 100%
print(binascii.b2a_hex(message))
ser.write(message)
ser.flush()
ser.close()