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.
I think I’m kind of on the same page that’s why I asked some clarifying question about how the device and stick were reset between the old system and new. The device could still have the old system zstick ID and be sending the manual messages to the wrong ID, but responding to OH messages too? Will need to see the answers.
My GE devices are not ZW+ and I don’t think his is either.
Bob
OK, I went back and looked at my “old system” carefully - note that it was a purchased system that came up and “just worked” as I more or less wanted, so never really bothered to look under the covers as to how it was accomplishing what it was. But now I did, and after a few different experiments and poking around I discovered that the way it “just worked” was:
So, at least the mystery of “but it used to work before!” is solved. I really think this is not going to work without polling. I know and understand how much of an anathema that is- trust me I have a Master’s in CS, and over 4 decades of experience in various systems including RF (but not ZWave), and understand that the use of polling in an inherently event-driven system is to be avoided. But, I don’t really see a way around it, without going out and spending 100’s of $$ on new ZWave+ equipment, since most of my equipment is legacy.
Anyone have any other thoughts? Otherwise, we can consider this topic closed.
I was wondering about that option. However, I have a graveyard of zwave devices that I didn’t like how they work and just buy newer and better having learned what to look for. Although retired, I do value my time. If it’s just the one switch, in the US about $30 for 700 series, longer range, etc. versus getting a non-ZW+ device to work. Anyway best wishes. I hope I was helpful in someway.
Bob
Are you kidding? You were EXTREMELY helpful, as were the others on this thread! I do get this is a passion for you all, and deeply appreciate the time that you take to clarify things for new users. I am getting started on this journey, and you are right, I probably will start replacing items one by one to make it easier on the budget. There are only 2 or 3 items that I need reporting to the controller on state change, and those I can have polled. The others are exclusively controlled by the controller buttons, and those I don’t need to poll. Anyway, I will start off with that, and see where I get.
Figuring out scripting is my next learning curve!
Again, thanks so much for taking the time!