Zooz ZEN30 relay not working

daemonalec · April 19, 2024, 12:07am

I have a ZEN30 which reports these messages:

2024-04-18 18:56:11.516 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 223: Command received zwave:device:52c7787c89:node223:switch_binary1 --> ON [OnOffType]
2024-04-18 18:56:11.525 [DEBUG] [converter.ZWaveBinarySwitchConverter] - NODE 223: Command class class COMMAND_CLASS_SWITCH_BINARY for endpoint 1 not found
2024-04-18 18:56:11.527 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 223: No messages returned from converter

when trying to activate it via OpenHAB. I’ve tried with both OpenHAB 3.4.0 and 4.1.2; once 4.1.2 was installed I did exclude and include the device again.

Anyone have any ideas?

apella12 · April 19, 2024, 11:44am

I don’t have the device, but looked briefly at the manual. What is your setup? Do you have the relays connected to a light? If not, is it connected to power? One potential issue is that if the relay is unconnected to anything, the device will not respond that the binary switch is supported.

daemonalec · April 21, 2024, 4:06pm

The relay is connected to a fan; the dimmer is connected to a light. The manual controls for the dimmer and relay both function as I expect they should.

apella12 · April 21, 2024, 9:47pm

What does the XML in userdata/zwave folder look like? Does anything look like EP 1 related?

One diagnostic idea to do the manual control for the relay while the binding is in debug to see what happens from that direction.

The other diagnostic idea to reinitialize the node while the binding is in debug to see if EP gets configured.

I’m wondering if the NIF is missing something, so the binding is not asking about it.

rpwong · April 22, 2024, 1:29am

I’ve had a Zen30 working for four years without issues, and I don’t recall having any trouble setting it up. Is there anything I can provide from my system to help? I suppose I could try doing a fresh installation to see if the binding can pick it up.

daemonalec · April 22, 2024, 3:06am

Hrm… so I glanced at the XML in userdata/zwave and this extracted bit seems suspicious:

# grep -C4 '<endPoint>' network_d73e0eed__node_223.xml 
  </associationGroups>
  <endpoints class="concurrent-hash-map">
    <entry>
      <int>0</int>
      <endPoint>
        <deviceClass>
          <basicDeviceClass>BASIC_TYPE_ROUTING_SLAVE</basicDeviceClass>
          <genericDeviceClass>GENERIC_TYPE_SWITCH_MULTILEVEL</genericDeviceClass>
          <specificDeviceClass>SPECIFIC_TYPE_NOT_USED</specificDeviceClass>
--
      </endPoint>
    </entry>
    <entry>
      <int>1</int>
      <endPoint>
        <deviceClass>
          <basicDeviceClass>BASIC_TYPE_ROUTING_SLAVE</basicDeviceClass>
          <genericDeviceClass>GENERIC_TYPE_SWITCH_MULTILEVEL</genericDeviceClass>
          <specificDeviceClass>SPECIFIC_TYPE_NOT_USED</specificDeviceClass>
--
      </endPoint>
    </entry>
    <entry>
      <int>2</int>
      <endPoint>
        <deviceClass>
          <basicDeviceClass>BASIC_TYPE_ROUTING_SLAVE</basicDeviceClass>
          <genericDeviceClass>GENERIC_TYPE_SWITCH_BINARY</genericDeviceClass>
          <specificDeviceClass>SPECIFIC_TYPE_NOT_USED</specificDeviceClass>
#

I’m happy to share the whole file, but I think this gets the point across that there are two GENERIC_TYPE_SWITCH_MULTILEVEL endpoints and then endpoint 2 is the GENERIC_TYPE_SWITCH_BINARY.

I did delete the relevant thing, stop openhab, delete the relevant XML file, start openhab, re-add the thing. It re-created the XML file in the same way.

I then stopped openhab, manually edited the XML to remove endpoint 1, and renamed endpoint 2 to endpoint 1; restarted openhab, and the log now shows something more reasonable (this is from the online log viewer):

