Can't seem to find the right trigger when buttons are 'misused'

[mango]

Hi all,

This must be easy, but I seem to be unable to find it:

I have a couple of areas running KPL's and SL's that I require to remain at a constant brightness level via a scene I refer to as 'main'.

Should a user 'accidentally' double press ON or manually hold down ON to ramp up, a program detects this and fires back the main scene  to ON as a response.

What I am unable to detect is if a switch is already ON, then the ON button is pressed once more, the lights ramp up to 100% and the program does not detect it. I have tried both STATUS and CONTROL states. Any pointers?

I have tried all sorts of things such as

or if status =100%

or if control =100%

Here's a basic program I have running. In this instance the scene keeps CHANDELIER at 10%.

 

Return to Preset - [ID 007A][Parent 002D]

If
        'Living Rm / SL Dimmer - CHANDELIER' Status > 11%
     Or 'Living Rm / SL Dimmer - CHANDELIER' is switched Fast On
 
Then
        Set 'Living Rm / Lounge Main' On
 
Else
   - No Actions - (To add one, press 'Action')
 

 

[lilyoyo1]

Directly linked devices will always respond in that way since the command comes directly from the device. There's no way to override that with a program. 

You can remove the controller from the scene and then use Control to trigger the responders when it's pressed. That would do away with devices changing when double tapped

[mango]

Thanks Lilyoyo1,

Strange that I can catch a double tap, or a manual hold down to ramp up, but not a second press? This is a local load device. The switch powers the load.

I use programs sparingly, and try to keep most of the day-2-day workings of the environment to be outside of the ISY with controller/responder scenes.

[mango]

So, then perhaps a dinosaur approach with a timer that is a activated when the scene is turned on, to periodically check (every 5 seconds or so) for the load to be 100%.

What a waste of resources this way, there must be a more economical method?

[mango]

Excuse my constant editing of posts. I have a few problems with communication including grammar and I see the errors once posted that appeared fine before posting.

[lilyoyo1]

10 hours ago, mango said:

Thanks Lilyoyo1,

Strange that I can catch a double tap, or a manual hold down to ramp up, but not a second press? This is a local load device. The switch powers the load.

I use programs sparingly, and try to keep most of the day-2-day workings of the environment to be outside of the ISY with controller/responder scenes.

I'm not following. Is the issue with the kpl or swl? A second press (not double tap) on a lol should result in an off command turning everything off. Hitting a swl on a second time will result in another on command turning everything on (if at a dim level). 

You can capture double tap, dim down and dim up because those are commands insteon sees and has. A second press is a second press. Still an individual tap. The isy cannot discern what your intentions are. Was it inadvertent, intentional, etc. It just knows the button was pressed resulting in the corresponding command to be sent. 

 

[lilyoyo1]

9 hours ago, mango said:

So, then perhaps a dinosaur approach with a timer that is a activated when the scene is turned on, to periodically check (every 5 seconds or so) for the load to be 100%.

What a waste of resources this way, there must be a more economical method?

A timer isn't needed and is the wrong way to fix this. You could use variables to track a second press to accomplish what you want. Personally, i feel this is a training issue.

When you get into automation, it's much different than what people are accustomed to.

If people are turning things off/on improperly then you're better served teaching them the proper way of doing things so that is done right the first and every time. Yes programming can help alleviate mistakes but it can also have unforseen consequences which can cause other problems down the road. 

Keep your setup consistent so that memorizing things are kept to a minimum and you'll find things will work much much smoother.

[mango]

2 hours ago, lilyoyo1 said:

 

I'm not following. Is the issue with the kpl or swl?

 

This is for any switch, KPL or SWL. a single tap ON turns on the switch to it's preset on level. A second tap ON turns the switch to 100%. It is this second tap I am unable to track via the ISY using either status or ON level through if.

Am I missing something simple? Should it just be:

Or 'Living Rm / SL Dimmer - CHANDELIER' is status is 100%

because it's not catching it.

The location is going to be used by guests that I am unable to 'train' to use the switches properly.

