since yesterday (I had a power outage, not sure if this is related), I have an issue with the ZWave Controller.
2019-04-25 21:07:19.088 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.zwave.handler.ZWaveSerialHandler@ab460e': null
java.lang.NullPointerException: null
at org.openhab.binding.zwave.handler.ZWaveSerialHandler.initialize(ZWaveSerialHandler.java:86) ~[?:?]
at sun.reflect.GeneratedMethodAccessor51.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
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) [?:?]
2019-04-25 21:07:19.172 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'zwave:serial_zstick:512': null
java.lang.NullPointerException: null
at org.openhab.binding.zwave.handler.ZWaveSerialHandler.initialize(ZWaveSerialHandler.java:86) ~[?:?]
at sun.reflect.GeneratedMethodAccessor51.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
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) [?:?]
In paper UI, the port is actually shown twice.
This happens with every restart of the openhab instance (on Raspi). When I manually change the port for the controller, it comes up again. But then I have to delete/include all my ZWave devices again …
How can I get this fixed?
Are you using a 2.5 zwave snapshot binding? If you search the community, this issue has been discussed recently. Updating to the latest snapshot might fix it.
Going back to the 2.4 binding fixed it for me. I subsequently upgraded to the OH 2.5 Milestone test build, and the zwave binding works properly. So, I’m sticking with that for now.
I saw the posts regarding the 2.5 snapshot already.
I run 2.4 stable with the zwave binding version . the issue only started a few days back, actually when the system rebooted after the power outage.
I think, the poweroutage may have corrupted my system. I have strange behaviour. every now and then, I loose access to the system from my mobile devices and from the windows pc. with the latest reboot I got “Failed to start hdcpcd on all interfaces” and can nolonger access the system at all from any other device.
I guess I may have to set it up from scratch again??
No… this started after the ESH reintegration, so will only be in the OH snapshots.
The power outage certainly could have caused hardware damage, or caused data corruption. If you’re on a Pi and using an SD card, swap out the card with a new one and restore your last backup. If it works, then you have it narrowed down to a bad SD or data corruption. If not, you may need to replace more hardware.
I have the system more or less up and running but continue have issues with the port for the zwave controller after every reboot.
2019-04-27 19:12:32.249 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyACM0'
2019-04-27 19:12:32.268 [WARN ] [erial.internal.SerialPortManagerImpl] - No SerialPortProvider found for: /dev/ttyACM0
I need to change the port in Paper UI, then restart openhabian again and change the port in Paper UI back … then it is working again
I run 2.4 stable.
How can I fix this issue? Any help is appreciated.
I am going to guess that this is a startup issue. Well, I mean, you’ve basically stated this, but to be more precise, I suspect that this is another issue with OH startup order.
I’m not 100% sure how everything hangs together with the serial port providers, but I think that the ESH serial driver will have different providers register on startup. Currently, I think there are 2 providers - the nrjavaserial driver for normal COM ports, and the RFC2217 driver.
My guess is that when the binding starts, the nrjavaserial driver is not yet loaded, and you therefore get the “no provider found” error. Restarting the binding, or changing the serial port (which reinitialises as well) a short time later probably solves the issue as the provider is registered.
As I say, this is a guess and unfortunately I’m not sure how to resolve it if it is what is happening. Maybe the OSGi startup ordering can be adjusted to improve this, although I think startup ordering has always been a significant issue in general, and I don’t think it’s fully solved (but I might be wrong).
@chris
thank you for your perspective.
Questions I have: If it is a start-up issue, shouldn’t everyone be affected? Who can I address this issue to? Is there any way to circumvent it until it gets resolved?
thanks.
No - because the startup order of bundles is not (completely) defined. I recall some time back there was some work to try and improve startup order, but I’m not sure it was really improved too much.
So, it probably depends on the speed of your system, and the order in which bundles are started, the number of bundles that need to be loaded etc…
I don’t really know - I guess you can open an issue on GH and one of the OSGi gurus might be able to take a look.
Note that I could be completely wrong in my assessment - but it seems likely to me at least. There are some OSGi settings to try to ensure some level of startup dependance with start levels, but I don’t know how that is configured in OH.
