Fan Control Capability design debate


#21

I think a Fan Device Driver should include the following Capabilities for maximum flexibility

Fan Control Capability

setSpeed - using enum list
plus these new commands

Switch Capability

on - resume last fan speed
off - stop the fan

Switch Level Capability

setLevel - so we can still use these Fan Controllers with Alexa/Google Home using good old fashioned dimmer level controls, until these voice assistants properly handle fan devices.


#22

I was with you right up to this statement. I'm not sure that's a practical workaround. If you have more than one fan, they don't always match up for level vs speed. For example the GE is very different than the Hampton Bay. So, you'd have to remember what level is what speed for each fan.

IFTTT has a recipe with Google Assistant that allows you to substitute a text string from what you speak to your Google Home. Along with the Maker API I have 1 applet per fan and am able to completely control each of my fans by just speaking the speed.


#23

With Alexa, I would use a voice activated Routine that would issue the correct setLevel command for the specific fan controller. Create as many Alexa Routines as the fan controller supports speeds, and you’re all set.

I think Google Assistant now supports voice activated Routines as well, but I haven’t experimented with them yet.


#25

There is no real reason to not include setLevel, it takes next to zero work to do, and is already in pretty much every fan driver - so it would be more work to remove it, than to leave it in.

Obviously, like any other capability, a user never has to use it if they don't want to. It is not an OR with other features, it is an AND.


#26

In a perfect world, once the fan capability and setSpeed command is fully supported by GH and Alexa any level setting commands should be sent to the "backend" of the driver and hidden from user control to make things simpler though, IMHO. Of course, that is the ideal state and who knows when that's going to happen.