HA 0.62.1 (also a few slightly less recent versions)
RPi3, Raspbian Stretch
This is my first zwave device, so apologies if this is a simple issue, but I haven’t been able to sort it out searching the forums or looking at the zwave or hass logs.
Basically, the light turns on perfectly through hass.
When I turn the light off in the frontend, a sequence of events happens in rapid succession:
The switch in the frontend turns off
The switch in the frontend immediately goes back to on
The actual light dims over 2 seconds or so and remains off
The switch in the front end remains on in spite of the light being off
I have the same lights but use a Aeotec z stick. My lights act the same way. I’m not sure if it’s a function of the zwave or those specific lights.
It is kind of annoying. I haven’t found it annoying enough to try to find a work around yet. Hopefully you’ll have some luck and I can piggyback off your success.
I can’t find the post here that helped me with this, but ultimately this is what solved it for me when using dimmer switches. It isn’t ideal but my switches work from the frontend on the first try. On the frontend the switch will shut off, turn back on, then switch off again. This is in my configuration.yaml under the zwave section currently.
Arguably, what should happen here is that the UI locks the switch in position until it gets a new status update from the z wave backend, but I’m not sure how feasible that is.
This is speculation based on the behavior, but what appears to be happening currently is that the UI reacts to your intent (e.g. turning OFF a switch that was ON) and shows the change to OFF. Then a periodic state update happens in the background, using a stale value, so the UI changes to show ON again. Then when the actual state is available from OZW, the switch turns OFF again.
Something (hand waving) needs to take into account the last-seen user input from the UI and ignore any state updates with timestamps older than the last-seen user input.
switch light on with HA toggle -> light physically raises slowly to 100% and slider raises slowly to 100%, toggle display turns to “on”
switch light off with HA toggle -> light physically dims to off, slider dims to around 10%, toggle shows “off”
switch light on again with HA toggle -> lights stays off, slider stays at 10%, toggle shows “on”
switch light off with HA toggle -> light stays off, slider dims to 0%, toggle shows “off”
switch light on again with HA toggle -> light comes on to 100%, slider stays at 0%, toggle shows “on”
switch light off again with HA toggle -> light turns off, slider jumps immediately to 100% then dims to 10%, toggle shows “off”
repeat ad infinitum from step 3 again.
Strange…
Only my zwave LED bulbs do that (both go control brand). My zigbee bulbs don’t (Sengled dimmables). the zigbee goes off and on as expected and the displays match immediately.
Manual for the bulb – note that in addition to parameter 1 (remember brightness level), it notes a configurable parameter 9 and parameter 10 for step and speed, but these aren’t currently exposed in the zwave config.
I’ve tried to figure out the zwconf*.xml format and added the snippet below (with a little context above):
<CommandClass id="112" name="COMMAND_CLASS_CONFIGURATION" version="1" request_flags="4" innif="true">
<Instance index="1" />
<Value type="list" genre="config" instance="1" index="1" label="Dim Level Memory" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="1">
<Help>Using Last Dim Setting will bring the bulb back to the last dimness setting when turning on, instead of full brightness by default.</Help>
<Item label="Full Brightness" value="0" />
<Item label="Last Dim Setting" value="1" />
</Value>
<Value type="byte" genre="config" instance="1" index="9" label="Dim / Bright Step Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="1" max="99" value="99">
<Help>When the brightness is adjusted by the controller/gateway, how much the bulb brightness will change is set by the programmed dimming step level. The step level is small when the value is low. The step level is large when the value is high. Default = 1</Help>
</Value>
<Value type="byte" genre="config" instance="1" index="10" label="Dim / Bright Speed" units="seconds (when step level is 1)" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="1" max="10" value="1">
<Help>When the brightness is adjusted by the controller/gateway, how fast the bulb brightness will change is set by the programmed dimming step speed. The step speed is fast when the value is low. The step speed is slow when the value is high. Example: If Parameter 9 is set to the default value of 1, setting Parameter 10 from 1 to 10 will equal the number of seconds it takes to dim down the bulb when the bulb is turned off, i.e. 1 equals 1 second for the bulb to dim down and turn off, 10 equals 10 seconds for the bulb to dim down and turn OFF Default = 3</Help>
</Value>
This seems to let me configure these settings in the hass zwave control panel, but they don’t seem to change the light’s behavior at all.
Looking in the HASS log, setting them seems to work:
Apr 24 14:26:22 homeslice hass[14023]: 2018-04-24 14:26:22 INFO (SyncWorker_5) [homeassistant.components.zwave] Setting config parameter 10 on Node 6 with selection 1
Looking in the OZW log, it doesn’t (seems to see value of 0 for some reason).
2018-04-24 14:26:22.687 Detail, Node006, Refreshed Value: old value=0, new value=0, type=byte
2018-04-24 14:26:22.687 Detail, Node006, Changes to this value are not verified
2018-04-24 14:26:22.687 Info, Node006, Received Configuration report: Parameter=10, Value=0
EDIT: Others variably reporting no luck or success setting these parameters – looks like it could be a firmware issue? Not sure how to find my firmware version.
The LB60Z-1 bulb seems to have been sold under a variety of names and it seems to be a bit random which ones support different features. I have one that does not appear to support the step and speed parameters. I’ve not seen anywhere that you could download updated firmware.
Interestingly, today I found that if I use the zwave config tool to set 1: Dim Level Memory to Last Dim Setting instead of full brightness, and I use the Services tab to manually set the brightness to 175 or lower, that all is well without any other special configuration.
The light isn’t as bright as I would like, but it reliably turns on and off with a single click.
I stumbled on this same problem today with my Jasco Products 14294 In-Wall Smart Dimmer … to fix I did something similar to what was described above with some variations:
For each of the 3 configurations (ALL ON/ALL OFF, Zwave command, local control) … adjust the following:
This looks like the solutions, still testing:
Configuration
Z-Wave
Select the Node you have issues with
In Node config options select 80: Notification status
As value select one of Basic or Hail
Set config parameter
Be happy
The example config fixed the Issue with my Linear WD500Z-1 Wall Dimmer Switch.
I have an Intermatic CA600 Wall Dimmer which doesn’t exhibit the problem. It ramps up and down much faster though. Both of these are pretty old Z-Wave switches.
I was experiencing the same issue with an Inovelli Black Series dimmer LZW31. The culprit is indeed the ramp rate. Fortunately, the Inovelli switches have discreet parameters for dimming rates from the switch and from Z-wave commands. I changed the Z-wave rates to 0 (instant) and left the manual rates to something a little slower.
EDIT: With the ramp rate set at 0, the interface works as expected: you flip the switch off, the light goes off, and the switch on the UI shows off. Same for on. With the ramp rate set at 1, the switch in the UI “bounces”: you flip the switch in the UI, it goes off, then back on, then off… but the physical light just turns off. With the ramp rate set any higher, the switch in the UI turns off, then back on & stays on, and the light stays on, but dimmed.
I’m keeping it at 1. I can deal with the UI switch bounce. I like the slight ramp at the light.
It seemed to largely go away after a couple days (maybe when the network did its automatic regular healing). It still happens occasionally, and seems to increase in the days immediately after adding a new device.
