Thanks, will try the script way first.
There is another interesting problem to solve here.
These controllers have direct association and scene association modes, per
When I used Vera, I’m pretty sure it configured them in direct association mode, because i was able to turn things on and off even when Vera was down, but LED propagation wouldn’t work in this case. When Vera was on, LED propagation would work, but with a noticeable delay – clearly through some logic in Vera.
The question is, if Vera configured direct associations, how did it know when rockers were pressed?
I enabled debug logging and all I can see when I press rockers is this event, which always carries the same payload, so clearly it’s not telling me specifically which rocker and which side was pressed:
2024-05-16T07:06:37.496Z SERIAL « 0x0115004984050f020100852d7c778273867291ef2b2cf1 (23 bytes)
2024-05-16T07:06:37.498Z SERIAL » [ACK] (0x06)
2024-05-16T07:06:37.500Z DRIVER « [Node 005] [REQ] [ApplicationUpdateRequest] payload: 0x050f020100852d7c778273867291ef2b2c
2024-05-16T07:06:37.501Z CNTRLR « [Node 005] Received updated node info
2024-05-16T07:06:37.502Z CNTRLR [Node 005] Node does not send unsolicited updates; refreshing actuator and sensor values...
I guess I could create an automation that listens to this event. Upon receiving it refreshes all switches and updates LEDs on all rockers with direct association to those switches.
The thing that’s blocking me now, is how to listen to this event. What would be the trigger parameters based on the above event data?