Lutron ceseta question?

This is not really a problem (except for when guests visit). I’m just curious if anyone else has a solution to this.
I have a bunch of lutron caseta pico remotes installed throughout my house, I have a lutron caseta pro hub. And I have some lutron caseta dimmers.

Whenever I create a rule for one of the buttons on the pico remotes to do anything, the reaction is immediate. Except, if i want the button to control another lutron caseta device, such as one of the dimmers(for those its like a 1-2 sec delay). I’m just curious if there is a way to fix this, mainly because guests find it confusing.
I have run multiple setups one with an old laptop running ubuntu, and on rpi2 and 3, as well as some other machines and this has symptom has always been present. Anyway I guess Im just seeking confirmation that this is a thing, I don’t really expect a solution.

So whenever som

Hi. I have a RA2 system myself, but I don’t believe there should be a noticeable delay when you send a command to any Lutron dimmer. Do you see a similar delay if you send a command to the dimmer using Paper UI or HABPanel, as opposed to using a rule triggered by a keypad button?

You may want to check the setting of the fadeInTime parameter on the dimmer things. I think it defaults to 1 second. If you have a type of bulb (e.g. some LED or CFL) that doesn’t ramp up smoothly, you may see some or all of that fade time as a delay. In that case, try setting fadeInTime=0.

I’m also on a Radio RA2 system. Currently I have been testing the main repeater in a rental house until our new home is completed. Among other things, I have programmed buttons on a Pico remote that trigger various rules, which in turn actuate some Z-Wave and ZigBee lights here. There is no noticeable delay from the time I press a button on the Pico remote until the affected devices change state. I have also written other rules that are triggered by button events for some RR2 keypads and dimmers. I have observed no noticeable delays with any of these devices.

I too was concerned about possible delays when my system is programmed this way, so I increased the log level for the lutron binding and compared time stamps for the original button press and the timestamps from when the programmed commands were issued. I found that there were no significant delays.

Thanks for the response, if I send a command to a dimmer from any rule, or habpannel, or paperui, it reacts instantly, the ramp is fine when I press a button on the switch itself and all my bulbs are dimmable leds and they work fine throughout the entire ramp.
I only see a delay when using the pico remote to trigger a rule to turn on or off the light.

I just checked and in my thing I have set a 2 sec delay for fade in and out, but if i try to change it, I click save and get error 409: conflict. not sure whats causing this.

edit: I was able to change the on and off fade times to 0 through the eclipse smarthome designer, unfortunately there is still a delay when triggering from the pico remote.
edit2: I changed to rule to send command ON rather than send command 100 and now reaction is instant, don’t know what this would make a difference

Huh. That’s really weird, but you can’t argue with success. :slight_smile:
I’ll take a look at the code and see if I can figure out why that might happen.

1 Like

Hi. I know it’s been a month, but I did take a look at the code for this a while back, and the only difference SHOULD be that when you send a 100 (or any number) to the dimmer’s lightlevel channel it uses a hard-coded fade time of 0.25 seconds, but when you send an ON command it uses the fade time specified by the fadeInTime parameter.

However, the code builds the integration commands that are sent in slightly different ways, so it is possible that something else weird is going on. If you have a chance, try enabling debug logging for the Lutron binding. Then try sending an ON command and a 100 command. In the log, you should see a debug message line from IPBridgeHandler that starts with “Sending command” and shows the integration command generated for each dimmer command you send. I’d be interested to see how the generated commands differ between ON and 100 in your environment.

Hey sorry it’s been a while… I’d love to show you my logs, how exactly do I enable debug logging for lutron? Sorry I just can’t seem figure it out.

Well, there are several ways to go about it. You can enable debug logging for org.openhab.binding.lutron from the console as described here. Or you can edit the org.ops4j.pax.logging.cfg file, which on my Linux system installed with apt is in /var/lib/openhab2/etc.

Since I’m often testing changes to the binding, I’ve added the following entries to my org.ops4j.pax.logging.cfg file so that messages from org.openhab.binding.lutron are logged at TRACE level to a separate log file:

# Logging configuration for debugging Lutron binding
log4j2.logger.org_openhab_binding_lutron.level = TRACE
log4j2.logger.org_openhab_binding_lutron.name = org.openhab.binding.lutron
log4j2.logger.org_openhab_binding_lutron.additivity = false
log4j2.logger.org_openhab_binding_lutron.appenderRefs = lutronlog
log4j2.logger.org_openhab_binding_lutron.appenderRef.lutronlog.ref = LUTRONLOGFILE

# Lutron binding Rolling file appender
log4j2.appender.lutronlog.type = RollingRandomAccessFile
log4j2.appender.lutronlog.name = LUTRONLOGFILE
log4j2.appender.lutronlog.fileName = ${openhab.logdir}/lutron.log
log4j2.appender.lutronlog.filePattern = ${openhab.logdir}/lutron.log.%i
log4j2.appender.lutronlog.immediateFlush = true
log4j2.appender.lutronlog.append = true
log4j2.appender.lutronlog.layout.type = PatternLayout
log4j2.appender.lutronlog.layout.pattern = %d{yyyy-MM-dd HH:mm:ss.SSS} [%-5.5p] [%-36.36c] - %m%n
log4j2.appender.lutronlog.policies.type = Policies
log4j2.appender.lutronlog.policies.size.type = SizeBasedTriggeringPolicy
log4j2.appender.lutronlog.policies.size.size = 16MB

For most people I wouldn’t recommend leaving it like that long-term, though, as it will generate a considerable number of log messages.