[SOLVED] Unable to independently control each output of ZW140

Tags: #<Tag:0x00007fc3ed178b40>

I am unable to independently control each of the two outputs of the ZW140s I am in the process of integrating into my OH2 installation in a new home. All other z-wave devices are working as expected. I am able to control both outputs in unison by linking to the switch channel of endpoint 0, but when I link two unique items to each of the switch channels of endpoints 1 & 2, no control of those two outputs is observed.

I have attached what I think is the relevant part of the zwave log from when I issued a command to two such items. Also attached is the XML for this device.

I open am open to any suggestions.

Thanks in advance!

node_15.log (542.3 KB)
network_cd32e15f__node_15.xml (23.3 KB)

What version of the openhab zwave binding?
From the time I see that device was last updated in the database, you likely need at least 2.5M2 or later to get the most current configuration.

Sorry, I forgot to provide the usual details.

I’m running a relatively recent snapshot here, 2.5.0-SNAPSHOT, Build #1678. The host system is a docker container running under CentOS 7, H/W is a quad core i5 with 32 GiB RAM.

1 Like

Usually edited debug logs are of no use. The zwave log viewer may give you some hints on the issue.

https://www.cd-jackson.com/index.php/openhab/zwave-log-viewer

The content of the log I uploaded was not edited, I simply extracted a contiguous section from the zwave log file.

I’m stumped. I would have thought someone is using a ZW140. Any help or ideas, @chris?

Looking at the log it seems that the command class is not found -:

2019-09-12 10:27:23.807 [DEBUG][    safeCall-65] [converter.ZWaveBinarySwitchConverter] - NODE 15: Command class class COMMAND_CLASS_SWITCH_BINARY for endpoint 1 not found

Looking at the XML confirms this. Either there was some sort of issue during initialisation such that the command class was missed, or the database is wrong and this command class is not supported and we would have to use BASIC (this seems a bit unlikely, although it’s possible).

I would suggest to reinitialise the device for starters. If you can get a log during the initialisation then I will take a look. If the command class doesn’t exist then we will have to think about this some more as it’s quite uncommon to only have BASIC command class (but it does happen on some strange devices - not normal Aeon ones though).

Thank you very much for the quick response. I’ll reinit one of my ZW140s and extract that section of the log for uploading here.

1 Like

Update: Re-reading your reply, I think it’s worth noting that all seven of the ZW140s in my system behave exactly the same way. Is it likely that they all would have initialization issues (no answer expected)?

Ok, there’s another possibility and that is that the device doesn’t correctly report all the command classes it supports. This can be fixed with a database update if needed…

Let’s get the init log and I’ll have a look, and we can see where to go from there…

1 Like

Great, I’ll continue with reinitialization of one of my ZW140s, then post the log segment here.

1 Like

I finally found some time to reinit one of my ZW140s. Its node number is 3. I have uploaded what I think is the complete log of the reinit sequence here: zwave-node_003-reinit.log (8.1 KB)

Scanning through Aeon Labs’ website, I found documentation for updating a ZW140 to version 2 firmware. I may try updating a ZW140 to the version 2 firmware, then reinitializing the updated device.

This isn’t really an initialisation log - it’s only got a single message in the log. This is the very first packet of a sequence that is possibly a few hundred packets.

The initialisation should take something like 10 seconds, and the log should be in the order of a few hundred kilobytes (or even megabytes - depending on what else is happening on the network).

Thanks for the quick reply.

When I get to the construction site this morning, I’ll capture the full sequence. Is there a unique string that can be searched that marks the true end of the initialization sequence?

Yes, I think you should be able to search for NODE 3: Node advancer - advancing to DONE.

OK, I’ve reinitialized the sample ZW140 device again, and this time I think I actually have all of the reinitialization transactions in the log excerpt I’ve uploaded – zwave-node_003-reinit.log (858.8 KB). I doubt that it is any different from the original device XML I uploaded before, but just in case it may be useful, here it is: network_cd32e15f__node_3.xml (22.8 KB)

Thanks for all of your help!

Just wanted to update this thread so it doesn’t get lost. @chris, have you any time to review this recently uploaded node reinit log from post #16 of this thread?

Sorry for the delay.

It looks like the device is not reporting the BINARY SWITCH command class is supported -:

This is inconsistent with the database. I’ve just updated the database to force this into the configuration. Once the database is updated, then you will need to delete the thing and add it back so that your system picks up the new definition.

If that doesn’t work, then it probably means that the command class isn’t supported, and we will need to deal with that differently.

Thanks for the update. I’ll watch for next build with a database update and give it a try. Will inform you here of the results.

I tried again with SNAPSHOT-2.5, build #1705 with the same results, i.e., no independent control of each relay. I broke down and updated the firmware installed on my ZW140s, and that did the trick. If you like, I can post the log of discovery for one of the updated ZW140s as well as the XML.