I may implement buttons differently in the future (use holdable, releasable, etc.) but for now this is how they work. All button events are pushable buttons. It acts like it has 12 pushable buttons.
Button Mappings:
ACTION BUTTON# BUTTON ACTION
Double-Tap Up 1 pushed
Double-Tap Down 2 pushed
Triple-Tap Up 3 pushed
Triple-Tap Down 4 pushed
Hold Up 5 pushed
Hold Down 6 pushed
Single-Tap Up 7 pushed
Single-Tap Down 8 pushed
4 taps up 9 pushed
4 taps down 10 pushed
5 taps up 11 pushed
5 taps down 12 pushed
@codahq:
Ran into the same troubles with the Status LEDs here as I did with the WD200+ (I just got the fan switch installed earlier). I made changes to lines 496 & 501 to change the color to color.intValue() and it is working fine (just what you did on the WD200+). I also changed the "brightness" description for the "double-tap" and "single-tap" up preferences to be "speed".
Imported the new version and everything works well. I was digging through it and made a change to setSpeed and getFanSpeedTextFromLevel (my fan is a 3 speed, so only has low/medium/high speeds) so that it breaks it out to those for 3 speed and leaves the rest for when the fan is set to 4 speed. This works great for setting the value and reading it back in...
But I was curious, how do you set the list of values for your Set Speed command dropdown? I could not find where it was and it always shows all 8 options (I would remove medium-low and medium-high for mine at least).
I think it would be a good thing for me to learn how to deal with such a field anyways.
Is it normal for fan controllers to appear to Google Home as lights?
I was previously using a dimmer configuration, which kind of did the job but I needed the double-tap functionality so I switched to this driver. I guess it would make sense that the dimmer would appear as a light.
Yes, that is normal until Mike Maxwell and company update the Google Home (Assistant) integration that is the way it will be. Google has made provisions for fan devices in their API but Hubitat hasn't taken advantage of them yet (or sensors). Hubitat's fans are implemented as Google switches or Google dimmers. If I take switch level off of this driver they just show up as a on/off switch instead of a dimmer which is pretty horrible.
Until the Hubitat side is updated correctly I've put switch level in this driver on purpose so that you can at least control fan speed like a dimmer from Google by saying "Set the [blah fan device] to [blah] percent" instead of just a on/off switch. Super, super annoying but I'm hoping it will get worked out soon. It feels like a lot of them (the HE group) have Google integrations but don't rely on them so I don't think they've felt the pain yet. Feel free to let them know. The squeaky wheel often gets the oil.
In setLevel there was still the SmartThings way of adding delays between commands. I fixed it and also made some other small changes. The easiest way to update is from from the device driver using the "Import" button and then click the "Save" button
I enabled "Double-Tap Up sets to full speed" and double tap doesn't do anything (tried it with "Single-Tap Up sets to full speed" and it had no effect either). It registered the double tap as an event, but doesnt do anything. is there a trick i'm missing to enabling this?
No trick. It looks like it is just broken. I never used this functionality. I see there is a bug though. For one, Hubitat doesn't like SmartThing's way of creating single delay commands. For two, Hubitat doesn't like SmartThing's way of mixing Z-wave commands with events.
I will fix it eventually.
The workaround is to use Rule Machine or Button Controller to setup what would have happened in the driver though if either of those two worked. If you fix it please submit a PR.
I just picked some of these up and installed them leveraging this driver. All is generally well. I have an issue with not being able to turn them off with a single click however and the family has started to voice their complaints for the fans in their rooms.
Is there a way to single click down for off, regardless of what speed it is at? I have to click down multipe times depending on what speed the fan is at to get it to turn off. the functionality is so different from my other fan controllers/switches.
That is not how mine behaves. A single tap turns it on to the previous speed and a single tap turns it off. Since that behavior is not possible with the documented features here I would probably ask HomeSeer about it. Are they new? Did the model number or firmware change?
Does the controller respect and react to the other parameters that can be set?
Those are good questions. It responds well to the configurations within the driver (3 speed fan, light color). If I turn it on, it defaults to medium-low (33%)- as intended. I will increment up one time and it will go to Medium (66%). Tap down once brings it to 33%, and then tap down again brings it to off.
The events for the sequence above look like the following: tap up/7/on/medium-low, tap up/7/66/medium-high, tap-down/8/off/on/33/medium-low, tap-down/8/off (switch)/off (speed)
So I think it's turning the switch off and then back on to the stepped lower setting until the lowest setting is off. Firmware wise, it lists it as null.null.
I will try to reach out on Homeseer's site and see what they say. Was hoping that the driver could have an option to hard-code what a single press button 8 (single tap down) and a single press from button 7 would do from the off state (use last fan speed setting).
There does not appear to be any firmware updates for the switch on Homeseer's website. There is a user on their forums who mentioned the functionality that I have been experiencing but I'm not sure they understood the problem and responded differently than I would have expected (set a scene with multiple taps).
I just did some more testing. You're right about how it behaves from the switch and I apologize for missing it first. It does always increment up just one speed. From off it goes to 33%, then to 66%, then 100%, always just going one step. I guess that was masked by the fact that digitally if you turn it off and one (with a button controller) it always resumes to the last speed. So, no need to check with HomeSeer. I think that's how these are designed when they are interacted with physically. Digitally, they do behave the way I described and appear to resume to the last speed.
I also noticed that some of the double-tap, single-tap preferences in the driver aren't working. (These were also reported broken for the dimmer. I haven't gotten around to fixing them yet.)
So, for this I suggest we add another preference so that we have a single-tap resume preference potentially to go along with the single-tap off preference. And then I'll also fix them so they actually work.
Admittedly I don't use the physical buttons on my HomeSeer devices often or ever. There are wireless button controllers on the nightstands that set scenes.
Well, @thebells. I fiddled with this some tonight and I re-learned and remembered some of the reasons why this was setup the way it was. And we were both wrong sort of about how the switch behaves I think.
The way the firmware behaves without any motivation from the driver is:
Single-tap up: Previous level
Single-tap down: One step down (33% if 3 speed or 25% if 4 speed)
All other taps nothing except send event but no action performed
So when we are seeing the switch go up AND down one level is because the switch was last turned off physically and the last level was really the lowest. However, if you setLevel(99) from the driver and then off() from the driver. Then single-tap up it will resume to 99. If you hit single-tap down it will go to 66 or 75 depending on what speed type you have set. If you were to off it at that point it would resume to 66/75 with a single tap up again. It's weird.
So... because of this we don't need a single tap up behavior change. The one preference we have to set to full on single-tap is enough because the default behavior is to go to last level.
What we need is a preference to single-tap down... and unfortunately, we are not going to be able to do it. With single-tap up to full we know the target because full is 100 (really 99). But going down we don't because the target depends on where we are. Here is an example of what happens. Let's say the switch is at 75%.
Switch is on and level is 75
Single tap down (physical)
Firmware moves level to 50 internally
Firmware sends the tap event and level event nearly simultaneously but no guarantee which comes first at least as far as I could tell from my logs. There may be an order but the way that driver instances start up I was seeing them switch orders
From the level event I don't know if the tap event has come first and vice versa. I could put a bunch of logic in there to check but it would be error prone, complicated and not worth it. Since I don't know if the level has already moved or not I don't know what to save as the last level or what to return to since the internal level of the firmware will have been 50 but really in the software (driver) I need to tell it 75. But I wouldn't know if it was really 75 or 50 because I don't know when I look at the level if I'm seeing it set yet. I think that's what's happening anyway.
So, instead of messing around with that, I added more functionality to the double tap since it won't do anything to the level. I changed double tap down to have two options; one that goes to 25% as before and one that goes to off. I think that's the best we can do.
At this point it will be a small training exercise for your users. Single tap turns it on to previous level but to turn off they will have to learn to double-tap down.
What do you think? If we can't come up with anything better I'll push these changes once I get a question about the firmware not showing up correctly and another feature I want to implement.
@codahq, is it possible to create a single-tap-down preference that would send 3 or 4 tap downs? Essentially forcing it down and even if it's only 1, 2, 3, or 4 taps to get to off, any extra taps that aren't needed effectively do nothing. Just a thought.
Given the constraints at hand with the firmware, I appreciate (and I'm sure others will as well when they find this thread) you taking the time to dive in and understand the physical properties of the switch.
If I happen to get an encouraging response from Homeseer, I'll reply back as well.
I could do that but it doesn't address the problem. I can turn it off easily with one tap but depending on how we do that the level is going to be wrong for when we turn it back on. Turning it off by sending multiple level down commands still affects where the level of the switch is. So when we go to turn it back on instead of resuming to the last good level it either resumes to one level down (or the correct level if I add a bunch of logic and we guess correctly with the just-turn-it-off approach) or the lowest level (if I were just to send a bunch of level down events with the level-it-down-until-off approach).
Let's see if you hear anything back from HS about it.
Added preference to not let setStatusLed to manage switch mode. If not used carefully this can conflict with bottom status on when load off or the setStatusLed command. However, it lets a user hide load when no status LEDs are set
Fixed firmware reporting for new Hubitat command classes
Made manufacturer an int and added manufacturer name
