Detached nodes in ZWave Network viewer

Right, but I did not exclude them myself.

Look at how this looks from my perspective.

For 2 years, the ZStick works without any problems at all. At first, I was
using Domoticz (didn’t like it much), then switched to OpenHab 1.8, then to
2.0RC and then 2.0 Release.

At some point, I even had the infamous SD Card corruption problem on my rPi

  • and still - multiple reinstalls, replacement of the sd card and rPi -
    still - devices would come up instantly after reformat/reinstall/reboot.

Then, one day - a day after I install 2.1 - I want to make a fresh image
backup - boot the rPi back up - devices are shown offline and no longer in
the network. When I wake them manually, OH log shows devices are not in the
network and messages are ignored.

I thought, maybe I screwed up the install, or something - try a new sd
card, new install - problem persists. I reformat a couple times more,
factory reset all devices - problem persists in Openhab, but Domoticz
installed on the same device, same installation of the system - boots up
without a problem, and properly discovers the devices when they wake up.

I get that it’s all probably a major coincidence that problems appeared
after installing 2.1 and kept persisting until I installed everything
manually, but damn if it doesn’t look weird.

There’s one other option - nobody here has control (or I don’t think they
do) over what libs and what versions get installed by third party apps
(like Java, python, Grafana, Influx, etc). Is it not possible that there
was a conflict there that just happened to impact what openhab was doing? I
can’t remember the exact thread here, but then there’s also the question of
OpenJDK. It is known that some things just won’t work with it (like
notifications didn’t work for me the first time I tried it, but started
working immediately after installing Oracle Java).

I’m probably a one off here, so it’s not worth the time to troubleshoot
until someone else reports this, but I had to check if someone else might
have had the same problem I did.

2017-07-13 09:03:55 +0000 SiHui :

Yes, definitely :smile:

But you did

After resetting a device it is excluded from the controller as far as I know

Also have in mind that deleting a Thing does not mean exclude a device from the stick.

Can’t remember reading anything like this, but maybe someone will respond who had similar issues.

Anyway, as long as it works now you might have more luck for the future :thumbsup:

A couple of versions back I had a similar issue, I noticed a wired light switch wasn’t responding and looking at the logs it showed that the node was missing as if it had been excluded. When I rebooted OH2 I noted the printout the binding does of all the nodes did not list the excluded node. I took the stick down there and re included it, plugged it back in and rebooted. The weird thing was that the node was back with the same node id, not a new node.

It hasn’t happened since so I just assumed my zstick had a stroke or something (I had been rebooting a lot at the time)

I have a similar problem.

In the log it says

NODE 4: Not initialized yet, ignoring message.

When I then push the button on the danfoss lc-13 the following Error is showned in the log:

==> /var/log/openhab2/openhab.log <==

2018-08-31 08:57:25.718 [ERROR] [ve.internal.protocol.ZWaveController] - Exception during ZWave thread: Input 2. {}

java.lang.ClassCastException: org.eclipse.smarthome.config.discovery.internal.DiscoveryResultImpl cannot be cast to org.eclipse.smarthome.config.discovery.DiscoveryResult

	at$2$1.accept( [?:?]

	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining( [?:?]

	at [?:?]

	at [?:?]

	at$ReduceOp.evaluateSequential( [?:?]

	at [?:?]

	at [?:?]

	at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl$1.getExistingDiscoveryResult( [90:org.eclipse.smarthome.config.discovery:]

	at org.openhab.binding.zwave.discovery.ZWaveDiscoveryService.deviceDiscovered( [198:org.openhab.binding.zwave:]

	at org.openhab.binding.zwave.handler.ZWaveControllerHandler.ZWaveIncomingEvent( [198:org.openhab.binding.zwave:]

	at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners( [198:org.openhab.binding.zwave:]

	at org.openhab.binding.zwave.internal.protocol.serialmessage.ApplicationUpdateMessageClass.handleRequest( [198:org.openhab.binding.zwave:]

	at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage( [198:org.openhab.binding.zwave:]

	at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage( [198:org.openhab.binding.zwave:]

	at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$7( [198:org.openhab.binding.zwave:]

	at org.openhab.binding.zwave.internal.protocol.ZWaveController$ [198:org.openhab.binding.zwave:]

Make sure through karaf that only one instance of the zwave bindings is running.
Also clearing cache and tmp could help.

I had the very same problems with my LC13’s and I think I have solved them now. The nodes still show up as detached, but they automatically reconnect when I restart the server (no need to take every thermostats battery out after each restart) and they stay connected. Here’s what I did:

  • Add the nodes using HABmin, rather than the Paper UI. In contrast to Paper UI, HABmin correctly determined the right attributes of the LC13: Basic Class = ROUTING_SLAVE, Generic Class = THERMOSTAT and Specific Class = SETPOINT_THERMOSTAT. With Paper UI, the discovered attributes were SLAVE, NOT_KNOWN and NOT_USED respectively.
  • I set the Wakeup Interval to 600 seconds.

Hope this helps.