Yep. Seems like the log:set command actually IS case insensitive even though the logging isn’t 
Try setting it to default first (log:set default org.openhab.binding.ZWave) and then set it to debug with the correct casing (log:set debug org.openhab.binding.zwave).
That did it, thanks!!
@chris Here is the debug log associated with turning on the switch (Node 3), changing the dimmer value to ~50% and turning off the switch. Let me know if you want me to run more tests or if I didn’t get all of the relevant section. Thanks.
https://drive.google.com/open?id=0B77VHtwPft8eYWxzWFdFYS0td0U
Thanks - that’s fine. I’ll look at doing a fix for this in the next few days.
Great, thanks again for all the great work!!
Anyone else using / having issues with Aeon ZW112 Door/Window Sensor 6’s With the new binding mine keep showing up as failed though they do seem to work when I open them. I keep getting error messages in my log showing them as failed.
@Chris I had time today to pull a debug log file. It’s related to nodes 41 and 45. I’ve tried multiple times to deassociate / reassociate them with the controller. Let me know if there is any other information I can pull to help figure out what is going on - https://drive.google.com/open?id=0B77VHtwPft8eeF9vdUU4UVlpeFE
I’ve updated the binding at the usual link. This mainly updates the database, but also fixes an issue with the multilevel_switch reports from some devices and adds some debugging for another issue.
The fix partially works. If I turn on the switch, the OH reflects the state it turns on to, if I change the dimmer level at the switch the OH doesn’t reflect the new state. If I then turn off and turn back on the switch, OH reflects the new state. Also, if I turn it on or off from an associated aux switch, OH doesn’t reflect the change in state. Let me know if you want me to pull another debug log. Thanks.
Yes - probably best to get a new log to avoid confusion. I have a feeling the device was using the BASIC class for ON/OFF - this should work though I think, but let’s see the log.
If I understand this, you have a second switch that is associated to this switch. If you change the state of this switch, it changes the state ok, but OH doesn’t update? If so, I don’t think there’s any way around this - as far as I know, if you switch a device from another device, the switched device will not send out status changes to associated devices. I believe this is to avoid endless loops if you set up an association loop. Certainly I’ve seen this previously.
I think your only option here is to associate the first switch directly to OH and then use a rule to update the state.
(I hope that makes sense! 
).
Here you go. I turned the switch on, changed the dim level, turned it off, turned it back on, (might have changed the dim level a 2nd time), and turned it off. I also did the same thing with the Aux switch. Main switch is Node 3, Aux is Node 4.
https://drive.google.com/open?id=0B77VHtwPft8eVjhISzhYeWRwTWM
I was pretty sure with the old binding that I was getting the changes showing up in OH when the Aux turned the main on/off but can’t be 100% sure and can’t go test. I can setup some postUpdate rules to take care of it so not a huge issue. Thanks.
Maybe I misunderstood what you meant by Aux then - I’ll take a look at the log…
I messed up the change to fix this - I’ll update the binding shortly.
Regarding the switch 4 - at the end of the log I see some messages from switch 4 - I guess this is where you are switching it to change switch 3 state? There are no switch 3 messages received during this time, so I think what I said earlier is correct.
Thanks, and correct on testing the Switch 4 (Aux).
So, the issue is that the controller (not the binding) thinks these devices have failed -:
When I wrote this binding, I wanted to simplify things and I removed the DEAD node code and I now only use the controllers view of the node. I figured that this would be more reliable as the controller is “continuously” (well, periodically) exchanging messages with devices at lower level that we see at binding level. I’m starting to think this isn’t as reliable though and may need to rethink this concept if the controller is going to make what I assume are working nodes as FAILED…
Binding is updated again… Hopefully it will now work when controlled directly from the switch.
The weird thing is that any triggers to these sensors do come through even with the failed notice. What I’m not getting that I did get with the old binding is the battery updated (though with the old one it took a while before that reflected). Should I try changing anything with polling intervals?
It’s working now!! Thanks.
I meant a stand alone auxiliary switch that is directly associated to the main switch.
You won’t get the battery update probably since this is normally polled by the binding. Since the binding thinks it’s dead it’s not polling I expect.