[SOLVED] USB Insteon PLM port not connecting

Hi all, I’m a beginner who’s having some trouble getting a USB Insteon PLM working with my devices. My setup is:

  • Raspberry Pi
  • Smarthome PowerLinc USB Dual-Band PLM #2413U
  • 2843-222 Wireless Open/Close Sensor
  • I installed openHab via apt-get and have updated. Starting automatically via /etc/int.d/

I’ve enabled Trace level messaging in the logs and those are below. I’ve also included the contents of my “insteon.items” file. The switches were linked with the PLM first, and I was able to see them communicating via the GUI software. However, in openHab, I am not getting any messages and it looks like that while the modem is attached to ttyUSB0, OH isn’t able to connect. I’ve tried ttyAMA0 as well.

INFO  o.o.b.i.InsteonPLMActiveBinding[:592]- devices: 0 configured, 0 polling, msgs received:  0

2015-10-18 15:29:36 DEBUG o.o.b.i.internal.driver.Port[:114]- starting port /dev/ttyUSB0
2015-10-18 15:29:36 ERROR o.o.b.i.i.d.SerialIOStream[:80]- got no such port for /dev/ttyUSB0
2015-10-18 15:29:36 DEBUG o.o.b.i.internal.driver.Port[:119]- failed to open port /dev/ttyUSB0

cat /dev/ttyUSB0 renders nothing, however I was able to see traffic by using the following and then pushing buttons on the devices:
stty raw -echo < /dev/ttyUSB0; cat -vte /dev/ttyUSB0

//// /etc/openhab/configurations/openhab.cfg ////
insteonplm:port_0=/dev/ttyUSB0
insteonplm:poll_interval=300000
insteonplm:refresh=600000    

//// DMESG ////
[    2.314000] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[    2.328419] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    2.343623] hub 1-1:1.0: USB hub found
[    2.353103] hub 1-1:1.0: 5 ports detected
[    2.643530] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[    2.763976] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[    2.790339] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    2.810379] smsc95xx v1.0.4
[    2.881656] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-20980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:82:d4:23
[    2.983489] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[    3.139921] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6001
[    3.163517] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.186967] usb 1-1.2: Product: FT232R USB UART
[    3.199800] usb 1-1.2: Manufacturer: FTDI
[    3.213491] usb 1-1.2: SerialNumber: A60332MD
[    3.793909] udevd[159]: starting version 175
[    5.293638] gpiomem-bcm2835 20200000.gpiomem: Initialised: Registers at 0x20200000
[    6.146976] usbcore: registered new interface driver usbserial
[    6.363656] usbcore: registered new interface driver usbserial_generic
[    6.372430] usbserial: USB Serial support registered for generic
[    6.758657] usbcore: registered new interface driver ftdi_sio
[    6.960748] usbserial: USB Serial support registered for FTDI USB Serial Device
[    7.160070] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[    7.333876] usb 1-1.2: Detected FT232RL
[    7.433608] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0

