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:
Start Fan (on breeze mode when implemented)
Send start playlist command to the local speaker to start “Waves on beach sounds”.
Send command to spray “scent of the ocean” into the room.
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
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.
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).
Go into “Network Management”, select your fan device, and click “Node Info”
Go to the “Command Classes” page (from main menu) and select your device from the left-hand window
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”
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.
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.
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”.
@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.
That is awesome!
