Homeseer 200 Dimmer doubletap

This is correct. DoubleTap is so new that we haven't gotten to updating apps to make use of it yet. It's on our list to get to.

You could write a little app to map doubleTap events into some other event to use with RM or BC in the meantime. Not an ideal solution, but it could be made to work.

Next release will support doubleTap in RM.

Thanks for your quick reply. Understandable. Looks like we are half way there! I have never written in groovy before but may give it a try. What are you guys using as your groovy IDE? I have Visual Studio Pro 2017, but don't know enough about groovy to know if VS is a good fit.

I use the built in editor, as does all the staff when writing drivers and apps. There really isn't a need for anything else, it will just slow you down...

Good to know. Thanks Mike

I assume this is refering to the default driver in Hubitat? not a custom loaded one?
Things missing:
Status LED color changes,
3,4,5 tap of buttons.

or is there an updated driver?

I added doubleTap support to my Button Controller app when I migrated to Hubitat from ST. Give it a shot.

The Homeseer 200 driver built into Hubitat. Unfortunately I don't believe Hubitat has any plans to support over double tap. Personally I never used the 4 and 5 tap, but I did use triple tap before moving to HE. I can confirm that double tap now works in rule machine after the last update.

Yes, double works...

I hope they support full scene like every other major hub at some point (particularly since they can just modify the ST device handlers), or I just wasted money on this potentially great hub :frowning:

What about control of the LEDs?

Thanks!

There is a toggle to enable LED control via setStatusLED command. It takes 3 parameters. Color and blink default to off and solid if not supplied.

LEDs will be used to display dimmer level, unless LEDs are being used to display a status. They switch back and forth automatically.

setStatusLED(led, color=“0”, blink=“0”)

LED: 1-7
0 = All Off
8 = All with parameters.

Color: (word or number)
"off": "0",
"red": "1",
"green": "2",
"blue": "3",
"magenta": "4",
"yellow": "5",
"cyan": "6",
"white": "7"

Blink: (word or number)
"solid": "0",
"no": "0",
"false": "0",
"blink": "1",
"blinking": "1",
"yes": "1",
"true": "1"

I have these commands setup as a custom command in rule machine.

2 Likes

Corey, could you share custom status LED command you created in RM. I would like to do this but I haven't had any luck getting it to work.

Looks like it has been many months since this issue with doubletap. I see it is there now but what about 3,4, and 5 tap and LED change for these 200 series switches?

Double tap has been supported on the Central Scene and the 200+ specific switches and dimmers since the inception of the driver I believe.

If I remember right, the HE teams has said they don't intend to support anything more than double tap.

Thanks. Any idea the reason for such a ridiculous stance? Most switches out there support more than double tap, usually up to 5 taps. Why limit the platform in such a manner?

I don't recall any specifics given.

Most switches do NOT support more than double tap (or even double tap at all)... I guarantee you that I can point out a dozen that don't before you can point out a dozen that do.

In any case, you can install a user driver any time you want if you need more than base functionality.

Every homeseer and every inovelli switch in my house support more than double tap. Older tech like the ge ones probably don't. But my point still stands. Why is hubitat limiting their support in such a ridiculous manner? In smartthings I was using rules on up to 4 taps on most of my switches. I want hubitat to be better than Smartthings.

So exactly TWO manufacturers out of many DOZENS...

As far as support / enhancing the driver, you already know the answer to the question, but I'll point it out just for completeness.

The Hubitat team is a small fraction of the size of the SmartThings team, and they have dozens and dozens of devices to support/make sure work. Thus they simply do not have time to put every single feature in every single in-box driver. They go for the best balance of features versus needs.

They very well may add the support to the in-box driver at some point, but I would expect it is about number 950 on the to-do list

You're portraying them as wanting to intentionally limit functionality (at least that is how I read it), when that isn't the case - it is a resourcing issue.

If your needs are different and more advanced, then you can use a user driver. That really isn't that big of a chore/sacrifice.

1 Like

I'd love for the team to open up their driver implementation so the community COULD extend it rather than starting from scratch. But as we know, that's not going to happen.

I agree, I'd rather see them focus on stability and extension. We can worry about tripple+ tap later.

100% agree with that!!! It would be wonderful to add just 1-2 features here and there off of a known good code base.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.