ZWS12 Unrecognised Zwave Device

Hi Everyone,

New to openHab so please bear with me! I have 2 problems and hoping someone can provide some suggestions to get these fixed

I’m currently adding all of my ZWave devices to openHab and came across a problem when adding a Fakro ZWS12 Window Winder, the node adds and while there is a ZWS-12 in the ZWave database the node comes up with an unknown ID of Z-Wave Node 36 (0085:0011:0001:4.13) and this is the AU version of the ZWS12

I also have a number of Aeotec Dual Nano modules, the modules include fine and are recognised as the correct device but when trying to add ‘linked items’ from Paper UI for individual switch control for switch 1 and switch 2 the boxes below these variables called ‘remove’ is also linked and the devices never get created in the control tab.

Thank you

It appears that the device ID you are reporting does not map to the device in the Z-Wave DB. You probably need to get a new device added for the AU version.

http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/325

I have a similar issue with Fakro ARZ Z-Wave roller shutters that are instead being reported as Fakro ZWS12 Chain Actuator (12V). I believe the product identifier for the ARZ Z-wave roller shutters were once added to the ZWS12 chain actuator, as can be inferred from the manufacturerRef value (0002:0001,0003:0001,0011:0001).
The certification info for the Fakro ARZ Z-Wave roller shutters can be found online. From what I understand, the ARZ roller shutters correspond with manufacturerRef 0003:0001.
Is there a way to fix this?

It’s a simple database change to move the 0003:0001 from the ZWS12 database entry to the ARZ database entry.

I can make the change. But I’d like to make sure you are 100% certain, as I don’t want to break it for someone else. I know in the past, @chris has been somewhat skeptical of the quality of the information in these certification reports. @chris I hope I’m not putting words in your mouth. :worried:

I see.

For what it’s worth, the same happens in OpenZWave so I suppose the Fakro ARZ Z-Wave entry was once coalesced with the ZWS12 entry at some point since the former more or less seemed to work with the already existing description of the latter. Unless some conversion error occurred when processing the Z-Wave certification information.

Here’s a snippet from the XML serialization of one of my Fakro ARZ Z-Wave roller shutters (found in /var/lib/openhab2/zwave/network_a1b2c3d4__node_2.xml):

<node>
<homeId>0xa1b2c3d4</homeId>
<nodeId>2</nodeId>
<version>4</version>
<manufacturer>0x85</manufacturer>
<deviceId>0x1</deviceId>
<deviceType>0x3</deviceType>
<listening>true</listening>
<frequentlyListening>false</frequentlyListening>
<routing>true</routing>
<security>false</security>
<beaming>true</beaming>
<maxBaudRate>40000</maxBaudRate>
<sleepDelay>1000</sleepDelay>
<nodeInformationFrame>
<commandClass>COMMAND_CLASS_SWITCH_MULTILEVEL</commandClass>
<commandClass>COMMAND_CLASS_SWITCH_ALL</commandClass>
<commandClass>COMMAND_CLASS_SWITCH_BINARY</commandClass>
<commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
<commandClass>COMMAND_CLASS_VERSION</commandClass>
<commandClass>COMMAND_CLASS_POWERLEVEL</commandClass>
</nodeInformationFrame>
<associationGroups class="concurrent-hash-map"/>

<!-- ... detailed description of the defined endpoints ... -->

</node>

What I don’t know however, is whether these data originate from the hardwired binding (configured in the database) or whether it comes from the Z-Wave protocol information. So far I couldn’t make sense from the Z-Wave debug log messages as it appears that only the capabilities of the USB Z-wave stick are being queried at start.

Here’s the relevant snippet from the Fakro ARZ Z-Wave roller shutter XML certification description:

<Id>2571</Id>
<Name>ARZ Z-Wave</Name>
<Brand>FAKRO</Brand>
<Identifier>ARZ Z-Wave</Identifier>
<CertificationNumber>ZC10-18015975</CertificationNumber>
<OemVersion>HW: 23 FW: 1.01:01.01</OemVersion>
<HardwarePlatform>ZM5202</HardwarePlatform>
<ZWaveVersion>6.61.00</ZWaveVersion>
<LibraryType>Enhanced 232 Slave</LibraryType>
<DeviceType>Window Covering - Pos/End Aware</DeviceType>
<RoleType>Always On Slave</RoleType>
<ManufacturerId>0x0085</ManufacturerId>
<ProductTypeId>0x0003</ProductTypeId>
<ProductId>0x0011</ProductId>
<FrequencyName>CEPT (Europe)</FrequencyName>
<UserIcon>0x1A00</UserIcon>
<InstallerIcon>0x1A00</InstallerIcon>

