[SOLVED] Trouble with Plum - Java permissions?

I’m having trouble with the Plum binding.

I recently built and bought a new home server, and migrated all of my services over from my old 2008 Dell to it. Most everything is working properly (and faster) on the new build, but the major exception is my Plum binding. It looks like Plum has gone under, but I don’t think that’s the cause of my problems (thought it could potentially complicate solutions). The binding worked up until the day I made my transition over to the new server.

It’s strange because the motion events are passed as expected via the binding, but no light control is possible. Based on the logs, it looks like some kind of java permissions issue, but I’m at a loss as how to fix it.

The binding appears to start fine:

2019-04-02 01:55:45.093 [INFO ] [g.openhab.binding.plum.PlumActivator] - Plum binding has been started.
2019-04-02 01:55:45.107 [INFO ] [ing.plum.internal.PlumMotionWatchdog] - Starting Plum motion sensor watchdog
2019-04-02 01:55:45.107 [WARN ] [enhab.binding.plum.PlumActiveBinding] - The Plum Binding does not support runtime updates. Restart OpenHAB for item changes to take effect
2019-04-02 01:55:45.109 [INFO ] [b.core.service.AbstractActiveService] - Plum has been started
2019-04-02 01:55:45.297 [INFO ] [ing.plum.internal.PlumMotionWatchdog] - Starting Plum motion sensor watchdog
2019-04-02 01:55:45.300 [INFO ] [.plum.internal.PlumTCPStreamListener] - Starting monitor thread for Plum IP: 192.168.1.91
2019-04-02 01:55:45.298 [INFO ] [ding.plum.PlumGenericBindingProvider] - processing item "V_3DIN_Fixture_MotionContact" read from .items file with cfg string 192.168.1.91:bfe1363d-1286-4211-bf2c-a1c184e7d9ad#motion
2019-04-02 01:55:45.301 [INFO ] [ing.plum.internal.PlumMotionWatchdog] - Starting Plum motion sensor watchdog
2019-04-02 01:55:45.301 [INFO ] [.plum.internal.PlumTCPStreamListener] - Starting monitor thread for Plum IP: 192.168.1.92
2019-04-02 01:55:45.301 [INFO ] [ding.plum.PlumGenericBindingProvider] - processing item "V_3KIT_Fixture_MotionContact" read from .items file with cfg string 192.168.1.92:db74fb2a-7c68-46b2-ac55-b6fc7fb4beca#motion
2019-04-02 01:55:45.302 [INFO ] [ing.plum.internal.PlumMotionWatchdog] - Starting Plum motion sensor watchdog
2019-04-02 01:55:45.302 [INFO ] [ding.plum.PlumGenericBindingProvider] - processing item "A_3DIN_Fixture_Dimmer" read from .items file with cfg string 192.168.1.91:bfe1363d-1286-4211-bf2c-a1c184e7d9ad#dimmer
2019-04-02 01:55:45.301 [INFO ] [ding.plum.PlumGenericBindingProvider] - processing item "V_3KIT_Fixture_MotionContact" read from .items file with cfg string 192.168.1.92:db74fb2a-7c68-46b2-ac55-b6fc7fb4beca#motion

However, these then appear in the logs at regular intervals, one for each of my two LightPads:

2019-04-02 01:45:50.788 [ERROR] [enhab.binding.plum.PlumActiveBinding] - Plum HTTP Request to IP 192.168.1.91 returned ERROR javax.net.ssl.SSLException: Received fatal alert: insufficient_security
2019-04-02 01:45:50.889 [ERROR] [enhab.binding.plum.PlumActiveBinding] - Plum HTTP Request to IP 192.168.1.92 returned ERROR javax.net.ssl.SSLException: Received fatal alert: insufficient_security

Old build:
2008 Dell Studio (I don’t see anything else on the case and it’s taken apart)
Ubuntu 16.04 LTS
openHAB 2.4 Release inside a Docker (via systemd)

New Build:
AMD Ryzen 5 2600 processor
ARock B450 motherboard
32 gb RAM
Ubuntu 18.10
openHAB 2.5M1 inside Docker (again, as a systemd service)

The new build was set up with a few minor changes that I don’t think are in play, but I’ll include anyway. Shinobi (CCTV) and node-red were both installed on bare metal (for various reasons). On the previous setup they were both containers.

