Weird interaction when setting up exclusive button group?

[andrew67]

Once again, I am re-programming my kitchen after my flood and rebuild.  My system has about 100 Insteon devices, and generally works fine. 

The new Kitchen has some different lighting in it though, so I need to change the programming.  Its been a few years though, and I forgot all of the f***ed up decisions and limitations of Insteon, so once again relatively simple things are working in weird ways.  Maybe one of you can help.

 

I have 3 keypads and 3 paddles, one each at the 3 entrances.  None of the keypads have any physical load connected, the main lights will be Hue running off of a Polisy, but I have not even tried to get to that yet....

I'd like the ON, A, and B buttons to be in a "mutually exclusive group" on all 3 keypads, and lets just say for the moment that we wanted 100%, 50% , and 33% on my counter and island lights to be all that they control.  The counter and island lights are each wired to one of the paddles.  The third paddle is for a chandelier which isn't installed yet, and we are not worried about yet.

Obviously we want the buttons to activate each respective scene.  I don't care much if they stay lit or not when that happens, but it makes most sense if only max of 1 stays lit, i.e. the last one, or none stay lit.

SO I programmed up the scenes, added all of the devices and buttons to each scene, factory reset all of the devices, and wrote all the links.  (Took almost 5 hours, which is insane, but thats a different set of posts that I have written before)

Each scene has both paddles, and all 3 buttons from all three keypads as responders, except obviously that one I want to trigger that scene is a controller...  In other words I setup this:

 

 

Now for the Weirdness....

Regardless of which button I push, every button lights up and the lights go to 100%.

In the past I used to use mutually exclusive button groups, and Non-Toggles to do various things, but apparently they are frowned upon now...  and I understand that.  What I don't understand is why this does not work.

Note that it is not communications issues, noise or any of those other excuses.  All 3 keypads work exactly the same way 100% of the time.

Any ideas?

 

 

 

 

 

 

 

 

 

 

 

[kclenden]

5 hours ago, andrew67 said:

Any ideas?

I'm guessing you've only set the ON levels for the what happens if you activate the scene via an ISY program.  You do that by clicking the scene name in the left-hand navigation.  Have you clicked on each of the nine real world controllers (3 per scene) that appear indented and in red in the left-hand navigation and set the ON levels for each device in the scene when controlled by that controller?

[andrew67]

Yes, I finally remembered that confusing issue late last night, and changed that, but the buttons backlights still don't turn off, ever.  I tried setting them to non-toggle[on], and it didn't help either.  

Also I seem to remember there was a way to push all of the ISY scene's levels to the other controllers, but I could not find that either....  Does that still exist?

 

[kclenden]

2 hours ago, andrew67 said:

Does that still exist?

What version of the firmware are you running.  The copy scene settings ability was removed at some point.  I think it was starting with v5.

2 hours ago, andrew67 said:

but the buttons backlights still don't turn off, ever.

As confusing as it sounds, for each scene where you want a keypad button backlight to be off, you have to set its ON level to OFF.  So for each of the three controller settings that control each scene, three keypad buttons should have an ON level of ON, and six keypad buttons should have an ON level of OFF.

[andrew67]

 

I'm running V5.3.0.

22 minutes ago, kclenden said:

As confusing as it sounds, for each scene where you want a keypad button backlight to be off, you have to set its ON level to OFF.  So for each of the three controller settings that control each scene, three keypad buttons should have an ON level of ON, and six keypad buttons should have an ON level of OFF.

Ya, so I did that.   I'm as confused as ever about what I can, and cannot do via Insteon, and I am not being helped by the UI.

1) When I have all of the buttons in Toggle mode, and everything is off, and I Push A, All 3 of the A's light up, and don't go out, even though they are programmed as Off in each other's responder lists.  Pushing the button itself again causes the Off command to be sent, with both the lights and all A-buttons going off, so the buttons indeed got changed into Toggle mode.  It "works" the same way regardless which keypad I use for the first or second press, so...  it appears that what is happening is that regardless of what I put into the responder link (On or Off), the net result is that On gets sent if the transition is Off->On. 

