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

mhilbush · March 13, 2019, 12:34pm

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

shutterfreak · March 13, 2019, 2:16pm

mhilbush:

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.

manuf.jpg721×94 14.5 KB

And the manual says it’s a Z-Wave Plus 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:

The ‘old’ Z-Wave version (v1.0) of the ARZ roller shutters looks like this - reports as 0085:0002:0002
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
The ‘new’ Z-Wave Plus version of the ARZ roller shutters looks like this - reports as 0085:0003:0011

shutterfreak · March 18, 2019, 8:52am

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

chris · March 18, 2019, 8:59am

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.

shutterfreak · March 18, 2019, 9:46am

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>

chris · March 18, 2019, 10:12am

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.

shutterfreak · March 18, 2019, 10:51am

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.

chris · March 18, 2019, 11:02am

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.

bmhvanbenthum · March 29, 2019, 7:20pm

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.

shutterfreak · March 29, 2019, 8:05pm

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?

bmhvanbenthum · March 29, 2019, 8:21pm

ARZ%20vs%20ZWS12

bmhvanbenthum · April 8, 2019, 8:07pm

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

shutterfreak · April 10, 2019, 4:19pm

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.

shutterfreak · April 12, 2019, 3:17pm

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:

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.
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).
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)
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:

BASIC_SET(0x00) → closes the roller shutters
BASIC_SET(0xFF) → opens the roller shutters
When the roller shutters opens, sending BASIC_SET(0x00) stops the shutters
When the roller shutters closes, sending BASIC_SET(0xFF) stops the shutters
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:

The ARZ Z-Wave shutters do not support positional awareness (only endpoint awareness is supported)
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 · April 15, 2019, 8:16am

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 · April 15, 2019, 9:56am

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

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

shutterfreak · April 16, 2019, 7:39am

I was unaware of these discussions.

Will do!

shutterfreak · May 10, 2019, 6:29am

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 · May 10, 2019, 10:37am

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 · May 10, 2019, 11:31am

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.