Open harryh opened 6 days ago
Hmm, that is rather strange. When I use the BP with a light group it does have a cascade effect instead of them all turning on in unison, but I haven't seen them bounce from on > off > on before.
When you look at the logbook for the specific light entity, does it say each change from on > off > on was triggered by the automation?
If so, I'll probably need you to send a log or screenshot of the Trace > Step Details > Step Config AND Changed Variables, for each trace in the sequence. Sorry that's a ton of data to request but I don't know another way to figure thus out since I can't seem to reproduce it locally.
I have been considering changing the mode to single, but I don't think that will help here as each run of the automation is relatively instant.
I took a quick video so can see it happen: https://www.dropbox.com/scl/fi/ae3ygowopcr130i5gyp8x/lights.blink.mov?rlkey=4oq521k885ji5j14qffstx9io&st=bud1a9tt&dl=0
When I look at the logbook for a single light I'm, weirdly, only seeing a single on event:
Kitchen Pendant 2 turned on triggered by automation Kitchen Pendants Sync 2 triggered by state of Kitchen Pendants Light (1) 10:51:25 AM
"Kitchen Pendants Sync 2" is the name of my automation "Kitchen Pendants Light (1)" is the entity name for the switch that is getting turned on by the automation from the Reverse Sync in the light binding.
Note that the log event above is coming 1 second after this one:
Kitchen Pendants turned on triggered by action Light: Turn on 10:51:24 AM
Maybe what's happening is 1) I turn on the light group which is causing an "on" to get sent to the individual light THEN 2) the automation sends an additional "on" to the light and that's why I'm getting this blinking behavior?
When I turn on the light group the automation is being executed 4 times. I'll grab all the traces for you.
Great timing on sending this--just sat down with my laptop and a cup of coffee.
Could you go to Settings > Devices & Services > Matter > Kitchen Pendants Light and send a screenshot of your Configuration for the Inovelli Switch?
"On transition time" should be set to 0 for optimal script performance, but I'm guessing you have set to >0.
Looking through the traces, in changed.variables.3.txt, an external source changed Kitchen Pendants Light (1) brightness from 255 to 0. Then, in changed.variables.4.txt, an external source changed Kitchen Pendants Light (1) brightness back to 255. My guess is that this is because the switch didn't immediately turn on to 255, it transitioned from 0 - 255 according to the On transition time.
Also, a comment I made on issue 7 may be helpful to you. I'll likely add this to the documentation in the next release.
All of my transition times were set to zero.
I also noticed the brightness changes. That's definitely a little weird, and I have no good explanation for it.
That is a good suggestion about targeting the switch first. That might hide the issue for me. I'll give it a try.
Though the reason that I have an entity for the light group rather than the switch in my dashboard is so I have easy access to color changing in the dashboard. I'll lose that if I change it to the switch,
My best guess is there's a bug with the switch itself. One thing you could try is setting both the On transition time and On/off transition time to a value >0, wait 10 seconds and then set it back to 0. I think Inovelli is close to updating the firmware soon as well, so perhaps that helps.
Thanks for the feedback on color changes, I had not thought of that limitation. Initially I didn't think there was a way to reverse sync brightness changes, but the more I think about it, it should be possible. I'll see if I can add that in the next release.
1) Ya, does seem like a bug in the firmware. I'll look into that. 2) I don't think this bug is the cause of the issue I'm seeing though. The subsequent runs of the automation aren't turning the lights off or on.
In the video the lights go from Off > On > Off > On, and I believe those three state changes match up to trace 1, 3 and 4, respectively.
At least that's my understanding of it. What's do you think is happening?
I think the reason you only see one entry in the logbook is because the logbook doesn't report brightness changes, and according to the changed variables in trace 3, it's technically not turning the light off but instead setting the brightness to 0 (which in itself is very odd, as I don't think 0 brightness is a valid value). Perhaps a condition to ignore changes to 0% brightness would be helpful here--I'll look into that as well.
Ah, OK. I didn't realize that the logbook doesn't report brightness changes. That's annoying. Let me see if I can do some more debugging and see if I can confirm your suspicion. It does make sense though given what we're seeing.
https://github.com/jay-kub/inovelli-matter-switch-tap-sequences/blob/416a0405c9c8d619e20e4bd2e8ed96b7faefc874/inovelli-matter-switch-tap-sequences.yaml#L281
I'm wondering if this should be mode: single instead of mode: queued.
I have a switch bound to a light group with 3 lights in it. When I turn the switch on in the home assistant interface I get some weird bouncing behavior with lights turning on and off and then back on due to multiple executions of the automation. I end up in a correct end state, but it's a weird transition.
I can step through the logs to get full debug data if that would be helpful.