What is the make and model of the device? Some devices need a slight addition in the Zwave database to report manual operation. Actually to be more precise they report a basic set when operated manually, but OH operation uses Switch Binary, both need to be there. it needs to look like this
<property name="binding:*:OnOffType">COMMAND_CLASS_SWITCH_BINARY,COMMAND_CLASS_BASIC</property>
Bob
In my case itās a Linear WS15Z-1 Wall Mounted Switch and GE 45605 wall outlets.
Where should I be looking for that XML property? I donāt have any elements named āpropertyā in the XML in my zwave folder and I am not sure how to export the DB entry to XML.
The line I copied is from the github zwave binding java files. They are in src/main/resources/OH-INF/thing and they are listed by company. For your switch the Basic_Set is missing;
<property name="binding:*:OnOffType">COMMAND_CLASS_SWITCH_BINARY</property>
What I have done on a short term basis, although not entirely kosher, it to change the file, recompile the jar and see if it works, intending to followup with a database edit.
One qualification, I did have a zniffer, so I could see that the switch was sending the basic set when operated manually and that OH was using Switch_Binary. I canāt say your switch would show manual state in OH without seeing the zniffer, but you could try.
Bob
edit GE 45605 have both, so should be report manual, if there is a basic set coming out of the device.
Some further information: I had the Zwave system working with a software called Axial Control (paid Windows software). I am interested in running in on a R-Pi instead of Windows, so I am trying this.
On the Axial system, when I turn on the closet light, it IMMEDIATELY reflects in the software UI. I am using the same Aeon Zstick (moving it back and forth between the two systems), so the hardware is exactly the same. So, I know the switch is sending the status update correctly, just something in OH that is not picking it up. So, your theory of Basic vs Switch_Binary sounds like a plausible one. How would I go about validating it?
A zniffer output would be one option or Providing the make and model of the switch and Iāll look it up.
The not so short story is that if it is missing you will need to get access to the community database, make an update to the device XML and then after a few days when the changes are approved and incorporated into the binding use the updated Zwave snapshot. Iām assuming you are on 3.1 at least, or there are more issues to getting things updated.
Bob
Mine is a GE 12722 - is that the right make/model info you are looking for, Bob?
So good news and bad news. The device is in the database as Zw4005 and does appear to be set-up to read both basic and switch binary command classes, so that is not the issue. The bad news is I donāt know why itās not working then. That was my best and only idea .
Sorry
Bob
So, I took a look at the network_xxxx_node_25.xml file (corresponding to this Thing) in /var/lib/openhab/zwave. In that, I saw the following snippet:
<nodeInformationFrame>
<commandClass>COMMAND_CLASS_SWITCH_BINARY</commandClass>
<commandClass>COMMAND_CLASS_SWITCH_ALL</commandClass>
<commandClass>COMMAND_CLASS_POWERLEVEL</commandClass>
<commandClass>COMMAND_CLASS_CONFIGURATION</commandClass>
<commandClass>COMMAND_CLASS_VERSION</commandClass>
<commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
<commandClass>COMMAND_CLASS_NODE_NAMING</commandClass>
</nodeInformationFrame>
So, looking at it, I DO see the
COMMAND_CLASS_SWITCH_BINARY
listed but NOT
COMMAND_CLASS_BASIC
I am on 3.1 Openhabian version. Thoughts?
Edit: I did not go down far enough. In the āsupportedCommandClassesā section of the XML further down, I see:
<entry>
<commandClass>COMMAND_CLASS_SWITCH_BINARY</commandClass>
<COMMAND__CLASS__SWITCH__BINARY>
<version>1</version>
<instances>1</instances>
<control>false</control>
<versionSupported>1</versionSupported>
<isGetSupported>true</isGetSupported>
</COMMAND__CLASS__SWITCH__BINARY>
</entry>
<entry>
<commandClass>COMMAND_CLASS_BASIC</commandClass>
<COMMAND__CLASS__BASIC>
<version>1</version>
<instances>1</instances>
<control>false</control>
<versionSupported>1</versionSupported>
<isGetSupported>true</isGetSupported>
</COMMAND__CLASS__BASIC>
</entry>
So, back to square one. Drats.
It appears that zniffer is no longer available for download anywhere (not that I can find). Do you have a way to get it? Would it be useful in debugging my sorry situation here?
So, I do believe the device supports sending manual changes, since it seems to work with my other software (see post a few above). However, I do NOT find an Association Groups section in the Thingās options (even with āadvancedā checked). Any thoughts on that?
There is a posting on zniffer (I think under solutions in the forum) set-up earlier in the year, but since the device appears to be set-up correctly and from your debug log, I see good and fast zwave communication it donāt think it will help here, although it is a good idea for your next project.
I looked at my GE switches and they do not have Association groups either. (just noticed this after many years). Anyway they work fine. Not that it matters, but they are not Zwave Plus devices, just regular Zwave and only transmit at 40Kb, not 100Kb like zwave plus
Separately Iām wondering if adding the metadata āauto-updateā to the switch āitemā might help.
Bob
Edit: Link to Zniffer instructions and other useful info
Tried setting auto-update to true on the point - no help 
Autoupdate is of no value in obtaining external status updates. Mostly, it actually masks many problems in this area.
The autoupdate was a hail mary.
At this point I would suggest manually operating the switch while z-wave is debug mode and look to see 1) if there is a message and 2) what seems to be happening to it. As these files can be big, try to minimize other zwave activity. Sometimes Iāll have the device right in front of me, switch to debug, do the tests and switch the binding back to Info. (Trying not to have my wife wandering around tripping sensors and lights 
Bob
That was actually pretty straightforward. And the answer is - there are NO debug messages when the switch is operated, ON or OFF. Total silence.
Yet, there MUST be something āin the airā that is not caught by OH, because my older system caught it and reacted to it immediately. So, the problem is at the driver level? Does that make sense?
It appears that the database entry for your device is malformed. There are no association groups configured.
This is why there are no association group options being rendered on the thing details screen for you. Presumably this is also why you are not getting any updates from the device because the lifeline (association group 1) is not set to controller at the moment as OH doesnāt know to do that and therefore the controller is not the target of the status updates from the device.
You need to check that the xml file you have does include a section on association groups and then work to update the database at OpenSmartHouse Z-Wave Device Database (click on the database user guide link in the banner to get started).
The only reference I found to association groups in the XML is an empty one:
<associationGroups class="concurrent-hash-map"/>
Is this OK?
The association group concern is beyond my knowledge. I agree there is ātypicallyā a lifeline association for most devices. My counter observations are:
As to no traffic from a manual operation in Debug mode, Iām also puzzled. Since you were getting messages on your old Windows system from manual operation, something zwave should have been broadcasted by the device and picked up by the controller and either rejected or accepted by OH.
A some random thoughts
This is really a nasty one.
Bob
Reminder that openHAB actively initializes devices. If it is doing something like setting association group to null, it matters little that it works with other systems that initialize it differently.
If in-service messages are not designated for āourā controller, they wonāt show up in the debug. See @JustinG above.
This is, I think (85% confident), independent of the issue at hand. I donāt think thereās any problem with the device being able to communicate with the controller. The problem is whether or not the device targets the controller for its messages once it is operating.
Iām stretching my memory here, but I believe that Lifeline as a standard is only a feature of ZW+. If these devices predate that then that may be the explanation for those missing association groups.
Right. But a status update from the device has to be addressed to the controller for it to use that last working route. My hypothesis here is that the device doesnāt know (for some reason related to how OH is currently handling a lack of association group 1) that node 1 should be the target destination. Wouldnāt that also explain the lack of any debug logging here?
The lack of association groups is probably correct then and this is just not a ZW+ device.