Not sure if this is a bug in 5.3.0, or a limitation of the protocol, but the UI should know and inform, and eliminate the idea that you can do this if you can't. 

2) I can't change a keypad's self responder link, its set to default, which I guess means its going to do the same thing as in #1, and you can't change it.  I think thats because its a limitation of Insteon, but of course no real info on this is available.  This would be one of those places where being able to tell why and exactly what is going to happen would be fine, and a link to how to make it behave differently would be even better.  

Bug:   

default is sometimes Default, 

Command is sometimes Command

Insteon is however always Insteon

Haven't tried Ignore yet...

3) Is the purpose of the "Command" option to allow an arbitrary command to be sent to the device?  How come that option isn't available if that is indeed how its supposed to work?  [Could "Send additional command after delay" be another option?] 

4) Now I went back and turned the buttons to Non-Toggle[on]. 

Bug: Note that the Buttons Toggle Mode Dialog box immediately writes to the devices, but has a "Cancel" button, which of course does nothing....  It also has an OK button, it really should have a Close button, and neither of the other two, or it should cache the data and write later.

The buttons indeed now are non-toggle.  Its impossible to turn off the LED.. its always on.  (note this is regardless if a scene is connected to the button or not).The buttons do indeed trigger the scenes On is sent each time they are pressed, however there is now no control over the backlight, its always on.

5)  In addition, there is now confusion about Led Brightness, which seems to have been hastily renamed to the "Backlight" button and dropdown.  They seem to set the same thing, but....    

a) It seems that all of the buttons must have the same brightness [which is fine, except you can't change some buttons to never light up, which would have been an OK fix for what I want to do], so leaving the ability to change it everywhere is adding to the confusion.  There should only be ONE place to change the backlight if its not changeable for each button individually.

b) the "Backlight" button and dropdown do not reflect the current state written into the device.  The LED brightness box seems to be correct, but the backlight dropdown holds whatever value you set it to, and never queries the device.  When you switch to a different device and switch back, it keeps the old value, suggesting that that is what is written into the device.

So at this point I am once again asking HOW IS IT SUPPOSED TO WORK?

[lilyoyo1]

Keep in mind, when you use mutually exclusive, that resides in the devices. If you haven't reset them (or remove the function via console), it could still be there which will effect how your buttons respond to new scenes and programs. 

[andrew67]

All of the Keypads have been reset multiple times since I started this process, and I have not tried to turn on Mutually Exclusive Buttons...  I would prefer not to, since ISY won't know whats going on.

I'm trying to use your method to do mutually exclusive buttons.  But my keypads don't seem to behave like yours....  The On/Off setting for the keys does not change their behavior.  Did you try your method to create links on a 5.x system?

I can't imagine its all been broken in 5.x and nobody noticed, but I have seen that again and again in other software...  There are no available diagnostics, not even a "verify device", and once again the whole process keeps exposing to me how excessively complicated the ISY UI is to understand.  Every time it looks "Obvious" what something does, it doesn't.

 

[lilyoyo1]

1 minute ago, andrew67 said:

All of the Keypads have been reset multiple times since I started this process, and I have not tried to turn on Mutually Exclusive Buttons...  I would prefer not to, since ISY won't know whats going on.

I'm trying to use your method to do mutually exclusive buttons.  But my keypads don't seem to behave like yours....  The On/Off setting for the keys does not change their behavior.  Did you try your method to create links on a 5.x system?

I can't imagine its all been broken in 5.x and nobody noticed, but I have seen that again and again in other software...  There are no available diagnostics, not even a "verify device", and once again the whole process keeps exposing to me how excessively complicated the ISY UI is to understand.  Every time it looks "Obvious" what something does, it doesn't.

 

Yes I have without any issues. Are you just updating the scene or the controllers in the scenes as well?

[andrew67]

I've wiped everything out several times....

Usually I just pull the air gap, and push it back in for 30 seconds, and then go do a "restore device."  Then I go get a Gin and tonic, and wait.  I have 3 keypads in that room, so I do all 3, takes about 1.5 Gin and Tonics....

Note that my kitchen ones are all relatively old (V.36).  I have some newer ones in the house (V.39) and (V.43) but they are not involved in this area.

[lilyoyo1]

