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

[shutterfreak (Olivier Biot)]

@shutterfreak

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.

The Z-Wave documentation is helpful in this matter. I managed to figure out several things (and confirmed them using a low-level Z-Wave tool). For instance:

1. CMD_CLASS_ASSOCIATION is NOT supported by the ARZ Z-Wave (2013 version) although you should be able to perform remote association (from device to device without controller) according to the manual.

2. SWITCH_ALL is a command class that allows devices to respond to SWITCH_ALL commands on a pre-configured manner. The idea is:

   • You can configure a device to respond (or not) to SWITCH_ALL commands (ALL_ON, ALL_OFF). There are 4 options:
     • obey only ALL_ON
     • obey only ALL_OFF
     • obey both
     • obey neither
   • When a device receives a SWITCH_ALL command, it will first check how it is configured to respond to these commands.

   You can set this behaviour in the Thing in OH2 Paper UI, but I don’t know however if the Z-Wave binding currently supports SWITCH_ALL commands to be propagated from OH2 (or if it’s even desirable).

3. SPECIFIC_TYPE_CLASS_B_MOTOR_CONTROL implies that the device MUST support at least:

   1. COMMAND_CLASS_SWITCH_BINARY version 1
   2. COMMAND_CLASS_SWITCH_MULTILEVEL version 3
   3. COMMAND_CLASS_MANUFACTURER_SPECIFIC (no specific version)
   4. COMMAND_CLASS_VERSION (no specific version)

4. In addition, SPECIFIC_TYPE_CLASS_B_MOTOR_CONTROL implies:

   1. COMMAND_CLASS_BASIC must be mapped to COMMAND_CLASS_SWITCH_MULTILEVEL
   2. The device is endpoint-aware, but not necessarily position-aware (if position awareness is not supported, the position return value 0xFE means ‘undefined position or in-between endpoints’, otherwise it only means ‘undefined position’ - e.g. after a power cut).
   3. The device MAY support positional awareness, and MAY use estimations to provide position info (in the range 0x01 → 0x63)
   4. The Primary Switch Type SHOULD be 0x02 (Up/Down).

So the Fakro ARZ “2013” version seems to properly report its capabilities.

While using a low-level Z-Wave tool, I tested several command classes directly. It appears that:

1. BASIC_SET(0x00) → closes the roller shutters
2. BASIC_SET(0xFF) → opens the roller shutters
3. When the roller shutters opens, sending BASIC_SET(0x00) stops the shutters
4. When the roller shutters closes, sending BASIC_SET(0xFF) stops the shutters
5. BASIC_GET() →
   1. Fully closed → returns 0x00
   2. Fully opened → returns 0xFF
   3. Opening or closing, or stopped in-between end positions → returns 0xFE

BASIC SET only supports full open/close commands. You can stop the roller shutters to land them in-between end positions by issuing the inverse end position while the roller shutters are operating.

While using a low-level Z-Wave tool, I verified that SWITCH_MULTILEVEL works the same way as BASIC, and that SWITCH_MULTILEVEL_STOP effectively stops the roller shutters when in motion. It is more reliable than using the inversion approach from BASIC_SET. I also confirm that:

1. The ARZ Z-Wave shutters do not support positional awareness (only endpoint awareness is supported)
2. The position of the ARZ Z-Wave shutters can be requested with a BASIC_GET or SWITCH_MULTILEVEL_GET command. Only the following 3 values will ever be returned:
   1. 0x00 (fully closed)
   2. 0xFF (fully open)
   3. 0xFE (after a power cut: position unknown; otherwise: position in-between endpoints)

The position value 0xFE is also returned while the roller shutters are operating (which makes sense and is expected).

This is good and bad news:

• The bad: the ARZ Z-Wave (2013 version) does not support positional awareness as it lacks support for this functionality. It also lacks the option some other similar devices offer to provide a rough estimate of an intermediate position for the same reason.
• The good: the Z-Wave binding should be able to properly report the position (state) of the roller shutters at all times. And that should be able to address the problems I currently have, in that today I’m still unable to get reliable state updates from the roller shutters. The problem is that I don’t know how.

Maybe @chris could shed some light on the way the Z-Wave binding currently manages positional updates and what it expects/needs from the device XML info to properly do its job? I would expect it should be possible to poll the device for a given time. Unless the device should be polled every X minutes?

[shutterfreak (Olivier Biot)]

@shutterfreak

Maybe @chris could shed some light on the way the Z-Wave binding currently manages positional updates and what it expects/needs from the device XML info to properly do its job? I would expect it should be possible to poll the device for a given time. Unless the device should be polled every X minutes?

In Paper UI it looked like I could only choose Command Poll Interval values of 1500 (ms) and Disabled. In HABmin I tried increasing the Command Poll Interval for the roller shutters to 20 seconds and was happy to see that it was possible. It was not intuitive from the UI that I could set a different poll interval value.

What I still can’t solve right now, is to manage the cases where a secondary (non-Z-Wave+) controller controls the roller shutters as OH2 doesn’t see these operations (they are not directed at the primary controller). Consequently, I can’t produce reliable roller shutter states in OH2.

The roller shutters obey the Z-Wave spec and announce themselves with Primary Switch Type 0x02 (Up/Down), which means that 0x00 means close and 0xFF means open. However, this is the opposite from what OH2 expects. Would it be up to the binding to translate from “Z-Wave open=100/close=0” to “OH2 open=0/close=100”? I can of course manually ask OH2 to invert the percentage, but I suppose it should be the responsibility of either the binding or the Z-WAVE device definition.

[sihui]

@shutterfreak

However, this is the opposite from what OH2 expects.

We already had endless discussions about this, not only for the zwave binding (please search the forum).

@shutterfreak

I can of course manually ask OH2 to invert the percentage

That is the brilliance of @chris: he made this our choice, so I suggest to use that.

[shutterfreak (Olivier Biot)]

@sihui

However, this is the opposite from what OH2 expects.

We already had endless discussions about this, not only for the zwave binding (please search the forum).

shutterfreak:

I was unaware of these discussions.

@sihui

I can of course manually ask OH2 to invert the percentage

That is the brilliance of @chris: he made this our choice, so I suggest to use that.

Will do!

[shutterfreak (Olivier Biot)]

Meanwhile I’ve collected 2 odd command class entries in the node.xml file of one of my shutters:

              <commandClass>COMMAND_CLASS_BARRIER_OPERATOR</commandClass>
              <COMMAND__CLASS__BARRIER__OPERATOR>
                <version>0</version>
                <instances>0</instances>
                <control>false</control>
                <versionSupported>0</versionSupported>
              </COMMAND__CLASS__BARRIER__OPERATOR>
            </entry>
            <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>
            <entry>

Since both report a supported version of 0 and 0 instances I assume that these are rather errors?

[mhilbush (Mark)]

@shutterfreak

Meanwhile I’ve collected 2 odd command class entries in the node.xml file of one of my shutters

The binding adds command classes to the node.xml when it receives a zwave transaction containing a command class that it has not seen before. Occasionally, when a bad/corrupted zwave frame is received, the binding will add a bogus command class. That is likely the case here. These are harmless and can be ignored.

[chris (Chris Jackson)]

@shutterfreak

Since both report a supported version of 0 and 0 instances I assume that these are rather errors?

The issue here is if they are seen after initialisation, as could be the case (especially for the APPLICATION_STATUS) then the binding doesn’t request the version so it will remain at 0.