Command Retry timing w/slow Transition set?

🧰 Built-In Apps and Drivers Built-in Apps
1

This might be an inconsequential edge case, but I have a dimmer (Fibaro RGBWW LED ZW controller named "Cabinet Lights") mirroring another dimmer ("Kitchen Light") via Mirror app, with Command Retry enabled plus a transition time of 5s.
Everything works fine, but Logs report appreciably longer delays in the chain of events following this ON command:

image
image2175×667 120 KB

which has me wondering why it consistently takes until "Retry: 4" (a span of 19 seconds!) for the slave dimmer to report "On".

Reference:

Am I naive to expect (a) the slave dimmer should take only "5 seconds" to reach its target brightness and report "On" after an "On" command (for comparison, "Bar Lights" is set to "2s" and seems to honor that), or (b) Command Retry could lengthen the gap between retries for devices with longer "Transition times" set?

In brief, everything's working fine here, and the Fibaro has always ramped slowly (perhaps there's a hidden parameter I need to check). But I can't help wondering if Command Retry is ignoring the device's "Transition" setting.

2

command retry will add the transition time submitted to the initial default retry for dimmers, which is 1.5 seconds if memory serves.

1 Like
3

Okay. I had gauged from your earlier note that it was only adding fadeTime if that parameter was issued with a Dim/SetLevel command. But not with an On as in my example. That leaves me wondering why 19 seconds elapse before my slave device reports itself as On, satisfying Command Retry.

Must just be an oddity in how Fibaro RGBWW controllers perform. I may just turn off Command Retry in this instance, and see how things go.