If I hit the cyclespeed button on the device page, nothing happens. However any other button I hit whether it's the on or off or set speed, etc. works. I imagine that has something to do with it?
More info: It seems that if I hit off on the device page of the parent unit and then cyclespeed, the fan will go into low mode but then not budge from there with further cyclespeed commands.
Here's the debug info if it helps anyone. This is me hitting cyclespeed twice and then off. The fan only goes into low mode and then off.
I have 5 of these controllers and I can confirm the "Cycle Speed" tab on the device settings page (rarely) is working. I say rarely because out of the 5 devices it did work twice once on two fans, but did not work after the first time. I myself have at least one peanut plug as a repeater near each one of these and they communicate fine instantly with every other selection on the device settings page. Everything else selectable shows immediately in the logs, however Cycle Speed does not.
@mike.maxwell Would you have anything to recommend to get this driver function to work?
I'm in the same boat, good zigbee repeaters within 10 feet of each fan and all other commands work almost instantly. It would be nice to get this working as the Pico remote replaces the need for the handheld remote mounted on the wall.
Seems like it should be an easy fix as the device responds to all commands, even manually setting the level of the fan. Just seems to be something not quite right between the command to cyclespeed and actually cycling the speeds.
@cj_rezz Here is mine rule and it's working. If I can be of any further help let me know. My is in Rule machine. Make sure you click on button device.
Something has definitely changed because I remember testing this briefly when it was introduced and it worked fine. Luckily I had my own method of cycling these fans already code in my ABC app before the cycle option was built in to the device driver, so this change hasn't affected me.
I'm sure @mike.maxwell will get this sorted out soon enough. In the meantime, feel free to try my ABC app and let me know if you have any issues in that thread. The cycle fan option works fine there.
1 Like
Thanks @leeonestop and @stephack, I'll look into these workarounds for the time being. @mike.maxwell, if it helps your troubleshooting, I'm still on version 2.1.4.130, haven't upgraded yet.
@stephack, this app works perfect! Thanks!
One question: is there anyway to set the fan to the "breeze" mode on a Hampton Bay Wink Fan? I think in Hubitat they call it the "Auto" mode.
I use the following rule to cycle through fan speeds on my HB with one button of a pico.
The Cycle Speed command used to get the fan speed set to Auto Mode, which activated the Breeze Mode in the HB. The breeze mode essentially just rotates through the speeds resting on each for a set duration.
The Auto speed setting is what gets Breeze Mode I believe.
Ahh...you're right. I never added that AUTO option when the updated the hampton driver to support breeze mode. It is literally adding the word auto to one line of code to fix. I will update when I get to my desk today and push to Github.
Yes, auto is one of the 8 options in the Fan Speed capability. This is one device that haunted me all the way back to my ST days so this is one device I know more than I care to know about. Just the memories are giving me a headache. Also, the "on" in the fan speed capability always confused me. Why would you ever have a speed of "on"? No one ever explained that one to my satisfaction.
My biggest complaint with the HB driver looks like it was resolved at some point and that is matching the switch with the Fan Speed. Before it was possible to have the fan switch off and the speed would still be set to the last saved speed. The fan would not be spinning but the speed would not be "off".
But now turning the switch off sets the speed to off as well. So, it appears that that has been fixed so part of the rule I linked to earlier isn't necessary anymore.
@mike.maxwell I think I may have found the issue. While updating my ABC app to support the auto fan speed, I created a Virtual Buttton and Virtual Fan Controller on my dev hub (don't have either device attached to this hub right now).
In the Virtual Fan Controller I decided to test the cycle command to see how it responded and not surprisingly it seemed to function as designed....but I also noticed that the cycle command went thought 5 fans speeds (low, medium-low, medium, medium-high and high). The Hampton device and driver only has 4 speeds (low, medium-low,medium,high). I then looked at the Set Speed options for a live Hampton device and saw that it also listed an option for a fan speed that doesn't exist on the device.
Setting that speed resulted in:
So there seems to be a couple of issues. The Hampton driver needs to remove the medium-high as a fan speed option and the cycleSpeed() command may need to be updated so that it doesn't try to cycle through an invalid speed option.
That's because Medium-High is part of the fan speed capability. It would have to be removed from the entire capability or the HB device wouldn't be able to use that capability. Either that or setting to Medium High would just use the same command issued to the device as "medium". You can't remove it from the HB without removing it globally from the capability.
As I said, the capability also lists the speed of "on". Is your cycleSpeed coimmand also cycling through that one as well as "off"?
I think the fix here is that the cycleSpeed command on the HB would only cycle through those speeds that it is capable of doing. Right now the cycleSpeed command just sets the speed to low and doesn't really cycle anything. Which was kind of the point of my thread that I opened way back when.
The command actually cycles through all 5 speeds as I noted in the Virtual Fan Controller. I think the issue is, whatever logic the cycleSpeed command uses to move to the next speed, it gets hung up on "an unsupported speed". The driver needs store the compatible fan speeds in a map (based on the device type) when the device is initialized and then the cycleSpeed command would cycle through those speeds only. That way the capability would be independent of the command.
The command doesn't do anything in the HB fan driver. Go to your HB device and click on "Cycle Speed". it it will set it to low. Hit it again and it will stay set to low. It doesn't matter how many times you "Cycle Speed" it will always be on low.
Here are the logs from the HB fan controller when you issue the Cycle Speed command that is built into the fan driver.
It appears that whatever app is issuing the command to the HB fan controller is not issuing a cycleSpeed command but is instead issues a setSpeed command, which is not the same thing.
Only when issuing a setSpeed to Medium-High do I get this error:
So, as I said, to remove that, you would have to remove the medium-high speed from the capability.
You might be right...the code for cycleSpeed in the virtual driver may be different from the HB driver...unfortunately I can't see the code so I can't say what is causing the issue...it is ALL based on the logic being used to cycle between speeds.
I'm just speculating and trying to provide clues so that this can be fixed...regardless the items I pointed out are issues that should be addressed whether related to this cycling or not.
My thought process on this was that the list of fan speed options would be dynamic based on the zigbeeid when paired...but now that you mentioned it..I think you are right...there would be no way to dynamically change the setSpeed dropdown as it needs to be hardcoded in the metadata. However it still could be used for the cycleSpeed command if coded correctly...I think 
It's easy to find out. Go to the edit device page and click on "Cycle Speed" and see what happens.
Absolutely...and the crazy part is that I already did that for a community version of a virtual fan driver before.
def cycleSpeed(){
def currentSpeed = device.currentValue("speed")
if (currentSpeed == "off"){
setSpeed(low)
} else if (currentSpeed == "low") {
setSpeed(medium-low)
} else if (currentSpeed == "medium-low") {
setSpeed(medium)
} else if (currentSpeed == "medium") {
setSpeed(high)
} else if (currentSpeed == "high") {
setSpeed(low)
}
}
So, I know it's not complicated since a novice like me can do it. 
I did this for a fan sync app that I wrote and since, as you say, the in-built virtual fan driver cycles through speeds that the HB doesn't support I need a custom virtual fan driver.
The only real issue would come if you are trying to issue cycleSpeed commands to multiple fans that don't all support the same number of speeds. That's why I had to build the custom driver and issue the cycle speed to it and then sycn them based on the setSpeed command rather than the cycleSpeed command.
Also, i think that if the capability is going to use "medium-high" it would make sense to me that if that command was issued to the HB that it would just use the "medium" zigbee command to the actual fan device. That way you wouldn't get the error in the driver and It would display "medium-high" as the speed. There are community versions of the GE fan driver which have done the same thing for medium-high and medium-low since neither of those speeds are supported by that controller.
That's not exactly what I was referencing. The code I'm referring to will need to be based on a map of supported values determined at initialization. What you have above is almost exactly what IU have written in my ABC app.
def cycleFan(devices) { //all fans will sync speeds with fisrt fan in the list
log.info "Cycling: $devices"
def mySpeed = devices[0].currentSpeed
if(mySpeed == "off") devices.setSpeed("low")
if(mySpeed == "low") devices.setSpeed("medium-low")
if(mySpeed == "medium-low") devices.setSpeed("medium")
if(mySpeed == "medium") devices.setSpeed("high")
if(mySpeed == "high") devices.setSpeed("off")
}
However, this code assumes that the speed options are low,medium-low,medium,high.
Another fan devices with 5 fans speeds including medium-high would balk at this code. You could put more if then statements to handle that option but who knows what other options lay in wait for the future. Having a value set based on device type at initialization would allow the capability to automatically adjust itself as needed...if written correctly. This might be more complicated than I'm laying out here but is just food for thought.
Your code is for an app.....and mine was to fix the code of the driver so you could issue the device a cycleSpeed command. You keep using setSpeed and that is not what the issue is.