Older devices aren't as capable as newer devices but it shouldn't matter overall. The writes to those will be much slower as i1 isn't nearly as quick as i2cs.

The way I set my scenes up are as follows:

A- Controller- Default 

B- Responder- off 

C- Responder- off 

D- Responder- off 

Other devices- desired state

 

A- Responder- off 

B- Controller- Default 

C- Responder- off 

D- Responder- off

Other devices- desired state 

The same applies for the rest of the buttons.

Depending on what the scene is for is how I determine how I'm going to use programs. For example, my all off scenes turns everything off. Using a program to turn the scene off isn't a big deal. I'll just have a program turn the same scene off 2 seconds after it's triggered. While I could get away with 1 second, the extra second is there to ensure all other communication has stopped. 

However, if I have lights that turn on for whatever reason, I'll create a separate scene and add that button as a responder. This way, the lights I want on will stay on even though the kpl backlight gets turned off.

An example of this is my media room. My all off button isn't directly linked to everything. Instead I created a program with everything as responders. During the day, hitting the all off will trigger my off program setting the scene off (includong the all off button. At night, triggering the scene will run a program turning the scene on. This in turn turns the lights to 50%, turns on the hallway lights, and turns everything else off. 

I have the button in a separate program which then turns the button off after 2 seconds. The room will turn itself off after a couple of minutes as will the hall lights. 

 

 

 

 

 

 

 

 

 

[andrew67]

I don't understand... 

Are you saying that the scenes with the other kpls buttons in the off state still need programs to turn off the backlights? i.e. that the "Off" doesn't do anything by itself?

[lilyoyo1]

13 minutes ago, andrew67 said:

I don't understand... 

Are you saying that the scenes with the other kpls buttons in the off state still need programs to turn off the backlights? i.e. that the "Off" doesn't do anything by itself?

You only need an off to turn off the button that you are controlling. If you look at how I set the scenes up, you'll see the other buttons are configured to turn off whenever the controller is turned on. 

How you turn off the controller depends on what you are trying to accomplish. That's why I included examples of how I use mine. To help you understand the differences ways. 

 

[andrew67]

On 3/16/2021 at 10:37 PM, lilyoyo1 said:

You only need an off to turn off the button that you are controlling. If you look at how I set the scenes up, you'll see the other buttons are configured to turn off whenever the controller is turned on. 

That just does not work for me at all.  No matter what I do, or how many times I try it or on which keypad, I cannot get an on command from a button to turn off the backlight of another button.  Its 100% consistent.  

I've reduced this down to a single scene, with the 3 buttons of a single keypad in it.  Everything is set to Off in each of the controllers.  There is no external control, and no load or other responders.  

Perhaps your program does the Off and you don't realize it?

 

 

[lilyoyo1]

35 minutes ago, andrew67 said:

That just does not work for me at all.  No matter what I do, or how many times I try it or on which keypad, I cannot get an on command from a button to turn off the backlight of another button.  Its 100% consistent.  

I've reduced this down to a single scene, with the 3 buttons of a single keypad in it.  Everything is set to Off in each of the controllers.  There is no external control, and no load or other responders.  

Perhaps your program does the Off and you don't realize it?

 

 

My programs have nothing to do with the other buttons.  For the most part, all of my systems are designed to work without a controller so it's paramount that a controller is not needed for most of the setup.

If you set your scene up exactly as I have shown, the other buttons will turn off on their own. Most likely you have not configured your buttons in the controller to send the off command to your other buttons.

I've configured hundreds of keypads over the years in this manner and all have the same behavior once programmed. 

[MrBill]

@andrew67  Here are screenshots that will hopefully help you there are a total of 4 scenes but I'm only going to paste two of them.  I suspect you are not configuring the Red controller buttons.  In my case the functions are for outdoor lightning Day, Evening, Late Night, Bright.  The ISY normally sets the first 3 based on sunrise / sunset / bedtime, the 4th mode Bright is always manual, the  buttons E,F,G,H exist on a keypad by the door. 

Note in the above screenshot the Root of the scene is selected.  "Front Lights - Evening" these settings are used when the ISY controls the scenes.

