Well, I added habmin.
Removed all the zwave devices, re-added them. But habmin won’t finish configuring the zwave controller, so the log just says the comm isn’t configured.
I’m done for today, too frustrated and have places to be, so I need to get cleaned up and get dinner.
Maybe tomorrow. 
Oh, and Thanks for the help!
How? Are you excluding them or just deleting their Things? And why? 
There should really be no need to delete them at this point.
If you’re using an Aeon Labs zstick and pulled it to exclude the devices, then it probably came up on another port. Restart the Pi and the controller should come up. Either shutdown OH before pulling the controller or use OH for doing the exclusions.
You are very welcome!
Well, new day new frustration.
I figured, let’s start from a clean slate and see what happens. So, I did the following:
Then, I added habmin and the zwave binding.
Used Zwave binding to find the zstick and used the discover button to find the 2 NZW39’s.
It appears, I have control over parameters of the NZW39’s.
This is progress!
BUT, now when I add the Aeotec Micro Switch (which always worked fine before) it creates a linked item which doesn’t appear to exist, won’t let me delete it. It will allow me to add a new item, both shown below in habmin:
What do you see in Items? What you see in that screenshot are Links and the Items associated to them. Deleting a Link does not delete the Item. Do you have Simple Mode turned on? I thought it was off by default.
Yeah, there was an item that had a duplicate name, when I deleted that the blank link shown above in the thing went away.
I didn’t change Simply mode…and now I can’t figure out where in the ui’s I found it. Sigh.
But, now I’m back to nearly where I was a few days back…
It appears the two NZW39 are recognized differently. In HABPanel the widget for one responds to local control and the other doesn’t. One has lifeline set to the controller and assoc group set the controller, it’s widget responds to local. The other has no lifeline and won’t update group 3 to the controller (or anything else).
Update, it just allowed to change the lifeline and group 3, now it works…I swear it didn’t a few minutes ago. 
This just won’t go away…
The configuration I change, for example, disable invert switch or the associated channel don’t seem to be persistent after a shutdown/restart of the pi.
Should OH be shutdown first so the data actually gets saved?
On another note, it also appears the snapshot definitions of the NZW39 aren’t quite right…or again I’m off in the woods.
When I select the NZW39 dimmer item in the new rules engine, it only has the options On, Off, Down and Close.
In hapanel though, if I add a slider widget and select the the NZW39 item it dims just fine.
@chris @5iver just tagged you in the reply because the subject goes back a way in the thread…
So, today I was working on rules and such. And again noticed that the LED invert disable on the two NZW39 I included a couple days back had reverted to enabled.
I noticed this when I attempted to include a third NZW39 and it showed up as unknown.
(I also noticed, around the same time, that the .things files were not being read and things weren’t being updated with the changes. Not sure it has any bearing on the NZW39’s…)
But, when I rebooted, the DSC26 micro switch had stopped communicating (this has been the most consistent device…) When I ran an include a new DSC26 showed up with the the same uuid (or whatever the hex code is: zwave:device:16500637f6a:node10:switch_binary
But, the old one:
zwave:device:16500637f6a:node:switch_binary
manufacturer is 0086"AEON Labs:" and the Type/ID is 0003:01a, firmware: 2.14
and the new one:
zwave:device:16500637f6a:node6:switch_binary
manufacturer is 0086"AEON Labs:" and the Type/ID is 0003:01a, firmware: 2.14
As for the NZW39:
one of the recognized ones:
and the non-recognized one:
The only delta I see is the manufacturer.
Thoughts?
This device is made by Inovelli (0312) and there is also a rebranded one from Willis (015d):
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/662
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/770
If you have the Willis you should use a recent snapshot or development version of the binding because all the configuration parameters were just added two weeks ago.
@Chris, do we need a unique reference id for this in the database?
Both devices, that one from Inovelli and that one from Willis, both have nzw39.
I thought because of the different manufacturer it is not necessary, but may be wrong 
Just another data point on the config values in the recognized ones.
When I attempt to change them and save I get this in the log:
2018-08-11 13:57:23.168 [ERROR] [st.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at 'things/zwave:device:16500637f6a:node2/config'
java.lang.NullPointerException: null
at org.openhab.binding.zwave.handler.ZWaveThingHandler.handleConfigurationUpdate(ZWaveThingHandler.java:623) [209:org.openhab.binding.zwave:2.4.0.201808101448]
at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.updateConfiguration(ThingRegistryImpl.java:92) [101:org.eclipse.smarthome.core.thing:0.10.0.201808011124]
at org.eclipse.smarthome.io.rest.core.internal.thing.ThingResource.updateConfiguration(ThingResource.java:435) [111:org.eclipse.smarthome.io.rest.core:0.10.0.201808011124]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invok
... and lots more
I am using the snapshot.
I think that’s why the first two were recognized…
I’m clueless about why the DSC26 went…
Are your Things unmanaged… meaning you have created Thing files for them? If so, you cannot change the configuration parameters for them and will need to accept the default values. Maybe I’m misunderstanding what you wrote?
I can’t explain this… but I have seen devices show up in the Inbox even though they had been previously discovered and their Things had not been deleted. After adding them from the Inbox, they still functioned though. Did you accept it and is it working?
Are you doing the discovery through OH or are you shutting down OH and taking the zstick over to the device? Either will work, but it is best to do the inclusion through OH.
i think we just need to add these ids 2700:2700 to 662. This is the correct manufacturer - it just doesn’t have the IDs for this version.
The zwave devices are not in the .things file I’m updating, only things def for the astro binding.
The zwave thing config in Habmin allows me to change, for example, the invert switch to disable. And it stayed for a while, then switched back to enable. It’s like they are getting refreshed from a stale cache…
I’m including them with OH. The other thing I noticed in the zwave tools zwave net work viewer, some of my devices never show connected to the matrix. The dimmers are always linked to the controller and each other. But the switch devices are never connected to the controller or the dimmers, but sometimes each other or nothing. But they can still be controlled.
Done.
Sometimes it’s so easy …
Sometimes a lot of problems are solved with cleaning tmp and cache folders:
Thanks.
I can test that once it’s in the snapshot, but:
***rummaging noises***off refreshing my memory on how to see if new snapshot is up 
Did a cache clear/reboot as recommended
After the reboot, using HABmin I changed the NZW39 Configuration parameter#4 “Invert Switch” from enable to disable. Now, some 15 hours later it seems to have stuck.
But, in the Association Groups, Group 3, I selected openHAB Controller.
But that did not stick, i.e. the field is blank again.
Are these settings stored in a file I can look at? Since the control display in PaperUI and widget in HAB Panel change when the local buttons are pushed, It appears the value is there. (That is, if understand it correctly that the association is what makes the feedback to update the displays in PaperUI and HAB Panel happen.)
Mac
This is a bug in HABmin, don’t worry. Take a look at PaperUI, you should see the correct association group.
Correct.