So I see something weird here, since the Z-Wave certification’s ProductId (0x11) for the Fakro ARZ Z-wave roller shutters cannot be mapped to any identifier in OpenHAB. The Z-Wave ProductTypeId (0x03) seems to be mapped to deviceType in OpenHAB.

I would expect that the tuple (ManufacturerId, ProductTypeId, ProductId) = (0x0085, 0x0003, 0x0011) would somehow map to similar values in OpenHAB. How could I find out what’s going wrong at my side?

Take a look in the xml generated for the device in /userdata/zwave/. IIRC, all of this information is read directly from the device.

I’m not sure what you mean by this. The ProductId is the deviceId in the node.xml file. I’m not sure I understand the relevance that the certification report shows 0x11. The certification report is a point-in-time snapshot whose type:id may or may not match the reality of devices currently on the market.

If there was an actual device that announced itself as (0x0085, 0x0003, 0x0011), then that’s what would go in the database as manufacturer:deviceType:deviceId.

Perhaps I’m misunderstanding the point you’re trying to make…

I’m not sure I understand what’s wrong. From your earlier post, I though the question was to determine conclusively whether 0003:0001 should be in this database entry or this database entry.

Here’s what I found in /var/lib/openhab2/zwave/network_a1b2c3d4__node_2.xml:

<node>
  <homeId>0xa1b2c3d4</homeId>
  <nodeId>2</nodeId>
  <version>4</version>
  <manufacturer>0x85</manufacturer>
  <deviceId>0x1</deviceId>
  <deviceType>0x3</deviceType>
  <listening>true</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>true</routing>
  <security>false</security>
  <beaming>true</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <sleepDelay>1000</sleepDelay>
  <nodeInformationFrame>
    <commandClass>COMMAND_CLASS_SWITCH_MULTILEVEL</commandClass>
    <commandClass>COMMAND_CLASS_SWITCH_ALL</commandClass>
    <commandClass>COMMAND_CLASS_SWITCH_BINARY</commandClass>
    <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
    <commandClass>COMMAND_CLASS_VERSION</commandClass>
    <commandClass>COMMAND_CLASS_POWERLEVEL</commandClass>
  </nodeInformationFrame>
  <associationGroups class="concurrent-hash-map"/>

<!-- skipping the endpoints description -->
</node>

So I get DeviceId = 0x01 and DeviceType = 0x03 which seem to correspond with the “old” ZWS12 chain actuator (see the 3rd column in my comparison table below).

I’m unsure what happens here.

Our messages crossed I see.

What I know for sure, is:

  1. I have Fakro ARZ Z-Wave external roller shutters
  2. I can find Z-Wave certification information for those shutters
  3. My roller shutters are invariably being recognised as “old” ZWS12 chain actuators (either in OZW or in OpenHAB), or as “0003:0001”

What I don’t know, is:

  1. How does this mapping to “old” ZWS12 chain actuators (0003:0001) happen
  2. How I could override the product identification on my installation only if this would be a viable workaround

What firmware version is displayed in the properties (or XML)? Maybe this is the differentiator?

The roller shutter I’ve been quoting in this thread, tells “version = 2”, if this is what you’re referring to. There’s no firmware tag in the XML file.

In the Z-Wave certification report, there’s the following info:

  <OemVersion>HW: 23 FW: 1.01:01.01</OemVersion>
  <HardwarePlatform>ZM5202</HardwarePlatform>
  <ZWaveVersion>6.61.00</ZWaveVersion>

I would gladly be able to help providing the missing bits of information. As long as I’m told where to search (e.g. the Z-Wave debug log).

No.

There is, but it’s not in the top part that you pasted above. It is also displayed in the properties which I suggest to look at instead as this provides all the information that should be needed here…

This is also not what we’re after - this is the ZWave protocol version against which it was certified and not really related to the device identification.

Here’s what paper UI tells me from the roller shutters:

