Zwave light doesn't turn off in frontend on first try

  • GoControl Z-Wave Dimmable LED Light Bulb, LB60Z-1
  • HUSBZB-1
  • 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:

  1. The switch in the frontend turns off
  2. The switch in the frontend immediately goes back to on
  3. The actual light dims over 2 seconds or so and remains off
  4. The switch in the front end remains on in spite of the light being off

Log: https://pastebin.com/WJCeXUUg

It seems to go from off to on just fine.

Any ideas?

2 Likes

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. :smiley:

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.

zwave:
  usb_path: /dev/ttyUSB0
  polling_interval: 10000
  device_config:
    light.ge_14294_inwall_smart_dimmer_level: 
      polling_intensity: 1
      refresh_value: 2
      delay: 3
    light.ge_14294_inwall_smart_dimmer_level_2:
      polling_intensity: 1
      refresh_value: 2
      delay: 3
    light.ge_14294_inwall_smart_dimmer_level_3:
      polling_intensity: 1
      refresh_value: 2
      delay: 3
2 Likes

Thanks!

I’ll give it a try when I get a chance and see how I like it.

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.

I’m not sure that isn’t correct but what I see is:

initial conditions: physical light off, frontend toggle display “off”, slider display 0%

  1. switch light on with HA toggle -> light physically raises slowly to 100% and slider raises slowly to 100%, toggle display turns to “on”

  2. switch light off with HA toggle -> light physically dims to off, slider dims to around 10%, toggle shows “off”

  3. switch light on again with HA toggle -> lights stays off, slider stays at 10%, toggle shows “on”

  4. switch light off with HA toggle -> light stays off, slider dims to 0%, toggle shows “off”

  5. switch light on again with HA toggle -> light comes on to 100%, slider stays at 0%, toggle shows “on”

  6. switch light off again with HA toggle -> light turns off, slider jumps immediately to 100% then dims to 10%, toggle shows “off”

  7. repeat ad infinitum from step 3 again.

Strange… :confused:

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.

This works. Light now flicks off, then on again, then off once it has fully dimmed (a couple seconds later).

1 Like

I’m still hoping to get a more satisfying answer for this, but not having luck so far. Going to compile a few related resources:

Another thread on this issue: Linear / GoControl LB60Z-1 Z-Wave bulbs not turning off in UI

  • 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.

2 Likes

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:

  • Dim step: 99
  • Dim rate: 1

I got the same problem with Aeotec ZW140, and found another post on github:

Maybe some can help us.

LOG:

