Very "chatty" zwave fibaro FGD212 dimmer 2

[mark.carline (Mark)]

I’ve just installed (yesterday) a Fibaro FGD212 dimmer 2 unit and i’ve managed to get the basics setup (not done any config of the dimmer unit yet so its all defaults) and i’m noticing this repeating in the “OZW_Log.txt” file:

2016-10-23 20:16:32.601 Info, mgr, Refreshing node 80: COMMAND_CLASS_SWITCH_MULTILEVEL index = 6 instance = 1 (to confirm a reported change)
2016-10-23 20:16:32.655 Info, mgr, Refreshing node 80: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-10-23 20:16:32.655 Detail, Node080, Queuing (Send) MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Get (Node=80): 0x01, 0x0d, 0x00, 0x13, 0x50, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x 26, 0x02, 0x25, 0x61, 0xba
2016-10-23 20:16:32.655 Detail,
2016-10-23 20:16:32.655 Info, Node080, Sending (Send) message (Callback ID=0x61, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): SwitchMultilevelCmd_Get (Node=80): 0x01, 0x0d, 0x 00, 0x13, 0x50, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x02, 0x25, 0x61, 0xba
2016-10-23 20:16:32.663 Detail, Node080, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2016-10-23 20:16:32.663 Detail, Node080, ZW_SEND_DATA delivered to Z-Wave stack
2016-10-23 20:16:32.675 Info, mgr, Refreshing node 80: COMMAND_CLASS_SWITCH_MULTILEVEL index = 6 instance = 2 (to confirm a reported change)
2016-10-23 20:16:32.678 Info, mgr, Refreshing node 80: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 2 (to confirm a reported change)
2016-10-23 20:16:32.678 Detail, Node080, Queuing (Send) MultiChannel Encapsulated (instance=2): SwitchMultilevelCmd_Get (Node=80): 0x01, 0x0d, 0x00, 0x13, 0x50, 0x06, 0x60, 0x0d, 0x01, 0x02, 0x 26, 0x02, 0x25, 0x62, 0xba
2016-10-23 20:16:32.793 Detail, Node080, Received: 0x01, 0x07, 0x00, 0x13, 0x61, 0x00, 0x00, 0x0e, 0x84
2016-10-23 20:16:32.794 Detail, Node080, ZW_SEND_DATA Request with callback ID 0x61 received (expected 0x61)
2016-10-23 20:16:32.794 Info, Node080, Request RTT 138 Average Request RTT 149
2016-10-23 20:16:32.794 Detail, Expected callbackId was received
2016-10-23 20:16:32.912 Detail, Node080, Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x50, 0x07, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x03, 0x63, 0x8a
2016-10-23 20:16:32.912 Detail,
2016-10-23 20:16:32.913 Info, Node080, Response RTT 257 Average Response RTT 269
2016-10-23 20:16:32.913 Info, Node080, Received a MultiChannelEncap from node 80, endpoint 1 for Command Class COMMAND_CLASS_SWITCH_MULTILEVEL
2016-10-23 20:16:32.913 Info, Node080, Received SwitchMultiLevel report: level=99
2016-10-23 20:16:32.913 Detail, Node080, Refreshed Value: old value=99, new value=99, type=byte
2016-10-23 20:16:32.913 Detail, Node080, Changes to this value are not verified
2016-10-23 20:16:32.913 Detail, Node080, Expected reply and command class was received
2016-10-23 20:16:32.913 Detail, Node080, Message transaction complete
2016-10-23 20:16:32.913 Detail,
2016-10-23 20:16:32.913 Detail, Node080, Removing current message
2016-10-23 20:16:32.913 Detail, Node080, Notification: ValueChanged
2016-10-23 20:16:32.949 Detail,
2016-10-23 20:16:32.950 Info, Node080, Sending (Send) message (Callback ID=0x62, Expected Reply=0x04) - MultiChannel Encapsulated (instance=2): SwitchMultilevelCmd_Get (Node=80): 0x01, 0x0d, 0x 00, 0x13, 0x50, 0x06, 0x60, 0x0d, 0x01, 0x02, 0x26, 0x02, 0x25, 0x62, 0xba
2016-10-23 20:16:32.958 Detail, Node080, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2016-10-23 20:16:32.958 Detail, Node080, ZW_SEND_DATA delivered to Z-Wave stack
2016-10-23 20:16:33.151 Detail, Node080, Received: 0x01, 0x07, 0x00, 0x13, 0x62, 0x00, 0x00, 0x13, 0x9a
2016-10-23 20:16:33.151 Detail, Node080, ZW_SEND_DATA Request with callback ID 0x62 received (expected 0x62)
2016-10-23 20:16:33.151 Info, Node080, Request RTT 201 Average Request RTT 175
2016-10-23 20:16:33.151 Detail, Expected callbackId was received
2016-10-23 20:16:33.273 Detail, Node080, Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x50, 0x07, 0x60, 0x0d, 0x02, 0x01, 0x26, 0x03, 0x00, 0xea
2016-10-23 20:16:33.273 Detail,
2016-10-23 20:16:33.273 Info, Node080, Response RTT 324 Average Response RTT 296
2016-10-23 20:16:33.274 Info, Node080, Received a MultiChannelEncap from node 80, endpoint 2 for Command Class COMMAND_CLASS_SWITCH_MULTILEVEL
2016-10-23 20:16:33.274 Info, Node080, Received SwitchMultiLevel report: level=0
2016-10-23 20:16:33.274 Detail, Node080, Refreshed Value: old value=0, new value=0, type=byte
2016-10-23 20:16:33.274 Detail, Node080, Changes to this value are not verified
2016-10-23 20:16:33.274 Detail, Node080, Expected reply and command class was received
2016-10-23 20:16:33.274 Detail, Node080, Message transaction complete
2016-10-23 20:16:33.274 Detail,
2016-10-23 20:16:33.274 Detail, Node080, Removing current message
2016-10-23 20:16:33.274 Detail, Node080, Notification: ValueChanged

