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:
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.
The fact that the ABC app is issuing a setSpeed command for a speed the device doesn't support has absolutely nothing to do with the fact that the cycleSpeed command for the driver doesn't work. They are completely independent issues. But I've proposed ways that the driver could be fixed in both cases. But in both cases those are driver fixes for the problems with the driver. I never proposed what should be done for ABC.
Yup, exactly, this will be fixed in 2.1.6, as well as setSpeed("on") restoring the last active speed (not counting off)
This is the way that all the other fan controllers work, we just forgot to get this one sorted when we updated the others.
Also this driver update will fix the issues with the parent zigbee id changing and then ganking the component children.
Please note that if you are using component children currently and click save settings after the new driver comes out, the existing components will be deleted and new ones will be created using the new DNI scheme, this obviously is going to break any automations using the old components, but it's a one time deal.
This will also be in the notes.
discussion over I guess. Mike, I look forward to fix for those that need one. Thankfully, it is not an issue for me.
