[SOLVED] Z-Wave devices remain unknown after update

[chris (Chris Jackson)]

@jeffryvu

Where do you see that initialisation has not completed?

It can be inferred from the following

@jeffryvu

2019-01-02 15:34:26.190 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 21: Received COMMAND_CLASS_SWITCH_MULTILEVEL V0 SWITCH_MULTILEVEL_REPORT

This shows the command class is version 0, which should not be correct if the initialisation had completed.

Unfortunately the log is way too short to be of any use - the binding itself has still not really initialised, let alone any of the devices. I would need to see potentially at least a few minutes of logging to see what’s happening - can you provide a longer log and I will take a look.

@jeffryvu

I enabled tracing so the complete log is quite large.

Please just use DEBUG - it should be enough. TRACE is very low level and will make the log a lot larger and harder to read.

Also, please use code fences when posting logs - I’ve edited your log to make it easier to read.

[phate (David Schulz)]

Hey @chris,

many thanks for your quick reaction! As always, I’m surprised about how quickly you manage to respond to support requests - Chapeau!

I’d love to try out the new snapshot version and then get you a complete log. Could you please also drop a hint on where to download the latest snapshot? I’ve tried here https://openhab.ci.cloudbees.com/job/openHAB2-Bundles/lastBuild/org.openhab.binding%24org.openhab.binding.zwave/, but was confronted with a " This DEV@cloud account is currently unavailable" message. Also checked here https://github.com/openhab/org.openhab.binding.zwave/tree/master, but couldn’t locate no .jar file in the repo.
Many thanks for your help again!

–
Edit: Here’s already a larger debug log of today using binding 2.4.0: zwave_log.txt (1003.2 KB)

[phate (David Schulz)]

In addition, I can confirm from Paper UI the command classes apparently having been properly determined while zwave version remains on 0.0:

This situation is present for all my devices - Wired as well as battery powered.

[sihui]

@phate

where to download the latest snapshot?

https://ci.openhab.org/job/openHAB2-Bundles/modules

[phate (David Schulz)]

many thanks, @sihui!
I put the .jar into the addons folder and restarted the OH2 service. Checking the log shows this error twice:

2019-01-02 22:36:01.446 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.zwave-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [287]
  Unresolved requirement: Import-Package: gnu.io

	at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]

Karaf reports the Snapshot being in use:

Any suggestions?

[5iver (Scott Rushworth)]

@phate

Karaf reports the Snapshot being in use

Installed, but not Active. Since you’ve manually installed, you’ll need to manually resolve the dependencies… in this case:

feature:install openhab-transport-serial

Replace bundle with custom version for real world testing

First, uninstall the production version. If it was manually added to addons.cfg, it will need to be removed from there. If not, uninstall through a UI or Karaf. Then copy the jar file into the /addons/ directory. The location of addons depends on the OH installation method, and can be found in the documentation. Once copied into addons, it is best to keep the file name consistent when upgrading, or the older version may get cached, requiring the older bundle to be uninstalled through Karaf, or …

Zigbee and zwave manual install script

A number of people have run into trouble performing manual installs of the Zigbee and Z-Wave bindings. A manual install (dropping the jar into addons) is rarely needed, but some people prefer a manual install over apt-get, or want to use a stable OH release with a recent Zigbee or Z-Wave binding. Here is a script that will hopefully make it easier to install, upgrade, and uninstall these bindings, and prevent some of the common issues. Who would benefit from this script: Anyone wanting to tes…

[phate (David Schulz)]

