OH2, Tellstick and 64-bit Debian

Hi.
I’m in the progress of moving my openhab2 over from a server running armhf Debian 8 to another server running arm64 Debian 9. I seem to have bumped into various problems, one I’m wrestling with now is the Tellstick binding. Upon startup of OH I get (amongst a lot of other stuff) the following errors:

2018-03-25 11:52:56.157 [ERROR] [l.discovery.TellstickBridgeDiscovery] - Could not load telldus core, please make sure Telldus is installed and correct 32/64 bit java.
java.lang.UnsatisfiedLinkError: Native library (com/sun/jna/linux-aarch64/libjnidispatch.so) not found in resource path (/usr/share/openhab2/runtime/lib/boot/org.apache.karaf.diagnostic.boot-4.1.3.jar:/usr/share/openhab2/runtime/lib/boot/org.apache.karaf.jaas.boot-4.1.3.jar:/usr/share/openhab2/runtime/lib/boot/org.apache.karaf.main-4.1.3.jar:/usr/share/openhab2/runtime/lib/boot/org.osgi.core-6.0.0.jar)
2018-03-25 11:52:58.492 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.tellstick.internal.core.TelldusCoreBridgeHandler@38a2cc02': Could not initialize class com.sun.jna.Native

I suspect the first one is the most important one here. On the old server I used the telldus-core binary from Telldus repository, but there is none for arm64 so I’ve downloaded and compiled instead (simply cmake, make and then make install). I can communicate with the devices using tdtool.

On both servers I use Oracle’s Java (using the package from webupd8), but “java -version” on the old server tells me it’s 32 bit Java and on the new server it’s 64 bits.

I’m kinda confused here. What needs to be 32 bits and what needs to be 64?

Running OH is 2.2.0 from repository on both servers.

edit: Oh, just for the record: Forgot to mention: The library is in /usr/lib in the package version and it ends up in /usr/local/lib after manual install, but I’ve changed the setting on the Tellstick thing so it finds the library.

Continued digging. From what I can see both Java and telldus (libraries and executables) are 64 bits on my new server, so it should match. @jarlebh, any ideas?

It might be that there is no JNA library for arm64. We could try to update the version of the JNA library, do you know enough about java to do this ?
Basically download the tellstick addon, unzip, replace the jna library with the latest version available. Zip it back and deploy to addons folder.

Jarle

Ok, I’ll try. I’m using the 2.2.0 stable version now, is that ok? Just take the jar and replace jna-4.0.0.jar with jna-4.5.1.jar and see what happens?

I checked in the jna jar files. 4.0.0 contains only libjnidispatch.so for linux-arm, 4.5.1 also has one for linux-armel and linux-aarch64 so this might very well fix stuff. Can’t test until I’m at home though…

Yes, just make sure that you rename jna-4.5.1 to jna-4.0.0

Jarle

1 Like

Yep, that did the trick. Thanks a lot!

I guess you ought to update the jna version included in the binding? You want me to register a ticket about it?

Oh, just for the record. I tried my new jar (with jna 4.5.1) on my old 32 bit server as well and it did NOT work there. I just get the “please make sure Telldus is installed and correct 32/64 bit java” error. Can’t really understand why, since I thought jna 4.5.1 has support for BOTH 32 and 64 bits. This isn’t a problem for me (I just copied the original jar back again, works good) but it might be good to know.

Ok. Didn’t get time to continue fiddling with this until today and it turns out it doesn’t work anyway. It finds my controller (Tellstick Duo) and it adds stuff (sensors and devices) to the inbox, but then all the things (both the controller and the others) are offline anyway and I can’t seem to do anything with them. Something else that doesn’t like arm64? Don’t really know where to go from here. You got any use for a debug log to look at, @jarlebh?

Now I think you need to enable debug for the tellstick binding and send me the logs :wink:
You do this in the console
Jarle

Yep, I’ll fix this. I’m trying to get hold of a second Tellstick so I can test this properly on my new server without affecting the “production environment” :slight_smile:

Ok, I’ve got some debug logs now. Doesn’t look like they actually say anythinig useful though :frowning:

https://pastebin.com/Vh5A36xd

What I did now was:

  1. Start the binding
  2. The gateway immediately appears in the inbox, add it as a Thing
  3. Now the devices (only one for testing now) and sensors appear in the inbox, add the device as a Thing
  4. Reconfigure gateway Thing, change library path (don’t know if this actually does anything?)

Which version of the binding are you using as the starting point, I see that the brige is taken down, but the re-initatilization does not seem to finalize.

It’s the 2.2.0 stable binding, just with the jna replaced.

Can you try the same with this version of the binding, you have to replace JNA again.

It looks much the same to me. Here’s a new log: https://pastebin.com/r50SQczj

openhab> bundle:list|grep Tellstick
230 │ Active │ 80 │ 2.3.0.201712190758 │ Tellstick Binding

Anything more I can do here to help find the problem? I guess I won’t be the last person who’d want this to work on arm64 :face_with_raised_eyebrow:

Hi again!
At last I got a 32 bit openhab on a 32 bit jvm and a 32 bit telldus-core running on my server (took quite some fiddling that I hope I dont need to go deeper into here). However the Tellstick binding doesn’t really like me anyway. Things pop up in the inbox and I can add them as Things, but the controller Thing just gets the status UNKNOWN. The only usable info in the log seems to be the following exception, hope it tells you more than it tells me:

11:02:14.102 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception
java.lang.IllegalArgumentException: Invalid calling convention 63
at com.sun.jna.Native.createNativeCallback(Native Method) ~[?:?]
at com.sun.jna.CallbackReference.(CallbackReference.java:263) ~[?:?]
at com.sun.jna.CallbackReference.getFunctionPointer(CallbackReference.java:449) ~[?:?]
at com.sun.jna.CallbackReference.getFunctionPointer(CallbackReference.java:426) ~[?:?]
at com.sun.jna.Function.convertArgument(Function.java:551) ~[?:?]
at com.sun.jna.Function.invoke(Function.java:338) ~[?:?]
at com.sun.jna.Library$Handler.invoke(Library.java:244) ~[?:?]
at com.sun.proxy.$Proxy35.tdRegisterDeviceEvent(Unknown Source) ~[?:?]
at org.tellstick.device.TellsticEventHandler.setupListeners(TellsticEventHandler.java:123) ~[?:?]
at org.tellstick.device.TellsticEventHandler.(TellsticEventHandler.java:48) ~[?:?]
at org.openhab.binding.tellstick.internal.core.TelldusCoreBridgeHandler.setupListeners(TelldusCoreBridgeHandler.java:167) ~[?:?]
at org.openhab.binding.tellstick.internal.core.TelldusCoreBridgeHandler.lambda$0(TelldusCoreBridgeHandler.java:119) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]

edit: Full log here

edit 2: Ha! think I’m finally back on track! Found this upgrade notes which indicates that this error has with my JNA upgrade to do. Now that I’m back on 32 bits I don’t really need the upgraded JNA anyway so I went back to the official binding and it actually seems to work!

edit 3: Ok. After some more digging, it seems the “Invalid calling convention” is something JNA spits out when wrong ABI is used. Guess the problem is that the newer versions of JNA supports aarch64 which the binding then tries to use even though it’s running in 32 bits and then things get weird. So I guess until running entire OH in 64 bits it will be a good idea to NOT upgrade JNA to anything above 4.1.0 :slight_smile: