LZW36 Fan/Dimmer Switch

The following added to my configuration.yaml helped a lot but isn’t quite perfect (edit, added polling intensity. No refresh on fan button, but light button does refresh on button press).

zwave:
  usb_path: /dev/ttyACM0
  config_path: /config/ozwconfig/config
  device_config:
    light.bedroom_overhead_light_dimmer_level:
      refresh_value: true
      polling_intensity: 1
    light.bedroom_overhead_fan_dimmer_level:
      refresh_value: true
      polling_intensity: 1

When I was looking into it previously, I remember coming across something saying there was some issues with the 700 series chip and OZW, but I’ve been unable to find that forum thread again, so that information may not be accurate.

No luck for me with the refresh_value set to true

I feel like I’m close to being able to like this and keep it. My original set of bulbs that have worked for other canopy modules were not working with this, they would go to a low dim when turned off. I swapped another set of bulbs in and that seems to have fixed it. Even with parameter 1 set to 0 the delay from wall switch can be a tad slow, it’s just the lack of immediate change that’s throwing it off. I could see someone thinking they didn’t press it firmly and doing a second press. Probably only an issue with company visiting, if at all.

Just need to get that entity status update in HA, do you think that 700 series issue is documented in the issues section of OZW on GitHub?

This is what I had to do to get my entities to always update. Its not pretty but seems to work

Explanation

Node Red Flow

[{“id”:“11bb60d1.3ced6f”,“type”:“comment”,“z”:“651c3ebc.4e08”,“name”:“Fix Fan/Light State”,“info”:"",“x”:290,“y”:2220,“wires”:[]},{“id”:“177532d8.a5ad5d”,“type”:“api-call-service”,“z”:“651c3ebc.4e08”,“name”:“Refresh Light”,“server”:“6c2daf11.fae89”,“version”:1,“debugenabled”:false,“service_domain”:“zwave”,“service”:“refresh_entity”,“entityId”:“light.inovelli_lzw36_fan_light_dimmer_level”,“data”:"",“dataType”:“json”,“mergecontext”:"",“output_location”:"",“output_location_type”:“none”,“mustacheAltTags”:false,“x”:870,“y”:2200,“wires”:[[]]},{“id”:“c6f46e4f.84d48”,“type”:“api-call-service”,“z”:“651c3ebc.4e08”,“name”:“Refresh Fan”,“server”:“6c2daf11.fae89”,“version”:1,“debugenabled”:false,“service_domain”:“zwave”,“service”:“refresh_entity”,“entityId”:“light.inovelli_lzw36_fan_light_dimmer_level_2”,“data”:"",“dataType”:“json”,“mergecontext”:"",“output_location”:"",“output_location_type”:“none”,“mustacheAltTags”:false,“x”:870,“y”:2300,“wires”:[[]]},{“id”:“65da22e2.16bc9c”,“type”:“delay”,“z”:“651c3ebc.4e08”,“name”:"",“pauseType”:“delay”,“timeout”:“1”,“timeoutUnits”:“seconds”,“rate”:“1”,“nbRateUnits”:“1”,“rateUnits”:“second”,“randomFirst”:“1”,“randomLast”:“5”,“randomUnits”:“seconds”,“drop”:false,“x”:680,“y”:2200,“wires”:[[“177532d8.a5ad5d”]]},{“id”:“e6fa39c.2dd63c8”,“type”:“delay”,“z”:“651c3ebc.4e08”,“name”:"",“pauseType”:“delay”,“timeout”:“1”,“timeoutUnits”:“seconds”,“rate”:“1”,“nbRateUnits”:“1”,“rateUnits”:“second”,“randomFirst”:“1”,“randomLast”:“5”,“randomUnits”:“seconds”,“drop”:false,“x”:680,“y”:2300,“wires”:[[“c6f46e4f.84d48”]]},{“id”:“e7376e9d.a93e1”,“type”:“api-call-service”,“z”:“651c3ebc.4e08”,“name”:“Refresh Light”,“server”:“6c2daf11.fae89”,“version”:1,“debugenabled”:false,“service_domain”:“zwave”,“service”:“refresh_entity”,“entityId”:“light.inovelli_lzw36_fan_light_dimmer_level”,“data”:"",“dataType”:“json”,“mergecontext”:"",“output_location”:"",“output_location_type”:“none”,“mustacheAltTags”:false,“x”:530,“y”:2200,“wires”:[[“65da22e2.16bc9c”]]},{“id”:“8f4e9446.e70b08”,“type”:“api-call-service”,“z”:“651c3ebc.4e08”,“name”:“Refresh Fan”,“server”:“6c2daf11.fae89”,“version”:1,“debugenabled”:false,“service_domain”:“zwave”,“service”:“refresh_entity”,“entityId”:“light.inovelli_lzw36_fan_light_dimmer_level_2”,“data”:"",“dataType”:“json”,“mergecontext”:"",“output_location”:"",“output_location_type”:“none”,“mustacheAltTags”:false,“x”:530,“y”:2300,“wires”:[[“e6fa39c.2dd63c8”]]},{“id”:“2f3eb7a8.7d6a08”,“type”:“trigger-state”,“z”:“651c3ebc.4e08”,“name”:“Fan/Light Change”,“server”:“6c2daf11.fae89”,“exposeToHomeAssistant”:false,“haConfig”:[{“property”:“name”,“value”:""},{“property”:“icon”,“value”:""}],“entityid”:“light.inovelli_lzw36_fan_light_dimmer_level_3”,“entityidfiltertype”:“exact”,“debugenabled”:false,“constraints”:[],“constraintsmustmatch”:“all”,“outputs”:2,“customoutputs”:[],“outputinitially”:false,“state_type”:“str”,“x”:290,“y”:2260,“wires”:[[“e7376e9d.a93e1”,“8f4e9446.e70b08”],[“e7376e9d.a93e1”,“8f4e9446.e70b08”]]},{“id”:“6c2daf11.fae89”,“type”:“server”,“z”:"",“name”:“DAN HA”,“legacy”:false,“addon”:true,“rejectUnauthorizedCerts”:true,“ha_boolean”:“y|yes|true|on|home|open”,“connectionDelay”:true,“cacheJson”:true}]

