I have a bunch of 2477D dimmers, 2477S switches and 2334-232 Keypads that I turn on/off their LEDs. Moving to the new OH binding and migrating these from legacy to new devices and I’m noticing none of these are listing the led-on-off channel. Is there a way for me to add this channel to my devices or does this need to be a code change to the binding code?
For any device that supports led brightness, the led on/off capability is part of the led-brightness
channel. You can send ON/OFF commands to that channel and the binding will send the appropriate commands to your device. Keep in mind that the ON command would also set the brightness at 100%. Likewise, in term of percentage, 0% is considered OFF and anything above as ON.
Thanks again for the reply on this.
So I connected both my LED brightness dimmer and my LED on-off switch to the same channel as I believe you are suggesting:
Dimmer computerRoomLED "Computer Room LED [%d]" <heating> (gLEDs, gDimmerLEDs) {channel="insteon:device:71b4fc0fe7:3df7a1:led-brightness"} //{insteonplm="3D.F7.A1:F00.00.01#ledbrightness"}
Switch computerRoomLEDOnOff "Computer Room LED" {channel="insteon:device:71b4fc0fe7:3df7a1:led-brightness"} //{insteonplm="3D.F7.A1:F00.00.01#ledonoff"}
My LED was previously set on the example device at 11%. My switch happened to be in the off position to start to I commended it to ON and as you predicted the LED went to 100%. I then tried to command it to OFF and I got the following in my log:
So it seems there may be an error on the thing handler.
Question for you on the behavior you mentioned on commanding percentage:
As you likely know setting the LED to 0% doesn’t normally actually turn the LED off, it just makes it as dim as it can go, but it is not off and you can easily see it at night. So are you saying that if I send a 0% command to the binding the binding actually sends the LED OFF command?
From Insteon Terminal:
def setLEDBLOff(self):
"""setLEDBLOff()
This sets the LED Backlight off"""
self.querier.setMsgHandler(DefaultMsgHandler("Set LED Backlight OFF"))
return self.querier.queryext(0x20, 0x08, [0x00, 0x00, 0x00]);
Update, I can command the dimmer to different brightnesses and they all work fine until I command to 0 and I get the same error as above when I tried to command to OFF.
Thanks for reporting this issue. I can confirm this is a bug and am able to replicate. I will submit a fix to be included in 4.3.1.
The stack overflow error only happens when the on/off state of the led needs to be changed. So if it is currently on and you send any commands other than 0 or OFF, the bug won’t be triggered. Same issue vice versa.
Correct. This channel basically controls the led on/off op flag and led brightness extended property.
If you look at the code closely, the led on/off is actually defined as a hidden feature on these devices that the led brightness feature is controlling when handling command requests.
The bug is actually from the fact that instead of sending the on/off command to the hidden feature, it is sent to itself which caused an infinite loop. This was probably caused when I did some refactoring around the feature handlers.
Thanks @jeshab appreciate this!
Just a quick follow up question on this: you mentioned that to go from off to on, the LED will go to full brightness. I have some rules that turn off a few LEDs in my bedroom as they are too bright for me at night and in the AM turn them back on. Also my LEDs are typically set kind of dim at about 11. I use the currently available on/off functions that don’t change the brightness property so I turn off at night and back on in the morning. To do this now, I think I can still command to OFF at night, but will I need to command ON and then set the brightness to my desired level, or will just commanding a new brightness level > 0 make it some on to the desired level?
Send OFF at night and 11 in the morning. The channel implementation will handle the commands to send to your device accordingly.
It might make sense to add some words in the docs to describe this behavior since it is pretty different than the previous binding.
I’m happy to try out your fix when you get it in place and a have a .jar built that I can drop in!