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.
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
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.
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!
From smartthings documentation:
Set the level to the given values
- Type: NUMBER
- Required: Yes
- Description: The level value, usually
- Type: NUMBER
- Required: No
- Description: The rate at which to dim or illuminate the light
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.
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
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.
Looked like this. The thing page was never cluttered with a bunch of virtual devices. All kept in one container.
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.
- 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.
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.
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.