//// /var/log/openhab/insteon.log ////
2015-10-18 15:29:36 INFO  o.o.b.i.InsteonPLMActivator[:34]- Insteon PLM binding has been started.
2015-10-18 15:29:36 TRACE o.o.b.i.InsteonPLMGenericBindingProvider[:78]- processing item "Door1" read from .items file with cfg string xx.xx.xx:0x000049#contact
2015-10-18 15:29:36 TRACE o.o.b.i.InsteonPLMGenericBindingProvider[:78]- processing item "Door2" read from .items file with cfg string xx.xx.xx:0x000049#contact
2015-10-18 15:29:36 TRACE o.o.b.i.InsteonPLMGenericBindingProvider[:78]- processing item "Door3" read from .items file with cfg string xx.xx.xx:0x000049#contact
2015-10-18 15:29:36 TRACE o.o.b.i.InsteonPLMGenericBindingProvider[:78]- processing item "Door4" read from .items file with cfg string xx.xx.xx:0x000049#contact
2015-10-18 15:29:36 TRACE o.o.b.i.InsteonPLMGenericBindingProvider[:78]- processing item "Door5" read from .items file with cfg string xx.xx.xx:0x000049#contact
2015-10-18 15:29:36 TRACE o.o.b.i.InsteonPLMGenericBindingProvider[:78]- processing item "Door6" read from .items file with cfg string xx.xx.xx:0x000049#contact
2015-10-18 15:29:36 DEBUG o.o.b.i.InsteonPLMActiveBinding[:155]- activating binding
2015-10-18 15:29:36 DEBUG o.o.b.i.InsteonPLMActiveBinding[:262]- global binding config has arrived.
2015-10-18 15:29:36 INFO  o.o.b.i.InsteonPLMActiveBinding[:268]- refresh interval set to 600s
2015-10-18 15:29:36 INFO  o.o.b.i.InsteonPLMActiveBinding[:276]- poll interval set to 300000 per config file
2015-10-18 15:29:36 INFO  o.o.b.i.InsteonPLMActiveBinding[:294]- dead device timeout set to 3000s
2015-10-18 15:29:36 DEBUG o.o.b.i.InsteonPLMActiveBinding[:295]- configuration update complete!
2015-10-18 15:29:36 DEBUG o.o.b.i.InsteonPLMActiveBinding[:338]- initializing...
2015-10-18 15:29:36 INFO  o.o.b.i.InsteonPLMActiveBinding[:350]- config: poll_interval -> 300000
2015-10-18 15:29:36 INFO  o.o.b.i.InsteonPLMActiveBinding[:350]- config: port_0 -> /dev/ttyUSB0
2015-10-18 15:29:36 INFO  o.o.b.i.InsteonPLMActiveBinding[:592]- devices:   0 configured,   0 polling, msgs received:     0
2015-10-18 15:29:36 DEBUG o.o.b.i.internal.driver.Poller[:176]- starting poll thread.
2015-10-18 15:29:36 DEBUG o.o.b.i.internal.driver.Driver[:64]- added new port: port_0 /dev/ttyUSB0
2015-10-18 15:29:36 INFO  o.o.b.i.InsteonPLMActiveBinding[:350]- config: refresh -> 600000
2015-10-18 15:29:36 INFO  o.o.b.i.InsteonPLMActiveBinding[:350]- config: service.pid -> org.openhab.insteonplm
2015-10-18 15:29:36 DEBUG o.o.b.i.InsteonPLMActiveBinding[:356]- setting driver listener
2015-10-18 15:29:36 DEBUG o.o.b.i.InsteonPLMActiveBinding[:358]- starting 0 ports
2015-10-18 15:29:36 DEBUG o.o.b.i.internal.driver.Port[:114]- starting port /dev/ttyUSB0
2015-10-18 15:29:36 ERROR o.o.b.i.i.d.SerialIOStream[:80]- got no such port for /dev/ttyUSB0
2015-10-18 15:29:36 DEBUG o.o.b.i.internal.driver.Port[:119]- failed to open port /dev/ttyUSB0
2015-10-18 15:29:36 DEBUG o.o.b.i.InsteonPLMActiveBinding[:360]- ports started
2015-10-18 15:29:36 ERROR o.o.b.i.InsteonPLMActiveBinding[:363]- initialization complete, but found no ports!
2015-10-18 15:29:37 DEBUG o.o.b.i.i.d.DeviceTypeLoader[:195]- loaded 36 devices:

 //// insteon.items ////
Contact Door1 "Door1 [MAP(contact.map):%s]" {insteonplm="xx.xx.xx:0x000049#contact"}
Contact Door2 "Door2 [MAP(contact.map):%s]" {insteonplm="xx.xx.xx:0x000049#contact"}
Contact Door3 "Door3 [MAP(contact.map):%s]" {insteonplm="xx.xx.xx:0x000049#contact"}
Contact Door4 "Door4 [MAP(contact.map):%s]" {insteonplm="xx.xx.xx:0x000049#contact"}
Contact Door5 "Door5 [MAP(contact.map):%s]" {insteonplm="xx.xx.xx:0x000049#contact"}
Contact Door6 "Door6 [MAP(contact.map):%s]" {insteonplm="xx.xx.xx:0x000049#contact"}

We’ve seen people having trouble with this before:

But that was a somewhat different device. There are a bunch of suggestions there about passing serial port parameters to the jvm on startup. I’m not sure why they are needed. I certainly don’t need them on Ubuntu 14.04 on intel.

It is most dubious that you see the device just fine at the OS level, but then the nrjavaserial (rxtx based) library that openhab uses for java serial port access cannot pick it up. But that was exactly the case as well for the post referenced above.

I have one suggestion: there is an “Insteon Terminal” program on github that uses the rxtx library (not nrjavaserial, which is a fork of rxtx). If you manage to get that one working it points to problems with the nrjavaserial code.

And another suggestion, this one easier: try the very latest OH 1.8 binding from the nightly cloudbees build. It should work with OH 1.7, just drop it into the addons folder. I don’t expect wonders from it, but at some point the InsteonPLM would not coexist with other bindings that used (a different!) serial port. Long story, but give it a try.

