ToggleLinc Double-Click?

[johnmsch]

I may replace my code with what Rand or northportphoneguy suggested.

 

Agreed. Either one of those should work every time. I'm giving up on the double-click functionality. Its just not worth the hassle.

[johnmsch]

Just to be sure I understand how this works, since this concept is new to me...

 

When you do this:

 

If

Control 'Small Bedroom' is switched Off

Then

Run Program 'VirtualFlag' (Then Path)

 

From that point on, until eternity (or until the ISY is rebooted), any reference to that program will come back as true until you specifically execute this:

 

Run Program 'VirtualFlag' (Else Path)

 

Is this assumption correct?

[northportphoneguy]

Hi,

The VirtualFlag program is set either true/false depending on running the if or then statement.

 

On the FirstDetect VirtualFlag is set true and is set back to false after 3 seconds. If another Off is detected within the 3 second window, then the Then clause is activated in the second detect.

 

I use the Run Program because I like to separate the Commands from the calling progams because the called program will run no matter what.

 

As you can guess, you can vary the window of operation and can vary the sequence. I use Off/Off, but you could use any of the four combinations.

 

You could even add more flags and detect programs and make a fancy sequence to do something. Maybe ON/ON/OFF/ON to open a garage door.

 

Hope this helps.

[johnmsch]

Yes, this is a big help. I've been reading through a very lengthy post here that was linked to in the Wiki. The one about the guy who wanted to open the garage door when he hit a key on his KeyLinc three times in a row. He basically uses this same concept. Took a while for all this to sink in, but now I'm getting lots of ideas of things I had not thought of before.

 

This forum is really awesome!

[northportphoneguy]

My wife thinks I need a life! Especially when the house gets a mind of it's own because I goofed a sequence.

 

"But Honey....it's my hobby".

 

Rolls eyes.....Yep, she loves me. Whew!!

[dnl]

Hi northportphoneguy,

 

The three programs you describe have a quirk you may or may not recognize. When 'Small Bedroom' is switched off the first time, the first program runs its Then clause that runs the flag program 'Virtual Flag'. The second program also runs when 'Small Bedroom' is switched off but, because Virtual Flag is false at that time, its Then clause is not executed.

 

If 'Small Bedroom' is switched off again during the 3-second window, the second program runs and, because 'Virtual Flag' is now true, its Then clause executes. The unexpected quirk is that the first program also runs again and restarts the 3-second window.

 

If 'Small Bedroom' is switched off a third time during the restarted window, the second program would run its Then clause again. The first program would also restart the 3-second window yet again. This may not cause any problems but it is something to consider.

 

More specifically, the longer sequence you suggest would not work without some additional logic to disable or inhibit the first program(s).

[northportphoneguy]

Yep, you're right. Thanks for saving additional 'wife eye rolls' while I figured that one out. But the double works fine for said wife. She double clicks the dressing room light on the way to bed, and 20 seconds later the whole house turns off. Cooool.

[northportphoneguy]

Hi dnl,

 

How about this for a thought experiment. To lengthen the sequence, if for each additional Detect, there would be an additional VirtualFlag. So in my example Detect3 would change VirtualFlag2...and so on. This way each Detect(n) program will have it's own flag associated with it, independent of all the others.

 

n_p_g

[dnl]

Hi northportphoneguy,

 

You are right that additional flag programs would be needed. Additional logic is also needed to tighten up the control of the 3-second (or whatever length) windows. In your original programs, the window can be restarted. If someone turned off the switch every two seconds, the window would keep restarting and the flag program would remain true. This would prevent the remaining programs from running the right way.

 

There are many ways this could be done. You could use additional flag programs or use enable/disable/stop commands to control program execution.

 

One way to do the programming that I recommend is to look at this as a series of different states. If we look at your original programs, we can express this in four states.

• 1. State S0 initializes everything to starting condition.
  2. State S1 occurs when the switch is toggled OFF.
  3. State S2 occurs when the switch is toggled OFF again within 3 seconds.
  4. State S3 occurs when the switch is not switched OFF within the 3-second window.

One program is written to control the change between states and another program is written perform the actions for each state.

 

This sounds a lot more complicated that it actually is. A very nice way to design the programs was written by ergodic. I have found his method very helpful when the programming gets complicated. See the thread "Triggers and conditions and IFs, oh my!" for details.

 

I have found a few ways to optimize his approach but I am still working on the details. I may write it up after I gain more confidence with my changes.

[dnl]

I woke up thinking about this post and realized I could have written just a little bit more to explain why the state-approach can be a good way to design programs.

 

If we start with the original example of how to handle two switch-OFFs, the state approach may seem much too complicated and not worth the extra effort. That may be true but it could be worth it if you need extra control. For example, the state approach would avoid restarting the 3-sec window if that is important and would allow you to do different things depending on whether the second OFF came within the 3-sec window or not.

 

I think the real value comes when you want to extend the programs for third, forth, fifth ... presses. They could be any sequence of ONs and OFFs.

 

I listed four states above. State S2 does one thing if a second OFF comes within the 3-sec window and state S3 does another thing if a second OFF does not come within the 3-sec window. If we do not want to do anything without the second OFF, then state S3 can be eliminated. When state S2 times out, it just goes back to state S0.

 

Let's keep the example of not doing anything if there is no second OFF. With this example, we can extend the programming to handle a third OFF by adding a single state. Now a new state S3 handles the third OFF. A state S4 could handle a fourth, and so on. Each additional state would require a very minor change to one existing program and two new programs that have the same structure used for the earlier states.

 

After you have programs working for two OFFs, it would be almost trivial to extend them to any number of OFFs and ONs.

 

This has strayed from the original topic of faston and fastoff. Sorry johnmsch. I did not mean to hijack your thread.

[johnmsch]

No problem dnl! This is all good information. I'm learning a lot here, but it still ticks me off that we have to jump through all these hoops since the double-click functionality is so unreliable and extremely difficult to implement.