Fakro ARZ shutters incorrectly identified as ZWS12 chain actuator + doesn't seem to actually report state

Our home has 3 Fakro ARZ roller shutters which are misidentified as ZWR12 chain actuator. To circumvent this problem, I manually define my things but rely on the automatically identified Z-Wave controller which I only changed the ThingID for convenience. I can however operate the roller shutters independently on how they are (mis)identified. Here’s an example Thing definition:

// Refresh thing status every 300 seconds:
Thing zwave:fakro_arz_00_000:controller:node2 "Fakro ARZ Roof Roller Shutter (N)" (zwave:serial_zstick:controller) [
	node_id=2,
	refresh_interval=300
]

And here’s an Item definition linked to one channel of the Thing:

Rollershutter	AT_Shutter_N	"Roller Shutter North"	<rollershutter>	(AT_GuestRoom, gShutter, AT_Shutters)	["Rollershutter"]            {
	channel="zwave:fakro_arz_00_000:controller:node2:blinds_control"
}

The product misidentification is due to the product identifier (133:3:1) already reported in the Z-Wave database for another product (the Fakro ZWS12 chain actuator). Here’s the relevant info from the XML node file:

          <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>

          <entry>
            <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
            <COMMAND__CLASS__MANUFACTURER__SPECIFIC>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <initSerialNumber>false</initSerialNumber>
              <deviceManufacturer>133</deviceManufacturer>
              <deviceType>3</deviceType>
              <deviceId>1</deviceId>
            </COMMAND__CLASS__MANUFACTURER__SPECIFIC>
          </entry>

What is weird, is that the 3 Fakro ARZ roller shutters have been installed at the same time, however they seem to report slightly different functionality. In the COMMAND_CLASS_SWITCH_ALL, node 2 reports SWITCH_ALL_INCLUDE_ON_ONLY whereas nodes 3 and 4 report SWITCH_ALL_INCLUDE_ON_OFF. Node 2 is a different roller shutter size (narrower and shorter) than nodes 3 and 4 (those are identical).

I can provide the XML files from /var/lib/openhab2/zwave if this can help.

A second issue I have, is that the roller shutters don’t seem to report their actual state through Z-Wave. As a result, I can not write rules that require knowing the state of the roller shutters. I suppose this is something I will have to look into with a Z-Wave control software. Could it be related to each roller shutter node having no association group specified?

  <associationGroups class="concurrent-hash-map"/>

I seem to recall another post on the forum about the misidentification. Let me see if I can find it.

Oh, wait. It was your post. So, we never did move the type:id to the ARZ database entry?

Probably.

Yes, please post the whole XML.

No, we didn’t as I first wanted to verify if manual Thing definition would help (it does). However it confuses, hence my question to bring back this to the attention.