That worked out fine, many thanks!
To me, the binding now appears to be working properly (see also within this log that shows the success immediately after having resolved the dependency as described by @5iver: zwave_log_250_initialstart.txt (347.1 KB)

All things remained unknown though. Thus, I’ve removed my thermostat thing again and re-added it via the inbox in Paper UI. See here for the log results covering some minutes of traffic: zwave_log_250_node14.txt (1006.6 KB)

Still, I cannot see any thing being properly identified. Maybe, someone can find a hint within the logs?
Thanks again!

[jeffryvu (Jeffry van de Vuurst)]

Thanks for your swift replies Chris, much appreciated!

I’ve set logging to debug and restarted OH. I’m attaching a few zwave xml files, the openhab.log and events.log.

events.log (17.5 KB)
openhab.log (530.0 KB)
network_0184e4e9__node_5.xml (2.3 KB)
network_0184e4e9__node_6.xml (1.9 KB)
network_0184e4e9__node_7.xml (2.3 KB)

[chris (Chris Jackson)]

There are 2 issues I note in the log. The main problem is that the controller seems to be rejecting most or all commands being sent to the controller from the binding. From below, we see the binding send a command, which is ACK’d by the controller as being received OK, and then rejected for some reason.

What controller do you have?

The other thing I note is that some of your devices seem to flood the network. Possibly this is misconfiguration of the associations in the device (but I think it’s unlikely given the large number of frames), or it might be indicative of some other problem (maybe related to the above issue) if the controller is not receiving the data. In the event that the controller doesn’t ACK messages sent from devices, then the device will resend, and you can end up with multiple messages being received.

Above we see around 20 messages being received - the information is exactly the same in all of them, although about 2/3rds of the way through something in the control area does change and I need to have a better look at that to see what it means.

This same thing happens whenever data is received from lots of nodes, so my guess is some sort of controller problem. This isn’t something the binding can really influence, so I’m suspicious that there is something wrong with the controller. Have you reset it?

[chris (Chris Jackson)]

@jeffryvu

I’ve set logging to debug and restarted OH. I’m attaching a few zwave xml files, the openhab.log and events.log.

In the log here there is no data received from any device so I’m not sure what I can comment on here. There’s nothing especially wrong that I can see, but there aren’t any device responses at all.

The XML files are also basically empty, so also indicate no communication with the devices.

I’m not sure what to suggest - first would be a soft reset of the controller (ie remove it from the USB so that it power cycles).

[phate (David Schulz)]

Hi @chris,

many thanks for your effort here! Highly appreciated!
I’m using an Aeotec Gen5 stick (see https://aeotec.com/z-wave-usb-stick).So far, I’ve not yet reset it as I’m not too eager about having to re-include all nodes into the network.
With OH 1.8, I’ve used Habmin in order to include the nodes and I’ve ensured each node also has the controller in their groups.
From what I see in Paper UI, the nodes don’t appear to have any neighbours assigned currently:

With OH 2, everything also worked out fine so far (I’m using OH 2 for a couple of months now). It’s just been the latest update onto 2.4 that resulted in this situation, not the major upgrade from OH 1 to OH 2.
As far as I understood, the way the zwave stick is identified / configured has also changed within this latest update, hasn’t it? I’ve so far not adjusted any of the settings that you can apply to the stick via Paper UI (desite the serial port used). Maybe, there’s something that could be tried out in that regards? Or is a complete reset and building up the network again from scratch the only possible option right now?

Many thanks again and best regards!

[chris (Chris Jackson)]

@phate

So far, I’ve not yet reset it as I’m not too eager about having to re-include all nodes into the network.

I didn’t mean a hard reset - just a soft reset for starters.

@phate

From what I see in Paper UI, the nodes don’t appear to have any neighbours assigned currently:

Yes, but at the moment there is no communication with the device, so you can’t rely on any of this information until you resolve the underlying issue.

@phate

As far as I understood, the way the zwave stick is identified / configured has also changed within this latest update, hasn’t it?

Not that I’m aware of, no. There is the option to configure using text files now, but the binding really doesn’t see any difference (it knows nothing about UIs or text files). I think that the way the dongle communicates is largely the same in 2.3 and 2.4. Higher level handling of transactions (ie how messages sent and received are correlated) has changed.

@phate

I’ve so far not adjusted any of the settings that you can apply to the stick

I don’t think there are very many (or any?) that can influence this.

@phate

Or is a complete reset and building up the network again from scratch the only possible option right now?

As above, the first thing I would do is to do a soft reset - ie remove the stick from the USB, wait a bit, then put it back.

[jeffryvu (Jeffry van de Vuurst)]

Thanks, it was a matter of soft resetting the controller. Duh!

[phate (David Schulz)]

Many thanks, this also solved it for me! I could meanwhile get all my rollershutters running again and also the thermostat is working properly. After a while, the door sensor joined in as well. I’m only still missing the smoke detectors and trying to wake them up manually didn’t yet lead to any success, so I hope to be seeing them soon.

What puzzles me a bit is that for one of my wall plug switches (an AEON Labs ZW075) is constantly writing this message package into the log:

2019-01-03 19:41:30.282 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 14 00 04 00 02 0E 32 02 21 74 00 00 00 00 00 00 00 00 00 00 86 
2019-01-03 19:41:30.283 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=2, callback=0, payload=00 02 0E 32 02 21 74 00 00 00 00 00 00 00 00 00 00 
2019-01-03 19:41:30.284 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=2, callback=0, payload=00 02 0E 32 02 21 74 00 00 00 00 00 00 00 00 00 00 
2019-01-03 19:41:30.284 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-01-03 19:41:30.284 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: Application Command Request (ALIVE:DONE)
2019-01-03 19:41:30.284 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: resetResendCount initComplete=true isDead=false
2019-01-03 19:41:30.285 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Incoming command class COMMAND_CLASS_METER, endpoint 0
2019-01-03 19:41:30.285 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: SECURITY NOT required on COMMAND_CLASS_METER
2019-01-03 19:41:30.285 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 2: Received COMMAND_CLASS_METER V3 METER_REPORT
2019-01-03 19:41:30.285 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 2: Meter: Type=Electric(1), Scale=W(2), Value=0E+1
2019-01-03 19:41:30.286 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveMeterValueEvent
2019-01-03 19:41:30.286 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_METER, value = 0E+1
2019-01-03 19:41:30.286 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Updating channel state zwave:device:30ef5acb:node2:meter_watts to 0 [DecimalType]
2019-01-03 19:41:30.287 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: Commands processed 1.
2019-01-03 19:41:30.287 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@77ac7e0e.
2019-01-03 19:41:30.287 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-03 19:41:30.287 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-03 19:41:30.288 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-03 19:41:30.288 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

I have an equal one at another place as well that doesn’t flood so much into my logs. Both of them are switched on with a consumer being switched off, so I don’t quite understand why only this plug is constantly publishing 0 watts to the controller… Everything works fine in that regards though, it’s just the flooding of the logs (and maybe also the network itself, which makes me afraid of further issues coming up in the future). Maybe, someone has an idea of where to configure this? I’ve checked the properties in Paper UI, but they’re the same for both plugs.

Other than that, it turns out that the hexadecimal part of the identifier (e.g. zwave:device:a22ef60c:node7:sensor_door) has changed for all my devices somewhere on the way, so I’ll have to adjust my items accordingly.

Many many thanks once again, @chris for your splendid help on this one!

[jamsven (Sven)]

Hi there I followed the tips here but I still not able to use my fibaro dimmer 2 anymore. All devices came up properly after a few hours, but the dimmer are stayed unknown, after updating to 2.5.

Before (i think it was 2.2) everything was working smoothly and than I updated to 2.5, went though the update tutorial to get all zwave device back in, but it diddn´t worked for the dimmers.
I tried soft reset via UI and also unplug the device.
put the dimmer in inclusion mode,several reboots etc…

I´m running openhabian on Pi and now also updated to the latest snapshot (before I tryed stable).
My zwave usb stick is the ZMEEUZB1 which is directly conntected to the pi.

If you have any suggestion, I would be more than happy to use my lights again

openhab.log (806.8 KB)

[sihui]

@jamsven

went though the update tutorial

Are you sure you deleted the “Thing” and readded it again? I only have one of the Fibaro Dimmer 2, but it is working without any problems in 2.5 snapshot.

[jamsven (Sven)]

After the update, none of my zwave device were going online, so I deleted all and uninstalled the zwave serial controller and reinstalled it again.

All other ZWave items came back and I needed to add them again.
All except the Dimmer. They still show unkown device.
From my understanding the “Thing” insn´t installed in oh yet, since it poping up in the inbox.

[sihui]

@jamsven

All except the Dimmer. They still show unkown device.

Are you sure it is in range of the controller?

Here is one of your FGR222 devices, it shows that the node info was received by the controller.

Here is your dimmer, the controller does not receive the node info:

[jamsven (Sven)]

The dimmers are at a distance of about 3-10m from the zwave dongle without any walls in between. Other devices on other floors much further away are working without any problem. Even now after a week the devices are still on same state.^

When I add the Thing i get following response.

[sihui]

@jamsven

Even now after a week the devices are still on same state.

You are on the right track: providing a debug log. BUT: please post it as text, please use code fences, please don’t filter the log.