Any ideas - Seems to be very chatty and just didnt want it swaping my zwave network.

Thanks!

[mark.carline (Mark)]

bump

So i looked into this alot more. I am only seeing this traffic when HA is running and its exactly every 2 seconds. Something seems to start it off but not sure what at the moment.

Could it be some kind of polling of this device?

Any ideas?

[mark.carline (Mark)]

I’m going to have a play with three polling intervals for the fibaro dimmer 2 tonight, based on this:

Z-Wave Polling Questions Answered

After doing a little digging of my own I wanted to hopefully shed some light on what the polling interval and polling intensity actually does within the HA (Home Assistant) configuration. There have been many questions and complains about devices not polling correctly, and while I shared some of the frustration with these issues after taking a look at the HA code and the libopenzwave python code it all became clear. To save you all the trouble of doing the same digging here are my findings. Z…

Anyone know what this means:

2016-10-23 20:16:32.601 Info, mgr, Refreshing node 80: COMMAND_CLASS_SWITCH_MULTILEVEL index = 6 instance = 1 (to confirm a reported change)

I’m seeing it for four parts of the dimmer:

index = 6 instance = 1
index = 0 instance = 1
index = 6 instance = 2
index = 0 instance = 2

[markferry]

I’ve seen this issue too.

Since the dimmer is always awake though I have no polling configured for it.

Still after some activity it starts spamming the network and filling my OZW logs.

[mark.carline (Mark)]

