LZW36 Fan/Dimmer Switch

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?


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:

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”
  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


You rock @jtronicus !

I went down the OpenZWave rabbit hole and found that the 1.4 config was missing both the mult-channel and multi-instance command classes. I updated the config to include them:

  <!-- Multi Instance -->
  <CommandClass id="96" mapping="endpoints" />
  <!-- Multi Channel -->
  <CommandClass id="142" ForceInstances="true" /

Then excluded and re-included the device. Now reporting works as it should, however the combo endpoint only seems to turn on the fan and never actually reports anything back. Someone with more knowledge than I (@EricM_Inovelli ?) might be able to clarify that behavior, however I didn’t care about that device anyway so I just disabled it in Home Assistant.

No more ugly refresh automation kludges FTW!

edit: PR is here

1 Like

In ST, Z-Wave Fan Controller is a device type by default. Not sure what that means for HA though.

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

HA recognizes GE Z-wave fan control as a fan, so not sure that is valid. So it’s doing something there, whether OZW is recognizing it or maybe it’s a workaround in HA.

I’ll look into your instructions, thanks for providing those. I would like to ditch the automation workarounds for updating the states. However, I’m nervous about undocking my Aeon Z-wave stick from my HA server and inserting it on my PC to run Zwave PC software. Will this ruin all the associations stored on the stick and cause me to have to re-pair everything when I put it back on the HA server? I had an issue a while back with a dead device I couldn’t remove and had to reset everything and start over, would like to avoid that.

There is a “Fan” DeviceType listed for ZWave+:
<DeviceType key="0x0400" label="Fan Switch" command_classes="0x5a,0x5e,0x59,0x72,0x73,0x85,0x86,0x26"/>

I think if there were a way to set that for the endpoint via the config or perhaps from the device, then HA would work just fine. It does see my HomeSeer fan switches as fan types without any workarounds since that device returns the proper type, but it is just a single switch rather than combo.

In HA with OZW 1.4, there appears to be a workaround file to force specific devices to be recognized in certain ways. This looks like it is device-specific, so I am not sure if it can be configured for specific endpoints on the same physical device. Workarounds do not exist in OZW 1.6 at this time (the developers are trying to avoid them if possible. See post)

HA/OZW (1.6, not sure about 1.4) will recognize a fan if the “Specific Device Class” is configured a certain way. From what I can tell, this device class is defined at the device level, not the individual endpoint level. If it is configured as a Fan, then that means the light will also show up as a fan.

Hopefully, we at least get a way to override the device class for individual endpoints in the config files. I havent found a way to do it yet.

1 Like

The device type for Z-Wave Fan controller is matching the device fingerprint to assign that device handler. So it is essentially reading the manufacturer and device info during inclusion to assign the appropriate device handler.

There is no “Fan” command class in Z-wave except for thermostats. Z-wave’s implementation of fans relies on the SwitchMultilevel command class that is the same for dimmers. So distinguishing a fan from a dimmer isn’t possible by looking at supported command classes alone. If you look at open-zwave’s device_classes config file the “command classes” are the same for a dimmer and a fan.

I don’t see anything in the config file that I can change that will make it be seen as a fan.

As @jtronicus mentioned there is a specific device class but that doesn’t apply to individual endpoints. So how do we set the individual fan endpoint as a fan controller instead of the root device?


The Zooz ZEN30 device is pretty similar to the LZW36. It has a dimmer and a fan controller, although the fan controller is only a relay, not a speed controller. When I added it to Open-Zwave, it showed up a s dimmable light (light domain in HA) and a switch device (switch domain in HA). Could we look at what they’ve done to see if there’s a way to implement this on the LZW36? I know it’s not exactly the same, but they do have it working with two different endpoints reporting as different “things”.


Could you provide us with the relevant section of your ozwcache.xml file?

Sure thing, here’s the file with the relevant nodes:

@EricM_Inovelli I was doing some light reading of the Zwave SDK, and found some interesting information (although this stuff is kinda cryptic, so I might be misinterpreting).

If the “Identical” bit is set to 0 on the multi-channel end point report, then you can set individual Specific Device Classes for each endpoint.

This would (theoretically) allow Home Assistant to know that the fan is a fan