1 Like

Not a node red user-- so I need to ask to be clear, is this an automation that triggers the refresh_entity service when you toggle the entities?

I’m not nearly as knowledgeable on the inner workings of OZW as I could be, but it looks like this a known issue with SwitchMultiLevel V4

Anytime the state or attributes (brightness is what I’m after) changes for my Fan/Light combo I call zwave.refresh_entity for the individual entities for both the fan and light. I then wait 1 sec and call it again for good measure.

The fan/light entity ALWAYS updates when a button is pressed on the switch with the last state of either the fan or light.

I looked around the web and you can either do what I did above, use z-wave polling, or trigger refreshes off the scenes (untested).

Right I forgot entirely that the combo entity always updates. That’s great, I’ll see about copying this right away… :wink:

Here’s what I came up with in my YAML automation, I think this should be about the same as yours. Refresh the individual entities for light or fan if the combo entity has any state change. I set it to off until the Z-Wave network is ready, wouldn’t expect much state change in that time period…

 #Refresh fan/light entities for current status
 - alias: Refresh fan/light entities
   initial_state: 'false'
   trigger:
     - platform: event
       event_type: state_changed
       event_data:
         entity_id: light.inovelli_lzw36_fan_light_dimmer_level_3
   action:
     - service: zwave.refresh_entity
       data:
         entity_id: light.inovelli_lzw36_fan_light_dimmer_level
     - service: zwave.refresh_entity
       data:
         entity_id: light.inovelli_lzw36_fan_light_dimmer_level_2
         
 #Turn on 'Refresh fan light/entities' automation after Z-Wave network started
 - alias: Refresh fan/light entities delay
   initial_state: 'on'
   trigger:
     platform: event
     event_type: zwave.network_ready
   action:
     - service: automation.turn_on
       data:
         entity_id: automation.refresh_fan_light_entities

Another option you could try is to use the zwave.scene_activated event. that way you don’t need to wait for the zwave network to start.

- alias: refresh_switch
  initial_state: 'on'
  trigger:
    platform: event
    event_type: zwave.scene_activated
    event_data:
      entity_id: zwave.inovelli_lzw36_fan_light_dimmer
      scene_id: 1
  action:
  ...

