Youâre the best!
This is what a node with an already configured association looks like ( just a X). Is something is going wrong when fetching the list of nodes in the network? 
Iâm not 100% sure whatâs happening - thereâs a method I use to see if an endpoint has any âcontrollableâ classes. ie rather than just listing every endpoint even when an endpoint might not be configurable, I check to see what it supports - it looks like this has stopped working.
Iâve recoded it and itâs working now I think so Iâll create an update shortly (just finishing adding a test for this).
Ok - Iâve updated the binding - let me know if itâs working better nowâŠ
Itâs working!
Cool - thanks.
Yes - I agree. Iâll take a look at this over the weekend.
Unfortunately also with the latest version of the test binding this problem still exists. When I only enable the item
Number Wohnung_Stromzaehler_Energy "Verbrauch Gesamt Wohnung" <energy> {channel = "zwave:device:b05631f0:node6:meter_kwh"}
then I get very reliable an update every 5 minutes via the poll mechanism.
When I enable both items
Number Wohnung_Stromzaehler_Energy "Verbrauch Gesamt Wohnung" <energy> {channel = "zwave:device:b05631f0:node6:meter_kwh"}
Number Wohnung_Stromzaehler_Battery "Batterie Level StromzÀhler [%d %%]" <battery> (Batteriestatus) {channel = "zwave:device:b05631f0:node6:battery-level"}
only the battery-level is being updated every 5 minutes. But the meter_kwh is not being updated most of the time. As mentioned before with the same setup the 2.0.0 binding updated the values every time.
@chris: I will send you a debug log.
Regards,
André
This suggests that your problem is probably related to associations. Please make sure any debug log includes the setting of associations.
I just moved over to the test version of the binding. I was just setting up a new rule to sync dimmer levels across switches and see that the binding doesnât seem to be reporting the dimmer level back to OH.
Iâm using a Cooper R9540-N. Itâs associated back to the controller. If I change the dim level through the BasicUI, the light changes and the dimmer value is correctly reflected in OH. If I set the dim level manually through the switch, OH doesnât reflect the new dimmer level. If I turn the switch manually off, it does update that in OH.
Let me know if you want me to pull a debug log as well.
I donât think anything has changed, but if you have a log Iâll take a look.
Changed from an earlier version of the test binding or from the main branch?
Are the debug logs not working? I just changed to Debug to test and got no entries.
openhab> log:set DEBUG org.openhab.binding.zwave
openhab> log:list
Logger | Level
-------------------------------------------------------------------
ROOT | WARN
javax.jmdns | ERROR
org.apache.aries.spifly | ERROR
org.apache.karaf.kar.internal.KarServiceImpl | ERROR
org.eclipse.smarthome | INFO
org.jupnp | ERROR
org.openhab | INFO
org.openhab.binding.ZWave | DEBUG
org.ops4j.pax.web.service.jetty.internal.JettyServerWrapper | ERROR
smarthome.event | INFO
smarthome.event.InboxUpdatedEvent | ERROR
smarthome.event.ItemAddedEvent | ERROR
smarthome.event.ItemRemovedEvent | ERROR
smarthome.event.ItemStateEvent | ERROR
smarthome.event.ThingStatusInfoEvent | ERROR
Here is what I got from the Event.log. Actions were:
-
Turned on from BasicUI
-
Turned off from BasicUI
-
Turned on from Switch
-
Changed dim level to 100% from Switch
-
Turned off from Switch
17-03-11 12:41:32.752 [ItemCommandEvent ] - Item âLight_GF_Dining_Mainâ received command 55
2017-03-11 12:41:32.772 [GroupItemStateChangedEvent] - GF_Dining_Lights changed from OFF to ON through Light_GF_Dining_Main
2017-03-11 12:41:32.791 [ItemStateChangedEvent ] - Light_GF_Dining_Main changed from 0 to 55
2017-03-11 12:41:32.792 [GroupItemStateChangedEvent] - GF_Lights changed from OFF to ON through Light_GF_Dining_Main
2017-03-11 12:41:32.941 [ItemCommandEvent ] - Item âLight_GF_Dining_Mainâ received command 55
2017-03-11 12:41:39.025 [ItemCommandEvent ] - Item âLight_GF_Dining_Mainâ received command 0
2017-03-11 12:41:39.037 [GroupItemStateChangedEvent] - GF_Lights changed from ON to OFF through Light_GF_Dining_Main
2017-03-11 12:41:39.041 [GroupItemStateChangedEvent] - GF_Dining_Lights changed from ON to OFF through Light_GF_Dining_Main
2017-03-11 12:41:39.052 [ItemStateChangedEvent ] - Light_GF_Dining_Main changed from 55 to 0
2017-03-11 12:41:39.220 [ItemCommandEvent ] - Item âLight_GF_Dining_Mainâ received command 0
2017-03-11 12:41:45.620 [GroupItemStateChangedEvent] - GF_Lights changed from OFF to ON through Light_GF_Dining_Main
2017-03-11 12:41:45.623 [ItemStateChangedEvent ] - Light_GF_Dining_Main changed from 0 to 55
2017-03-11 12:41:45.625 [GroupItemStateChangedEvent] - GF_Dining_Lights changed from OFF to ON through Light_GF_Dining_Main
2017-03-11 12:41:50.017 [ItemStateChangedEvent ] - Light_GF_Dining_Main changed from 55 to 0
2017-03-11 12:41:50.018 [GroupItemStateChangedEvent] - GF_Lights changed from ON to OFF through Light_GF_Dining_Main
2017-03-11 12:41:50.023 [GroupItemStateChangedEvent] - GF_Dining_Lights changed from ON to OFF through Light_GF_Dining_Main
2017-03-11 12:42:00.004 [ChannelTriggeredEvent ] - astro:sun:local:plus30:noon#event triggered END
I mean no recent changes that should impact this within this branchâŠ
I just installed the test binding a couple of days ago so donât have a history to compare to.
As far as I know, itâs fine - certainly fine here.
Isnât this case sensitie? Iâm usually using âorg.openhab.binding.zwaveâ here and it works fine. Tried your version (uppercase ZW) now and it doesnât work.
Iâll try again, I thought I had tried both ways before. Thanks.
Actually, I double checked and I had used lower case, the list back reported it uppercase:
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