OK – I’ve just committed a redesign of the dimming logic which vastly improves its performance.
I’ve reverted from recursion back to looping, but also broke the logic apart so that an entry method takes the current levels of all devices on the last button switched, and then passes the particulars (that button device, its starting levels, and the directional increment) into a separate looping method, which (now) just increments iteratively upon its own starting value (rather than trying to re-read the actual device level on each loop).
This eliminates the timing issues (and erratic lags) in trying to read (and then rewrite) the level on every loop, and has the added benefit of “locking” the ramp for the duration of the button-press (even if some other controller is simultaneously trying to alter its level).
It still needs an empty (inner) loop just to slow the iterations – otherwise, the device either doesn’t track the ramp (maybe because it can’t respond to so many level changes so quickly?) or it buffers up too many level changes before it can respond to a change in the atomicState flag (and thus “overruns” the ramp when you let go of the dimmer button).
As it stands now, it seems very reliable/consistent, and fairly accurate on starting/stopping dimming – certainly usably responsive, at least (if a little slower on the ramp than I might otherwise like). I still have it incrementing (or decrementing) by only 1 (out of 0 to 100) on each loop; I might experiment with larger increments while also further slowing the inner loop, which should make it more responsive (but possibly less “smooth” looking?)
.
P.S.: Now further improved, as described here