Since the last update, 2.1.6.x, the “setLevel” command appears to no longer function for the fan component device. The “setSpeed” command works as expected. I’ve removed and recreated the component devices with no change in behavior.
Was this an intentional change or a bug introduced with the cycleSpeed changes?
set level does work for the lights tho, at least on my fan controller. The controller itself is a very poorly made piece of sh!t. If I sneeze wrong it falls off the mesh. Adding a repeater in the loft above the fan has helped it stay connected for a couple months.
I have two controllers that have been working well (with repeaters) for a few months. I was using setLevel via button controller to allow me to cycle up or down the fan speed with pico remotes (+/- 25). I’ve switched to using setSpeed, so I can live with the new behavior.
Is there a reason that this command shows up on the fan child, then?
The above is what I see after completely deleting my HBFC device and re-adding it with the new driver on 2.1.6 (something I did to make it easier in the future if I ever have to rejoin it again, but also something I hope to never have to do again after having replaced the antenna, which drastically improved my RSSI and I think should take care of that "need a repeater super-close" problem--I can't recommend that enough).
There may be some trick I'm missing, but without setLevel, they don't seem to play well with Alexa. 
It also breaks the integration with the homebridge/makerapi plug in. That may be resolved if the setLevel capability is removed entirely...
I've also observed this behavior with the level state (note the level at "high" speed):
speed -> level
low -> 25
medium-low -> 50
medium -> 75
high -> null
auto -> 100
Yeah, I'll remove the switch level capability in the next platform release.
Please don’t remove it, rather reimplement it. Other fan controllers implement setLevel to allow Amazon Alexa control over these devices, like the Lutron Caseta Fan Controller driver.
I'm torn because the set level is the only way to control the fan level using my google home. However, since the switch capability is enabled in the fan child, google home treats the fan as a light (meaning it turns on and off with a "turn off all the living room lights" command). Since there is no way in the google home app to tell it that a fan is not a light, It will always do this if switch capabilities are enabled.
It's a double edge sword.
What happens if you just put the fan in it’s own GH room?
I can do that, and it would fix the "turn off the living room lights" problem, but would still do the same with "turn off all the lights".
Also I try to keep the Google home from getting too "hacky" since that is how the family interacts with most things.
It's a minor issue, and TBH it is really google's fault. GH looks for words in the name of most things to determine if it is a light or not (for example I have smart plugs on lamps that respond as lights, but GH is smart enough not to turn off the pond pump with the backyard lights). It is just hard coded into GH logic that a switch level capability means it is a light, no matter how the device is named.
I am much more of an Amazon Alexa user, so please bear with me... If Hubitat were to remove the “Switch Level” capability, would Google Home still be able to adjust the fan’s speed? (Without any workarounds using virtual devices). Does Google Home support Hubitat’s “Fan Control” capability?
I'm not sure. I don't fully understand the GH implementation. I don't know if GH would then recognize it as a fan and uncover the speed control, or what it would do without the switch level capability.
As it is currently, the commands "set fan speed to low" does nothing. "Set the fan to low" works, but then GH states it is "setting the fan's brightness to low" so I think that is not proof of anything. On the GH UI the device appears as a light, so the slider is there for "brightness" but that is it.
I wish I had a copy of the driver code so I could try just removing the capability and see what happens. I figure either the GH sees it as a fan and now uncovers the speed capability, or it sees it as an on/off plug (which would fix the turns on/off with lights problem, but now no way to set speed in GH).
You could easily create Virtual Driver that you could use purely for testing purposes, to see how GH behaves with/without different capabilities.
I'm planning at this point of implementing a child option for the fan component, one with setLevel and another without, that way everyone wins, you just pick the one that meets your use case...
Will it support both child options??
I think the handwriting's on the wall.. setLevel is a "previous" method and for antique integrations like Alexa and GH, they will still need that BUT shouldn't we be following the standard that more closely matches how fans are built in this decade?
(I know that fully variable fans can be built but that the cost of DC motors would have to drop significantly for them to be common.)
fan child options, select from:
For Alexa to respond to voice commands that leverage set fan speed, does that require a change to just the hubitat skill or also the whole Alexa platform?
Alexa already can utilize “setLevel” on any devices that are dimmable switches. That’s how all dimmers and fans are currently controlled via Alexa today.
Or, are you wondering how Alexa and Google Assistant would make use of the Fan Control capability? For that to work, those platform would need to have support for fans, and the the skill would have to be updated to support fans.
Oops just realized from your response I wrote setlevel when I mean set fan speed. Edited above post. Thanks Dan.
Download the Hubitat app