So i see this in the xml:

  	<CommandClass id="38" name="COMMAND_CLASS_SWITCH_MULTILEVEL" version="3" request_flags="1" innif="true">
  		<Instance index="1" endpoint="1" />
  		<Instance index="2" endpoint="2" />
  		<Value type="byte" genre="user" instance="1" index="0" label="Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="99" />
  		<Value type="button" genre="user" instance="1" index="1" label="On" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
  		<Value type="button" genre="user" instance="1" index="2" label="Off" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
  		<Value type="bool" genre="system" instance="1" index="3" label="Ignore Start Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="True" />
  		<Value type="byte" genre="system" instance="1" index="4" label="Start Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
  		<Value type="byte" genre="system" instance="1" index="5" label="Dimming Duration" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="255" />
  		<Value type="byte" genre="user" instance="1" index="6" label="Step Size" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
  		<Value type="button" genre="user" instance="1" index="7" label="Inc" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
  		<Value type="button" genre="user" instance="1" index="8" label="Dec" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
  		<Value type="byte" genre="user" instance="2" index="0" label="Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
  		<Value type="button" genre="user" instance="2" index="1" label="Bright" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
  		<Value type="button" genre="user" instance="2" index="2" label="Dim" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
  		<Value type="bool" genre="system" instance="2" index="3" label="Ignore Start Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="True" />
  		<Value type="byte" genre="system" instance="2" index="4" label="Start Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
  		<Value type="byte" genre="system" instance="2" index="5" label="Dimming Duration" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="255" />
  		<Value type="byte" genre="user" instance="2" index="6" label="Step Size" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
  		<Value type="button" genre="user" instance="2" index="7" label="Inc" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
  		<Value type="button" genre="user" instance="2" index="8" label="Dec" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
  	</CommandClass>

So I think it has something to do with:

  		<Value type="byte" genre="user" instance="1" index="6" label="Step Size" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
  		<Value type="byte" genre="user" instance="1" index="0" label="Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="99" />
  		<Value type="byte" genre="user" instance="2" index="6" label="Step Size" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
  		<Value type="byte" genre="user" instance="2" index="0" label="Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />

Hmm

[mark.carline (Mark)]

Not tested this yet but i’m trying this:

zwave:
usb_path: /dev/ttyACM0
config_path: /srv/hass/hass_venv/lib/python3.4/site-packages/libopenzwave-0.3.1-py3.4-linux-armv7l.egg/config
polling_interval: 60000
customize:
light.fibaro_system_fgd212_dimmer_2_level_80_0:
polling_intensity: 0
light.fibaro_system_fgd212_dimmer_2_level_80_0_2:
polling_intensity: 0
light.fibaro_system_fgd212_dimmer_2_step_size_80_6:
polling_intensity: 0
light.fibaro_system_fgd212_dimmer_2_step_size_80_6_2:
polling_intensity: 0

[mark.carline (Mark)]

UPDATE - Tested this change - no impact, still spamming

[mark.carline (Mark)]

ok - i’ve no idea. We need to work out @markferry why these four lines are being writtern to the OZW log:

2016-10-23 20:16:32.601 Info, mgr, Refreshing node 80: COMMAND_CLASS_SWITCH_MULTILEVEL index = 6 instance = 1 (to confirm a reported change)
2016-10-23 20:16:32.655 Info, mgr, Refreshing node 80: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
…
2016-10-23 20:16:32.675 Info, mgr, Refreshing node 80: COMMAND_CLASS_SWITCH_MULTILEVEL index = 6 instance = 2 (to confirm a reported change)
2016-10-23 20:16:32.678 Info, mgr, Refreshing node 80: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 2 (to confirm a reported change)

The rest just seems to be z wave communication (sending the message and then getting a result). Its just like HA seems to be polling these devices to check on their status every 2-3 seconds.

anyone else review this ?

UPDATE: Just to verify - I’ve tried spinning up ozwcp and then checking the logs, there’s none of this 2-3 second activity happening at all under there, all seems normal. Very odd. I think 99% this is some kind of bug in HA for these devices.

[mark.carline (Mark)]

So ! I found something !!

This unusual activity that we’re seeing every 2-3 seconds in the logs (the repeated log entries in the original post above) is always happening for me but I found something to stop it happening so I thought I would recreate it and upload some logs

btw - The forum wouldnt let me upload the files - See my dropbox folder under “Test1”: https://www.dropbox.com/sh/e4wf1gp5bl24r3h/AAC_Zc36d3tdzp17jnYexcTEa?dl=0

Step 1) 17:20 - Rebooted the PI

