Cycle speed is auto.
No, it's not. That's a separate fan speed. One that isn't support by the Hampton Bay Zigbee fan controller.
See, the fan speed actually get set to Auto. Cycle Speed is supposed to go from off to low to low medium to medium to high and then off again each time the button is pressed.
What is cycle then? Mine literally cycles through a bunch of speeds, changing ever minute or so, when I do this, same as on the remote when you pick the "waves" icon.
That's not cycle speed. Cycle speed change to the next higher speed and then returns to either low or off, depending on what they've chosen to do, each time the cycle speed command is issued. Not continually cycle the speed. Take a look at the edit device page. you can see the auto speed under the Set Speed command.
Oh, that isn't happening. I didn't even know that was supposed to do that. Isn't that named weird or is it just me? Shouldn't it be "increment speed" or some other name?
Sorry for getting off topic.
That's okay. Actually, cycle speed is exactly what the command does. The command cycles through the speeds. What you're talking about is AUTOmatically cycle the speeds. That's why the command you're talking about is setSpeed(auto)
Don't know, but I have these fans, so will look into it.
I tried to replicate this but ran into other problems. Notably, my HBFC child fan device seems to respond to commands (usually, as often as it ever does, anyway...) but doesn't update any of the "Current State" attributes. I assume this is because it's fallen off a couple times and I've had to re-join it, but I kept the existing device and maybe something messed it up when the (parent) DNI changed.
Anyway, when I try to cycle the speed on the child device, nothing happens, despite the fact that most other commands seem to work. Trying on the parent instead, I think I got the same behavior, but it's hard to tell because I soon run into an NPE that turns off the entire fan (and light kit, even though nothing I touched should have affected that) for some reason. FWIW, the logs did show it getting set to low before I got this (and a dark room) immediately after:
dev:98 2019-08-17 00:44:06.140 errorjava.lang.NullPointerException: Cannot invoke method sendEvent() on null object (parse)
(The device indicated by dev:98 is the HBFC parent device.)
So...I can't quite tell if this is happening to me, but I definitely have some problems in either case.
Not to stray off topic but wanted to clarify one thing. The 'auto' fan speed is an actual fan setting of the HBFC controller. There is a setting called Breeze mode built into the controller (speed 5) that is supposed to mimic natural breeze by randomly switching to different speeds at varying intervals. HE probably chose to rename it to Auto to avoid any patent/trademark issues. As @Ryan780 mentioned, this is different than cycle, which is supposed to move through the different speeds in a predictable manner.
Also...I just tested using the cycle command and it does exactly what Ryan stated...simply sets the fan speed to low.
I think that the "auto" setting is a little misleading since that implies that it will automatically adjust the speed based on the temp of the room. But there is no other function within the fan capability that would match up with "Comfort Breeze" so I completely understand why it was put in there. I wasn't aware that what was actually happening when you set it to auto though.
Has anyone figured out the issue here? I'm trying to program a Pico remote to control my Hampton Bay Fan and I'm getting the same behaviour, at best, can only get the cyclespeed command to set the fan speed to low and nothing else.
I built this manually through a rule using If/Then statements.
Just to update this thread for others that stumble upon it trying to figure out why the cyclespeed command doesn't work; It seems this is an ongoing issue in Hubitat however @stephack's Advanced Button Controller App works beautifully!
This is not a fix for the Cycle Speed command in the Hubitat driver. The function called in ABC is "Adjust Fan Speed" which does the exact same logic that you could do in Rule Machine. The issue called out in this post is the issue with the "Cycle Speed" command build into the HB fan driver. Which cannot be fixed by an app because you can execute that command from the edit device page.
Actually the "adjust fan speed" is something different and was left there as a legacy option (was used for zwave fan controllers in ST).
I also have a "Cycle Fan speed" option that was written before Mike add the command in the Hampton driver (I was one of the folks that pushed for it). Luckily I never updated that code to use the cycle() command and left my own cycle code that works independently of the driver.
My point is that the Cycle Speed command in the HB driver doesn't work. An app might have a command called the same thing but that is not the same as issuing a command of cycleSpeed to the driver.
You are correct. But your statement above referenced a completely different option in my app and provided incorrect info. I posted as a point of clarification on that statement.
Just going by what was linked in the previous post.
That post was specific to someone that was already using the "adjust fan speed" option for....a zwave fan controller. These devices had their fan speeds adjusted via setLevel commands and needed different commands...precisely why I left the option in the app.
HE may have updated these drivers to work similar to the Hampton...not sure...but I have no plans to remove that section of the app because there is bound to be users who would need it for a ported driver at some point.
The Cycle Fan Speed option was written specifically for the Hampton fans.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.