It would be nice if the Fan Control Capability included a “CycleSpeed” command. That way each fan driver could implement it specifically for the set of speeds that device supports. @mike.maxwell, @bravenel what do you think?
For Hampton Bay Fan Controller the list would be “low, medium-low, medium, high, off”
For Lutron the list would be “low, medium, medium-high, high, off”
For GE/Jasco ....
For Leviton ....
Etc...
This would allow Apps, like Button Controllers, ABC, and Rule Machine to simply implement the CycleSpeed command without any concern for the specific fan device being used.
+1
This was precisely what I had in my custom driver. When I switched to the built in driver I had to move the code from the driver to ABC. Anything that allows me to simplify my apps is preferred and having this in the built in drivers would be better for everyone.
For example, it would allow many to completely remove or at least simplify the Custom Commands they are already using to accomplish this.
I would prefer an explicit adjustSpeed(+/-) command to built-in cycle commands, or consistent mapping of level<->speed so simply setting level +/- an offset to the current level would change speed. (This would probably be device-specific since different numbers of speeds would map differently to 0-100, which is why I think an explicit adjustSpeed would be preferable.) I think cycling is a poor substitute for explicitly increasing/decreasing speed--at least based on my own experience with cycling that is generally, "click click Is that max speed, or is there one more? click Nope, now it's off, need to cycle again click click click Wait are there three speeds or four? click Dammit."
There already is a builtin setSpeed command within Hubitat's Fan Control Capability. It does map speed names to the proper levels for the specific fan device.
What I am asking for is a new command to be added, one which allows the driver to handle cycling through fan speeds, including off.
@ogiewon Unless I am misunderstanding, the setSpeed command still requires knowing the current speed name and the next speed name (i.e., knowing that "medium-high" follows "medium"). I am suggesting a command that would let me simply say adjustSpeed(1) or adjustSpeed(-1) to move between speeds without needing to know that mapping. Is this doable today without knowing the device-specific supported speeds?
Ahhh! You would like 'speedUp' and 'speedDown' commands to be added as well! Similar to 'volumeUp' and 'volumeDown' in the Audio Volume Capability. I can totally understand that request. Thanks for clearing that up... I missed the point of the (+/-) notation in your OP.
For me, I just like the idea of being able to emulate the old pull chain, and thus the 'cycleSpeed' command would suit my needs. However, I can definitely see where bumping the speed up and down would also be very useful. Great idea!
I think this could be done easily if the HE team decide to implement the CycleSpeed recommendation. Simply add a parameter...cycleSpeed(up) or cycleSpeed(down). At least that's how I would do it.
Yes, sorry for being unclear! Perhaps explicit speedUp/speedDown would be clearer. I guess we have different use cases. For me, since I want to map the actions to Pico buttons, having discrete on/off/speedUp/speedDown makes the simplest integration. Having a simple cycle command would be useful where you have fewer buttons or are trying to emulate the pull-chain.
That would certainly work, and avoid needing to add new commands. Though I think explicit commands like @ogiewon's speedUp/speedDown suggestion are nice because they are self-documenting. No need to remember/look up "Is it cycleSpeed('down') or cycleSpeed(-1) or...?"
@clang1 If they do not implement this on the next update but fix the bug where it reports the wrong speed, give me a shout on the ABC thread. I think I can easily have the existing Cycle Speed in the app adjust for Lutron Fan Controllers. I used to have to do this for the Aeon minimotes back on ST there were 2 popular drivers that behaved very differently, so the app is already prepped to do different things based on the driver type. What is the exact name of the driver it uses now?
@ogiewon, unless something has changed recently the HB controller only has 4 speeds.
Low, medium-low, medium and high....and of course off.
I just want to confirm what the Lutron device has so I can create the code properly. @ogiewon or @clang1, please confirm the exact names for the Lutron Controllers fan speed.
Edit: I am also assuiming this driver takes the setSpeed command with numeric values like the HB controller does. Please confirm this as well.
My experience was that using the numeric values did not work. But I did not do any specific debugging/investigation. Unless someone knows the answer already, I can do some more testing later today or tomorrow.
Let's just ask the all knowing all wise instead. @mike.maxwell, what are the compatible fan speeds for the Lutron Fan Control device (somehow I doubt they support all 5 listed) and do they support the setSpeed() command with numeric values like the HB controllers?
From google images so I can't say for sure if this is as it appears in the app...looks legit.
This might explain why @mike.maxwell and team have now added the MEDIUM-HIGH option. The HB used medium and medium-low for speeds 2 and 3. I assume the HE team wanted the app to match the driver so they made they added medium, medium-high for the Lutron devices. Kind of confusing to list both on the same driver though.
It seems that trying to track multiple manufacturers' English-language level descriptions in every app that needs to set speeds will get hairy. Mapping to a numeric level (perhaps with a separate attribute indicating the number of discrete levels) seems more sustainable in the long run. Perhaps drivers could still expose a human-readable speedName attribute if desired (but if this was read-only for purposes of displaying to user, apps would not need to worry about the complexity of which speed names were supported, and how they were ordered).
In other words, knowing that levels go 0 -> 1 -> 2 -> 3 -> 4 is a lot easier than tracking that one device supports "off" -> "low" -> "medium-low" -> "medium" -> "high" while another is "off" -> "low" -> "medium" -> "medium-high" -> "high".
Exactly. This was why the setSpeed() allowed both string and numeric values. We could easily adapt to a different naming convention on HE. Bare in mind what I said in my previous post was just conjecture. We'll have to wait for Mike to chime in for a reality check.