Above screen shot is Same Scene but note this time the cursor on the tree is highlighting the Controller or RED entry from the previous screen shot.  You much set the OFF's on the other buttons here also.

 

Now let's look at the next button.

 

This is similar to the first screen shot.  we are setting off for the other buttons added as responders when the ISY is the controller.

and finally:

Now the RED controller of that scene is selected and I again need to set OFF for the other buttons in the scene.

 

As I said I'm skipping Day, and Late night but they are the same thing..... just different red controller branches.

 

The buttons are "non-toggle"-"on".

[andrew67]

First, I want to thank you MrBill, Its at least clear what you did, and I wanted to show you what happens when I do it.  I DO NOT GET THE SAME RESULT.  And I think I can now (after days of working on this) explain WHY.  Its NOT pretty what is going on.

My procedure (I had to do this several times to really understand how ISY works BTW.  It took HOURS to do this):

1. I took a spare keypad 12.BD.0D I had laying around, factory reset it, and hooked it up with an extension cord to an outlet shared with my PLM, to be near my computer.  Its a 2486D, v.36.  I have a few v.39's too, but mostly v.36 in my system.
2. I linked it.
3. I checked Buttons Grouping (Nothing was checked)
4. I checked Buttons Toggle Mode (All were set to Toggle)
5. I then created a scene named Test
6. I then added buttons A B and C from it to that scene.
7. At this point it looks like this:
8. 
9. I then went through and changed all of the Actions to Off.
10. So now each of the three buttons looks like this:
11. 
12. At this point I tried the keypad.
13. It works as YOU expected it to...  i.e. the buttons are indeed mutually exclusive.  The last one pushed stays lit.  You would think the problem is solved. 
14. The key to understanding what is going on is available at this point, but you would never know to go looking for it.  On my fourth time through I stopped at this step and did diagnostics...  but I won't spoil it for you now.
15. I then linked in another keypad.  This time it was 12.B8.1E, also a V.36.
16.  Now all of my button scenes look like this:
17. 
18. At this point the keypads are hopelessly out of sync, and DO NOT do the right thing.  What happens is:
19. Pushing ANY button on either keypad lights up ALL buttons on the OTHER keypad, and just the one pushed on its own keypad.
20. Pushing ANY of the LIT buttons on either keypad turns off ALL buttons.
21. Pushing ANY of the NOT-LIT buttons turns off the LIT button on its own keypad, lights up itself, and doesn't affect the LIT buttons on the other keypad.
22. Here's the video to demonstrate:
23. You can imagine how frustrating that could be when you can't see them side by side to understand, but the hint's are there.
24. WHAT IS ACTUALLY GOING ON, is that ISY is creating an old style Mutually Excusive Button Group on EACH KEYPAD.  If we go back to step 12, and look at the device's Buttons Grouping page, you see this:
25. 
26. The second keypad's Buttons grouping page looks the same, with its address.
27. However, clearly Mutually Exclusive Button groups can't be made between separate keypads, as there is no way to add them in.
28. The third line of text in the box above is indeed correct, reset deletes the button group and destroys the Mutual Exclusivity within a keypad.   However, the two lines above are FALSE.    
29. a) The ISY does not know the true status of the buttons on the second keypad when a button is pressed on the first.
30. b) You cannot set a button to Off from an Off-On transition of a button, even though the ISY gives you the option to do so.
31.  
32.  
33.  
34. This is either a bug in 5.3 which you have not experienced, or a limitation of my keypads.  Your keypads are much newer than mine, new model number even, and maybe they understand  and properly interpret the ISY's intent, But it seems QUITE BUGGY.

 

ANY COMMENTS GUYS?

 

 

[lilyoyo1]

I can't speak on your version with 5.3 since I haven't used those since the dual band versions came out. One thing I noticed is that you're using a single scene with all buttons as controllers instead of individual scenes for each controller with the other buttons as responders in the corresponding scenes like I had in my earlier example

Ie:

A- Main Light (one scene)

B- Lamps (Separate scene)

C- Relax (Separate Scene)

 

 

[andrew67]

