Dimmer items support ON/OFF commands. No need for an additional Switch item linked to the same channel.
Yeah, understood, I did it this way so I didn’t have to go edit my sitemap that has both of these controls and also edit some rules for the same reason.
Anyway, I removed the switch item and rebooted my RPI and I’m still seeing the same behavior as previously described. Sometimes the LED will come back on but takes a few seconds, sometimes it doesn’t come on at all.
I dug into this a bit more and it seems that if I start with the LED ON, switch to OFF, wait about 3 seconds and command ON, the switch bounces from ON back to OFF and the LED never turns on (debug log of this happening here: 14:02:47.361 [DEBUG] [internal.handler.InsteonDeviceHandler] - channel insteon:d - Pastebin.com). If I wait a bit longer like 10 seconds and commend to ON, the led goes to ON.
Not sure this matters much in real life use cases as you are probably unlikely to want to turn on/off in 3 seconds but I’m not sure.
I’m not sure if I know where to look for the release notes, I saw the code change you made, but I’m not sure how to set my configuration for this.
I was referring to the notes in the (beta) release I linked above.
If you are setting the new things in MainUI, you can click on “Configure Channel” and you should see the new parameter I added.
1 Like
Got it. Thanks.
Thank you again for all of your help getting me up and running. Greatly appreciate the new binding all of of your efforts here. Since you weren’t able to replicate the part of my problem with physical presses not being detected on legacy devices, I moved on and have migrated my system to having all of the devices setup as the new things types and marked this thread as solved with your fix that included handling my old .things file.
1 Like
So the issue here is that the state of the led on/off isn’t changing internally until the binding poll its latest state. So when you sent the ON command 3 seconds later, the binding still considered the on/off state as on, even though an off command was sent a second before since the poll request was still in queue, skipping the need to send a command to turn it on. I think I will update the logic to always send the led on/off command regardless of the current state. Thanks for reporting this one.
1 Like
I included the change in the stack overflow fix PR. I uploaded on the same (beta) release a new build including this change.
1 Like
I downloaded and put this into my system. This seems to have solved the issue!
1 Like