You could just add an or for the trigger to catch scene_id 1-6 (1 is fan button, 2 is light button, 3/4 are light dim button up/down, 5/6 are fan dim up/down.
I use the scenes to toggle/dim the zigbee smart bulb in the fan. (ordered a zwave one today, we’ll see how that goes :wink: )

1 Like

That’s a good take, I’m not worried about that 1 minute downtime during a reboot (and I’m feeling “done”) but I’ll keep it in mind if I need it.

Question about the scenes on this-- my other devices use a double/triple/etc taps for scene but this has scenes for a single tap as well, how does that work? Turn light or fan on/off AND trigger a scene command? What’s a use case for something like that? (outside of this of course…)

Yeah you’re right. For me, i use it to control my smart bulb as i disabled the relay. and i think i saw a long press scene which can probably be used to turn off everything in the room or something else useful…
But the only other valid 1 push scene scenario i can think of is:
Push fan button:

  1. Start Fan (on breeze mode when implemented)
  2. Send start playlist command to the local speaker to start “Waves on beach sounds”.
  3. Send command to spray “scent of the ocean” into the room.

yeah, that’s about it. :grin:

1 Like

Ok, I think this is a joke but really… where do I find instructions to build this!? :slight_smile: That is awesome!

Yes, single tap sends a scene and triggers the relay in the device (technically the same as other red series switches).

@benj I had thought about using zwave.scene_activated too, but it wouldn’t then catch changes done with the dimming paddles.

So I just added this to Home Assistant using the new ozw integration. It all worked for me without any modifications (other than adding the lzw36.xml file and modifying the manufacturer_specific.xml file). I tried removing and re-adding the devices with the command class 38 section un-commented out. That added the names for the three instances (Fan/Light, Light, and Fan), but otherwise didn’t make a difference.

One thing I’ve noticed is that the third instance (the fan) shows up as a light in Home Assistant. @EricM_Inovelli Is there any way the firmware can be updated to present that device as a fan instead of a light? I know I can use a fan template to fix it, but it makes sense to me to fix it upstream.

EDIT (by Eric H): Tagging the other Eric as I’m not sure - I’m just a marketing guy :slight_smile:

I’m not aware of a way to fix this via firmware. Z-wave doesn’t have a “fan” command class. They expect the fw to just use the SwitchMultiLevel command class which is the same that a dimmer uses. I think this has to be approached from HA, but I don’t know if there is a way to force the config file to present it as a fan.

Makes sense. I wonder if there’s a way to make the change in the OpenZwave config file so that it presents as a fan. HA just uses whatever OpenZwave gives it, so it’d make sense to change it there. The new OpenZwave integration in HA supports fans directly: https://github.com/home-assistant/core/tree/dev/homeassistant/components/ozw

Super helpful dan1. I ended up having to use a combination of the zwave.refresh_entity and set polling to 1 for the light in order to get the light switch to turn on other smart bulbs in the room. I frequently use the fan only and this puts the “master” switch into the on position and this state doesn’t change if the fan is already on and the light is turned on. Sometimes it takes up to 30 seconds for the smart bulbs to turn on but I can’t think of another way to accomplish a faster response. Even a scene wouldn’t seem to solve this issue since the “master” switch state doesn’t change.

If anyone has any suggestions, I’m all ears.

Any idea when this is all resolved? The LZW36 is advertised as being compatibly with Home Assistant, that was a requirement that led me to purchase. I was disappointed when it didn’t work.

I went through the hack to get the individual light and fan dimmer switches to show up. Annoying that the fan shows up as a light. Very annoying that the states don’t update on a physical button press, this is a basic feature that’s broken. I now have a bunch of automation workarounds involving triggers on the “master” switch and other triggers that monitor power as it crosses different thresholds. This was necessary because as we know the master switch doesn’t change state if it’s already on and the second device is turned on.

Is there active work with the Home Assistant devs to assure an expected Z-Wave experience per the advertised feature?

2 Likes

I have spent more time than I would like to say trying to get these devices to work correctly. First went down the Home Assistant configuration.yaml and manually editing the files and realized that it was version 1.4. Then went to 1.6 OZW MQTT when the PR for LZW36 was merged. Now every time a dimmer is changed from Home Assistant OZW goes into a polling loop for 5 minutes before everything responds. I hope when https://github.com/home-assistant/core/pull/38254 gets merged the issue goes away.

I think this is more of a Zwave limitation. To my knowledge, Zwave does not have a “fan” type, so Home Assistant has no way to tell what the device is without workarounds (hopefully the new Openzwave integration will fix this).

I had this problem for a while, I managed to resolve it with the Zwave PC controller software. I think it has to do with the way OZW sets up the lifeline association (using regular association instead of multi-channel association).

When using regular association, zniffer logs show that the device sends a regular Multilevel report. Since there is no source endpoint for this type or report, we dont get proper status updates as the hub is not sure what is being updated:
image

When using multi-channel association, the device will send a report from the correct endpoint (in this example it is endpoint 002, which is the fan):

Setting up proper association with Zwave PC Software

The following instructions assumes your Z-stick is Node 1 and you have already set up the Zwave PC software (it is also used for firmware updates). I am not sure if there is a way to do this directly within HA (I was never able to find a way, but that doesnt mean its not possible).

  1. Go into “Network Management”, select your fan device, and click “Node Info”
  2. Go to the “Associations” page (from the main menu) and select your device->Root device, and click “Get Groups”
    image
  3. Select Group 1 -> Nodes -> 1, and then click the “Remove” button.
  4. Go to the “Command Classes” page (from main menu) and select your device from the left-hand window
  5. Click the “Select” button on the right side of the screen and choose “ver.4 - Multi Channel Association” -> “Multi Channel Association Set” and click “OK”
  6. Fill out the information on the screen as highlighted below and click “Send”. You should see a confirmation message at the bottom of the window

At this point, reports should start working properly

4 Likes