[lilyoyo1]

Unless double tapped, a keypad should turn off on a second press (if it's in toggle mode). Only switches will turn 100% on when it is pressed a second time since on is always the default command built into the device.

You cannot override default behavior with the isy. You can only have the isy adjust it once done. 

You could use the status of the light to adjust the light downward. The problem with that is it will always dim even for the times you may want the light 100%.

If you're that concerned about a second tap, using variables is the best way to go. It can see the second press and adjust the light after the fact. Keep in mind, the same thing from above applies. Should there be a need for 100%, the lights will not go to it. 

If this is a guest only location, why bother automating it in that way? You'll cause more confusion and headache trying to program for vs keeping things as normal as possible for people who are not accustomed to that. 

Here's a video on variables 

https://youtu.be/d8sHbgWc0vQ

 

 

[mango]

It is not a guest only location, but there will be times when guests are using it. It's a cottage address.

The scene on levels are certainly high enough in the way of light levels. Most locations have 60w equivalent bulbs that I prefer to use but when they are full brightness it is much too bright, if that makes sense. 100% in these locations is too high.

Do you know which function will catch this: Status or control? I've tried both and the program does not trigger.

To put it another way, what 'if' line do I need to add to catch the second press which causes the switch to go to 100%?

 

I appreciate your help thank you.

[lilyoyo1]

A variable is the best method. The link I sent earlier showed how to set that up.

You could use status. 

If status of light is 100%

Wait 2 seconds

Then set to 60%.

The wait is there to ensure the isy has time to process everything

[mango]

ahh it could be the wait, I tried if status is 100%, I will view the vid and try the wait time, thanks!

[xlurkr]

I think the problem is one I noticed a few months ago - that the ISY does not change the status of a switch when it is turned on a second time.  The status remains at the pre-defined ON level of < 100%, if that's how it is defined.

I just checked, and if the on level is defined as 100%, and you programmatically lower it, then when the light is turned on again, status correctly shows 100%.  So maybe you need to set the light's ON level to 100%, and lower it to wherever you want it every time it is turned ON from OFF.

-Tom

[lilyoyo1]

If the isy doesn't show 100% based off the button press, then status will not work since it'll be wrong. Using variables is the only way to accomplish what you want

[MrBill]

14 minutes ago, xlurkr said:

I think the problem is one I noticed a few months ago

This is what I thought too... I looked briefly for that thread to link it but couldn't remember enough details to find it.

[mango]

3 hours ago, xlurkr said:

I think the problem is one I noticed a few months ago - that the ISY does not change the status of a switch when it is turned on a second time.

My goodness, I never even considered looking at the switches status on the second tap. You are quite correct the switch does not send its new status out. The ISY is none-the-wiser.

Thank you!

 

[mango]

3 hours ago, lilyoyo1 said:

Using variables is the only way to accomplish what you want

The $64k question would be, how can variables help if the status change to 100% is completely transparent to the ISY?

[lilyoyo1]

4 minutes ago, mango said:

The $64k question would be, how can variables help if the status change to 100% is completely transparent to the ISY?

Did you watch the video? It explains how it would help you? 

[mango]

No, not yet, working today but I will this evening thank you.

[xlurkr]

10 hours ago, lilyoyo1 said:

Unless double tapped, a keypad should turn off on a second press

This may be true for the non-load-controlling keys on a KPL, but I believe that the KPL load acts like a dimmer or relay, so it will go to the ON level on first press, then 100%, then ON level, then 100%, etc.

Looking at the Event Viewer, it looks like an ST event is triggered when the switch is turned on manually ONLY if the status is not the same as the ON level when it happens.  If so, it goes to the ON level (whether that is higher or lower than the status; i.e, down or up) and there's an ST command.  If it is at the ON level, it goes to 100%, with no ST command.  So maybe the solution will involve setting the light programmatically to be 1% away from the ON level, so you will always get an ST command if it's manually manipulated.  Also, turning the switch on, no matter what its current state, always generates a DON 0 event, so maybe just look for those somehow.  Dimming doesn't generate a DON 0, but does always lead to an ST event, in my testing.

-Tom

[mango]

1 hour ago, xlurkr said:

So maybe the solution will involve setting the light programmatically to be 1% away from the ON level, so you will always get an ST command if it's manually manipulated.

Ahh, nice thinking, so have the switch tweaked 1% away when manually turned on (first press). That would be undetectable. I think I understand, I will give it a shot tomorrow hopefully as well as check the variable video, I've had to work later than planned...

[lilyoyo1]

1 hour ago, xlurkr said:

This may be true for the non-load-controlling keys on a KPL, but I believe that the KPL load acts like a dimmer or relay, so it will go to the ON level on first press, then 100%, then ON level, then 100%, etc.

Looking at the Event Viewer, it looks like an ST event is triggered when the switch is turned on manually ONLY if the status is not the same as the ON level when it happens.  If so, it goes to the ON level (whether that is higher or lower than the status; i.e, down or up) and there's an ST command.  If it is at the ON level, it goes to 100%, with no ST command.  So maybe the solution will involve setting the light programmatically to be 1% away from the ON level, so you will always get an ST command if it's manually manipulated.  Also, turning the switch on, no matter what its current state, always generates a DON 0 event, so maybe just look for those somehow.  Dimming doesn't generate a DON 0, but does always lead to an ST event, in my testing.

-Tom

It's true for all keypads in regards to turning on and off. A 6 button kpl would be the same as a dimmer since it's on and off are separate (didn't add that tidbit). An 8 button in default mode toggles on/off. Depending on the level, you can dim up from a low level or dim down from higher levels. 

Regardless, for what he wants to accomplish and why, any other method other than variables will most likely lead to more programming to make up for something else that goes wrong with those methods

[xlurkr]

Thanks for the clarification.  I only have 6 button KPLs, but I can understand why an 8 button toggles the load on/off by default.  There's no off button!

I still don't see how variables can fix the following issue: a switch doesn't appear to generate either a control or status event if it is turned on when it is already at its ON level.  Without a means to trigger the ISY to know this has happened, how can the ISY do anything to establish the desired state?

If you suggest using variables along with not having an ON level of <100%, then I get it.

-Tom

[xlurkr]

I forgot to add: having an ON level of <100% is really nice built-in Insteon behavior.  If the ISY is down, or you want to or need to remove it from the environment, you can still have a low lighting level set with the first press, and go to 100% with the second.  I remember loving it when I was first starting out with Insteon and didn't have my ISY, 20 years ago.

-Tom

[lilyoyo1]

7 hours ago, xlurkr said:

Thanks for the clarification.  I only have 6 button KPLs, but I can understand why an 8 button toggles the load on/off by default.  There's no off button!

I still don't see how variables can fix the following issue: a switch doesn't appear to generate either a control or status event if it is turned on when it is already at its ON level.  Without a means to trigger the ISY to know this has happened, how can the ISY do anything to establish the desired state?

If you suggest using variables along with not having an ON level of <100%, then I get it.

-Tom

As in life, there's no elegant fixes for behavioral fixes. Nothing is really going to fix his issue perfectly as there are other variables that will inevitably come into play. Going that the rabbit hole will cause more problems long term than it solves.

Personally, I'd leave well enough alone and show guests how to use things properly rather than deal with trying to program my way out of it. 

variables can help with the swl (the way he describes the situation this sounds like it's the problem). Whether it's a double tap or a second press in general, the isy can capture that via the variable (including programming) and trigger the proper scene based on the second tap regardless of what the light level the switch is showing. 

1 tap would move the counter to 1 and the scene would run as normal. Should a person tap it a second time, the counter would move to 2, his program for the second tap would then see it and run causing the lights to go back to their normal level. Once he turns off the switch, the counter would reset, restarting the whole process over again. 

There are other factors at play which could impact things, which would require additional programs to account for. This is why I said earlier that there are no elegant solutions.