Ya, so if we know anything about Insteon, its pretty obvious that controller vs responder is not the issue.  The issue is that the protocol is brain damaged, INTENTIONALLY, to reduce traffic at the expense of of [debug, weird use cases, anything more than a 3 way circuit],  the issue I have is that UD and Insteon are hiding the disaster that is now the Insteon protocol, which needs to be taken out back and shot.

Sadly Zwave is apparently trying to be just as bad.

They needed to go to V3 protocol at 100x the bandwidth, and own the industry 5-10 years ago, but instead we have ISY built on code from 1985, and then we are adding a Polisy of mediocrity which cant even  deal with 1 update per second, when CK [www.colorkinetics.com] were doing 44 updates per second acroos 800 lights in 2000.  [actual numbers].  

[COMMENT  I don't usually do this, and the last time I was on this forum I was more polite:

Ive been doing this a long time... TOO LONG actually, and I'm fucking tired of the BS that home AutoNOTMation is dishing out.  Its bad at every price level. So I try to pay less for the same amount of BS.  I thought UD had some great people.... in 2012.  Michael... I salute you.  But fucking shoot this thing now, and get the VC to fund something better.  

/COMMENT]

[lilyoyo1]

1 hour ago, andrew67 said:

Ya, so if we know anything about Insteon, its pretty obvious that controller vs responder is not the issue.  The issue is that the protocol is brain damaged, INTENTIONALLY, to reduce traffic at the expense of of [debug, weird use cases, anything more than a 3 way circuit],  the issue I have is that UD and Insteon are hiding the disaster that is now the Insteon protocol, which needs to be taken out back and shot.

Sadly Zwave is apparently trying to be just as bad.

They needed to go to V3 protocol at 100x the bandwidth, and own the industry 5-10 years ago, but instead we have ISY built on code from 1985, and then we are adding a Polisy of mediocrity which cant even  deal with 1 update per second, when CK [www.colorkinetics.com] were doing 44 updates per second acroos 800 lights in 2000.  [actual numbers].  

[COMMENT  I don't usually do this, and the last time I was on this forum I was more polite:

Ive been doing this a long time... TOO LONG actually, and I'm fucking tired of the BS that home AutoNOTMation is dishing out.  Its bad at every price level. So I try to pay less for the same amount of BS.  I thought UD had some great people.... in 2012.  Michael... I salute you.  But fucking shoot this thing now, and get the VC to fund something better.  

/COMMENT]

Your issue has nothing to do with insteon, zwave, no the isy. It is completely how you are setting things up. 2 different people have shown you with examples what to do only for you to still do it incorrectly (according to your examples). This is solely operator error. Not Insteon, zwave or isy shortfalls. 

[kclenden]

6 hours ago, andrew67 said:

ANY COMMENTS GUYS?

Interesting.  I tried to simulate what you setup with two of my 8-button keypads.  I'm lazy though, so I only added two buttons from each keypad to the same scene.  Here it is:

Then I set about changing all of the ON levels appropriately:

Next I looked at the Button Grouping:

And I thought that looked similar to what you had (i.e. FR-Keypad only had FR groupings and FY-Keypad only had FY groupings), so figured things wouldn't work like they're supposed to.  But they did.

• When I pressed FR-Keypad Button C it lit up, and FR-D, FY-C and FY-D all went out*.
• Likewise pressing FR-Keypad Button D made it light up, and FR-C, FY-C and FY-D all go out*.
• Pressing FY-Keypad Button C made it light up, and FY-D, FR-C and FR-D all go out*.
• Finally pressing FY-Keypad D made it light up, and FY-C, FR-C and FR-D all go out*.

* when I say all the others go out, only one of them was ever lit (i.e. the last one I pressed) so in reality one went out and the others stayed OFF.

The bad news is that I'm not able to replicate your results.  The good news (for me) is that I'm not able to replicate your results.  I'm not sure what to tell you, but I'm happy to test other things if it will help.
 

FR-Keypad (2486D) KeypadLinc Dimmer 8 Button v.41

FY-Keypad (2486D) KeypadLinc Dimmer 8 Button v.41

I'm running firmware V.5.0.15A  (been too lazy to upgrade since most of the updates seem to be for Zwave)

[oberkc]