What I’ve tried:
Installed Zulu JDK 8 (on host, obviously)
Crypto policy = unlimited (see my openhab.service file below)
Ensured that openhab user (9001) has permission to read the binding jar
Cleared the cache
Uninstalled and reinstalled binding
Lightpads and server all use static IPs (assigned by router)

Here’s my systemd service file:

[Unit]
Description=openHAB 2
Requires=docker.service
After=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/docker run --name=%n --net=host --tty \
  -v /etc/localtime:/etc/localtime:ro \
  -v /etc/timezone:/etc/timezone:ro \
  -v /opt/openhab/conf:/openhab/conf \
  -v /opt/openhab/userdata:/openhab/userdata \
  -v /opt/openhab/addons:/openhab/addons \
  -v /opt/openhab/.java:/openhab/.java \
  --device=/dev/ttyUSB0 \
  --device=/dev/ttyACM0 \
  -e USER_ID=9001 \
  -e GROUP_ID=9001 \
  openhab/openhab:milestone
ExecStop=/usr/bin/docker stop -t 2 %n ; /usr/bin/docker rm -f %n

[Install]
WantedBy=multi-user.target

Even though the Plum is essentially a dead product, I was hoping to still get some good years out of use of them. They are attractive and integrate really well with openHAB. I would be really grateful for some advice!

which ? (java -version)
Your problem is around TLS and there used to be problems with that and crypto policies in older JDK versions, try upgrading to latest update.

Thanks for the suggestion. I uninstalled the old JDK and installed via apt install default-jre.

I have a new error:

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.plum [191]
  Unresolved requirement: Import-Package: org.openhab.core.autoupdate
	at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]

Dunno neither that error nor package. Is that latest Zulu JDK now ? If yes, it might be sufficient to reinstall openHAB. But your setup has so many variables (Docker, JDK you don’t tell, your homegrown systemd startup mechanism etc) that it can be anything.

And then you state

AFAIK, this is the openJDK Runtime Environment and not Zulu!
There are indeed some known issues with openJDK, Zulu builds seem to be more reliable.
For Zulu, try this. Of course, you can stick to Oracle, but licensing might be an issue!

Not sure about x86 but with ARM/Raspbian, Azul stopped updating repo at 8u152.
So double-check and eventually resort to manual download.

Not for amd64!

If you use the Docker container you don’t need any Java on your host at all.
It’s self contained inside the container. :wink:

I don’t see it being used anywhere in that file? You could try adding:

-e CRYPTO_POLICY=unlimited

You’ll probably need to recreate the container before it picks up the new environment variables.

That’s my mistake. I added it after starting this post and forgot to update the post. Since the service destroys and recreates the container each time it runs, that should be sufficient, right? I did clear the /userdata/cache and /userdata/tmp folders as well for good measure.

It sounds like the version on the host machine is irrelevant. I’ll still try the up to date Zulu version since I’m kinda out of ideas.

I see that binding uses HTTPS. Did you check if those devices still have valid HTTPS certificates? Maybe they use self signed certificates and need to be imported into the Java keystore again.

Maybe @mikenemat also has some suggestions?

I wonder if plum’s SSL cert expired since they went out of business. I’ll take a look this weekend.

1 Like

Hah, I can’t take credit for that. That’s all thanks to the Docker master @rlkoshak.

Nothing is that significantly different besides a newer OS and newer version of openHAB, so this unfortunately seems possible. I’ll be curious to hear your thoughts. Either way, thanks for your efforts in developing this binding!

Actually I don’t use systemd for startup of containers any longer. When I posted that original tutorial I was just learning Docker and didn’t understand that I could do everything through Docker itself. Now I just set the restart flags and let Docker manage restarting it and starting it at boot.

Hah, that’s funny. Here I thought it was a superior way to do it!

Sounds similar to my issue. I’m guessing the loss of something in the userdata folder is what brought this problem to light.

I’ve been too busy to try much on my end, only thing I’ve done is make openHAB a regular container rather than a service. It didn’t help.

For the benefit of anyone who finds this - the new JAR located on this GitHub page fixes the issue for me.

Thanks @mikenemat for your work! My smart home is smart again!

Make sure to follow the directions on the page by logging in to the karaf console to properly uninstall the old binding before installing the new one.