How to turn off KPL LED in DIM Scene?

[Scottmichaelj]

I am trying to figure out how to get the KPL LED to turn off if I dim to off on a lamplinc device.

 

Below is my code - I am using it with 4 IR buttons (on/Bright/Dim/off). When I use "Fade Up" the KPL led in the scene turns on - but when I dim the device to off the KPL LED stays on. The device shows off in the Admin console. What else do I need to add in the code to make the KPL led turn off if I dim it off? Thanks in advance for the help.

 

If

IR 'TV : Channel +' is Held

And IR 'TV : Channel +' is not Released

 

Then

Set Scene 'My Lighting' Fade Down

 

Else

Set Scene 'My Lighting' Fade Stop

[Michel Kohanim]

Hi huddadudda,

 

Unfortunately, this is a known issue: LED do not know anything about status except for on or off. What you might want to do is to create another scene, with just that KPL button as responder, and checks the status of your lamplinc and then turn the new scene off when the status is off.

 

With kind regards,

Michel

 

I am trying to figure out how to get the KPL LED to turn off if I dim to off on a lamplinc device.

 

Below is my code - I am using it with 4 IR buttons (on/Bright/Dim/off). When I use "Fade Up" the KPL led in the scene turns on - but when I dim the device to off the KPL LED stays on. The device shows off in the Admin console. What else do I need to add in the code to make the KPL led turn off if I dim it off? Thanks in advance for the help.

 

If

IR 'TV : Channel +' is Held

And IR 'TV : Channel +' is not Released

 

Then

Set Scene 'My Lighting' Fade Down

 

Else

Set Scene 'My Lighting' Fade Stop

[Scottmichaelj]

Hi huddadudda,

 

Unfortunately, this is a known issue: LED do not know anything about status except for on or off. What you might want to do is to create another scene, with just that KPL button as responder, and checks the status of your lamplinc and then turn the new scene off when the status is off.

 

With kind regards,

Michel

 

 

Could you give me an example of the code for that? How often should it check it? There is no other way? Any ETA of resolving this in the new firmware release or is it a bug in the actual smarthome kpl product not the ISY?

[Sub-Routine]

I think it will work if you add a couple of lines to your existing program...

 

If
IR 'TV : Channel +' is Held
And IR 'TV : Channel +' is not Released

Then
Set Scene 'My Lighting' Fade Down
Set 'My Light' Query

Else
Set Scene 'My Lighting' Fade Stop
Set 'My Light' Query

 

and another program:

If
Status 'My Light' is Off

Then
Set Scene 'My Button' Off

Else

 

Rand

[Scottmichaelj]

Thanks Sub those changes worked perfectly. Its too bad that you have to have a program run another program. Its getting to the point that you start forgetting what does what and the list of programs is growing and growing! Then a bug is fixed programs then stop working....ahh the joys of this stuff. Shows you how much we love to play and tinker I wonder still since no one said anything more but is this a KPL Smarthome Device bug or a bug in the ISY? Does anyone know?

[Sub-Routine]

I'm glad it works!

I think only the fade commands act this way.

 

There are a few quirks in Insteon. Good thing we have the ISY to help us out

[Brian H]

Even more fun. Sometimes the quirks vary depending on the firmware revision.

[khearn]

I think the problem is that the controller sends DIM commands to the group, and none of the devices besides the dimmer knows when the dimmer gets to 0%. All the KPL sees is a bunch of DIM commands, and it has no way of knowing whether the dimmers is at 20%, 10%, 1% or 0%, so how can it know when to turn off the LED?

 

In order for the KPL to know the dimmer is off, the dimmer would have to send out a message to the group when it gets a DIM which takes it down to 0% (and probably one would also want a message when a BRIGHT brings it to 100%). I don't think the Insteon protocol has any provision for that. So I don't think it's a bug in the Insteon device or the ISY. You could say it's a design flaw in the Insteon protocol, but it'd be a pretty difficult one to fix.

 

