I was away for a week and returned to two new zwave devices in the mail.
I’m on openhabian snapshot.
I added the first and it was found but not recognized as in the database. (Strange since it has been there for over a year…)
So I removed it and used openhabian-config updated to the latest snapshot.
I shutdown OH and rebooted the pi.
At that point all my devices except the hub (Aeotec gen5 usb stick) showed as not initialized.
I then added the NZW36 and it was included just fine. But could not be switched on/off.
BUT! a new usb controller controller also showed up. (a duplicate of the first)
So, I added it. It showed as off-line because the serial port was in use.
So, I removed the original one.
Then the new one went on-line and all my devices showed up as newly added devices (all with different names from the originals, most notably all have format, for example: zwave:device:512:node13:switch_dimmer as opposed to the original: zwave:device:16500637f6a:node13:switch_dimmer. Note the 512 instead of 16500637f6a.)
So, now I have a whole bunch of devices whose names don’t match the previously associated items.
And a bunch of old things that I had to disassociate from the items, before they’d link to the new.
And a bunch of rules that are probably broken.
I only have 16 devices now, so fixing it was annoying, but, doable.
What I want to avoid is when I have 100 devices and lots of rules having to re-do this.
It’s a randomly(?) generated ID for the new controller thing, you can change it to whatever you want during creation, here:
For example, i’ve renamed mine to be “zStick” so all my zwave things show like this: zwave:device:zStick:node2:switch_binary. This can be helpful in the future if you ever have to delete the controller thing
Do you mean the ThingID for the controller? This shouldn’t change, as the instructions state to not delete the Thing for the controller. If you did, and added a new Thing for the controller, just delete it again, add it again with the ThingID that you had before. Check your items files (if you have them) for what it was. Then your items will not need to be changed.
But you can also start all over again too. Do a search and replace in your item files with the old/new ThingID and everything should come back up.
Well, since I barged through things before knowing about the instructions, I did delete the old controller thing and add the newly found one.
Since the things and the items were added in habmin/paperui I don’t have thing/item files I can edit right?
I now have new things with the new controller thing id. And, additionally, I have all the old things with the old controller id. And these won’t go away. If I click the trashcan, they get marked “REMOVING”, but never disappear. I tried the clear cache trick and they all came back marked “UNINITIALIZED”.
Ok, so I now have a controller with the old ThingID.
But, the old things that match that ID still show as “UNITIALIZED”.
If I remove one then scan again it shows up as online, but the device can’t be controlled and I get java Null pointer errors in the log:
2018-09-13 09:53:29.480 [ERROR] [me.core.internal.events.EventHandler] - Dispatching/filtering event for subscriber 'org.eclipse.smarthome.core.events.EventSubscriber' failed: null
at org.eclipse.smarthome.core.thing.internal.AutoUpdateManager.receiveCommand(AutoUpdateManager.java:141) [100:org.eclipse.smarthome.core.thing:0.10.0.201809111909]
at org.eclipse.smarthome.core.thing.internal.CommunicationManager.receiveCommand(CommunicationManager.java:266) [100:org.eclipse.smarthome.core.thing:0.10.0.201809111909]
at org.eclipse.smarthome.core.thing.internal.CommunicationManager.receive(CommunicationManager.java:145) [100:org.eclipse.smarthome.core.thing:0.10.0.201809111909]
at sun.reflect.GeneratedMethodAccessor37.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) [94:org.eclipse.smarthome.core:0.10.0.201809111909]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [94:org.eclipse.smarthome.core:0.10.0.201809111909]
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) [?:?]
What version do you see when you start Karaf? It will give you a build number. The latest is build 1361. I’m still on 1348, but I should have some time later today to try out 1361 in a test environment. I’m only guessing, but this may be related to…
I’m curious… did you have to relink all of your items after deleting/rediscovering the Things? When using .items files, the links are reestablished when the Things come back in, because the channels are the same. I wonder if you would get the same error if you created an item in a .items file.