Hello, I have strange behavior and I was not able to resolve it using forum or my experience with Z-Wave.
Environment:
openHAB 2.5.12 (quite old, but stable, preparing for upgrade 
Z-Wave 2.5.12 binding
Aeotec Gen5 stick as controller
Fibaro Dimmer 2 (around 20 pcs)
Problem:
Everything works quite smoothly, but I added another Fibaro Dimmer 2 into network and I get no dimmer channel update when physical switch is used (only power channel update). I can control the light using item linked to the channel.
Logs when the physical switch is used. One from existing dining table light (which works OK) and one from library light (the problematic new one):
library problematic.log (8.3 KB)
dinig table OK.log (5.9 KB)
After analysis of the log, the difference is that problematic one is missing these lines from the log:
NODE XX: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
NODE XX: Updating channel state zwave:device:50211680:nodeXX:switch_dimmer1 to 100 [PercentType]
Instead of updating power consuption channel and dimmer channel, it updates power consumption channel twice.
What I have tried:
Wait - the dimmer was in the network for a week to settle down
Reboot the VM running openHAB, restart openHAB service
The lifeline of dimmer is set to Controller
Remove and Add the node from the z-wave network - same behavior (same log results as well)
The firmware of the dimmers reported by openHAB are same - 3.5
The attributes of the dimmers reported by openHAB are identical
Hope you guys would point to something I’m missing. Thanks in advance.
Are the Z-Wave associations of all dimmers the same?
Thanks for suggestion. Yes, they are the same.
Dining table OK:
Library problematic:
2022-01-22 12:12:30.162 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 20: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SWITCH_MULTILEVEL, value=0
vs.
2022-01-22 11:35:32.151 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint=1, command class=COMMAND_CLASS_SWITCH_MULTILEVEL, value=99
The endpoints are different. IMHO a SWITCH_MULTILEVEL_REPORT should come from endpoint 1 (or 2), but never from endpoint 0. A SWITCH_MULTILEVEL_REPORT from endpoint 0 doesn’t make sense to me and for endpoint 0 no channel is defined in the Z-Wave database:
So - if @chis doesn’t disagree 
- I would conclude that OH/Z-Wave binding is working as designed and there is a problem with your device.
You could do the following:
- Exclude the problematic device from OH/Z-Wave controller.
- Factory reset device.
- Disconnect it from mains, reconnect.
- Factory reset device.
- Re-include it into OH/Z-Wave controller.
If the problem persists and you are really adventurous, you could do steps 1.-5. to a working device. If the previously working device survives this procedure, this would be an additional indication that your problematic device is the culprit (and not OH). Of course, you could end up with two non-functional devices … But then the probability that your problematic device is defective would be very low.
Just an additional idea:
Is the wiring of the dimmers all the same? It could be that the endpoint a report is sent from depends on the wiring configuration of the dimmer.
A perfect point with the endpoint number. This is definitely a clue.
I have factory reset twice the problematic device, as suggested. It didn’t help.
Then I tried to remove and add a device that worked in a guest bedroom and after re-inclusion, it ended up using endpoint 0.
guest bedroom.log (5.0 KB)
The wiring of the dimmers is the same.
Someone else had this problem as well here. But the debugging wasn’t properly finished and ended up with another problem that dimmer and button were added securely and non-securely (all my dimmers are added as non-secure).
@chris wanted to see the inclusion log and node XML, attaching it below, the NODE 23 was added. The log file has 4 MB, uploaded to dropbox: inclusion-node23.log.
network_c9148173__node_23.xml (44.7 KB)