The problem is the way group commands are acknowledged, or rather, the way they aren't acknowledged. Forgive me if you undertsand this already, but in case readers don't know how group commands work, here is a description.

 

Let's say we have three devices, a controller 01.01.01, a dimmer 02.02.02 and a KPL 03.03.03 (we'll ignore that the KPL has individual buttons to keep things simple).They are all in 01.01.01's group 1.

If the controller sends an ON to the group it sends out a broadcast:

01.01.01 -> ALL : Group 1 ON

With luck, both 02.02.02 and 03.03.03 receive it and turn on. But neither replies, because they'd step on each other and neither response would get through. Instead, the controller sends out cleanup messages to each device in the group, and each devices replies to its cleanup

01.01.01 -> 02.02.02: Group cleanup 1

02.02.02 -> 01.01.01: Group cleanup ACK (for Acknowledge)

01.01.01 -> 03.03.03: Group cleanup 1

03.03.03 -> 01.01.01: Group cleanup ACK

 

With good luck, all of the responders react immediately with no delays between each light. But if one or more responders didn't hear the initial group message, the cleanups should reach it because if the controller doesn't get an ACK from a cleanup message, it will send a series of retries with higher maximum jump numbers (it shouts louder each time) until it gets through or eventually decides that responder is dead and gives up. So if a responder misses the first group command, it will still come on, just a bit late.

 

On thing to note though, is that the group cleanups are low priority, and if some other normal Insteon command comes across the line, the cleanups will be aborted.

 

This works nicely for ON or OFF commands. But things like DIM and BRIGHT tend to get repeated as long as the button is being held. I'm not sure exactly what the timing is, but I'm pretty sure there isn't time for many of the cleanup messages before the next DIM gets sent out. There may not be time for any cleanups. So the dimmer doesn't get a chance to send a response back to the controller until the button is released and the final DIM command is sent. At that point the dimmer could let the controller know what on level it is at, so the controller could know the final state. But the dimmer never sends anything out that the other responder (the KPL) would hear. The group cleanup ACK isn't addressed to any device bu the controller, so the KPL won't even notice it.

 

So there is never any way for the KPL to know if or when the dimmer got to 0% during or after a series of DIM commands. And it would take a significant rewrite of the way Insteon does group commands to make it possible. You'd have to make each responding device send a broadcast to the entire group with its final status after a series of DIM or BRIGHT commands. And remember, you might have several dimmers in the group, and you don't want them all sending at the same time. Basically, you'd have to make the group cleanup ACK go to the whole group instead of just the controller.

 

Even then, it wouldn't be reliable, because the dimmer wouldn't know if everyone in the group got the broadcast, so it wouldn't know if it needed to retry. You'd have to have each responder send a "group cleanup cleanup" to each device in the group to make sure they all heard the "group cleanup ACK". But at the same time, the controller is trying to send out the rest of its cleanups to the other members of the group to make sure they all got the original command.

 

Keith

[Scottmichaelj]

The brighten command works fine for me and will turn on the KPL Led button when going from an off state to say 25% - its just the Dim to off that I need a program to run as a query to turn off the KPL Led, which I think is strange.

[ulrick65]

The brighten command works fine for me and will turn on the KPL Led button when going from an off state to say 25% - its just the Dim to off that I need a program to run as a query to turn off the KPL Led, which I think is strange.

 

It's not really strange if you consider how it's working: Anything higher than 0% is ON to the KPL so issuing a Brighten command must mean the light is either ON or turning ON and the LED will come on (the LED does not respond to brightness levels, just on and off). So as you brighten it, it will be on each and everytime and when you get 100% it is still on so it appears to be "in sync" even though it really does not know you are at 100%. However, as you DIM the only thing the KPL knows is that you are dimming...when you get to 0% it has no way of knowing that (it never saw an off command) so it is still ON...which is NOT "in sync" any longer.

 

As Keith said, this is not a bug really...perhaps maybe a flaw in the design of the KPL.