Here you are (this is the XML file for Node 3 (remember: it reports SWITCH_ALL_INCLUDE_ON_OFF (whereas node 2 reports SWITCH_ALL_INCLUDE_ON_ONLY):

<node>
  <homeId>0xa1b2c3d4</homeId>
  <nodeId>3</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"/>
  <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_CLASS_B_MOTOR_CONTROL</specificDeviceClass>
        </deviceClass>
        <endpointId>0</endpointId>
        <secureCommandClasses/>
        <supportedCommandClasses class="concurrent-hash-map">
          <entry>
            <commandClass>COMMAND_CLASS_SWITCH_ALL</commandClass>
            <COMMAND__CLASS__SWITCH__ALL>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <isGetSupported>true</isGetSupported>
              <mode>SWITCH_ALL_INCLUDE_ON_OFF</mode>
            </COMMAND__CLASS__SWITCH__ALL>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_NO_OPERATION</commandClass>
            <COMMAND__CLASS__NO__OPERATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__NO__OPERATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_SWITCH_BINARY</commandClass>
            <COMMAND__CLASS__SWITCH__BINARY>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__SWITCH__BINARY>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_BASIC</commandClass>
            <COMMAND__CLASS__BASIC>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__BASIC>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_SWITCH_MULTILEVEL</commandClass>
            <multiLevelSwitchCommandClass>
              <version>3</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>3</versionSupported>
              <switchTypePrimary>CLOSE_OPEN</switchTypePrimary>
              <switchTypeSecondary>UNDEFINED</switchTypeSecondary>
              <isGetSupported>true</isGetSupported>
            </multiLevelSwitchCommandClass>
          </entry>
          <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>
          <entry>
            <commandClass>COMMAND_CLASS_POWERLEVEL</commandClass>
            <COMMAND__CLASS__POWERLEVEL>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <powerLevel>0</powerLevel>
              <powerTimeout>0</powerTimeout>
            </COMMAND__CLASS__POWERLEVEL>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
            <COMMAND__CLASS__MANUFACTURER__SPECIFIC>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <initSerialNumber>false</initSerialNumber>
              <deviceManufacturer>133</deviceManufacturer>
              <deviceType>3</deviceType>
              <deviceId>1</deviceId>
            </COMMAND__CLASS__MANUFACTURER__SPECIFIC>
          </entry>
        </supportedCommandClasses>
      </endPoint>
    </entry>
  </endpoints>
  <nodeNeighbors>
    <int>1</int>
    <int>4</int>
  </nodeNeighbors>
  <lastReceived>2019-03-13 10:06:55.657 UTC</lastReceived>
</node>

I’m surprised the device doesn’t report any association groups.

Does the manual describe any association groups or config parameters?

According to the online manual, there are 3 association groups available:

  1. Life Line – group for position reporting roller shutter after each a stoppage and alarm reporting (overcurrent, damage encoders). This group can be a maximum 1 device.
  2. Basic Repeat – group used to transfer the received basic commands to the devices included in this group. This group can be a maximum 5 devices.
  3. Multilevel Repeat – group used to transfer the received multilevel commands to the devices included in this group. This group can be a maximum 5 devices.

Sadly no information is given on how to assign a roller shutter to an association group.

From the XML

&lt;manufacturer&gt;0x85&lt;/manufacturer&gt; 
&lt;deviceId&gt;0x1&lt;/deviceId&gt; 
&lt;deviceType&gt;0x3&lt;/deviceType&gt;

But, the manual is reporting a different type:id.

And the manual says it’s a Z-Wave Plus device.
command-classes

Have you tried emailing the manufacturer with your device type:id to ask them for the specs for the device?

You’re right. It appears that there are a number of ARZ roller shutter variants, the old ones being Z-Wave and a newer one being Z-Wave Plus. Ours are definitely not Z-Wave Plus.

No, I haven’t. However I found an online copy of the manual that was shipped with our roller shutters here - it’s from 2013 whereas the other manual is from 2017.

So:

  1. The ‘old’ Z-Wave version (v1.0) of the ARZ roller shutters looks like this - reports as 0085:0002:0002
  2. The ‘intermediate’ Z-Wave version (v2.1 if inferred from applicationVersion) we have at home (info not found on the Z-Wave Alliance portal) - reports as 0085:0003:0001
  3. The ‘new’ Z-Wave Plus version of the ARZ roller shutters looks like this - reports as 0085:0003:0011

Here’s the current list of all Fakro Z-Wave devices in the database, ordered by Device Type and Device ID:

Manufacturer Label Description Version (Min) Category deviceType deviceId
Fakro ZWS12 Chain Actuator All Blinds 2 1
Fakro ARZ Roller Shutter Module All Blinds 2 2
Fakro ZWS12n Chain actuator - window opener All Window 2 11
Fakro ZWS12n Chain actuator - window opener All Window 2 111
Fakro ZWS12 → ARZ (?) Chain Actuator → Roller Shutter (?) All Blinds 3 1
Fakro ARZ 1.1 Roller Shutter Module All after 1.1 Blinds 3 111
Fakro ARZ Solar Roller Shutter All Blinds 3 112
Fakro ARF Roller blind module All Blinds 4 11
Fakro AMZ Awning Blinds Controller All 5 1
Fakro AMZ Solar Solar Awning All Blinds 5 2
Fakro VMZ Solar Awning Blind All Blinds 6 2
Fakro VMZ Solar z-wave plus Awning Blind z-wave plus version All Blinds 6 112
Fakro ZWMP Weather Module All 7 1
Fakro ZWS12 Chain Actuator All Blinds 11 1

From this overview, I would infer that 0085:0003:0001 was incorrectly assigned to the window winder category (products with Device Type 0002)…

It’s not clear to me how you infer this from this table?

The category is really not so relevant - it’s only used in OH to show an icon. The bigger issue is how the device identifies in the ZWave database.

Unfortunately, it’s hard to know what everyone else uses and I’m always hesitant to change IDs. Generally, someone added the device, and presumably it was tested and their system works. If someone else thinks it’s wrong, and changes it, then we get into a mess.

It would be good if others with these devices can comment on what they have, and what the device ID/Type are so we can build a table with this information.

Alternatively, if the manufacturer can supply this it would be the best option. Manuals and the ZWave Alliance database tend to be very poor at documenting this information - the ZWA database is generally very incomplete.

Apparently Fakro window winders are listed as having a Device Type 0x0002, and external roller shutters are listed as having a Device Type 0x0003. There are 2 exceptions: 0002:0002 (ARZ roller shutter) and 0003:0001 (the problematic “double” item: ARZ Roller shutter AND ZWS12 window winder).

I agree that it’s difficult to change something in the device database once it’s been added, as it relies on authentic profiles being submitted. For what it’s worth, the same problem occurs with OZW (also reported as ZWS12 Chain actuator 12VDC:

<Node id="3" name="Roof Shutter SE" location="Attic" basic="4" generic="17" specific="6" type="Motor Control Class B" listening="true" frequentListening="false" beaming="true" routing="true" max_baud_rate="40000" version="4" query_stage="Complete">
	<Manufacturer id="85" name="Fakro">
		<Product type="3" id="1" name="ZWS12 Chain actuator 12VDC" />
	</Manufacturer>
	<CommandClasses>
		<CommandClass id="32" name="COMMAND_CLASS_BASIC" version="1" request_flags="4" mapping="38">
			<Instance index="1" />
		</CommandClass>
		<CommandClass id="37" name="COMMAND_CLASS_SWITCH_BINARY" version="1" request_flags="4" innif="true">
			<Instance index="1" />
			<Value type="bool" genre="user" instance="1" index="0" label="Switch" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="True" />
		</CommandClass>
		<CommandClass id="38" name="COMMAND_CLASS_SWITCH_MULTILEVEL" version="3" innif="true">
			<Instance index="1" />
			<Value type="byte" genre="user" instance="1" index="0" label="Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="255" />
			<Value type="button" genre="user" instance="1" index="1" label="Open" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
			<Value type="button" genre="user" instance="1" index="2" label="Close" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
			<Value type="bool" genre="system" instance="1" index="3" label="Ignore Start Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="True" />
			<Value type="byte" genre="system" instance="1" index="4" label="Start Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
		</CommandClass>
		<CommandClass id="39" name="COMMAND_CLASS_SWITCH_ALL" version="1" request_flags="4" innif="true">
			<Instance index="1" />
			<Value type="list" genre="system" instance="1" index="0" label="Switch All" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="3" size="1">
				<Item label="Disabled" value="0" />
				<Item label="Off Enabled" value="1" />
				<Item label="On Enabled" value="2" />
				<Item label="On and Off Enabled" value="255" />
			</Value>
		</CommandClass>
		<CommandClass id="114" name="COMMAND_CLASS_MANUFACTURER_SPECIFIC" version="1" request_flags="4" innif="true">
			<Instance index="1" />
		</CommandClass>
		<CommandClass id="115" name="COMMAND_CLASS_POWERLEVEL" version="1" request_flags="4" innif="true">
			<Instance index="1" />
			<Value type="list" genre="system" instance="1" index="0" label="Powerlevel" units="dB" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="1">
				<Item label="Normal" value="0" />
				<Item label="-1dB" value="1" />
				<Item label="-2dB" value="2" />
				<Item label="-3dB" value="3" />
				<Item label="-4dB" value="4" />
				<Item label="-5dB" value="5" />
				<Item label="-6dB" value="6" />
				<Item label="-7dB" value="7" />
				<Item label="-8dB" value="8" />
				<Item label="-9dB" value="9" />
			</Value>
			<Value type="byte" genre="system" instance="1" index="1" label="Timeout" units="seconds" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
			<Value type="button" genre="system" instance="1" index="2" label="Set Powerlevel" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
			<Value type="byte" genre="system" instance="1" index="3" label="Test Node" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
			<Value type="list" genre="system" instance="1" index="4" label="Test Powerlevel" units="dB" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="1">
				<Item label="Normal" value="0" />
				<Item label="-1dB" value="1" />
				<Item label="-2dB" value="2" />
				<Item label="-3dB" value="3" />
				<Item label="-4dB" value="4" />
				<Item label="-5dB" value="5" />
				<Item label="-6dB" value="6" />
				<Item label="-7dB" value="7" />
				<Item label="-8dB" value="8" />
				<Item label="-9dB" value="9" />
			</Value>
			<Value type="short" genre="system" instance="1" index="5" label="Frame Count" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="-32768" max="32767" value="0" />
			<Value type="button" genre="system" instance="1" index="6" label="Test" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
			<Value type="button" genre="system" instance="1" index="7" label="Report" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
			<Value type="list" genre="system" instance="1" index="8" label="Test Status" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="1">
				<Item label="Failed" value="0" />
				<Item label="Success" value="1" />
				<Item label="In Progress" value="2" />
			</Value>
			<Value type="short" genre="system" instance="1" index="9" label="Acked Frames" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-32768" max="32767" value="0" />
		</CommandClass>
		<CommandClass id="133" name="COMMAND_CLASS_ASSOCIATION" version="1" request_flags="2">
			<Instance index="1" />
			<Associations num_groups="1">
				<Group index="1" max_associations="5" label="Lifeline" auto="true" />
			</Associations>
		</CommandClass>
		<CommandClass id="134" name="COMMAND_CLASS_VERSION" version="1" request_flags="6" innif="true">
			<Instance index="1" />
			<Value type="string" genre="system" instance="1" index="0" label="Library Version" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="Unknown" />
			<Value type="string" genre="system" instance="1" index="1" label="Protocol Version" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="Unknown" />
			<Value type="string" genre="system" instance="1" index="2" label="Application Version" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="Unknown" />
		</CommandClass>
	</CommandClasses>
</Node>

That’s interesting then. Since the two databases are independent, it’s probably reasonable to assume that these were added to each database separately, and therefore people really do have these devices with these IDs…

Of course, it’s also possible someone copied one database to another, but as far as I’m aware there’s not too much of this happening.

That’s why I wanted to report this. I suppose some users cleverly combine the information that is available, irrespective of the origin.

Oh, and I just found out one of my roller shutters suddenly appears to support yet another command class: COMMAND_CLASS_APPLICATION_STATUS:

          <entry>
            <commandClass>COMMAND_CLASS_APPLICATION_STATUS</commandClass>
            <COMMAND__CLASS__APPLICATION__STATUS>
              <version>0</version>
              <instances>0</instances>
              <control>false</control>
              <versionSupported>0</versionSupported>
            </COMMAND__CLASS__APPLICATION__STATUS>
          </entry>

I find it weird that this doesn’t seem to ‘stabilize’ over time. For now, only one roller shutter reported this additional command class.

I doubt this is correct in general. Most people make changes to the database to add support for the devices they own - they don’t typically start copying over device information from other devices.

The binding adds all the classes that the device states it supports. Often, devices don’t report all their classes in their NIF - the binding will add anything else it hears from the device later, so in this case devices that don’t report their NIF correctly will change over time.

That is the case here - this class is not reported in the devices NIF.

The identification problem is a hardware/firmware error made by Fakro.

I have 3 ARZ devices and 3 ZWS devices. Those devices identify themselves as:

ARZ Shutters
ID 0x0001 Type 0x0003 - Fakro ZWS12 Chain actuator 12VDC
ID 0x0002 Type 0x0002 - Fakro ARZ Roof Window Roller Shutter

ZWS12 Windows Openers:
ID 0x0001 Type 0x0002 - Fakro Unknown: type=0002, id=0001
ID 0x0001 Type 0x0003 - Fakro ZWS12 Chain actuator 12VDC

What you can see is that I have both an ZWS12 as well an ARZ, both identifying themselves as ID 0x0001 Type 0x0003.

Probably Fakro made a mistake in their firmware. How to tell them about this error, and convince them. I already tried to mail them about this issue in 2018, but without any responds. They simply ignored my email about this.

Now I’m reading more people are having trouble with ARZ devices recognized as ZWS12.

Because it is an Fakro mistake, this can not be solved in OZW, openhab, domoticz, home assistant or whatever. Users of those devices need a software update, or a new device covered under fakro warranty, because it is an production failure.

Thanks for your input on the matter!

It would be great if we could find a way to distinguish the ZWS12 chain actuator from the ARZ roller shutter. I was hoping that they would be using different firmware versions. Can you check if they state the same or different firmware versions?

ARZ%20vs%20ZWS12

I sent an email to Fakro about this problem, for the second time, and this time I received an answer:

Beste heer van Benthum,

Een aantal jaar geleden zijn er inderdaad problemen ontdekt met de identificatie van een aantal producten, op basis daarvan zijn er wijzigingen doorgevoerd (november 2016) en zouden de producten onderstaande identificatie moeten bezitten:

ARZ Z-Wave: TYPE: 0x0003, ID 0x0001

ZWS12: TYPE: 0x0002, ID 0x0001

Indien uw producten dit niet bezitten en dit voor u een probleem vormt met de configuratie hiervan of anderszins dan kunnen de drivers van de producten een update krijgen.

De update kan echter alleen door de serviceafdeling op onze fabriek worden uitgevoerd en dit houdt in dat de producten hier dan retour naar moeten.

Indien u hiervan gebruik wilt maken verneem ik het graag, en ontvangen wij vervolgens de producten graag hier bij ons in Nederland, zodat wij kunnen zorgen dat de update wordt uitgevoerd en u de producten weer ontvangt.

Alvast bedankt.

Luc Bonnet | Technisch adviseur

luc@fakronederland.nl

They tell there was indeed an error, they discovered in 2016, en changed the device identification numbers from 2016.

It means that ZWS12: TYPE: 0x0003, ID 0x0001 is the wrong combination. Every ZWS12 showing up with 0x0003, ID 0x0001 is wrong. Fakro tells it can update the device software, but therefore the module needs to be returned to Fakro.

To solve the trouble with the duplicated in the open z-wave database, the ZWS12 with TYPE 0x0003, ID 0x0001 should be removed, and only ARZ Z-Wave: TYPE: 0x0003, ID 0x0001 can exist.

People with faulty ZWS12 should contact Fakro to solve the problem, if the have trouble with operating the device properly.

Bram

I just installed the latest Z-Wave binding and can now confirm that the ARZ Z-Wave roller shutters are correctly being identified.

Now I can start correcting the XML entry in the Z-Wave database as I see some things don’t seem to work the way expected.

For instance, I cannot assign the controller to group 1:

2019-04-10 17:51:22.318 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration update received
2019-04-10 17:51:22.324 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration update set action_heal to false (Boolean)
2019-04-10 17:51:22.326 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration update ignored switchall_mode to 255 (BigDecimal)
2019-04-10 17:51:22.328 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration update set binding_cmdrepollperiod to 1500 (BigDecimal)
2019-04-10 17:51:22.330 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration update set action_reinit to false (Boolean)
2019-04-10 17:51:22.333 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration update set action_failed to false (Boolean)

2019-04-10 17:51:22.335 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration update set group_1 to [controller] (ArrayList)
2019-04-10 17:51:22.337 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Association [controller] consolidated to {}
2019-04-10 17:51:22.339 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Unknown association group 1
2019-04-10 17:51:22.341 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration update set action_remove to false (Boolean)
2019-04-10 17:51:22.343 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration update set binding_pollperiod to 86400 (BigDecimal)
2019-04-10 17:51:22.346 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling intialised at 86400 seconds - start in 41644800 milliseconds.
2019-04-10 17:51:22.348 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration update ignored node_id to 2 (BigDecimal)

The problem is that the documentation for these roller shutters seems to be incomplete. I will now modify locally the XML file in my Z-Wave binding JAR file to make it work and then update the Z-Wave device database once I figured out how things work (in the absence of complete documentation).

Update: Although CMD_CLASS_ASSOCIATION is supported, I can’t figure out how. The manual mentions “All On” and “All Off” function (groups) but nowhere I can find proper documentation on how tp properly add these to the XML file.