I installed a new Lutron Caseta Fan Control today and am trying to control it with a Pico via the Button Controllers app. I am able to turn the fan on/off by holding Pico buttons 1 and 5 (so I know the Button Controller app is correctly subscribed to the Pico), but am not having any luck cycling the fan speed.
I first tried mapping holding buttons 2 and 4 to adjusting the level +/- 25, but that seemed to have no effect (probably because the Fan Control device does not report its level). I then tried mapping holding button 3 to the Adjust Fan action, but that also does nothing. The fan stays at its current speed, and the device page for the fan does not show any events being sent.
Attached is the Button Controller app setup and status page for the attempt to use button 3. Should this work? Is there any chance of getting the Fan Control device to report its level so I can use buttons 2/4 to adjust the level up/down rather than just cycling through speeds?
I know the Button Controller App is going to get some love in an upcoming release from Hubitat. Until then, you might want to check out @stephack’s amazing ABC App. I use it to cycle through the fan speeds on my Hampton Bay Fan Controller.
In 2.0.9, Hubitat added the Lutron Fan Controller driver. It uses the standard Hubitat Fan Speed Capability, same as the Hampton Bay Fan Controller. However, it only supports 4 of the five speeds. Low, Medium, Medium-High, and High. Currently Medium-Low and Auto are not implemented in the driver. In the next release, Medium-Low will be mapped to Medium, and Auto will be mapped to Low, IIRC. Also, On currently sets the Fan to High, regardless of the previous setting. This will be fixed as well, to return to previous speed.
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 ....
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.
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."
@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!
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?