dbReference 325
defaultAssociations 1
manufacturerId 0085
manufacturerRef 0002:0001,0003:0001,0011:0001
modelId ZWS12
vendor Fakro
zwave_beaming true
zwave_class_basic BASIC_TYPE_ROUTING_SLAVE
zwave_class_generic GENERIC_TYPE_SWITCH_MULTILEVEL
zwave_class_specific SPECIFIC_TYPE_CLASS_B_MOTOR_CONTROL
zwave_deviceid 1
zwave_devicetype 3
zwave_frequent false
zwave_lastheal 2019-02-06T01:43:14Z
zwave_listening true
zwave_manufacturer 133
zwave_neighbours
zwave_nodeid 2
zwave_routing true
zwave_secure false
zwave_version 2.1

I see no firmware info, only a Z-Wave version tag. However I now realize that there’s version info in COMMAND_CLASS_VERSION description in the XML file as protocolVersion (3.42) and applicationVersion (2.1):

  <entry>
    <commandClass>COMMAND_CLASS_VERSION</commandClass>
    <COMMAND__CLASS__VERSION>
      <version>1</version>
      <instances>1</instances>
      <control>false</control>
      <versionSupported>1</versionSupported>
      <libraryType>LIB_SLAVE_ROUTING</libraryType>
      <protocolVersion>3.42</protocolVersion>
      <applicationVersion>2.1</applicationVersion>
    </COMMAND__CLASS__VERSION>
  </entry>

Does this help?

Yes, this is the firmware version. These properties are a little verbose so it’s not really possible to spell everything out fully.

I just discovered the nifty online Z-Wave debug log viewer, which tells me that it appears that mty Fakro roller shutters indeed report themselves as 0085:0003:0001:

RX REQ ApplicationCommandHandler MANUFACTURER_SPECIFIC_REPORT 0085:0003:0001 (0 /128)
01 10 00 04 00 02 08 72 05 00 85 00 03 00 01 AA 00 BB

RX REQ ApplicationCommandHandler VERSION_REPORT APPLICATION_VERSION VERSION 2.1 (0 /128)
01 0F 00 04 00 02 07 86 12 06 03 2A 02 01 AD 00 E4

THING TYPE zwave:fakro_zws12_00_000

Bottom line: my Fakro ARZ Z-Wave blinds report themselves as 0085:0003:0001, which gets translated into THING TYPE zwave:fakro_zws12_00_000.

Yes, this is displaying the same information as discussed above from the XML - it’s all exactly the same…

The question still remains if this isn’t correctly identified, then we need to work out how to differentiate it from the other similar devices.

From what I understand, either Fakro reused the same Z-Wave parts throughout their product range without bothering about subsequent identification; or 0085:0003:0001 was historically included as ZWR12 since that profile was available first (deliberate incorrect assignment due to earlier absence of ARZ profile).

I suppose there’s currently no means to (locally) override a Z-Wave device assignment to address such cases?

If that is really true, and even the firmware is the same, then there’s no way to differentiate them. The question I still have is if the firmware version can be used fo differentiate them?

If you manually define the things in a thing file, then you can define it as any thing type (ie you can select the thing type in the thing file).

From the cd-jackson DB entries it appears that the command classes differ across the chain actuator and the roller shutters.

I think I’ll give that track a go. I didn’t know it was possible.

That didn’t work.

I first created a Thing description in /etc/openhab2/things.fakro.things, taking into account the requirements for manually defining Z-Wave Things:

Thing zwave:device:1a2b3c4d:node2 "Fakro ARZ Z-Wave Roller Shutter 1" (zwave:serial_zstick:controller) [
        zwave_nodeid=2,
        zwave_manufacturer=133,
        zwave_deviceid=2,
        zwave_devicetype=2,
        zwave_version="2.1"
]

As you can see, I try to manually override the zwave_devicetype (3 → 2) and zwave_deviceid (1 → 2) in the hope that I would then overrule the Z-Wave bindings communicated by the roller shutters, and let OpenHAB pick the ARZ entry instead of the ZWR12 entry from the Z-Wave product DB.

Then I deleted the Thing in paper UI, and manually searched for new Things.

The Thing appears with status: UNINITIALIZED - BRIDGE_UNINITIALIZED.

So obviously I’m doing something wrong.