h0m3h4kk3r

By way of an update: I've had the solution @kclenden recommended in place now for several days, and apart from the button flashing twice on a short-press, it's working flawlessly. I still have no idea what's causing the flashing. Apart from this application, I've never used a keypad button in "Non-Toggle (On)" mode. Perhaps it's normal behavior for a non-toggle (on) button to flash twice? I don't see an obvious way to prevent it (especially if I don't know what's causing it in the first place...) Anyway, thanks again @kclenden for your excellent advice.

Indeed! This makes the long-press behavior work perfectly and reliably, as far as I can tell thus far. It does have an unexpected (and somewhat undesirable) side-effect on the short-press behavior, though. Now, with the keypad button in "Non-toggle On" mode, when I short-press the button, the button light comes on, goes off, comes on again, goes off again, and then comes on a third time and stays on while the short timer is running. The flashing behavior surprised me. I need to do a little more experimentation to figure out what's causing that... 10 points for Gryffindor!!! This is the debugging equivalent of printf, which I was sorely missing. Brilliant suggestion. Thanks! I will use this strategy to try to see what's causing the button flashing on the short-press now that I've disabled toggle...

How might I verify that the "default local on level" is what's causing the inconsistent behavior I see? I don't see how that can be in play here, since every event related to pump control explicitly sets the scene to 100% or 0% once the program is responding. In my case, where I get the wrong behavior, I *know* that my program has indeed begun executing, because the button light comes on. That doesn't happen if my program is disabled, no matter how long I hold the keypad button.

Understood. (I mentioned that option as well). But the long-press should work, if my assumption is correct: Specifically, if the button is in the "off" state, a long-press will generate "Fade Up" signals, followed by "Fade Stop" when you let go. The alternating behavior of Fade-Up and Fade-Down only occurs when the button is in the "ON" state when the long-press occurs -- and I don't care about that case at all. (If the button is in the "ON" state, the pump is already running.) In any case, even if I don't end up keeping the long-press behavior as my goal, I'd still like to understand what's going on with the timing of this solution if only to deepen my knowledge for future projects. The timing-sensitive behavior tells me that I'm missing something that's probably pretty fundamental.

I have a strange problem with a 2334-2 v.44 KeypadLinc Dimmer and some programs I'm using to get the behavior I want. Mostly, the solution I have is working, but there's a timing dependency that I don't understand--and if you get the timing just right, the program doesn't work correctly and the keypad button even seems to malfunction. In a nutshell, the goal is for a keypad button to control two devices (a pump and a status light relay) that will run on a timer. @kclenden and @apostolakisl will recognize this application, since they were kind enough to help me sort out an efficient way to control this same pump with a different setup. @apostolakisl's suggestion to use an ApplianceLinc to control the pump directly is what started me down this path. For the new setup, I want a normal keypad button press to start a short timer, and a long press to start a longer timer. I realize there are other ways to do this (use a different button for long timer, or use a double-tap for long timer, etc....). The short-press/long-press approach is desirable to me because it mimics the way the devices are controlled by the analog buttons. For feedback (and again, to mimic they way the analog buttons will work), I want the user at the keypad to trigger the long timer by pressing the keypad button and waiting until the keypad button lights up before the user releases the button. I'm differentiating between short press and long press by responding to the Control "On" (for short timer) and Control "Fade Up" (for long timer). (Thanks again, @kclenden, for helping me understand the difference between Control and Status!) The problem is to do with the "long-press" behavior. Here's the program that starts the pump and the timer: KeypadLongTrip - [ID 0027][Parent 001A] If Control 'Family Rm KPD - Can Lights / Family Rm KPD.C' is switched Fade Up And $iTestTimerRunning is 0 Then Set Scene 'TESTING / Test-RunningLights' On Set 'TESTING / TEST-LampLinc' On Set 'TESTING / TEST-Relay' On Run Program 'SensorLongTimer' (Then Path) Else - No Actions - (To add one, press 'Action') Note, "TEST-LampLinc" is my stand-in for the ApplicanceLinc that will control the pump -- that should arrive tomorrow. "Test-RunningLights" is the Scene that has the keypad button as a responder. And here's the timer program that cuts the pump off again (ignore the conditions for this timer program -- those are there to give me the behavior I want with the analog buttons): SensorLongTimer - [ID 0026][Parent 001A] If Control 'TESTING / TEST-Sensor' is switched Off And $iTestTimerRunning is 0 And $iTestInSensorTrip is 0 Then $iTestTimerRunning = 1 Wait 60 seconds Set 'TESTING / TEST-LampLinc' Off Set 'TESTING / TEST-Relay' Off Set Scene 'TESTING / Test-RunningLights' Off $iTestTimerRunning = 0 Else - No Actions - (To add one, press 'Action') The KeypadLongTrip program starts running about 1-1.5s after the user presses the keypad button, and "Set Scene 'TESTING / Test-RunningLights' On" changes the state of the button, so the button backlight comes on. (Presumably the button state changes to "on" as well.) If I hold the button for about another second, all of this works splendidly. Releasing the button leaves the button backlight on, and the LampLinc and Relay are both on, and the long timer is running. Everything is copacetic. However, if I press the keypad button, and release it as soon as I see the button backlight come on, havoc ensues: The keypad button state goes OFF In the ISY Event Viewer, I see two "OFF" events from the keypad button (which is weird because the normal behavior after "Fade Up" would be "Fade Stop" -- exactly what I see if I hold the button for an extra second after the light comes on...) Pump and relay are OFF, and no timer is running. (This is ensured by a separate program that responds to the Keypad "OFF" event.) Keypad button appears to be in a seriously hosed state. The next keypad button press (regardless of whether it's a short press or a long press) does not seem to generate any event at all, but it does change the button state to "On". You have to do this, and then tap the button again (turn it off) before the button will correctly send "On" or "Fade Up" signals. If I take the "Set Scene 'TESTING / Test-RunningLights' On" command out of the KeypadLongTrip program, I don't seem to have the problem. And that seems reasonable-- if there's an issue, it seems likely to me that changing the state of the button while the button is in a transient state (fade) could be the culprit... But, of course, if I take out that Scene-On command, I get no feedback for the user at the keypad, and it's harder to tell whether I've held the button long enough to mean "Long Timer". And I'm confused about why the problem doesn't occur if I hold the button just a little longer... It's still in the same transient "fade" state, and I've still changed the state externally... So, I'm puzzled. I don't really have enough experience reading the event log to know what I'm looking for-- so I've attached the event logs for a "Normal" Long-timer trip (where I hold the button long enough to get the correct behavior), and for a "Failure Mode" trip (where I hold the button long enough to start the long timer program, but release it immediately after the button backlight comes on). Perhaps wiser, more experienced forum members may spot the issue? For reference, I've also attached the event log for a normal short-run. If it would be helpful to post the event log for "recovery", where I cycle the button on and off to get it back into a correct/stable state, I have that as well, and I'm happy to post it. ISY-LongRun-Normal.txt ISY-LongRun-FailureMode.txt ISY-LongRun-Normal.txt