Advanced Button Controller (ABC)

The Lutron Integration was primarily for Caseta devices and the pro hub. He might have been using a workaround but I got the impression he was using a built in ramp feature. In any case, the Hubitat engineers have managed to accomplish this seemlessly. If itā€™s with a hack, itā€™s transparent to me and would love to have access to a parameter that taps their fade functionality.

From Lutron forum talking about Caseta devices (not an official response but might be a clue)

Any app or system that uses the 3rd party integration (i.e. telnet) has the ability to set the fade rates when they activate a light. So, it should be possible to Lutron to add the ability to set the fade rate when using their app. However, I don't know whether it's possible to change how the switch behaves when you press a button. If it is, that would be fantastic .

Thatā€™s actually awesome news! If thatā€™s the case, thereā€™s probably a Capability already created for dimming ramp time, and itā€™d just be a matter of finding out what. After some research, Lutron REALLY REALLY doesnā€™t want to expose the communication methods to the smartbridge pro because it could eat into their more expensive RA2 offerings.

1 Like

As @bravenel replied in another post

Sounds like it's not going to work for CasƩta dimmers.

Maybe I just donā€™t get the difference between ramp rates and fadeā€¦but on the device page for my dimmers I can set the level to dim and the speed at which they dim e.g. dim to 20 and take 20 seconds to get there. Is that not what fade means?

Confirmed what stephack is saying. Using the ā€œsetLevelā€ command on my dimmer device page, I can put in a dim-to value and a time in seconds value, and it slowly dims to that value, as expected. This is with Lutron Caseta dimmer.

I get the following message in the log:

[dev:43](http://192.168.2.3/logs#dev43)2018-03-13 20:17:20.221:inforcvd: OUTPUT,9,1,0.00

[dev:42](http://192.168.2.3/logs#dev42)2018-03-13 20:17:20.210:infoKitchen Lights was set to 0.0% with a duration of 30
1 Like

Yes, to me itā€™s just a different term for the same this, unless Iā€™m wrong about that. I started with Insteon and so I know it as Ramp Rate, but Hubitat calls it Fade. So it is.

1 Like

Nice! Well that says you can define that in RM then correct? And so if you can do it there, you can do it in an app too right? Iā€™m enamored with the fade function. Up to now, Iā€™ve hated watching my lights that werenā€™t Insteon or Hue just shut off abruptly. So uncivilized! :wink:

From smartthings documentation:

Commands

setLevel(level, rate)

Set the level to the given values

Arguments:

  • level
    • Type: NUMBER
    • Required: Yes
    • Description: The level value, usually 0-100 in percent
  • rate
    • Type: NUMBER
    • Required: No
    • Description: The rate at which to dim or illuminate the light
1 Like

The lights that have been the ugliest turning on and off are the Sengled Element Plus. They're handy bulbs, since you can dim them with a regular dimmer. My wife appreciates that, and likes that we can color tune them, but they don't react all that smoothly via Zigbee vs, using the wall dimmer. So it's been nice to have the improved control over them. What would be great to eventually see is, White Color Temperature Drivers that could simulate incandescent by automatically adjusting the color temp warmer as the bulbs dim and cooler as they brighten, the way this ST DH for TrƄdfri does. I've been tweaking RM to get these to react as best I'm able, and this is what I've come up with to give a smoother appearance as the Sengled Element Plus turn ON and OFF.

Update app to v0.2.180328
You can now set the color temperature,
and set the color using hue and saturation.

It seem like Hubitat changed the way setting colors work a bit. I canā€™t say for sure how it differs (without documentation) but I ended up adjusting my Lifx dth to match how it worked with the Hue bulbs.

NOTE: I have ONLY tested with Hue and Lifx. I donā€™t know if this will work with any other light types.

1 Like

Does ABC support multiple button presses? So lets say I push button 1 to turn on the lights and then push it again to change the mode.

I donā€™t understand. Are you referring to double taps? If so, then yes , it can process double tapsā€¦but only if the button device actually supports it.

I am using this with a hue dimmer switch. When it's paired directly to the hue bridge, I can cycle through various scenes by pushing the button multiple times. I was hoping the app would allow me to do something similar. Example:
(Button 1 push 1) Dimmer set to 50%
(Button 1 push 2) Mode set to Away
(Button 1 push 3) Room 2 lights on
etc.....

Unfortunately itā€™s not THAT advanced.

In ST I had a custom app that allowed me to do something similar. I called it a Virtual Container that spawned child Momentary devices as components. I tied each child to a scene/routine and made a custom option in ABC to ā€œcycleā€ through each momentary. One use case was for various radio stations on my Sonos. I never shared it because it was too difficult to explain how to use.

If HE ever allows component child devices, I may port and share.

1 Like

Looked like this. The thing page was never cluttered with a bunch of virtual devices. All kept in one container.

2 Likes

Stephan- I apologize for a very basic question, but Iā€™ve toyed with using ABC with your MR101Z controller and i canā€™t get it working the way I want. Would you give me some simple tips on how to deploy this?

Iā€™m flexible on the methodology. Iā€™d be happy with Buttons 1-4 setting speeds 1-4; or each push of button #1 steps up the speed ladder; or any suggested way you might give me. Thanks for your help.

Yeahā€¦right now Hubitat isnā€™t friendly to these types of devices. Thatā€™s why I went down the Component road in ST to avoid these little pains. Right now the ABC canā€™t directly control each Fan speed because I donā€™t know the code to access custom commands in devices. I asked for guidance but it doesnā€™t look like the secret will be revealed any time soon :).

If all you want to do is control your fan with one controller there is an ā€œeasyā€ option.

Easy option:

  • using the built in Button Controller App, create the custom commands fanSpeed1, fanSpeed2, etc and fanOff.
  • You should now have access to map a button to each custom command using the built in BC app.

Not so easy but more flexible option (allows Alexa control):

  • manually create virtual switch for each speed.
  • use RM and create a rule for each speed to sync on/off with fanSpeed1/fanOff
  • use switches in ABC or other control app as normal

Wait and see option:

  • wait till HE allows component devices OR I get fed up with the existing fan control options and create a smartApp that simplifies this a bitā€¦whichever cones first.
1 Like

When I have some extra time, Iā€™m also going to look at @ericm Virtual Sync smartApp and see how I can adapt it for something like these controllers. His app is for Zwave devices with multiple endpoints but hopefully I can take his theory and adapt it to our zigbee controller.

1 Like

Iā€™ll go with Door B, two fans Ɨ 5 states = 10 switches. Iā€™m in the camp that doesnā€™t like to mess up the Device List with dozens of virtual switches, but Iā€™m coming to the conclusion that is the way it is with HE.

Meanwhileā€¦ ā€œWait and Seeā€ option now activated.