Is Button "Press" an auto-repeat?

[EagleMoon]

I'm confused by how this keypad is acting. System is 1.8.0.

I've set up a 6-button keypad to toggle the POWER_STATE of a room and set a particular audio source when a button is pressed. That appears to work as I expect.

But now I want to change the LED color to RED to show the room is "ON" even if Volume is muted. I do this on another keypad for the theater and it appears to work as I expect. But there I used a "Triple Tap" in the programming, not a "Press".

For the one in question, the LED only flashes RED for an instant and goes back to BLUE, yet the room stays on and music keeps playing as I'd like. It acts as if the "Press" event is triggered multiple times each time I've just pressed the button once, but the music doesn't toggle unexpectedly: press once for "On", press again for "Off". That works consistently.

Here's the programming for the keypad:

When Kitchen->6-Button Keypad button 1 is pressed

Toggle Dining->POWER_STATE

if Dining->POWER_STATE is True

Select the XM Dock as the audio source in Dining

And this for the room (exactly what I do in the Theater, which works):

When the variable Dining->POWER_STATE changes

If Dining->POWER_STATE is False

Set LED:1 current color to Blue on Kitchen->6-Button Keypad

If Dining->POWER_STATE is True

Set LED:1 current color to Red on Kitchen->6-Button Keypad

Using the POWER_STATE variable to control LED color should allow it to work even if the power state is changed from a SR250 or a GUI/Touchscreen.

Edit: Forgot to mention that I use Buttons 2 and 3 "Press" to bump up/down the volume. And those work correctly, so I know it's not really a repeating function. Something else is resetting the LED color?

[EagleMoon]

Another update: If I go to the "Monitoring" section, select the keypad and click the button with the mouse, the LEDs (both the icon and the physical) behave correctly.

It's only the physical tap that I can't figure out.

BTW, what is the default color of the LEDs? It's not "Blue", it's a much darker blue.

[EagleMoon]

Another update:

If I press and hold the button, it initially turns green. Then after about half a second it turns red. But when I release the button, it turns back to the default dim blue.

So the "Release" event is changing it back to default. But that doesn't happen on the double or triple tap.

[pharmdsmith]

I think your problem revolves around the timing for a press event versus a triple tap. A press event occurs instantly, which is why you see the red, then you release it and it goes to your default release color. For your triple tap, control4 waits a certain time to ensure you got all your taps in. So you have finished releasing the button before control4 toggles your variable.

The fix is to add a delay before your "if" conditionals on your variable change. This gives you time to get your finger off the button before it executes the color changes you want, or put your programming under single tap instead of press.

[EagleMoon]

... or put your programming under single tap instead of press.

That's what I would have thought. But "Single tap" was not one of the options. ComposerHE 1.8.0, same version and the controller.

In fact, I thought I had seen it there before, but when it wasn't one of the choices I assumed I'd been dreaming.

[pharmdsmith]

Guess they added that in 1.8.2 or 2.0 :-). Put a half second delay in and that should fix it.

[EagleMoon]

Guess they added that in 1.8.2 or 2.0 :-). Put a half second delay in and that should fix it.

I think it was added in 1.8.2 ... I need to order some parts (some more dimmers, some switches, keypads, sensors) so I'll ask my dealer to upgrade me as part of all that. But he's two hours away; he'll have to send me a CD or flash drive or something and we'll do it remotely when we add the devices. Unless one of his guys wants to come over and go skiing afterward! (And thus not charge me extra).

Not ready to bog down my little HC-300 with 2.x yet.

However, I'm not sure delay is the *real* problem because I see the color change from blue to green immediately upon Press (and hold), then half second later it turns red as programmed and will stay red until I release the button, then it goes back to blue. So I think there's something I don't have access to that is controlling it and resetting to blue upon release.

Oh, nevermind ... now I understand what you meant about adding the delay: so my "set color" statement doesn't execute until after I release the button, i.e. after the built-in Release function sets it to blue, so the Release doesn't change my color. I suppose probably could also use "Release" rather than "Press" to get around it.

[jwhitaker@revit]

the real issue you are seeing is the way button interactions are perceived by director. In standard programming in 1.8 and beyond each keypad button has 4 perceived commands. Press, release, single tap, double tap, and triple tap. The release is the key. The release function is not associated with any of the tap events, it is only associated with the press event. So any time you program on the press a second event is perceived by director. This will cause your led to change to the default release color unless you program the appropriate color on the release as Paul stated. The delay Paul is saying to add is actually placing a timer in to change the color after the release event triggers.

An easy way to avoid all this is to no longer program on the press. Especially if you are using the double and triple taps. I always try to program on the single tap UNLESS there is something very specific that I need to happen upon the release.

[thecodeman]

An easy way to avoid all this is to no longer program on the press. Especially if you are using the double and triple taps. I always try to program on the single tap UNLESS there is something very specific that I need to happen upon the release.

