I am having a problem with the Z-Wave binding for OH2. I can successfully configure the Z-Wave binding and the devices (things) are working as expected, but after a reboot all Z-Wave devices (including the controller) remain in the state “INITIALIZING” in Paper UI - there is also no Z-Wave activity in the logs.
This is the only stuff I see in the logs after restarting:
The current OH2 runtime is broken. This isn’t a problem with the ZWave binding, but a problem in ESH. I saw a fix was merged this afternoon, so maybe it will flow through and be fixed in the next day or so.
Hi Chris,
thanks for your quick reply. I got that.
It’s possible to manually trigger the initialization by changing some values of the controller - however, that is not a solution.
Thanks again, looking forward to the fix of that problem.
I’m travelling today and back home tomorrow, but am hoping that this fixes the issue as my system hasn’t worked at all since Saturday or Sunday when I ‘upgraded’.
2016-07-09
01:44:53.452 [INFO ] [ome.core.thing.internal.ThingManager] - Not delegating
command ‘ON’ for item ‘EW_Switch’ to handler for channel
’zwave:device:controller:node4:switch_binary’, because thing is not initialized
(must be in status ONLINE or OFFLINE).
Phil, you mentioned that it is possible to manually trigger
the initialization. Can this be done through a static configuration i.e.
programmatically (through rules or somewhere else)?
I upgraded to the latest binding on Thursday evening and still had similar issues. I looked at upgrading again yesterday, but late last night it was still building ESH so I didn’t bother - I’m not sure if this will have flowed through into the binding this morning or not.
Manually triggering initialisation (if that’s possible) probably isn’t a good idea. This will change the state of the thing to something that the binding doesn’t know about. If the binding thinks the thing isn’t initialised, then there’s a reason for that and I wouldn’t try and bodge it.
Currently I am not having these problems with the Z-Wave binding. But I am having it when I install other bindings like NTP. @Martin_C, what I do to manually “trigger” initialization is I change the controller port to something bad and force it to go “offline” (because after the binding configuration change, the Z-Wave binding starts working). After that I change it back to the correct port - sometimes this helps and sometimes I have to restart openhab2 after that to finally make Z-Wave work. Not sure if doing this is recommended (@chris ?) and if it can be done using a script. Hopefully it is just a workaround for a limited time.
That is what I meant - sometimes it does only set the controller to “Online”. For me it works if I restart openhab2 (and the platform (RPI2)) after that.
My guess would be that just restarting the runtime would do the same thing and changing the port probably doesn’t make too much difference - but it’s a guess. Changing the COM port will reinitialise the thing, but this probably doesn’t do a lot in the grand scheme of things.
Yes the controller being stuck on INITIALIZING is intermittent. If I restart OH2 a few times, it comes back to online. In my case, it is my node being stuck on INITIALIZING that I cannot seem to shake off. No dice with today’s version either.
As a matter of interest, did you delete (or rename!) the mapdb folder in your userdata folder so that this gets recreated? It will destroy your system (unless you use the text files for configuration) but I found I needed to do this with todays version.
I still have issues with the version today - not with ZWave as that appears to work, but with another binding. So I’m not exactly sure it’s working well, but might be worth trying to rename mapdb to see if it helps - you can always rename it back either way.
With every new download (I’m trying offline and online just for kicks), I move the existing openhab root to archive and copy the existing conf folder to the new version. Consequently the userdata folder should be clean.
I’m just wondering if I screwed up something my node definitions (things or items) and caused this everlasting intialization state. Is there a lower level of traces (without doing full code debug as I’m not setup for this) I can enable to figure out more details about why it is stuck in this state?
The log at debug level should be find, but if it’s only enabled for ZWave, then it might not be complete as the exception might occur elsewhere (ie in the core). You can enable full debug in the console by typing log:set debug and then change it back to info later.
I’d be interested to know if you have an exception anywhere that talks about a missing callback…
If you want to send me a full log during startup I can take a look.
Hi Chris, I sent you the logs by email (not sure what the proper procedure is here as I can only add pdfs). Meanwhile I’ll continue trying my luck, see if I find anything. Thanks.
The changes last week didn’t work, but I saw Kai thinks he’s found the problem with the startup yesterday so hopefully it will flow through the system over the next few days (I just checked and the fix is not yet merged).
Once this issue is resolved, we can see if there are any problems with the Z-Wave binding.
