LZW36 Fan/Dimmer Switch

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

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?

2 Likes

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

2 Likes

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

That is very interesting. If HA were to have that information for the individual endpoints would it know what to do with them at this point? Is it possible to have device endpoints displayed differently in HA at this time?

I am not sure. The only information I have been able to find on the subject is in this post. I asked the question on the github page, hopefully I get an answer.

It looks like it is currently not possible. Although the ozwdaemon collects the information, it does not currently publish it to Home Assistant (although it is feasible).

I believe that it is. At least, the Zooz ZEN30 has found a way to show two different entities in totally different domains (light vs switch). The second device listed here is a switch, and the first is a light.

Hi, coming here from the HA Github issue that was linked… Thought I’d try to help and clear up some things. I’m not a Z-Wave expert by any means, but I like to read the docs and help with HA support, so here I am. :slight_smile:

There are two, maybe three problems here. First, the way HA determines how entities are created. Directly related is that the LZW36 is a multi-channel device. Another is that this device is Z-Wave Plus V2.

As already mentioned, Home Assistant with the new OZW integration only creates fan entities for devices that advertise themselves as Fan Switches. A “Fan Switch” is a Device Type (DT) that is defined by the Z-Wave Plus Device Type specification. There are two other specifications, the original Z-Wave DT and the new Z-Wave Plus V2 DT. HA’s OZW integration only supports the Z-Wave Plus device type.

My GE fan switch is not Z-Wave Plus, so it takes on the Multilevel Switch Generic Device Class as defined by that version of the spec. There is no Fan Switch in that version. The generic device class is GENERIC_TYPE_SWITCH_MULTILEVEL, and the specific device class is SPECIFIC_TYPE_POWER_SWITCH_MULTILEVEL. This looks exactly like a dimmer switch. This is why HA uses the manufacturer ID and product ID/Type as a “workaround” in the old zwave integration to detect it instead.

I also have a Homeseer fan switch that is programmed as a Fan Switch DT, which was added to Z-Wave Plus. The generic device class is GENERIC_TYPE_SWITCH_MULTILEVEL, and the specific device class SPECIFIC_TYPE_FAN_SWITCH. Those two device classes, along with the Multilevel Switch Command Class, is how HA decides it is a fan.

The LZW36 (which I don’t own) says it is Z-Wave Plus V2. If that’s true, the Z-Wave Plus V2 Device Types spec doesn’t define a fan type anymore! It seems they’ve dropped the fan specific class for some reason (simplification?). In fact they call out Fan Switch DT as a example type that should be a Multilevel Switch DT in V2:

The Multilevel Switch Device Type is intended for products that can be switched between more than 2 discrete levels or states, such a light dimmer, water valve or a fan.

The Multilevel Switch DT is required to use generic device class GENERIC_TYPE_SWITCH_MULTILEVEL and specific class SPECIFIC_TYPE_NOT_USED. Based on the posts here, it seems the LZW36 is following the spec.

So if you are abiding by the spec for Z-Wave Plus V2, then you cannot program a specific type of SPECIFIC_TYPE_FAN_SWITCH. Sounds like a dead end then? I don’t know anything about how the V2 certification works and if you’re able to deviate from it, but the spec is pretty clear that it is a requirement. To add to this, I could find one other product in the ZWave DB that is a Z-Wave Plus V2 Fan Controller, and it too is certified as a “Z-Wave Device Type: Multilevel Switch”. If you browse for Z-Wave Plus fan controllers you’ll find them certified as “Z-Wave Device Type: Fan Switch”.

This is the next problem, but it is solvable. HA does know about the different endpoints, but it currently has no way of knowing that they are different device types.

Let’s pretend the LZW36 actually did report one endpoint as a dimmer and another as a fan switch in the Z-Wave Plus DT style. As long as the Node Information Frame (NIF) advertises the device as a dimmer, HA will continue to consider it that way.

The generic and specific types that HA uses for discovery are from the Node Information Frame of the device. Even if the device correctly reports different classes with the Multi Channel Capability Report, OZW will not tell HA about it. If you look at the OZW code it saves the endpoint values (I don’t think they’re persisted in the cache though), but the application (in this case ozwdaemon) doesn’t use the endpoint values in any way.

HA could support this scenario. First, ozwdaemon would need to expose the per-endpoint values in the MQTT payloads it sends, and then HA would need to recognize the per-endpoint values when it determines which entities to create. Since it already knows about endpoints that part shouldn’t be difficult.

This is an interesting observation, but I’m not sure it’s really helpful in the end.

That is the “Z-Wave Plus Assigned Icon Types”, which is reported via the Z-Wave Plus Info Command Class. The intent was/is to use this to display some (terrible) icons in an application. The icon types are defined by the standard. My HomeSeer fan switch does report “Fan Switch”.

The icon is supposed to be reported individually for each endpoint (I have a device that doesn’t). Based on the cache file posted above, you can see that it is, or at least the root and endpoints are different:

                                <Value type="short" genre="system" instance="1" index="1" label="InstallerIcon" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-32768" max="32767" value="7168">
                                        <Help>Icon File to use for the Installer Application</Help>
                                </Value>
                                <Value type="short" genre="system" instance="2" index="1" label="InstallerIcon" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-32768" max="32767" value="1536">
                                        <Help>Icon File to use for the Installer Application</Help>
                                </Value>
                                <Value type="short" genre="system" instance="3" index="1" label="InstallerIcon" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="-32768" max="32767" value="1536">
                                        <Help>Icon File to use for the Installer Application</Help>
                                </Value>

We can look at the Assigned Icon Types document to see what these mean.

Endpoint 1 is 7168:

ICON_TYPE_GENERIC_DIMMER_WALL_SWITCH
Dimmer Wall Switch
This icon is intented for the installer and user icon types in the root device of a Multi Channel device implementing a wall controller. A user interface should not show the root device. The user icon type of each wall controller End Point should be either ICON_TYPE_GENERIC_LIGHT_DIMMER_SWITCH, ICON_TYPE_GENERIC_ON_OFF_POWER_SWITCH.

Endpoint 2 and 3 are 1536:

ICON_TYPE_GENERIC_LIGHT_DIMMER_SWITCH
Generic Light Dimmer icon
This icon is intented for user icon types

So looks like Inovelli is again following the spec, but notice the phrasing says should be. That terminology usually means it’s not a requirement, just a strong suggestion. So maybe the device could report Fan Switch instead for that endpoint? I’m not sure who decides what a device/endpoint will report, does the vendor set it?

Of course, you could also hack the device XML file to override the detected values if you wanted.

The spec says “Icon types do not affect the operation of a product or how it is certified.” Does that mean applications shouldn’t consider it in determining behavior? Kind of sounds like you wouldn’t want to rely on it. Is there any hub on the market that uses this information?

Either way, you’d still need to get Home Assistant to implement it. Might be useful for a control panel or something. As for behavior, it’s probably easier just to go with the manufacturer based workarounds at that point, because then you can also support non-Plus devices.

Zooz isn’t really doing anything special here. When HA sees the Binary Switch command class, it just creates a switch, there is nothing else it considers. Because they are different command classes, Binary Switch vs. Multilevel Switch, there is no ambiguity.

Here’s a list of documents for reference. If I got something wrong, I’m happy to be corrected.

  • SDS10242 Z-Wave Device Class Specification
  • SDS11847 Z-Wave Plus Device Type Specification
  • SDS14224 Z-Wave Plus v2 Device Type Specification
  • SDS13738 Z-Wave Plus Assigned Icon Types
4 Likes