9 hours ago, andrew67 said:

ANY COMMENTS GUYS?

Regarding your step 20, this appears normal to me.  If you press a button (configured in toggle mode) that is already on, it will turn off, as will all responders to that button.  If your use case include pressing a button that is currently on, and you expect it to stay on, you would have to configure the button to be "non-toggle (on)".

As extensive as your post was, it is focused on the responder settings for button 12.BD.0A.A, and those look correct (all responder buttons are set to OFF).  Reminder, you must check this for EVERY controller button in the scene.  Select 12.BD.0A.B....are all responders set to off.  Check C button for same responder settings.  Then, individually select each of the three buttons on device 12.B8.1E and ensure each of the responders is set to off.

Regarding the ISY automatically configuring a mutually-exclusive relationship based upon your scene settings, I have no experience to confirm this (unfortunately, also, I do not have a couple of spare keypads with which to play around).  I would not expect this either and your trials suggest to me also that this may be a bug.  Was that relationship also automatically set up for the second keypad?  Edit...I checked one of my Keypads (single keypad, single scene with four buttons (all controllers), all responders set to OFF.  In fact, my keypad also shows a mutually-exclusive relationship configured.  I don't believe that I did this either.  I guess I can now confirm behavior like yours in this regard.  

[MrBill]

@andrew67  I do have two different 8-button controllers (both 2334-222 Rev 7.7) that control the same 2 fanlinc's with mutually exclusive Off, Low, Med, ,and the light on a 5th button.. the other 3 buttons are used but unrelated to the fanlincs.    (so 2 -  8-button wall controllers, 2 fanlincs that are controlled together, 5 scenes total, OFF, Low, Med, High, Light) and the lights on BOTH controllers stay in sync.  

The only thing that I note that I do differently is only one button in the scene is the controller.   That is for the function "High" it is a button that is a controller for the scene, while Off, Med, and Low buttons are Responders to the scene.   (yes i waste a button and a scene for OFF, I think now I could save a scene by making the OFF button, a non-toggle OFF controller for one of the other scene's but when I set this up I didn't think of trying that). 

Also probably unrelated to your debugging, but all of my mutually exclusive buttons are programmed Non-toggle. 

Also I assume you know this, but in case you don't, when setting things like this up to make use of this button: on the ribbon?   It turns off writes to the devices, allow you to make programming changes to multiple buttons and scenes, when your done with the whole keypad or whole group or whole whatever you're setting up then turn the button back on and go refill you coffee (or get another beer).  (I got the idea at some point during the read of your post above you might not know.....)

 

 

 

[lilyoyo1]

2 hours ago, MrBill said:

@andrew67 

Also probably unrelated to your debugging, but all of my mutually exclusive buttons are programmed Non-toggle. 

 

 

 

It probably does play a large part in things and how they work. Insteon's weed designed to work without a controller so the right modes are built into the devices themselves. Because of this, they would override the information that is sent via a scene. 

Toggle on- on command sent 

Toggle off- off always sent

 

[MrBill]

30 minutes ago, lilyoyo1 said:

It probably does play a large part in things and how they work. Insteon's weed designed to work without a controller so the right modes are built into the devices themselves. Because of this, they would override the information that is sent via a scene. 

Toggle on- on command sent 

Toggle off- off always sent

 

I think the larger item that will change how it works is multiple controllers on the same keypad vs single controller with the other buttons being responders.  I didn't realize the ISY would even allow what he's doing, there a dialog box to the effect asking if you want it to be a responder because another button is already a controller.

[lilyoyo1]

I think it's a combination of both in regards to trying to use a single scene in addition to using the toggle modes vs non toggle.

Toggle send a specific command to everything in that scene. Since controllers are responders too, a toggle on would tell all devices to turn on regardless of how configured.

The isy allows him to use 1 scene since they are still their own controllers within that scene. I do the same with my upstairs lights. The 4 locations that turns on those lights together are all controllers in 1 scene. However, the behavior is different depending on which button i hit. With that said, the scene isn't setup to be mutually exclusive so it doesn't cause any other issues. 

Regardless, he's doing something wrong with his setup since we both know it's possible to accomplish what he's trying to do.