Step 2) Checked for messages being recreated every 2 secs.
OZW_Log.txt - Time: 2016-10-28 17:25:14.330

Step 3) Put HA into zwave “add node” mode
OZW_Log.txt - Time: 2016-10-28 17:27:21.477

Step 4) Re-include the dimmer back into the zwave network (press button 1 three times quickly)
OZW_Log.txt - Time: 2016-10-28 17:27:29.704

Step 5) Check fixed.
No more repeated log entries observed in Step 1 noticed anymore.

NOTE:

1. home-assistant.log - See lots of errors received about:
   16-10-28 17:27:29 openzwave: Z-Wave Notification ValueRemoved for an unknown value ({‘id’: 72057595384922113}) on node 80
   plus the python errors

16-10-28 17:27:39 openzwave: Error in manager callback
Traceback (most recent call last):
File “/srv/hass/hass_venv/lib/python3.4/site-packages/openzwave-0.3.1-py3.4.egg/openzwave/network.py”, line 950, in zwcallback
self._handle_value_changed(args)
File “/srv/hass/hass_venv/lib/python3.4/site-packages/openzwave-0.3.1-py3.4.egg/openzwave/network.py”, line 1501, in _handle_value_changed
‘value’ : self.nodes[args[‘nodeId’]].values[args[‘valueId’][‘id’]]})
File “/srv/hass/hass_venv/lib/python3.4/site-packages/PyDispatcher-2.0.5-py3.4.egg/pydispatch/dispatcher.py”, line 338, in send
**named
File “/srv/hass/hass_venv/lib/python3.4/site-packages/PyDispatcher-2.0.5-py3.4.egg/pydispatch/robustapply.py”, line 55, in robustApply
return receiver(*arguments, **named)
File “/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/components/sensor/zwave.py”, line 75, in value_changed
self.update_ha_state()
File “/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/helpers/entity.py”, line 184, in update_ha_state
).result()
AttributeError: ‘NoneType’ object has no attribute ‘loop’

NOTE: I wasnt removing the node but its something about the device being “readded” that seems to fix this. I’ve tried to add the node using the open z wave control panel and checking the contents of the ID 80 for the xml to see if its any difference and nothing.

So. I am now 100% sure this is a bug with HA and these devices - maybe its not reading the local device xml correctly or something.

Any ideas what the next steps are? I can run more tests / debug log files if somebody tells me what to do?

Cheers in advance guys!

[mark.carline (Mark)]

UPDATE Been looking at the logs when i’ve re-added the fibaro wall dimmer back in (see timestamp in the “OZW_Log.txt” logs “2016-10-28 17:27:29.704”) here:

https://www.dropbox.com/sh/e4wf1gp5bl24r3h/AAC_Zc36d3tdzp17jnYexcTEa?dl=0

and i’ve noticed these four lines:

2016-10-28 17:27:29.883 Info, Node080, DisablePoll failed - value not on list
…
2016-10-28 17:27:29.935 Info, Node080, DisablePoll failed - value not on list
…
2016-10-28 17:27:29.942 Info, Node080, DisablePoll failed - value not on list
…
2016-10-28 17:27:29.946 Info, Node080, DisablePoll failed - value not on list

and then these again:

2016-10-28 17:27:34.563 Info, Node080, DisablePoll failed - value not on list
…
2016-10-28 17:27:34.583 Info, Node080, DisablePoll failed - value not on list
…
2016-10-28 17:27:34.762 Info, Node080, DisablePoll failed - value not on list
…
2016-10-28 17:27:34.766 Info, Node080, DisablePoll failed - value not on list

I’m stabbing in the dark but something isn’t right - i’m sure its something to do with the XML defintion not being correct but the device 80 seems to be defined in the xml as per:

poll_intensity=“0”

I wonder if anyone knows if we can check what devices on a device ID are being polled.

Thanks

Mark

[mark.carline (Mark)]

@markferry - have you tried re-adding and see if it stops but then reboot and see if it starts again ?

[mark.carline (Mark)]

bump

I’ve opened a bug report on github for this:

https://github.com/home-assistant/home-assistant/issues/4159

