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

[clang1]

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?

Also attaching events from the Pico device, so you can see that it is generating the held events correctly.

[ogiewon]

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.

Advanced Button Controller (ABC)

For changelog, please scroll to the the bottom of this post. This is a port of my smartThings app. If you have used the ST version then this should be very familiar. Of course all the devices options listed have not been tested since they are not yet available with Hubitat. This app takes advantage of the new doubleTap events available for button controllers as well. PARENT APP Hubitat/Advanced_Button_Controller.groovy at master · stephack/Hubitat · GitHub CHILD APP Hubitat/ABC_Child_Cr…

[clang1]

Thanks, @ogiewon. I tried installing ABC and got different results. I deleted the regular Button Controller apps to avoid interference, and configured it to cycle the fan speed when button 3 is held:

When I hold button 3, I get a single event on the Fan Control:

"4" does not seem to be a valid setting, and repeated holding of button 3 does not seem to have any further effect.

Any ideas? It seems the problem is with the interaction with the Fan Control device, rather than with the Pico button subscriptions.

[clang1]

I changed the cycleFan implementation to look like:

def cycleFan(devices) { //all fans will sync speeds with fisrt fan in the list
    log.info "Cycling: $devices"
    def mySpeed = devices.currentSpeed
	def newSpeed = "off"
    if(mySpeed[0] == "off") newSpeed = "low"
    if(mySpeed[0] == "low") newSpeed = "medium"
    if(mySpeed[0] == "medium-low") newSpeed = "medium"
    if(mySpeed[0] == "medium") newSpeed = "high"
    if(mySpeed[0] == "high") newSpeed = "off"
	log.debug "cycleFan: mySpeed = ${mySpeed}, devices = ${devices}, newSpeed = ${newSpeed}"
	devices.setSpeed(newSpeed) 
}

This works better, but the fan control device seems to incorrectly report "low" as its value when set to 100%, per comment here: Lutron Fan Control Behavior

So really I just end up alternating between two speeds. Hopefully that issue is fixed soon. But it seems neither Button Controller nor ABC correctly work with the Lutron Fan Control as-is.

[ogiewon]

@clang1

But it seems neither Button Controller nor ABC correctly work with the Lutron Fan Control as-is.

Hubitat has mentioned in another thread that they are aware of the Lutron Fan controller driver issues, and should have them fixed in an upcoming firmware release.

[stephack]

I don't own one of these fan controllers but if someone could let me know the details I "may" be able to make it compatible with ABC.

How many fan speeds?
How are each reported in the logs/attributes for the device?
Are there any other differences (commands etc) between this device and the Hampton Controller?

[ogiewon]

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.

[stephack]

Thanks Dan. So essentially not worth the effort to fix as an upcoming update should take care of these oddities.

[ogiewon]

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.

[stephack]

@ogiewon

It would be nice if the Fan Control Capability included a “CycleSpeed” command.

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

[Ryan780]

Rule machine now allows you to select a specific fan speed not just to cycle the fan through the speeds like it used to.

[clang1]

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]

@clang1

I would prefer an explicit adjustSpeed(+/-) command

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.

[clang1]

@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?

[ogiewon]

@clang1

the setSpeed command still requires knowing the current speed name and the next speed name

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!

[stephack]

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.

[clang1]

@ogiewon

You would like 'speedUp' and 'speedDown' commands to be added as well! Similar to 'volumeUp' and 'volumeDown' in the Audio Volume Capability

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.

[clang1]

@stephack

Simply add a parameter...cycleSpeed(up) or cycleSpeed(down).

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

[stephack]

@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?

[clang1]

@stephack

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.

Thanks, I'll do that!

@stephack

What is the exact name of the driver it uses now?

It's Lutron Fan Control.