Thank you for the reply. I saw that post earlier and tried some of the troubleshooting tips in it. I tried Insteon Terminal but got an X11 error since I’m accessing the Pi via SSH. I’ll look into the configuration of it.

I installed the 1.8 insteonPLM from Cloudbees, and there were two lines that changed in the log. See the ** lines below.

2015-10-19 16:32:58 DEBUG o.o.b.i.internal.driver.Driver[:75]- added new port: port_0 /dev/ttyUSB0
2015-10-19 16:32:58 INFO  o.o.b.i.InsteonPLMActiveBinding[:361]- config: refresh -> 600000
2015-10-19 16:32:58 INFO  o.o.b.i.InsteonPLMActiveBinding[:361]- config: service.pid -> org.openhab.insteonplm
2015-10-19 16:32:58 DEBUG o.o.b.i.InsteonPLMActiveBinding[:367]- setting driver listener
2015-10-19 16:32:58 DEBUG o.o.b.i.InsteonPLMActiveBinding[:369]- starting 0 ports
2015-10-19 16:32:58 DEBUG o.o.b.i.internal.driver.Port[:132]- starting port /dev/ttyUSB0
***2015-10-19 16:32:59 TRACE o.o.b.i.i.d.SerialIOStream[:102]- ports found from identifiers:
***2015-10-19 16:32:59 TRACE o.o.b.i.i.d.SerialIOStream[:121]- final port list: /dev/ttyUSB0
2015-10-19 16:32:59 ERROR o.o.b.i.i.d.SerialIOStream[:76]- got no such port for /dev/ttyUSB0
2015-10-19 16:32:59 DEBUG o.o.b.i.internal.driver.Port[:137]- failed to open port /dev/ttyUSB0
2015-10-19 16:32:59 DEBUG o.o.b.i.InsteonPLMActiveBinding[:371]- ports started
2015-10-19 16:32:59 ERROR o.o.b.i.InsteonPLMActiveBinding[:374]- initialization complete, but found no ports!

You may well be the first one besides the authors to try the Insteon Terminal. Very useful to get feedback!

I think there is a way to run the Insteon Terminal inside a terminal (text) only. @dan_pfrommer can you comment on this (or get it working)?

The log says it builds the port list correctly. I’m sure you checked for permissions already and they look fine. Very tough one, don’t know what to say. The other user with the raspberry pi eventually gave up :frowning:

Is this an older pi, or a newer one? Anything special about it that could make the difference? Is it an OS issue. I thing I recall others running on it successfully…

Everything was installed/run via sudo, and I don’t think I’m getting any errors in the logs, so it looks okay from that perspective. But if there is another way to troubleshoot permissions I’d look into it. The OS is the most up-to-date Raspbian.

The Pi itself is a Raspberry Pi Model B (512 RAM), purchased in March 2014. Not the newest Pi2, but not too antiquated either.

Really tough one to debug since there are no error messages.
I suspect nrjavaserial is not finding a native library.
Do you have any other bindings running that use serial (zwave?) successfully? All of openhab uses the njravaserial lib, so that would be an interesting data point.

Not sure the raspberry pi allows you to run “strace”. I’ve used it on linux systems successfully (run “strace -f command_name”). It gives you a list of all system calls a process makes, it dumps a lot of stuff (redirect the output to a file). In the output, grep for “open”, it’ll give you all files the process opens. See if it opens successfully the nrjavaserial shared objects, or at least tries to:

native/linux/ARM/libNRJavaSerial.so
native/linux/ARM/libNRJavaSerial_HF.so
native/linux/ARM/libNRJavaSerialv5.so
native/linux/ARM/libNRJavaSerialv6.so
native/linux/ARM/libNRJavaSerialv6_HF.so
native/linux/ARM_A8/libNRJavaSerial.so
native/linux/ARM_A8/libNRJavaSerial_legacy.so
native/linux/PPC/libNRJavaSerial.so
native/linux/x86_32/libNRJavaSerial.so
native/linux/x86_32/libNRJavaSerial_legacy.so
native/linux/x86_64/libNRJavaSerial.so
native/linux/x86_64/libNRJavaSerial_legacy.so

I can think of one more desperate option: run ser2sock to connect your serial port to a local socket, then in the insteonplm binding pretend it’s an old hub (not hub2!), and connect to the port on localhost where you have exposed your serial socket.

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.