Feels like it would be a very good idea for @mike.maxwell and @bravenel to take a comprehensive look at how the Fan Control Capability is implemented for all of the various Fan Devices supported by Hubitat. As long as it is consistent across all of the devices, the Apps will be happy.
They know the architecture the best, and probably have a design philosophy that they’d like to adhere to. I’d just like to see differences between physical fan controllers abstracted away from the Apps wherever possible and moved into the Drivers. Adding a few more commands to the Fan Controller Capability seems like a good idea, based on the above discussion.
Yup, @bravenel and I are chatting about this.
The setSpeed( Number ) call in the KOF driver is an anomaly and isn't part of the capability, so this won't be added to the existing controllers.
We will be adding two commands to all the fan controllers (setNextSpeed() and setPreviousSpeed()) as well as app support for them, though not sure which apps will release in 2.1.0 with these updates.
These new setXXXSpeed() commands will cycle through the fan's internally implemented speed settings but in different directions.
Awesome! Can I make one suggestion? I think @ogiewon's suggested speedUp and speedDown are clearer than "next" and "previous", which are context-dependent--if I'm in the process of lowering the speed, the "next" speed would be slower than the current speed, though I'm sure the intended meaning is that "next" refers to a higher speed. Or maybe setHigherSpeed/setLowerSpeed.
Thanks Mike! If the new “setNextSpeed()” command reaches the end, will it loop around to “off”, then “Low”, etc... Or will it simply stop at “High”? Alternatively, the “looping feature” could be a User Preference. Doing so would allow the driver to emulate the typical “pull chain” behavior.
I believe he is saying it will go from high to off and then low, medium,etc...like a pull chain as Dan mentioned.
In the other direction it would go from low to off, then high, medium, etc.
I agree. If it's meant to cycle, calling it cycleUp is clearer. For my integration, I don't want the cycle behavior. I want "up" to raise the speed; if it's at the maximum speed, it should do nothing, just like trying to raise the volume level on a device that's already at the max. If it's going to cycle, then I have to write a more complex integration not to do that.
Maybe I'm missing the scenario that is driving everything towards cycling. I get trying to mimic a pull-chain if that's the goal--cycling is an elegant solution if you only have one control. But if I have on/off/up/down buttons, why would I want it to cycle? That's just unexpected behavior that seems anachronistic, like we're trying to make it behave like an old pull-chain out of nostalgia or something.
This.
If you only want to devote one button to a fan, this is the best solution. I have a pico that I use to control my bedroom lights. I do not want to use another button device so I assigned the middle button to control my ceiling fan. Cycle is the best for this scenario.
I'm certainly not opposed to more features, I just am not sure why building a simple, clear command that works analogous to existing commands (volumeUp/volumeDown) is a bad thing. If supporting cycling is important to people, I have no problem with that! But that seems like an "advanced" command compared to simply going up or down a speed (or doing nothing if already at the min/max).
He should just make everyone happy and make a speed up and speed down that don't cycle, and a cycle speed function. Don't really need a cycle up down, just one cycle.
For the record I actually don't think speed up and speed down should ever turn it off either...
In my case it actually doesn't really matter as I already have this working with ABC. I'm ok with whatever Mike and team implement...as long as it's consistent across devices.
Yeah, I see the motivation here now. Both the single-button mode and the full-up/down/on/off mode seem like reasonable integrations. It would be nice to arrive at a simple set of commands that do "the expected thing" for their respective modes. I think that would be:
setSpeedUp - up one notch, do nothing if at max
setSpeedDown - down one notch, do nothing if at min
cycle - up one notch, wrap around to off
"
