NPE in MQTT when starting up as a daemon

Add-ons Bindings
1

Hi!
I’m facing an issue with MQTT binding. When I start OpenHAB 3.3.0 via ssh on my raspberry, everything works fine, but I need to have the ssh session running all the time and cannot disconnect my laptop from the network, otherwise OpenHAB gets killed.
So I created an init script using start-stop-daemon, which is basically just running the start.sh the same way as I run it and also using the same user. But when started like that, it crashes during the startup and it is 100% reproducible. I can see following exceptions in openhab.log:

2022-08-25 22:16:57.339 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.mqtt.generic.internal.handler.GenericMQTTThingHandler@1b13535': null
java.lang.NullPointerException: null
	at org.openhab.binding.mqtt.generic.internal.handler.GenericMQTTThingHandler.initialize(GenericMQTTThingHandler.java:154) ~[?:?]
	at jdk.internal.reflect.GeneratedMethodAccessor47.invoke(Unknown Source) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
	at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]
2022-08-25 22:16:57.438 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'mqtt:topic:victronMqttBroker:EssBattery': null
java.lang.NullPointerException: null
	at org.openhab.binding.mqtt.generic.internal.handler.GenericMQTTThingHandler.initialize(GenericMQTTThingHandler.java:154) ~[?:?]
	at jdk.internal.reflect.GeneratedMethodAccessor47.invoke(Unknown Source) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
	at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]

Any idea why this happens only when not started via ssh and how to fix it?

2

If on a RPi, why not use openHABian where OH is installed and configured to run in the background by default?

Or, since you are running Linux, why not install it using apt which also sets OH to run in the background by default?

It is somewhat odd to choose a manual install on an RPi and it’s going to cause you a bit of extra work.

There’s no reason why it should be failing on the MQTT binding but I can imagine it might be related to networking problems or something like that. Without more logs and perhaps the syslogs so we can see what OH may have output before it came up enough to transition to the logs :person_shrugging: .

It is common to see unusual errors like this if you’ve not installed the proper prerequisites (i.e. Java 11). Perhaps the path to java isn’t the same under that init script as it is when you log in. Remember, systemd doesn’t get a bash shell when it runs those init scripts. So all the stuff in your $PATH and the like won’t be there.

3

Well, the thing is that I got the rpi preinstalled with OpenHAB 1.8 using a custom made binding, which uses some custom libs and I’m not able to convert that to OpenHAB 3 at this point, so I need to have that running in parallel for now. By switching to openhabian I would lose those bits. Also I’m a bit afraid that using the apt based installation would conflict with the setup, so I took the hard way to make it work.
Anyway thanks for the tip with the java version and the overall environment setup. I’ll try to verify that.

4

It’s really not feasible to run two instances of OH on the same RPi. There isn’t enough RAM on any RPi 3 or before. If you were on an RPi 4 which could have enough RAM to run both, you would have had to reinstall everything anyway because the older RaspberryPi OS isn’t compatible with the RPi 4.

So even if you get past this hurdle you are likely headed for trouble. It’ll be a lot less work in the long run to get another RPi to run OH 3 on which will then allow you to use openHABian and/or apt to install it.