Unknown device, no Z-Wave node XML - Fakro ZWP10 remote

You’re welcome, but according to @chris the XML files I posted still don’t offer any usable functionality.

That was the case initially as the device didn’t report any user command classes - however that has now changed.

So, with the latest XML, it will add some classes. If this is still incomplete, then you can force classes if you are 100% sure they are supported.

I have to check at home if the XML file grew in size. However, it appears that OZW is able to infer that COMMAND_CLASS_WAKE_UP is also supported. I’d expect it to support COMMAND_CLASS_BATTERY as well but I don’t know how I could test this.

COMMAND_CLASS_ASSOCIATION itself is very useful, as you can remotely associate 2 devices through user interface. Some of my devices have pretty inaccessible pairing button.

No - not really. It is not a user command class - what I mean by this is that there will be NO user channels created. Associations are only used to link information together and by themselves are of no use.

If the association command class was only used configure a device (as is often the case with controllers) then it’s not useful at all here. On the other hand, if the association command class is used to allow configuration of the device, then it’s of use - BUT - only if the device actually supports user command classes, otherwise it still can’t control anything.

That’s also how I understood how Z-Wave ASSOCIATION works: you can e.g. associate the opening of one roller shutter if another roller shutter opens, without requiring a controller node.

The ZWP10 controller can effectively be used to operate other Z-Wave devices. Each “channel” supports 5 operations (commands): short click (up, down, stop), sustained keypress (up, down). With the sustained keypresses, one can operate other Z-Wave devices in a gradual on / off (like a dimmer). In this mode, roller shutters will move while a key is pressed, whereas short clicks result in a full up/down or stop command.

The issue, I understand, is that the ZWP10 remote seemingly fails to properly report its actual capabilities.

Yes, but as I said above, we now know this, and we can account for it in the database. Firstly, the XML now has this information, so it will add it to the database. The database can then be programmed to force these command classes in the binding - thus working around the fact that the device doesn’t report all its command classes.

I’m a bit lost here. How come it’s not useful. I understand that if we create association groups in DB and device supports COMMAND_CLASS_ASSOCIATION then we can remotely configure our controller.

I understand that the Binding actually ignores this class and its version and that is why it’s not useful in this context. It is not required in xml definition to work. Please correct me if I’m wrong.

Small digression… if we associate a controller button with primary controller, can we technically create a channel for that and pass that information to other devices in the network, which are not z-wave devices?

I didn’t say it wasn’t useful (at least initially) - I said it wasn’t a user class. It doesn’t do anything - it is only a maintenance class.

Hmmm - I’m not sure I understand what you mean, but I’m not sure it’s correct.

No - the binding doesn’t ignore this class, or its version. It, along with the other association classes (multi-channel and association info) are heavily used in the binding.

The point I tried to make earlier is that without OTHER classes, the association class does not really do anything.

So, in this application, the controller is being used to configure the network - ie it is used to configure other devices. Often these sort of remote controls support this sort of association configuration, although it’s not often used these days. It was used in the past before the days when everyone uses a central controller.

In this application, the controller talks directly to the other devices, and the binding, or any controller/gateway, is not involved at all.

In this application, the remote is being configured by the binding, so that when you press a button on the remote, it sends a command to (for example) turn on your lights. In this application, associations would be of no use unless the controller supported other commands (such as BINARY_SWITCH for example). Otherwise, it can’t send commands to perform these functions.

You can either do it directly between the remote, and the device, or you can use a rule in OH to do it. It’s the same as any switch really.

Here’s the current status (no changes to the Z-Wave XML node files for a couple days now):

commandClass version versionSupported instances control isGetSupported deviceManufacturer deviceType deviceId libraryType protocolVersion applicationVersion maxGroups
COMMAND_CLASS_BASIC 0 0 0 false true

I attached one node file for the ZWP10 Remote Controller to this post:
network_f6e419c7__node_7.xml (5.7 KB)

What I don’t know, is how to add the missing COMMAND_CLASS_WAKE_UP to the XML file in a meaningful way. Here’s the relevant info reported by OZW:

<CommandClass id="132" name="COMMAND_CLASS_WAKE_UP" version="1" request_flags="2">
	<Instance index="1" />

I would also like to find a way to probe the remote for the unreported yet expected COMMAND_CLASS_BATTERY command class (to query the battery level). This way I can check if the command class is indeed supported.

You can’t. If it supports wakeup, and it’s not reporting, then it would need to be added to the database and an option added to force this command class to be added during initialisation. (this is the ADD option)

You do need to be careful with this - adding command classes because you think they are supported, but they aren’t, will cause problems with the device and will likely slow down the network, so please don’t add anything you are not sure exists!

It would be interesting to understand how OZW manages to find a way to get the ZWP10 remote report COMMAND_CLASS_WAKE_UP, as apparently OZW is able to report it. Unless, of course, someone added COMMAND_CLASS_WAKE_UP by hand in the OZW configuration file for the ZWP10.

It can probably be inferred from other information (eg the listening flag), but that can also cause problems since there are devices that do not support the wakeup command class that also don’t listen.

We support around 1000 devices in the binding, so I suggest that you just update the database as suggested since doing something else to try and resolve this for this device, may cause problems with other devices.

I just applied for an account with the same user name as on OH. I suppose you need to assign extra privileges to new users before they can add / edit the database?

I’ve updated your access…



1 Like


When I submitted the ZWP10 remote, I got the following error message:

1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‘135,1,1,2380)’ at line 3

Should I re-submit?

Probably (ie almost certainly) the entry was added anyway. I’ve not been able to find the error, but it doesn’t seem to cause any real issue.

Yes - it’s here -:


Okay. The ZWP10 remote has been submitted for review.

Not sure what I should do with the MaxGroups (10) and with the Basic Class though.

Don’t worry about the basic class issue, but if the device supports associations, then it should be added or it won’t be very useful.

If only I knew how I can turn the XML files generated by OH2 and OZW into meaningful associations… The controller supports 10 “association groups” and I have the impression that associaiton group 1 is a lifeline group as it only contains the controller node. But the ZWP10 controller has 5 “channels” with 2 channels each (left/right), which could also be the groups? I get confused in the used terminology.