2020-04-17 20:15:02.233 Info, Node016, Response RTT 30 Average Response RTT 33
2020-04-17 20:15:02.233 Info, Node016, Received a MultiChannelEncap from node 16, endpoint 1 for Command Class COMMAND_CLASS_SWITCH_BINARY
2020-04-17 20:15:02.233 Info, Node016, Received SwitchBinary report from node 16: level=Off
2020-04-17 20:15:02.233 Detail, Node016, Refreshed Value: old value=false, new value=false, type=bool
2020-04-17 20:15:02.233 Detail, Node016, Changes to this value are not verified
2020-04-17 20:15:02.233 Detail, Node016,   Expected reply and command class was received
2020-04-17 20:15:02.233 Detail, Node016,   Message transaction complete
2020-04-17 20:15:02.233 Detail,
2020-04-17 20:15:02.233 Detail, Node016, Removing current message
2020-04-17 20:15:02.233 Detail, Node016, Notification: ValueChanged
2020-04-17 20:15:02.309 Detail, Node016,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x10, 0x07, 0x60, 0x0d, 0x01, 0x01, 0x25, 0x03, 0x00, 0xaa
2020-04-17 20:15:02.309 Detail,
2020-04-17 20:15:02.309 Info, Node016, Received a MultiChannelEncap from node 16, endpoint 1 for Command Class COMMAND_CLASS_SWITCH_BINARY
2020-04-17 20:15:02.309 Info, Node016, Received SwitchBinary report from node 16: level=Off
2020-04-17 20:15:02.309 Detail, Node016, Refreshed Value: old value=false, new value=false, type=bool
2020-04-17 20:15:02.309 Detail, Node016, Changes to this value are not verified
2020-04-17 20:15:02.309 Detail, Node016, Notification: ValueChanged
2020-04-17 20:15:02.972 Info, Node016, Value::Set - COMMAND_CLASS_SWITCH_BINARY - Switch - 0 - 2 - True
2020-04-17 20:15:02.972 Info, Node016, SwitchBinary::Set - Setting node 16 to On
2020-04-17 20:15:02.972 Detail, Node016, Queuing (Send) MultiChannel Encapsulated (instance=2): SwitchBinaryCmd_Set (Node=16): 0x01, 0x0e, 0x00, 0x13, 0x10, 0x07, 0x60, 0x0d, 0x01, 0x01, 0x25, 0x01, 0xff, 0x25, 0x66, 0x00
2020-04-17 20:15:02.972 Detail, Node016, Queuing (Send) MultiChannel Encapsulated (instance=2): SwitchBinaryCmd_Get (Node=16): 0x01, 0x0d, 0x00, 0x13, 0x10, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x25, 0x02, 0x25, 0x67, 0xff
2020-04-17 20:15:02.972 Detail,
2020-04-17 20:15:02.972 Info, Node016, Sending (Send) message (Callback ID=0x66, Expected Reply=0x13) - MultiChannel Encapsulated (instance=2): SwitchBinaryCmd_Set (Node=16): 0x01, 0x0e, 0x00, 0x13, 0x10, 0x07, 0x60, 0x0d, 0x01, 0x01, 0x25, 0x01, 0xff, 0x25, 0x66, 0x00
2020-04-17 20:15:02.977 Detail, Node016,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2020-04-17 20:15:02.977 Detail, Node016,   ZW_SEND_DATA delivered to Z-Wave stack
2020-04-17 20:15:02.992 Detail, Node016,   Received: 0x01, 0x07, 0x00, 0x13, 0x66, 0x00, 0x00, 0x02, 0x8f
2020-04-17 20:15:02.992 Detail, Node016,   ZW_SEND_DATA Request with callback ID 0x66 received (expected 0x66)
2020-04-17 20:15:02.992 Info, Node016, Request RTT 20 Average Request RTT 20
2020-04-17 20:15:02.992 Detail,   Expected callbackId was received
2020-04-17 20:15:02.992 Detail,   Expected reply was received
2020-04-17 20:15:02.992 Detail,   Message transaction complete
2020-04-17 20:15:02.992 Detail,
2020-04-17 20:15:02.992 Detail, Node016, Removing current message
2020-04-17 20:15:02.992 Detail,
2020-04-17 20:15:02.992 Info, Node016, Sending (Send) message (Callback ID=0x67, Expected Reply=0x04) - MultiChannel Encapsulated (instance=2): SwitchBinaryCmd_Get (Node=16): 0x01, 0x0d, 0x00, 0x13, 0x10, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x25, 0x02, 0x25, 0x67, 0xff
2020-04-17 20:15:02.997 Detail, Node016,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2020-04-17 20:15:02.997 Detail, Node016,   ZW_SEND_DATA delivered to Z-Wave stack
2020-04-17 20:15:03.013 Detail, Node016,   Received: 0x01, 0x07, 0x00, 0x13, 0x67, 0x00, 0x00, 0x02, 0x8e
2020-04-17 20:15:03.013 Detail, Node016,   ZW_SEND_DATA Request with callback ID 0x67 received (expected 0x67)
2020-04-17 20:15:03.013 Info, Node016, Request RTT 21 Average Request RTT 20
2020-04-17 20:15:03.013 Detail,   Expected callbackId was received
2020-04-17 20:15:03.023 Detail, Node016,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x10, 0x07, 0x60, 0x0d, 0x01, 0x01, 0x25, 0x03, 0xff, 0x55
2020-04-17 20:15:03.023 Detail,
2020-04-17 20:15:03.023 Info, Node016, Response RTT 31 Average Response RTT 32
2020-04-17 20:15:03.023 Info, Node016, Received a MultiChannelEncap from node 16, endpoint 1 for Command Class COMMAND_CLASS_SWITCH_BINARY
2020-04-17 20:15:03.023 Info, Node016, Received SwitchBinary report from node 16: level=On
2020-04-17 20:15:03.023 Detail, Node016, Refreshed Value: old value=false, new value=true, type=bool
2020-04-17 20:15:03.023 Detail, Node016, Changes to this value are not verified
2020-04-17 20:15:03.023 Detail, Node016,   Expected reply and command class was received
2020-04-17 20:15:03.023 Detail, Node016,   Message transaction complete

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.

Thanks for posting the solution!

EDIT
My config:

zwave:
  usb_path: !secret zwave_usb_path
  network_key: !secret zwave_network_key
  device_config:
    light.office_overhead:
      polling_intensity: 1
      refresh_value: 3
      delay: 3

I’m having this problem with a single ZOOZ ZEN26 light switch. I have 3, but only one is having this problem. I don’t understand.

I have the ZEN23 and it seems to do this, did you solve it with yours?

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.