Z-Wave binding inclusion process (2.4.0)

I’m cheking the inclusion process in Z-Wave and I noticed a strange behaviour sniffing the packets.

Meanwhile openhab is searching for things (spining icon), the comunication with the installed device seems to go fast (packets requested from controller each few milliseconds), but once the searching process finishes (icon stops spinning), the frames slow down (>10 seconds per packet).

You can see in the image the final part of the inclusion, and how the packet rate drops in line 3316:

Is there a limitation with this process?

Just a guess, but I don’t see any Config Reports in response to the Config Gets. It seems to start with the Get on line 3310 not getting a response. If there’s no response to the Get, I suspect the binding is timing out after 5 seconds, then resending the Get for that parameter.

It’s strange, cause it’s a powered device. I don’t know either the inclusion process, so maybe just a weird coincidence? I’m just starting with the sniffer.

One thought… When a device doesn’t support a config parameter, it usually is just silent when it receives a command for that parameter. Not saying that’s the case here, but I’ve seen that behavior with some of my devices.

What are you using for your sniffer?

BTW, a binding debug log plus the log viewer makes it a lot easier to see what’s happening at the command class transaction level. :wink:

But the “Configuration Get” is replied previously, isn’t it? Or each get affects different parameters?

Z-Wave static controllre ACC-UZB3-E-STA

During the inclusion/initialization process, there will be a GET for each config parameter. If it’s consistently getting stuck on a specific parameter(s), then check to make sure the device really supports those parameters. Perhaps the device doesn’t support the parameter, or the parameter is write-only.

That means a parameter in the .xml database? I thought that during the inclusion process, a /var/lib/openhab2/zwave file is created, and the database file only affects to interact with channels from UI.

I’ll enable the full logs, and try to do it again (if possible).

The node.xml doesn’t contain anything about config parameters and associations. Those come from the database.

At a high level, the lifecycle normally works this way.

  • Create database entry
  • Import node.xml into database to pick up supported command classes
  • Manually enter config parameters into database
  • Manually enter associations into database
  • Submit db entry for approval
  • DB entry is approved
  • DB entry gets exported during binding build process and then included in the binding as a thing-type

This is the process to add a device to the DB, isn’t it? Then I guess that:

  1. The initial node.xml is auto-generated from “Manufacturer Specific Report” packets or similar.
  2. Once the DB entry is created, approved and added to the binding, the inclusion process performs extra steps to ask parameter info with “Configuration Get” packets.

Am I slightly right? Do you know a good/straight guide were it explains the inclusion process at packet-level?The Z-Wave standard it too much for me :sweat_smile:

I found another strange behaviour too:

  1. “Version Command Class Report” ask for COMMAND_CLASS_METER (32), and the controller replies saying that supports version 4.
  2. At the end of the inclusion process, the controller sends “Meter Get”, but the device doesn’t reply.

Does it make sense?

After inclusion, the binding runs through a rather extensive process to query information from the device. This results in the creation of the node.xml file (among other things).

Separate inclusion from initialization. Inclusion is the standard z-wave process. Initialization is the process the binding goes through after inclusion. And, yes, initialization involves getting the config parameters, associations (including setting the Lifeline association), setting the wakeup interval, etc.

Not sure. A debug log might help show what’s going on.

Still reviewing sniffer logs from yesterday. I don’t have the chance to perform the re-inclusion again with the logs enabled.

Thank you!