COMMAND_CLASS_ASSOCIATON isn’t missing, but the Z-Wave Binding doesn’t configure the association groups either. IMHO a strong indication that the missing COMMAND_CLASS_CONFIGURATION isn’t the root cause.
As your device is battery operated:
Try to wake it up many times (assuming that it is not fully configured yet).
I would be a little more concerned about the missing CC Configuration in the NIF section of the XML. I believe the NIF frame from the node takes priority over what is in the DB. It could be the device needs to wake per the above post, if you do not have the five lines on the UI page
However, if those lines are there, then you might try to delete the thing (not exclude) then go to the inbox/zwave/scan then press the action button per an inclusion (The inclusion protocol typically send a NIF) and that may get the missing CC added. I do not think either the OH3.4 or Zwave binding is cause
It looks like the initialization skips the parameter updates, again probably because the NIF does not contain the configuration CC. I would tend the idea that the device is bad, but maybe someone else has another idea.
The next level would be to exclude the device. Try a factory reset on the device and reinclude as a new number. You can unlink your items before excluding, so you can keep the names after reincluding and then relink the channels of the new device to the old items so your rules and persistence will not have to change. I can’t say for sure that will work but it is worth a try before buying a replacement ?
It makes no sense for a Z-Wave device to have configuration parameters but not support COMMAND_CLASS_CONFIGURATION. As you might expect, Product Command Classes claims that the Z-TEMP2 supports COMMAND_CLASS_CONFIGURATION V4.
I have removed the device from the controller. I have reset the device (20 seconds on button). I have included the device. Below an extract from the logging. You can find there: GET_CONFIGURATION - CONFIGURATION class not supported. Could that be related and causing this issue?
I believe so, but that message means that the node doesn’t support it, not the binding. It seems to me the device has failed, but we can see if @chris has a moment to weigh in.
On a side note the XML in the OH zwave folder is from the device. That is the artifact that helps to build an entry for a new device. Since the Configuration CC is in the DB, it was there on an XML from the device for someone.
Lastly
I wouldn’t worry too much about this as they are stale from sometime before the Configuration CC disappeared.
edit: one last thing (and possibly should have asked earlier, but it is unlikely) What do you see in the karaf console with bundle:list |grep ZWave
As I think eluded to above, if the class is not specified in the NIF, then the binding won’t provide support for it even though the database does have it defined. We can force it to add added by adding a config to the database that tells the binding to add it even if it’s not in the NIF. This is probably the solution here.
To force this to be added, we need to add the ccAdd option to the command class options as below -:
I didn’t know this was possible. Chris is the expert
What the change will do will force the binding to ask about the configuration even though there is no Configuration CC in the NIF. Of course the node will still have to respond with the parameters 1-14.
It is the DB you referenced in your first post Anyway I will add the ADD. It could be a few days before it is merged into the binding
I can’t quite believe that the device doesn’t claim to support COMMAND_CLASS_CONFIGURATION. I would really like to see the NIF … Even if the fix solves the problem, something (the device itself?) seems to be severely broken.
Sometimes devices don’t report all their command classes in the NIF. This isn’t too uncommon (sadly). There may be other requirements that mean the binding should always assume some of these classes are supported even if not reported (eg the device class reqjuirements).
I have installed openhab through a repository. Please let me know how and when I can test.
cat /etc/apt/sources.list.d/openhab.list
deb [signed-by=/usr/share/keyrings/openhab.gpg] https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable main
apt list --installed | grep openhab
openhab/stable,stable,now 3.4.0-1 all [geïnstalleerd,opwaardeerbaar naar: 3.4.1-1]