Fan Control Capability design debate


#1

You are correct. I have corrected my post above.

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.

Hubitat Team - any thoughts?


Problem adjusting Lutron Fan Control speed via Pico w/ Button Controller
#2

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.


#3

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.


#4

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.


#5

yeah, setSpeedUp and setSpeedDown do make more sense

both will loop, just in different directions


#6

So setSpeedUp if on high will make it go to low or off? I'm not super thrilled about that at all...

That sounds a lot more like next or previous, like you mentioned originally...

Maybe I'm just anal, but up should not go down. A loop is a circle, no up or down in a circle.


#7

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.


#8

I understand that. But that is not up and down, that is previous and next.

Very poor design choice to use up and down wording on a looping function, in my opinion.

But whatever, the world will not end either way.


#9

Gotcha, either way someone's gonna be unhappy I guess. I personally prefer the loop but I get why you might prefer a different setup.


#10

I actually like it looping. I just think he should call the function something else that makes sense in the context of what it's actually doing.

A function called "up" should never make the device go "down". Just like "on" can't make something go "off", and "ok" can't make something "cancel".


#11

How about cycleUp cycleDown?


#12

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.


#13

Eh, if the cycling bothers me I'll just make a user driver for the fan anyway.

Regardless, I like more features, so don't want to complain too much. :slight_smile:


#14

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.


#15

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


#16

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

:grin::grin::grin:


#17

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.


#18

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


#19

Now you're talkin. :slight_smile:


#20

As Confucius and other wise men say: "Options are good :sunglasses:"