Hope we can fix this as otherwise HA is a non starter for me (and i really like it / want to help etc), I’ve just ordered two more of these fibaro wall switches (it’s the only ones I can use as I’m in the UK and i have a two wire setup).

Thanks in advance to anyone that can help!

[reed (Reed Taylor)]

I’m experiencing a very similar issue, only I have 3-4 devices in this state.

I was able to make some progress in shushing them by forcing them to wait 5, rather than 2, seconds before refreshing the status of the light. I did this by hackiily changing homeassistant/components/light/zwave.py to mimic the behavior implemented more thoughtfully in this change. @mezz64 in case he finds this interesting.

Note that this approach had nothing to do with multiple instances. I do have some multi-instance devices but the overactive dimmer switches were not among them.

Edit: I take it back. After restarting I found that extending the refresh delat from 2 to 5 did not have the effect of quieting these nodes. Here’s a log of the network going crazy for a while. There are some exciting sections like the following, which I’m not surprised are leading to refresh storms.

2016-11-10 23:45:32.293 Info, mgr, Refreshing node 14: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:32.293 Detail, Node014, Queuing (Send) SwitchMultilevelCmd_Get (Node=14): 0x01, 0x09, 0x00, 0x13, 0x0e, 0x02, 0x26, 0x02, 0x25, 0x0a, 0xe2
2016-11-10 23:45:32.293 Info, mgr, Refreshing node 14: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:32.293 Detail, Node014, Queuing (Send) SwitchMultilevelCmd_Get (Node=14): 0x01, 0x09, 0x00, 0x13, 0x0e, 0x02, 0x26, 0x02, 0x25, 0x0b, 0xe3
2016-11-10 23:45:32.293 Info, mgr, Refreshing node 14: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:32.293 Detail, Node014, Queuing (Send) SwitchMultilevelCmd_Get (Node=14): 0x01, 0x09, 0x00, 0x13, 0x0e, 0x02, 0x26, 0x02, 0x25, 0x0c, 0xe4
2016-11-10 23:45:32.294 Info, mgr, Refreshing node 14: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:32.294 Detail, Node014, Queuing (Send) SwitchMultilevelCmd_Get (Node=14): 0x01, 0x09, 0x00, 0x13, 0x0e, 0x02, 0x26, 0x02, 0x25, 0x0d, 0xe5
2016-11-10 23:45:32.294 Info, mgr, Refreshing node 14: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:32.294 Detail, Node014, Queuing (Send) SwitchMultilevelCmd_Get (Node=14): 0x01, 0x09, 0x00, 0x13, 0x0e, 0x02, 0x26, 0x02, 0x25, 0x0e, 0xe6
2016-11-10 23:45:33.142 Info, mgr, Refreshing node 10: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:33.142 Detail, Node010, Queuing (Send) SwitchMultilevelCmd_Get (Node=10): 0x01, 0x09, 0x00, 0x13, 0x0a, 0x02, 0x26, 0x02, 0x25, 0x0f, 0xe3
2016-11-10 23:45:33.143 Info, mgr, Refreshing node 10: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:33.143 Detail, Node010, Queuing (Send) SwitchMultilevelCmd_Get (Node=10): 0x01, 0x09, 0x00, 0x13, 0x0a, 0x02, 0x26, 0x02, 0x25, 0x10, 0xfc
2016-11-10 23:45:33.143 Info, mgr, Refreshing node 10: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:33.143 Detail, Node010, Queuing (Send) SwitchMultilevelCmd_Get (Node=10): 0x01, 0x09, 0x00, 0x13, 0x0a, 0x02, 0x26, 0x02, 0x25, 0x11, 0xfd
2016-11-10 23:45:33.143 Info, mgr, Refreshing node 10: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:33.143 Detail, Node010, Queuing (Send) SwitchMultilevelCmd_Get (Node=10): 0x01, 0x09, 0x00, 0x13, 0x0a, 0x02, 0x26, 0x02, 0x25, 0x12, 0xfe
2016-11-10 23:45:34.120 Info, mgr, Refreshing node 25: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:34.120 Detail, Node025, Queuing (Send) SwitchMultilevelCmd_Get (Node=25): 0x01, 0x09, 0x00, 0x13, 0x19, 0x02, 0x26, 0x02, 0x25, 0x13, 0xec
2016-11-10 23:45:34.121 Info, mgr, Refreshing node 25: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:34.121 Detail, Node025, Queuing (Send) SwitchMultilevelCmd_Get (Node=25): 0x01, 0x09, 0x00, 0x13, 0x19, 0x02, 0x26, 0x02, 0x25, 0x14, 0xeb
2016-11-10 23:45:34.121 Info, mgr, Refreshing node 25: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:34.121 Detail, Node025, Queuing (Send) SwitchMultilevelCmd_Get (Node=25): 0x01, 0x09, 0x00, 0x13, 0x19, 0x02, 0x26, 0x02, 0x25, 0x15, 0xea
2016-11-10 23:45:34.121 Info, mgr, Refreshing node 25: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:34.122 Detail, Node025, Queuing (Send) SwitchMultilevelCmd_Get (Node=25): 0x01, 0x09, 0x00, 0x13, 0x19, 0x02, 0x26, 0x02, 0x25, 0x16, 0xe9
2016-11-10 23:45:34.122 Info, mgr, Refreshing node 25: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:34.122 Detail, Node025, Queuing (Send) SwitchMultilevelCmd_Get (Node=25): 0x01, 0x09, 0x00, 0x13, 0x19, 0x02, 0x26, 0x02, 0x25, 0x17, 0xe8
2016-11-10 23:45:35.058 Info, mgr, Refreshing node 12: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:35.058 Detail, Node012, Queuing (Send) SwitchMultilevelCmd_Get (Node=12): 0x01, 0x09, 0x00, 0x13, 0x0c, 0x02, 0x26, 0x02, 0x25, 0x18, 0xf2
2016-11-10 23:45:35.058 Info, mgr, Refreshing node 12: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:35.058 Detail, Node012, Queuing (Send) SwitchMultilevelCmd_Get (Node=12): 0x01, 0x09, 0x00, 0x13, 0x0c, 0x02, 0x26, 0x02, 0x25, 0x19, 0xf3
2016-11-10 23:45:35.058 Info, mgr, Refreshing node 12: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:35.058 Detail, Node012, Queuing (Send) SwitchMultilevelCmd_Get (Node=12): 0x01, 0x09, 0x00, 0x13, 0x0c, 0x02, 0x26, 0x02, 0x25, 0x1a, 0xf0
2016-11-10 23:45:35.058 Info, mgr, Refreshing node 12: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:35.059 Detail, Node012, Queuing (Send) SwitchMultilevelCmd_Get (Node=12): 0x01, 0x09, 0x00, 0x13, 0x0c, 0x02, 0x26, 0x02, 0x25, 0x1b, 0xf1
2016-11-10 23:45:35.059 Info, mgr, Refreshing node 12: COMMAND_CLASS_SWITCH_MULTILEVEL index = 0 instance = 1 (to confirm a reported change)
2016-11-10 23:45:35.059 Detail, Node012, Queuing (Send) SwitchMultilevelCmd_Get (Node=12): 0x01, 0x09, 0x00, 0x13, 0x0c, 0x02, 0x26, 0x02, 0x25, 0x1c, 0xf6

[moskovskiy82]

Plus me in on this. Every 2 seconds something comes up. Any solution?

[reed (Reed Taylor)]

I know it’s been a while, but I was indeed able to remedy this situation, so I’ll post my solution for posterity. They key was taking the problematic device and changing the refresh delay to a longer number. The needed changes were released a couple of versions ago, with thanks to @turbokongen . Here’s a relevant config example from what I’m now using:

zwave:
  usb_path: /dev/ttyUSB0
  polling_interval: 60000
  customize:
    light.lr_behind_tv_recessed_level_6_0:
      polling_intensity: 2
      refresh_value: true
      delay: 5