From what I can tell, then are mains switches. They are regularly reporting meter data…
The binding is not sending the requests to the device - it’s not a case of them sleeping (mains switches won’t sleep anyway). The is because the database has the NOGET option set (at least for the PAN11 and the MT02646 - I’m not sure what nodes they are).
Gotcha… I saw he referenced some plug-ins, but wasn’t sure if there were possibly some battery devices in the mix.
thanks all for your effort…really frustrating. 
PAN11 for example is Solar_Switch…Node8
MT02646…is PVng5Poly and PVng5Mono…Node 49 & 50.
Especially these never update…at all.
So Chris, you say that for sure these device brands have no chance at all to react to polling…
Again, its strange to me how it ever could have worked with OH1. But i get what you say.
All are plug-devices, so all time online, never sleeping.
what is “polling” called in PaperUI Things properties?
zwave_listening true (???)
Currently, this is disabled in the database. As I said, I don’t know why this is - maybe it’s incorrectly set, but that’s the way it is. If you think it’s wrong, then please feel free to change it and we an see if it works, but it’s likely it was set this way for a reason.
OH1 database is not configured like this.
Yes.
It’s just called “polling time” - there’s nothing else.
No - this is a low level zwave device attribute. It basically indicates if the device is a mains device or a battery device.
sorry, Chris - that this is a slow progressing item…but things start to get clear now.
Recap:
The named plug-brands are definitely “disabled” for polling. so what we see in the logs has to be that way as the 3 plugs are per DB not able to react…unclear if they could, but not tried yet.
As you are the incredible chief of zwave binding - was the DB as well disabling polling in OH1 for the named plugs?
Can you advice me for example how to enable polling for the PAN11-devices…which files to touch.
No - that’s what I said above - OH1 database is not configured like this.
What I suggest is the following. Stop the binding (or stop OH), then edit the XML file for this node. In the XML you should find something called <isGetSupported>false - either remove this line or change it to true. Then restart and it should now work.
something called false? there are more than 6 false in the xmls…
do you mean this part?
<entry>
<commandClass>SWITCH_BINARY</commandClass>
<binarySwitchCommandClass>
<version>1</version>
<instances>1</instances>
<versionSupported>1</versionSupported>
<isGetSupported>false</isGetSupported>
</binarySwitchCommandClass>
</entry>
<entry>Sorry - I didn’t code fence the XML.
This is the line you want to remove.
seems to work…
there was long time written in HABMIN “getconfig initialization”…or similar.
changed the polling to 60 to speed up things and the first time after OH2 migration i see:
2017-09-05 23:29:34.285 [temChannelLinkRemovedEvent] - Link ‘Solar_Switch => zwave:device:f7e2c745:node8:switch_binary’ has been removed.
2017-09-05 23:39:47.680 [ItemChannelLinkAddedEvent ] - Link ‘Solar_Switch-zwave:device:f7e2c745:node8:switch_binary’ has been added.
2017-09-05 23:47:31.752 [ItemStateChangedEvent ] - Solar_Switch changed from NULL to OFF
Will this be updated in DB for current snapshots?
Anyhow a side question,… is it possible somehow to update bindings to 2.2.0 snapshot and still keep the core to 2.1?
(or nonsense as its a bundle you would not want to mix with others?)
Please can you confirm the devices - is this for all 3 of the devices you listed above?
Yes, you can uninstall the binding, then put the latest snapshot into the addons folder. Then go to Karaf and type the following -:
feature:install openhab-transport-serial
You can then start the new binding in Karaf.
Except the PAN11…the other two work much better, means that after 10mins or so I can see the real state in the GUI (changed from NULL to…).
However - PAN11 Plugs behave strange…no update at all on the switch state and suddenly the power-level is also shown with a “-”…so uninitialized. Therefore i removed the True and went back to False for PAN11…still checken for PAN11.
As said, the two others work definitely as it should in terms of real state.
@snapshot bindings…i’m using the *.kar files. So i have to uninstall all bindings of 2.1 before I can switch to 2.2 bindings? would that have any impact to configs done via GUI.
Hi guys
ive got a similiar issue, Zwave debug shows everything working fine and changes to the bright of the Fibaro Zwave Dimmer are instant but the Basic UI and HabPanel updates dont work unless I restart OH2.
Something is a bit odd.
I am displaying the Meter_kw & meter_watts channels in Basic UI but they dont update. I figure ill focus on getting things changing correctly in this UI until I work on HabPanel.
Any thoughts?
19:35:46.668 [DEBUG] [tocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
19:35:46.669 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0E 00 13 04 07 60 0D 01 01 26 01 42 25 2B E7
19:35:46.669 [DEBUG] [ding.zwave.handler.ZWaveSerialHandler] - NODE 4: Sending REQUEST Message = 01 0E 00 13 04 07 60 0D 01 01 26 01 42 25 2B E7
19:35:46.672 [INFO ] [smarthome.event.ItemStateChangedEvent] - KitchenDim1 changed from 13 to 66
19:35:46.672 [DEBUG] [ave.internal.protocol.ZWaveController] - Message queued. Queue length = 0. Queue={}
19:35:46.677 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
19:35:46.678 [DEBUG] [ave.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
19:35:46.678 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8
19:35:46.678 [DEBUG] [ave.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8
19:35:46.679 [DEBUG] [ave.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01
19:35:46.679 [DEBUG] [ol.serialmessage.SendDataMessageClass] - NODE 4: Sent Data successfully placed on stack.
19:35:46.694 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 2B 00 00 02 C2
19:35:46.695 [DEBUG] [ave.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
19:35:46.695 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 2B 00 00 02 00 00 CC
19:35:46.696 [DEBUG] [ave.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 2B 00 00 02 00 00 CC
19:35:46.696 [DEBUG] [ave.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=2B 00 00 02
19:35:46.696 [DEBUG] [ol.serialmessage.SendDataMessageClass] - NODE 4: SendData Request. CallBack ID = 43, Status = Transmission complete and ACK received(0)
19:35:46.696 [DEBUG] [ialization.ZWaveNodeInitStageAdvancer] - NODE 4: Starting initialisation from DONE
19:35:46.697 [DEBUG] [ave.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@69d9423d already registered
19:35:46.697 [DEBUG] [l.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=4, callback=43, payload=04 07 60 0D 01 01 26 01 42
19:35:46.697 [DEBUG] [l.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=2B 00 00 02
19:35:46.697 [DEBUG] [l.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=43, expected=SendData, cancelled=false transaction complete!
19:35:46.698 [DEBUG] [ave.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
19:35:46.698 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 4: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
19:35:46.707 [DEBUG] [tocol.ZWaveController$ZWaveSendThread] - NODE 4: Response processed after 35ms/99ms.
Items:
/*Group Definitions*/
Group gPowerConsumption
Group:Number:SUM gPowerUsage
/*Reset ZWave Usage*/
Switch LivingRoomReset { channel="zwave:device:d4900ba9:node2:meter_reset" }
Switch KitchenReset { channel="zwave:device:d4900ba9:node4:meter_reset" }
/*ZWave Switches*/
Switch LivingRoomSw1 "Living Room" { channel="zwave:device:d4900ba9:node2:switch_dimmer1" }
Dimmer LivingRoomDim1 "Living Room [%d %%]" { channel="zwave:device:d4900ba9:node2:switch_dimmer1" }
Number LivingRoomNum1 "Living Room - Current Consumption [%.1f W]" { channel="zwave:device:d4900ba9:node2:meter_watts1" }
Number LivingRoomNum2 "Living Room - Usage [%.1f kW]" (gPowerUsage) { channel="zwave:device:d4900ba9:node2:meter_kwh1" }
Switch KitchenSw1 "Kitchen" { channel="zwave:device:d4900ba9:node4:switch_dimmer1" }
Dimmer KitchenDim1 "Kitchen [%d %%]" { channel="zwave:device:d4900ba9:node4:switch_dimmer1" }
Number KitchenNum1 "Kitchen - Current Consumption [%.1f W]" { channel="zwave:device:d4900ba9:node4:meter_watts1" }
Number KitchenNum2 "Kitchen - Usage [%.1f kW]" (gPowerUsage) { channel="zwave:device:d4900ba9:node4:meter_kwh1" }
kris@OpenHAB:/etc/openhab2/items$
I’m not completely sure what it is you are wanting to show in the log, but it does not show any received data - just the command to set the switch. Until the device is sending data, it won’t be displayed 
.
The issue I have is the UI’s dont get the updates frequently enough. Any thoughts on what I would debug to show that?
I would look in the logs - if the logs show that the data is coming in from the device, but the UI isn’t displaying it, then we know the problem is in the framework. If the device just isn’t sending the data as often as you want, then that’s another issue all-together, and for this you need to look at the device configuration.
The third option is that the binding is doing something strange - again, the logs will show this as you will see the data being received, but not updating the channel.
Thanks @chris
I posted the above debug in a hope you’d see data. It looks like data is coming in, because the light brightness changes .
The options in terms of frequency in the Thing are default, 3600 for Option 52, Option 50 & 53 are set to 10.
No - the light brightness was a command sent by the binding. There is no data coming in from the device to provide any meter information.
I would check the associations. You could also look at using the development binding which fixes some issues with associations in new devices.
In addition to what @chris said, once you confirm that data is coming into the binding, you can look at events.log to verify that the event is being placed on the event bus. Using something like this command will filter out any other events.
tail -f events.log | grep "NameOfYourItem"