+1, in 1.7.4 and previous, I program on the release, 182 and later on the taps, personally.

[EagleMoon]

An easy way to avoid all this is to no longer program on the press. Especially if you are using the double and triple taps. I always try to program on the single tap UNLESS there is something very specific that I need to happen upon the release.

+1' date=' in 1.7.4 and previous, I program on the release, 182 and later on the taps, personally.[/quote']

Thanks, all. I began to figure all that out about the time you guys all posted the answers.

I think I just need to get upgraded to 1.8.2 so I have "Single Tap" available.

Now, will Double Tap be recognized as different from a Release? If so, I think I'll want to use Release (or Single Tap after upgrade) to turn room on/off and use Double Tap to cycle through different sources.

[NkySpike65]

I not sure about others , but I found when you use "single, "double', or "triple" Tap, then you do not want to use "Press" or "Release" on that same key on the same keypad at all...

Lets just say you,

Program button 1 -- "Press": turn on TV.

Program button 1 -- "Release": turn on DVR.

Program button 1 -- "Single Tap": turn lights on.

Program button 1 -- "Double Tap": turn light off.

Program button 1 -- "Triple Tap": turn off TV-DVR-Lights.

Now "any" time you "single, double,or triple Tap", you are also "press"ing and "release"ing button 1. So, when you triple tap to turn everything off, you are also telling it to turn on the TV and DVR at the same time...

There is no delay on the action when Press, and Release are used. Now when you Tap, there is a delay to verify on how many times you taped the button...

[RyanE]

That is correct, because if Control4 didn't still fire the press and release, the end user's code that used them for implementing their own double-tap, etc. would not work properly.

RyanE

[EagleMoon]

I just now attached my script to the Release rather than Press and it works fine unless I did a really quick tap. Then the "power_state change" script ran and set color to red before the internal function of the release had reset the color to dark blue. Thus the need for the 0.5 sec delay in the "power_state change" script before setting color to red. It all makes perfect sense now. I sure am glad I accidentally discovered this week that you could copy/paste the entire script from one event to another! Made changing two buttons like this a trivial matter.

Here's the perfect solution (for me) on my 1.8.0 system for one of the rooms:

When Kitchen->6-Button Keypad button 4 is released

Toggle Living->POWER_STATE

If Living->POWER_STATE is True

Select the XM Dock as the audio source in Living

When the variable Living->POWER_STATE changes

If Room Living Room Power is ON

delay 500 milliseconds

Set LED: 4 current color to Color Red on Kitchen->6-button Keypad

If Room Living Room Power is OFF

Set LED: 4 OFF on Kitchen->6-button Keypad

That "set LED OFF" statement seems to be poorly named -- it's more like you're setting the "button" to "Off" because it doesn't actually turn off the LED; it sets the LED to an "Off" color which apparently is still the default color of dim blue. Right?

[thecodeman]

That "set LED OFF" statement seems to be poorly named -- it's more like you're setting the "button" to "Off" because it doesn't actually turn off the LED; it sets the LED to an "Off" color which apparently is still the default color of dim blue. Right?

Correct.

[EagleMoon]

This "button color" thing is insanely mysterious. I used the exact same code for my theater POWER_STATE change to control a button LED on a different keypad. I always turn off the theater from the SR-250. Doing it that way, the color would never change back to default until I touched the button. Then it immediately went to the default blue. I added to the power change code a "Release" command for that button on power-off. It had no effect. It was late and I don't remember if I tried a combined "Press" and "Release" command.

Can anyone explain what logic controls that button color? It obviously is not exactly what I thought.

Edit: Nope. Programmatically sending "Press", "Delay 100 ms", "Release" doesn't work. It appears to require a physical press.

[diezzler]

I had funny things happen to me similarly to what you are having happen above, until I realized that these were happening to me when I was using boolean agents, or I didn't define a stop to the scripts. If you post all of your images of the programming, maybe I can come up with some possible ideas. The first thing that pops to my mind, is when you use a function that is part of a variable=true, composer will run down the "script" from top to bottom, but if you never defined in your script a stop or "false", then composer will sit at the bottom of the script until the script is broken in some funny way (say doing the opposite of the action you defined IE: lights on --> then lights off). And then maybe the script will work again randomly, but the real defined script is not functioning as it should (Idle/ready state, Start script, stop script, idle/ready state). I'm not really sure how to word this, but hopefully you get what I'm trying to say.

I feel like your lights aren't acting right, because the script runs and then stalls at the bottom. Maybe I'm just confused. If POWER_STATE is True, and changes your lights, and the led.. script ends and is waiting for a power state change to change the led again, not in the middle. Maybe define a false at the end of your script.

BTW, been a computer programmer for 15+ years, and still composer confuses me sometime, because It doesn't have all the programming actions I want it to have.