Two LZW31-SN in three-way using associations - LED sync

[mamber]

@PJF

If you read what I posted, it is clearly an association issue.

Not necessarily. I did read what you posted and based on your symptoms, it still could be an issue with with parameters 1 and 3 swapped in an outdated device handler.

BTW, all my associations are working with proper LED sync and matching dim/ramp rates (after the device handler was fixed regarding params 1 and 3)

Associated devices use zwave commands to communicate with each other and, as you know, zwave dim/ramp rates can be set differently than local dim/ramp rates. Its perfectly understandable that local dimming/ramping works differently than zwave command/association since there are different settings for each.

You stated that you have local and zwave ramp set the same, but that is assuming parameters 1 and 3 are not swapped in the device handler. Your symptoms sound A LOT like the issue I documented in this post from last year:

Dimming Speed and Ramp Rate (Parameter1 and Parameter3) are swapped - FIXED IN 2020-08-12 DRIVER

I found what I believe to be a bug with Ramp Rate/Dimming parameters in the Red Series Dimmer (probably also for the Black dimmer but I don’t have any of those to check) After extensive trial-and-error I have discovered that Parameter1 and Parameter3 seem to be swapped. In other words, Param1 description says it controls the “Dimming Speed” used with zwave dimming up or down. But what it actually controls is the “Ramp Rate” which is used with zwave ON or OFF. Likewise, Param3 description sa…

Consider your scenario IF parameters 1 and 3 were swapped. Local controls (params 2 and 4) work as expected (which you have confirmed) but zwave commands (and associations) dim/ramp opposite of expected (params 1 and 3 swapped)

You have parameter 1 (zwave dim rate) set to 3 and parameter 3 (zwave ramp rate) set to 0. When 1 and 3 are swapped in the device handler (the issue I documented last year) then what you get is zwave dim rate of 0 and zwave ramp rate of 3 - which sounds like what you are seeing.

What you are describing matches what I saw in the older ST and HE drivers and was fixed initially by me hacking my own driver and eventually fixed in updated ST and HE drivers from Inovelli. Unfortunately, I don’t know anything about HA device handlers and it appears Inovelli does not supply them (supplied by community open source I presume? ) So its certainly plausible that whatever HA driver you have is based on the older ST/HE handlers which had 1 and 3 swapped.

I understand you are convinced this is a different problem, but your symptoms match what I dealt with a year ago. Its not hard to try/test what I am suggesting. Prove me wrong and try swapping the values for parameters 1 and 3 and report back the results