That’s what mine does. I always assumed it was just helping you to do the most common thing… Set the controller to receive data from nodes. I’m pretty sure you can just type another comma separated node number in there and it will take, too.
I’ll take a look at this - agree that something doesn’t seem right at the moment.
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: