I have a couple rules that use pico buttons to cycle fan speeds from low, med, high. I'm not sure when this broke, but from off to low works. Then if you press button 2 again, the fan goes to medium, then to high.
No matter the fan speed, the step down rule turns the fan off.
It's not the pico, because using the button presses from the pico page does the same thing. If you watch the fan device info, you can see it go to medium for a second then to high.
I have 3 sets of these rules for 3 different fans. Two of them control Bond fan modules. One controls a Lutron fan controller. Both sets of rules for the Bond modules are acting up.
From the fan device page, I can command whatever speed directly and it's fine. Only from rule machine it seems to misbehave.
the next platform release will add two custom commands to the bond fan driver, increaseSpeed and decreaseSpeed, also fixed the cycleSpeed command which would hang at specific speeds on some fans as well as populate all the speed names for 6 speeds and above.
Any reported issues with 2.3.5.125 buttons toggling Hampton Bay fans?
I updated to this build today after hanging back a few builds. Everything was working. Now after update Sonoff and Xiaomi devices required repairing and now toggling light and fan on HB devices does not work. I tried in with Button Controller, Simple Rules, and Rule Machine and seems to be broke using each of them. Best I can get is separate condition for off and on.
no, nothing's changed platform wise that would cause this. Does the device respond correctly from the driver UI?, if it doesn't its not going to work from any rules...
I think you're on the right track. This looks like the fan status is updating to medium before the third "if" condition is being evaluated. The rule doesn't need to be modified though. There's essentially an implicit ELSE and END-IF happening. It just doesn't read well.
@scoob8000 can you go back to that timespan and include the fan device along with the rule logs?
I still think this is more a race condition that's apparent now for some reason (maybe the rule is executing slower) but the crutch is that this would be better suited as a nested IF-THEN-ELSE
if(fan off) set fan low
ELSE-IF (fan low) set fan medium
ELSE-IF (fan medium) set fan high
Using the nest method above, the IF conditions are evaluated in order until one evaluates as TRUE and then the rest will not be checked. This is what you want to happen.
My hypothesis is that the fan speed is updating before the rule finishes. Let's say it is set to low and you hit the button.
//This evaluates to false
IF(fan is off) set fan to low
// This evaluates to true, so the command to set the fan to medium is sent.
// The fan speed gets updated instantly
IF(Fan is low) set fan to medium
//This will still be evaluated. If the fan speed has already updated to medium,
//then this will evaluate as true and the fan speed will be command to high.
IF(fan is medium) set fan to high
You can see this in the logs you posted. The top two lines (last two logs entries) show that the IF conditions for both low and medium are evaluating as TRUE in the same run.
I just couldn't wrap my head around why one rule set worked but the others didn't. In hindsight, I guess these rules always worked, but barely.
HAL9000,
Seeing that extra button press in the RM log is what made me be so stubborn. Now that I'm at home I tried to re-create that a few times but never could.
I'm guessing the bond drivers just update a touch faster for some reason.