22:04:02.293	223	
COMMAND RECEIVED zwave:device:52c7787c89:node223:switch_binary1 OFF [OnOffType]
22:04:03.974	223	
TX REQ SendData 177 MULTI_CHANNEL_CMD_ENCAP EP-1 -> EP-1 SWITCH_BINARY_SET OFF  ACK AUTO_ROUTE EXPLORE
22:04:03.984	223	
RX RES SendData 177 ACCEPTED BY CONTROLLER 0 /128
22:04:04.036	223	
RX REQ SendData 177 ACK RECEIVED from device in 62ms 0 /128

I don’t have any explanation for why the XMLwas goofy (and I am not actually close enough to the ZEN30 to tell if the relay is activating remotely or not).

daemonalec · April 22, 2024, 12:55pm

The relay does not respond to zwave control with the above changes. https://www.support.getzooz.com/kb/article/468-zen30-double-switch-advanced-settings/ mentions that there are three hardware versions of the ZEN 30, I wonder if the version I have has different endpoint configuration from the device database?

apella12 · April 22, 2024, 12:55pm

According to the ZW DB OpenSmartHouse Z-Wave Device Database, there is no EP2, so I also do not know how that got there, unless the device itself is advertising it. I’d be curious as to what @rpwong XML looks like.

Also might want to review the FW change log. ZEN30 Double Switch Change Log - Zooz Support Center (getzooz.com) to see if anything pops up

apella12 · April 22, 2024, 1:46pm

This could still have value, but the reason has changed. Now looking for when/why EP 2 is created.
Also the command class information in the Debug is important and is stripped by the viewer.

rpwong · April 22, 2024, 4:32pm

Here’s my XML file. I don’t know what you’re looking for, so I’ve attached the whole thing.

network_d696818f__node_11.xml (21.6 KB)

It’s worth noting that my ZEN30 will probably be a v1, with old firmware.

apella12 · April 22, 2024, 6:46pm

Thanks @rpwong I was mostly looking at the EP 1 CCs. Your device aligns with the ZW DB entry and works, the “not working” ZEN30 XML appears different. Based on the Zooz change log, you are (as you suspected) on version 1.03 (original release). Does your UI page show FW version under properties?

In many devices EP0 and EP 1 are mirrors. In the original ZEN30 device this was not true, but in the non-working device this seems to be the case (can’t tell for sure, since the entire XML was not shown) and to cover the relay, EP 2 was added. I’m guessing the non-working device is the latest ZEN30 (is there a reference to 800 chip or ZWLR on the package?).

Anyway, I think a call to Zooz is needed to confirm this theory. If true, @daemonalec could test by adding this XML
zen30_0_0.xml (25.0 KB)
to the binding following this procedure. If that works the ZW DB will need to be modified

Note that the userdata/zwave XMLs are different than the binding XMLs. Userdata XML’s are also overwritten frequently, so changes in them won’t work (or won’t work for long).

rpwong · April 22, 2024, 7:53pm

Nope. I wondered about that earlier. I see a zwave_version 1.3, but nothing for firmware or 1.03.

It would be nice if we could add both the v2 and v3 hardware, but I assume we’d need one of each to ensure that it works.

chris · April 22, 2024, 8:43pm

That is the firmware version - 1.3, 1.03 - it’s the same in ZWave since it’s treated as a major.minor version (so the 1 is the major version, and the 3 is the minor version)…

rpwong · April 22, 2024, 8:45pm

Correction: I saw the firmware version in properties, but didn’t know that I was looking at it.

daemonalec · April 23, 2024, 2:22pm

zen30_0_0.xml does work for me. The device properties show zwave_version = 4.10. I’ve added a device or two to the database over the years, but am certainly not an expert at it. Should I take a shot at updating the database per the instructions?

apella12 · April 23, 2024, 2:42pm

Give it a go. I could take an unofficial review. Two tips to highlight from the blog

change the TYPE:ID on your XML temporarily. You can’t load the same numbers. After loading change them back while adjusting the versions
After loading use the Gear option to import from the old device to save a lot of entries.