Is there a workaround for the polling_intensity problem? When I turn one of my GE Dimmer’s that I added on 0.67.1, it never turns off on the UI. I have set the polling_intensity in my yaml and set it under the Z Wave panel and tried to call the polling_intensity service, none of it works and it is very frustrating. Does it matter that I added it on 0.67.1? I upgrade to 68.1, should I try remove node and re-including it?
I assume the dimmer takes about 3 sec normally to turn off and on. That’s how mine works. If so, then you need to use refresh_value: true and delay: 3. Something like this:
zwave:
usb_path: /dev/zwave
network_key: !secret zwave_network_key
device_config:
light.family_room_lamp:
refresh_value: true
delay: 3
See the following for more details:
1 Like
Here is my current zwave config. In this instance all of the dimmers are working properly, except for the light.living_room, which never turns off on the UI. I already have the delay set, by that doesn’t seem to do anything. Do I need to set a delay somewhere else?
zwave:
usb_path: /dev/ttyACM0
network_key: "secret"
config_path: /srv/homeassistant/lib/python3.5/site- packages/python_openzwave/ozw_config
polling_interval: 60000
device_config:
light.front_room_level:
refresh_value: true
polling_intensity: 1
delay: 3
light.breakfast_room_level:
refresh_value: true
polling_intensity: 1
delay: 3
light.living_room:
refresh_value: true
polling_intensity: 1
delay: 3
switch.mudroom_switch:
refresh_value: true
polling_intensity: 1I know there are different models, with different firmware versions, but for what it’s worth, I have one GE dimmer and four GE switches. Two of the switches also have Add-on switches connected (to form 3-way configurations.) I found that I only need polling for the switches that have Add-on switches connected, because those don’t cause HA to update when the Add-on switches are operated. (They only update when the main switches are operated.) Polling is not a good thing if you don’t need it. I would suggest trying to figure out which switches/dimmers you can get away without polling enabled (i.e., without polling_intensity set.) Or, to put that another way, try to figure out which ones you absolutely need it for.
Back to the dimmer. That’s weird that one behaves differently than the rest. I would suggest checking OZW_Log.txt for clues. E.g., here is what I see when I turn on my dimmer (which for me is node_id 7):
pi@raspberrypi:/home/homeassistant/.homeassistant $ tail -f OZW_Log.txt | grep 'Info, Node007'
2018-06-05 19:50:21.760 Info, Node007, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Lamp - 0 - 1 - 255
2018-06-05 19:50:21.760 Info, Node007, SwitchMultilevel::Set - Setting to level 255
2018-06-05 19:50:21.761 Info, Node007, Sending (Send) message (Callback ID=0x61, Expected Reply=0x13) - SwitchMultilevelCmd_Set (Node=7): 0x01, 0x0a, 0x00, 0x13, 0x07, 0x03, 0x26, 0x01, 0xff, 0x25, 0x61, 0x7e
2018-06-05 19:50:21.792 Info, Node007, Request RTT 30 Average Request RTT 30
2018-06-05 19:50:21.794 Info, Node007, Sending (Send) message (Callback ID=0x62, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=7): 0x01, 0x09, 0x00, 0x13, 0x07, 0x02, 0x26, 0x02, 0x25, 0x62, 0x83
2018-06-05 19:50:21.825 Info, Node007, Request RTT 30 Average Request RTT 30
2018-06-05 19:50:21.841 Info, Node007, Response RTT 46 Average Response RTT 46
2018-06-05 19:50:21.841 Info, Node007, Received SwitchMultiLevel report: level=2
2018-06-05 19:50:24.861 Info, Node007, Sending (Send) message (Callback ID=0x64, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=7): 0x01, 0x09, 0x00, 0x13, 0x07, 0x02, 0x26, 0x02, 0x25, 0x64, 0x85
2018-06-05 19:50:24.891 Info, Node007, Request RTT 30 Average Request RTT 30
2018-06-05 19:50:24.906 Info, Node007, Response RTT 45 Average Response RTT 45
2018-06-05 19:50:24.907 Info, Node007, Received SwitchMultiLevel report: level=99
And here is what I see when I turn it off:
pi@raspberrypi:/home/homeassistant/.homeassistant $ tail -f OZW_Log.txt | grep 'Info, Node007'
2018-06-05 19:50:37.753 Info, Node007, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Lamp - 0 - 1 - 0
2018-06-05 19:50:37.753 Info, Node007, SwitchMultilevel::Set - Setting to level 0
2018-06-05 19:50:37.754 Info, Node007, Sending (Send) message (Callback ID=0x66, Expected Reply=0x13) - SwitchMultilevelCmd_Set (Node=7): 0x01, 0x0a, 0x00, 0x13, 0x07, 0x03, 0x26, 0x01, 0x00, 0x25, 0x66, 0x86
2018-06-05 19:50:37.785 Info, Node007, Request RTT 31 Average Request RTT 30
2018-06-05 19:50:37.786 Info, Node007, Sending (Send) message (Callback ID=0x67, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=7): 0x01, 0x09, 0x00, 0x13, 0x07, 0x02, 0x26, 0x02, 0x25, 0x67, 0x86
2018-06-05 19:50:37.817 Info, Node007, Request RTT 30 Average Request RTT 30
2018-06-05 19:50:37.833 Info, Node007, Response RTT 46 Average Response RTT 45
2018-06-05 19:50:37.833 Info, Node007, Received SwitchMultiLevel report: level=98
2018-06-05 19:50:38.756 Info, Node007, Sending (Send) message (Callback ID=0x68, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=7): 0x01, 0x09, 0x00, 0x13, 0x07, 0x02, 0x26, 0x02, 0x25, 0x68, 0x89
2018-06-05 19:50:38.787 Info, Node007, Request RTT 30 Average Request RTT 30
2018-06-05 19:50:38.802 Info, Node007, Response RTT 45 Average Response RTT 45
2018-06-05 19:50:38.802 Info, Node007, Received SwitchMultiLevel report: level=66
2018-06-05 19:50:39.759 Info, Node007, Sending (Send) message (Callback ID=0x69, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=7): 0x01, 0x09, 0x00, 0x13, 0x07, 0x02, 0x26, 0x02, 0x25, 0x69, 0x88
2018-06-05 19:50:39.790 Info, Node007, Request RTT 30 Average Request RTT 30
2018-06-05 19:50:39.805 Info, Node007, Response RTT 45 Average Response RTT 45
2018-06-05 19:50:39.805 Info, Node007, Received SwitchMultiLevel report: level=33
2018-06-05 19:50:42.826 Info, Node007, Sending (Send) message (Callback ID=0x6a, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=7): 0x01, 0x09, 0x00, 0x13, 0x07, 0x02, 0x26, 0x02, 0x25, 0x6a, 0x8b
2018-06-05 19:50:42.858 Info, Node007, Request RTT 31 Average Request RTT 30
2018-06-05 19:50:42.873 Info, Node007, Response RTT 46 Average Response RTT 45
2018-06-05 19:50:42.873 Info, Node007, Received SwitchMultiLevel report: level=0
See especially the lines that contain Received SwitchMultiLevel report: level=NN. Notice when the dimmer is turned on it goes to 2 (right after it gets the command to turn on), then to 99 after the 3 sec delay. (Note that z-wave reports levels as 0 to 99.) Then when it’s turned off, it goes to 98 immediately, then to 66, then 33, then finally to 0 (again, after the final 3 sec delay.)
You might want to try the same experiment with one of your dimmers that works correctly, and then the one that doesn’t. Of course you can get the node_id from the States page.
Is OZW taking the delay from the config? Or from someplace else, because the delay seems to not being read by OZW
Edit: This is interesting, I just checked my OZW.log.txt file and it hasn’t been updated since 3/15/18. My z-wave system is working, but that seems to indicate to me that OZW isn’t communicating with HASS? Have you ever seen that behavior before?
I wonder if this has to do with the config_path line in your configuration file. I don’t have that (which I think means it finds it in the “usual” place.) You might want to look for your OZW_Log.txt file:
sudo find / -name OZW_Log.txt 2>/dev/null
I’m no z-wave or openzwave expert by any means. Just sharing the little I learned when I tried to set up my small z-wave network.
Another file I found that is important is zwcfg_*.xml. I know there are settings in there that affect how z-wave works on your system. Unfortunately the z-wave infrastructure seems to be overly complicated.
Deleting the OZW_Log and restarting seemed to help it take hold, but my Node wasn’t acting like the transitions in your log. It would go from level 99 to level 19 when turned off. No gradual decrease, and even though the light itself was off, OZW was still showing a level of 19
Interesting. I suppose it’s possible the dimmer isn’t actually going all the way off, even though the light doesn’t seem to be on anymore. (Some lights, especially LEDs, don’t come on at very low voltage levels. I was just helping someone where they wanted their dimmer to only go between 60% and 100% when “on”. But in that case we were doing it via automations, not z-wave configuration.)
You might want to look at your zwcfg_xxxxx.xml file. I believe OZW creates this file when devices are first installed. It gets default values from its own config directories.
E.g., in mine I see these lines (and some more, of course) for my dimmer:
<Node id="7" name="Family Room" location="" basic="4" generic="17" specific="1" type="Multilevel Power Switch" listening="true" frequentListening="false" beaming="true" routing="true" max_baud_rate="40000" version="4" query_stage="Complete">
<Manufacturer id="63" name="GE">
<Product type="5044" id="3031" name="12718 Plug-in Dimmer" />
</Manufacturer>
<CommandClasses>
<CommandClass id="32" name="COMMAND_CLASS_BASIC" version="1" request_flags="4" mapping="38">
<Instance index="1" />
</CommandClass>
<CommandClass id="38" name="COMMAND_CLASS_SWITCH_MULTILEVEL" version="1" innif="true">
<Instance index="1" />
<Value type="byte" genre="user" instance="1" index="0" label="Lamp" 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="Bright" 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="Dim" 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" />
</CommandClass>
I’ve haven’t played with all of these, but I wonder if maybe the “Ignore Start Level” and/or “Start Level” lines might have something to do with your odd dimmer. Specifically, could the value="N" of the “Start Level” line be something other than zero?
Honestly, I’m a bit at the end of my experience level with z-wave. 
OK thanks, I will try and compare the zwcfg file. That would be the only place that it would make sense for a setting to not take hold, as I have the same dimmers in other places but they are working properly. The LEDs might also be a possibility, and I wanted to change them out anyways. I’ll take any lead I can get haha, as its driving me crazy
Interesting discovery, when using the physical dimmer switch, the UI reacts appropriately. But when using HASS to turn off, the dimmer switch never goes off on the UI?
Solution: Solved by changing the dim rate from 3 to 2
Did that make the dimmer ramp faster? If so then you should have been also able to solve it by making the delay parameter longer instead I would think. Glad you got it working!
there was no faster ramp that i could tell, and i even tried a longer delay with no luck. but glad its working!
1 Like