oberkc Posted January 30, 2018 Posted January 30, 2018 I think it is triggering, but evaluating true and running then.... Agreed ‘Control’ is the trigger. Not in this case, during a dimming operation. The 'control not switched off" statement during a dimming operation is not triggering. ‘Not Off’ means any one of On, dim, brighten, fast on or fast off. Since dim is one of those, it may be true at the moment the status comes in as ‘not off’. "not off" is, simply, anything above zero. Therefore, ‘Then’ will run instead of ‘Else’ - as is being seen. Again, I agree, but am trying to reconcile this with a statement from an earlier post: So, both the first and second condition is false at the triggering event. If this last statement is true, "then" will not run (as claimed above). The ISY is behaving exactly as I believe it should be, given my understanding of the two conditions. I suspect I am failing to understand what you are saying.
MWareman Posted January 30, 2018 Posted January 30, 2018 OK - I've tested the two clauses separately... with a network event in 'Then' or 'Else' to send a Pushover notice (true or false) I created this program: aaaaaaaTest - [ID 02B6][Parent 0001] If Control 'Main / Kitchen / Dinette (near Vestibule)' is not switched Off Then Resource 'Pushover - M - TEST - True' Else Resource 'Pushover - M - TEST - False' The program IMMEDIATELY showed a 'True' status - but did not run either branch (no message pushed)... Dimming, Brightening did not trigger anything. Fast-on or Fast-off did not trigger anything. Off send a 'False' (Else branch ran) - as expected. On did NOT trigger anything... not sure if this is expected.... Why? 'Control' 'Switched Off' appears to be the trigger - and the 'Not' inverts the result (true becomes false). With the above program - there is no way to get the 'Then' clause to run... which is a surprise to me. Switching On should have caused 'Then' to run - but it did not.... Bug? Next test: aaaaaaaTest - [ID 02B7][Parent 0001] If Status 'Main / Kitchen / Dinette (near Vestibule)' is not Off Then Resource 'Pushover - M - TEST - True' Else Resource 'Pushover - M - TEST - False' Dim to about 50% - and let go - a single 'Then' runs... Bright to about 80% - and let go - a single 'Then' runs.... Dim to 0% - and let go - a single 'Else' runs... All as expected... Recreating... aaaaaaaTest - [ID 02B7][Parent 0001] If Control 'Main / Kitchen / Dinette (near Vestibule)' is not switched Off Or Status 'Main / Kitchen / Dinette (near Vestibule)' is not Off Then Resource 'Pushover - M - TEST - True' Else Resource 'Pushover - M - TEST - False' ON: Then runs Bright (and let go): Then runs Off: Then runs.... twice! Dim to Off: Then runs... In fact, I cannot get 'Else' to run at all with this program. Synopsis... Either clause triggers. And there are two discrete events - the 'Control Not Switched Off' that only triggers on an 'On' command.. Then the 'Status not Off' which processes a fraction of a second later - it's a separate instance of the program being run. Putting them together like this appears to be somewhat odd.. Again, split to two programs - each running the scene on their relative events...
apostolakisl Posted January 30, 2018 Posted January 30, 2018 Why? 'Control' 'Switched Off' appears to be the trigger - and the 'Not' inverts the result (true becomes false). With the above program - there is no way to get the 'Then' clause to run... which is a surprise to me. Switching On should have caused 'Then' to run - but it did not.... Bug? Not a bug, this is proper behavior. "switched off" is a specific thing. It is the physical act of single clicking the down paddle. "switched on" is the physical act of single clicking the up paddle. The only trigger in your program was the act of single clicking the down paddle. The program takes no notice of anything else, including pushing the up paddle. It is correct to say that the "not" simply inverts the logical result. In an "if" clause containing a "control not" (and with no "or's"), the "if" can only ever run the else clause.
apostolakisl Posted January 30, 2018 Posted January 30, 2018 aaaaaaaTest - [ID 02B7][Parent 0001] If Control 'Main / Kitchen / Dinette (near Vestibule)' is not switched Off Or Status 'Main / Kitchen / Dinette (near Vestibule)' is not Off Then Resource 'Pushover - M - TEST - True' Else Resource 'Pushover - M - TEST - False' ON: Then runs Bright (and let go): Then runs Off: Then runs.... twice! Dim to Off: Then runs... In fact, I cannot get 'Else' to run at all with this program. Synopsis... Either clause triggers. And there are two discrete events - the 'Control Not Switched Off' that only triggers on an 'On' command.. Then the 'Status not Off' which processes a fraction of a second later - it's a separate instance of the program being run. Putting them together like this appears to be somewhat odd.. Again, split to two programs - each running the scene on their relative events... The else can't run on this program because the "or" clause will always allow one or the other to be true. You get a double wammy on shutting the light off because you have two triggers hitting ISY. You get the "control off" first then a split second later you get a second trigger "status off". did you try hitting the "off" paddle while the light was alread off. This should run your else. If the light is off, then the statement "is not off" will evalute to else. And the statement "is control not switched off" will also evaluate to the else. EDIT: Just did some testing (on v 5.0.11b) and get crazy results. New Program - [ID 014A][Parent 0093] If 'Kitchen / Kitchen Intercom-Island L' is not switched Off Or 'Kitchen / Kitchen Intercom-Island L' Status is not Off Then $true += 1 Else $false += 1 off, press off false variable goes to 4 off, press on, true variable goes to 2 on, press off, true goes to 2, false to 3 (and yes, I reset to zero after each test) I won't go on. But this is weird. Edit: on, press on, runs True twice. That shouldn't do anything!!! No status change, no off paddle press. I suspect a v5 issue here but maybe not? edit again: It is the status clause. I removed the control clause and got two runs of "then". Vice-versa did nothing. And I moved this over to a non-variable situation. I had two switches that I set to beep (one for true, one for false), and I got the true switch to beep twice. OK, this has something to do with when I replaced the switches and used the "replace with command" a while ago. I posted this in version 5 issues. Something really weird happens where turning on the light causes ISY to show the status as on for a split second and then back to off (even though the light stayed on). I had to completely erase these devices from ISY and rebuild from scratch to fix this. So I need to fix these switches before I can use them for testing this issue. FINAL EDIT: I tested with a different switch that doesn't have that issue. The results were as expected. The same as you got, plus indeed, pressing the off paddle when already off does run the else. See this post for what weirdness ISY inserted when I used the replace with command. https://forum.universal-devices.com/topic/23423-replace-with-not-working-correctly/ Sadly, I have been replacing tons of switches in my house and this issue is killing me.
larryllix Posted January 30, 2018 Posted January 30, 2018 Switchlincs are composed of three separate and independent devices, that independently send their statuses and are independently detected by ISY condition logic statements. The pushbutton under the top of the paddle is detected by control switched On./ Fast On/ Brighten The pushbutton under the bottom of the paddle is detected by control switched Off./Fast Off/ Dim The dimmer electronics status is detected by status /On/Off/XX%
oberkc Posted January 30, 2018 Posted January 30, 2018 On did NOT trigger anything... not sure if this is expected.... I believe that is exactly as intended. But others have already pointed this out. The only thing I have to add is that your next statement seems inconsistent with the first: the 'Control Not Switched Off' that only triggers on an 'On' command.. This seems confusing to me as I read the results of your experiments.
tjkintz Posted January 30, 2018 Posted January 30, 2018 OK guys, I asked for explanations but didn't expect this; now I have a headache. Let me ask what I hope is a simple question about "... with a network event in 'Then' or 'Else' to send a Pushover notice (true or false)". I have never seen anything called a network event or a Pushover notice. I don't see that anywhere in Admin Console choices for Actions. Please explain. Keep in mind that my goal is the fewest lines of code, with no failure possibilities, to detect when the dimmer transitions to Off. It was really a prototype for other programs, especially some that involve a mini-remote. I thought this example was simplest because it only involved pushing a paddle. Most of my programs have to deal with paddle pushes and status changes from other programs. Yes, I could split things into multiple programs but that misses the goal of fewest lines of code. Side note: don't you wish there was an Else If clause in ISY? It sure would make things simpler and clearer. oberck's first post makes the most sense to me with a couple caveats. My background is in operating system development based on hardware utilizing an interrupt controller. I assumed any press of the paddle would generate an interrupt which ISY would interpret and then trigger a program that tested that device. However operck said the only way the first clause would trigger was via a Control Off. I expected the first clause to trigger on any paddle press but due to the Not condition to evaluate to True in all cases but Switched Off. I might be splitting hairs but I think there are subtle differences depending on how things actually work. The difference might be key to what I am experiencing with the mini-remote but that is another topic. I think his analysis of the logic is right though. If either of A or B is True the Then clause will be executed. The not Control Switched Off will always be True for all paddle presses other than Off. Therefore A will continue to be True and it really doesn't matter what B is; the Then clause will always execute. Switching to an And test makes B relevant. For anything but a control Off, A remains True but once the light gets to 0, B (status Not Off) becomes False. With A true and B false the else clause executes which is what I observed. It is curious that the light doesn't turn off until I release the paddle but I can life without understanding that. I can envision redundant actions which would not be visible to the user so I consider them benign. In my example, I could see that pressing off might cause one execution of the Else due to the first If clause and the resultant Off status cause a second execution of the Else clause due the second If clause. I guess it falls into the no harm, no foul category.
oberkc Posted January 30, 2018 Posted January 30, 2018 Personally, I would not worry about network events or pushover notices or whatever. Some of these guys are serious nerds (intended as a compliment) and really exploit some cool capability of the ISY. For folks like you (maybe) and me, stick with insteon events for now, I suggest. The "if control is......on/off/dim/bright/etc" are universal in that they trigger only by the specified command. A "control is switched on" will be triggered only by "on". A "control not switched off" is triggered only by an "off" command. Once a condition is triggered by any event, the entire clause is evaluated. I think you have got it there. A "control not switched off" is, indeed triggered by "off" only, and evaluates true at all other times. Feel free to perform your own experiments to confirm. Write a simple program if control is not switched off then nothing else nothing Turn the switch on...does it trigger the program (Check the log, I believe you will find not)? Turn it off...does it trigger the program (yes, and you will find from the log that it is false (last run condition)). Given this, it sounds like you are good with Boolean logic and have figured the rest out. If you have a specific problem that you are trying to solve with the least lines of code, state the problem, with specifics. Too many times, folks get on here and post their program and complain it does not work, without defining WHAT they are trying to achieve. Have fun. I am sure others will chime in.
tjkintz Posted January 30, 2018 Posted January 30, 2018 But I am a nerd! I may not find network events and pushover notices useful but I just want to know about them. I have never seen them mentioned before so a link to something that explains them would be appreciated. At the risk of derailing this thread further than I already have, let me elaborate on my needs and a specific, simple example. It all started with the mini-remote. I want to the keys to function as pure toggles; one press turns something on and another press tuns it off. If you don't already know, the mini-remote is an 8 button device. It can be configured as a 4 scene with pairs of buttons functioning as on and off, 8 scene toggle, 8 scene non-toggle. Conceptually I want the 8 scene toggle mode. However, toggle is not a pure toggle in that holding a button down will actually brighten and dim depending on if it is moving from on to off or vice versa. I don't want to have to test for Off, Fast Off, Dim or Fade down until status is Off, just to determine that I consider it toggling off. Not to mention repeatedly going through that much work for each program. So this implies the following program which seems intuitively logically correct: Mini Remote Test - [iD 003E][Parent 0001] If Control 'Test / Test - A' is switched Off Then Set 'Office Devices / S2, ceiling floods' Off Else Set 'Office Devices / S2, ceiling floods' On However this program does not work for the reasons discussed earlier; the only thing that will make this program run is tapping Off because that is what is being tested for. Any other sort of key press will not run the program at all hence the Else clause will never be executed. It follows that switching things around and testing for Not Switched Off also fails. The only thing that will ever run this program is a Control Off and then once it runs it will only execute one clause, never the other, depending on if you are testing Off or Not Off. For someone that has had a career writing software, this is the antithesis of intuitive. It seems that to cover all Control possibilities, each has to be explicitly spelled out in the If clause. For example, if I did not explicitly test for Fast Off and I did a Fast Off, I would guess the program would simply not run. IMO, this really sucks! Testing status seems much more flexible and easy to program for in that testing for status not Off will run the program as long as a new status is not 0. Once the program runs, logic can take over. However there was one case where I turned a mini-remote on and pushed a button. Unfortunately ISY and the remote status were not in synch and the button did not do what I wanted. That was why I started looking at Control again, thinking any button push would result in the program running since the If clause was testing Control and at that point logic would take over. Alas, that is not the case; it isn't testing control that gets the program running, it is just the specific controls that are being tested. Personally, my needs are best handled through status. I don't like writing a program that I know has a potential for failure but I think it is the lesser of two evils.
apostolakisl Posted January 30, 2018 Posted January 30, 2018 I think his analysis of the logic is right though. If either of A or B is True the Then clause will be executed. The not Control Switched Off will always be True for all paddle presses other than Off. Therefore A will continue to be True and it really doesn't matter what B is; the Then clause will always execute. Switching to an And test makes B relevant. For anything but a control Off, A remains True but once the light gets to 0, B (status Not Off) becomes False. With A true and B false the else clause executes which is what I observed. It is curious that the light doesn't turn off until I release the paddle but I can life without understanding that. The paddle press has to generate a trigger event. So, if you have "status" and the status changed, then yes, it will do what you say. But a paddle press that doesn't involve a status change (ie pressing on when already on) will leave the program sit idle. So you would need more lines of code in the "if" to capture things like that, unless you don't want to capture things like that.
lilyoyo1 Posted January 31, 2018 Posted January 31, 2018 I'm brand new to the ISY and learning how to program it. A first program I want is to do something if someone leaves an insteon light on for more than 2 minutes. Basically: Trigger:Light On Action: Wait 2 minutes, If light ON Then, ACTION If during two miutes, light off, then cancel program I need the cancel program, as I don't want it to happen if someone turns the light on, then off, and then back on and two minutes after the first action the action occurs because it's on after two minutes even though it went off before. I'd want the two minutes to re-start at the second turn on. I can't see how to do this. Any hints or pointers to a discussion of this before? I looked but didn't find it. Thanks! Why not add a motion sensor to the room. This could help prevent the light from turning off if someone was still in there regardless of how it was turned on.
stusviews Posted January 31, 2018 Posted January 31, 2018 It seems that to cover all Control possibilities, each has to be explicitly spelled out in the If clause. For example, if I did not explicitly test for Fast Off and I did a Fast Off, I would guess the program would simply not run. IMO, this really sucks! Any time you find a program that causes something to occur without explicitly specifying it, then you found a bug or an error in programming, most likely the latter
apostolakisl Posted January 31, 2018 Posted January 31, 2018 It seems that to cover all Control possibilities, each has to be explicitly spelled out in the If clause. For example, if I did not explicitly test for Fast Off and I did a Fast Off, I would guess the program would simply not run. IMO, this really sucks! What would really suck is if you couldn't explicitly call out each action on its own. If a program contained the line "if control switched on" but ran on every "control" Insteon message, you would lose a lot of control. I suppose it might be nice if there was a "control anything" option where you basically wanted the program to trigger with any physical action upon the switch instead of having to list them all out. But I would much rather have to list them out then not be able to pick and choose.
larryllix Posted January 31, 2018 Posted January 31, 2018 But I am a nerd! I may not find network events and pushover notices useful but I just want to know about them. I have never seen them mentioned before so a link to something that explains them would be appreciated. At the risk of derailing this thread further than I already have, let me elaborate on my needs and a specific, simple example. It all started with the mini-remote. I want to the keys to function as pure toggles; one press turns something on and another press tuns it off. If you don't already know, the mini-remote is an 8 button device. It can be configured as a 4 scene with pairs of buttons functioning as on and off, 8 scene toggle, 8 scene non-toggle. Conceptually I want the 8 scene toggle mode. However, toggle is not a pure toggle in that holding a button down will actually brighten and dim depending on if it is moving from on to off or vice versa. I don't want to have to test for Off, Fast Off, Dim or Fade down until status is Off, just to determine that I consider it toggling off. Not to mention repeatedly going through that much work for each program. So this implies the following program which seems intuitively logically correct: Mini Remote Test - [iD 003E][Parent 0001] If Control 'Test / Test - A' is switched Off Then Set 'Office Devices / S2, ceiling floods' Off Else Set 'Office Devices / S2, ceiling floods' On However this program does not work for the reasons discussed earlier; the only thing that will make this program run is tapping Off because that is what is being tested for. Any other sort of key press will not run the program at all hence the Else clause will never be executed. It follows that switching things around and testing for Not Switched Off also fails. The only thing that will ever run this program is a Control Off and then once it runs it will only execute one clause, never the other, depending on if you are testing Off or Not Off. For someone that has had a career writing software, this is the antithesis of intuitive. It seems that to cover all Control possibilities, each has to be explicitly spelled out in the If clause. For example, if I did not explicitly test for Fast Off and I did a Fast Off, I would guess the program would simply not run. IMO, this really sucks! Testing status seems much more flexible and easy to program for in that testing for status not Off will run the program as long as a new status is not 0. Once the program runs, logic can take over. However there was one case where I turned a mini-remote on and pushed a button. Unfortunately ISY and the remote status were not in synch and the button did not do what I wanted. That was why I started looking at Control again, thinking any button push would result in the program running since the If clause was testing Control and at that point logic would take over. Alas, that is not the case; it isn't testing control that gets the program running, it is just the specific controls that are being tested. Personally, my needs are best handled through status. I don't like writing a program that I know has a potential for failure but I think it is the lesser of two evils. Your example can never run Else. Test - A is either switched 'Off' or nothing is happening. For the logic to be evaluated the event has to occur and that makes that single logic line always True.
oberkc Posted January 31, 2018 Posted January 31, 2018 Mini Remote Test - [iD 003E][Parent 0001] If Control 'Test / Test - A' is switched Off Then Set 'Office Devices / S2, ceiling floods' Off Else Set 'Office Devices / S2, ceiling floods' On However this program does not work for the reasons discussed earlier; the only thing that will make this program run is tapping Off because that is what is being tested for. Any other sort of key press will not run the program at all hence the Else clause will never be executed. It follows that switching things around and testing for Not Switched Off also fails. The only thing that will ever run this program is a Control Off and then once it runs it will only execute one clause, never the other, depending on if you are testing Off or Not Off. For someone that has had a career writing software, this is the antithesis of intuitive. It seems that to cover all Control possibilities, each has to be explicitly spelled out in the If clause. For example, if I did not explicitly test for Fast Off and I did a Fast Off, I would guess the program would simply not run. IMO, this really sucks! Perhaps I am getting a little lost on your goals here, but (just in case it is not obvious) I am concerned you are using a program where an insteon scene is a better approach. In your example test program, I cannot help but wonder why you would not simply link Test-A as a controller to ceiling floods as a responder. I guess I am a little uncertain regarding what you want to accomplish. Are you trying to avoid dimming of the ceiling floods? Do you want them to have only two states (off and on) and to go to one of those two states even if you dim or brighten or fast on or off (in which case, why not put the ceiling floods on a relay device and use a scene)? Unfortunately, I can neither agree or disagree whether this is intuitive or not. I am not encumbered by prior experience. I know that you are not the first to make this allegation.
tjkintz Posted January 31, 2018 Posted January 31, 2018 Thanks for all the responses and suggestion. Let me address them individually. Re: Your example can never run Else. Test - A is either switched 'Off' or nothing is happening. For the logic to be evaluated the event has to occur and that makes that single logic line always True.", I know. That was the whole point of the post. "What would really suck is if you couldn't explicitly call out each action on its own. If a program contained the line "if control switched on" but ran on every "control" Insteon message, you would lose a lot of control. I suppose it might be nice if there was a "control anything" option where you basically wanted the program to trigger with any physical action upon the switch instead of having to list them all out. But I would much rather have to list them out then not be able to pick and choose." There is nothing I have said that would prevent explicitly testing for each control. I also reached your conclusion regarding control anything and I am going to suggest it to UDI. Conceptually it would have several advantages: 1) Any key or paddle press would run the program. Additional logic would control what happens. For example in pseudo code. If control switched anything and control not switched off then send message "Lights are on" else send message "Lights are off" This program would run the else clause if the lights were turned on, brightened or dimmed, without having to explicitly test for each of those. 2) No existing programs would be effected by adding control anything 3) No additional system overhead would occur as would be the case if any program testing control would run for each key/paddle push. Any time you find a program that causes something to occur without explicitly specifying it, then you found a bug or an error in programming, most likely the latter By testing not On I am explicitly testing for everything other than On. It is the job of the programmer to know what they are doing. In traditional programming languages it is normal to not explicitly test for everything and have a final clause that catches everything else. For example: If then <do something> else if then <do something> else <do something for all the other possibilities> The same thing is typically handled by Case: statements Perhaps I am getting a little lost on your goals here, but (just in case it is not obvious) I am concerned you are using a program where an insteon scene is a better approach. In your example test program, I cannot help but wonder why you would not simply link Test-A as a controller to ceiling floods as a responder. To do what I want, the foyer light would need to be a controller for a scene with all the closets as members. Also to replicate the foyer turning on if a closet light turns on and the foyer light turning off when the last closet light turns off the closet lights would need to be linked to the foyer. All this would sort of work but all closet lights would turn on when the foyer light turned on. Typically there is only one closet being entered at a time so that is wasted energy. Also, turning off any closet would turn off the foyer but there could be other closet lights still on and I wouldn't want the foyer light turned off. Why not add a motion sensor to the room. This could help prevent the light from turning off if someone was still in there regardless of how it was turned on. That is additional expense and it doesn't address turning the foyer light on or off depending on the closets. It could probably be programmed for but I am right back where I stated regarding programming. Besides, I have experience with motion sensors and they are far from 100% reliable.
apostolakisl Posted January 31, 2018 Posted January 31, 2018 There is nothing I have said that would prevent explicitly testing for each control. I also reached your conclusion regarding control anything and I am going to suggest it to UDI. Conceptually it would have several advantages: 1) Any key or paddle press would run the program. Additional logic would control what happens. For example in pseudo code. If control switched anything and control not switched off 'Control any' or 'control anything' would basically be saying, "the switch was touched". it would be a shortcut to current code: control switched on or control switched off or control switched fast on or control switched fast off or control switched dim up or control switched dim dowm I imagine adding it to ISY firmware would not require re-building anything. But what do I know about ISY back end.
tjkintz Posted January 31, 2018 Posted January 31, 2018 'Control any' or 'control anything' would basically be saying, "the switch was touched". Exactly! Hopefully that would run the program and the program logic could do what was desired. Currently you would have to have all those lines of code you listed (and I think two more) to be sure the program was run if the switch was touched. It is so much simpler with a control anything.
oberkc Posted January 31, 2018 Posted January 31, 2018 To do what I want, the foyer light would need to be a controller for a scene with all the closets as members. Also to replicate the foyer turning on if a closet light turns on and the foyer light turning off when the last closet light turns off the closet lights would need to be linked to the foyer. All this would sort of work but all closet lights would turn on when the foyer light turned on. Typically there is only one closet being entered at a time so that is wasted energy. Also, turning off any closet would turn off the foyer but there could be other closet lights still on and I wouldn't want the foyer light turned off. Perhaps it is time to step away from the programming side and state, in English (not programs or scenes), what it is that you want. I am confident that it can be accomplished. I have, personally, got to a point where I am very uncertain what you are trying to do here. Clearly there is a disconnect between what "you want" and what you have been able to accomplish. I tried going back over earlier posts but am not seeing a clear picture.
larryllix Posted January 31, 2018 Posted January 31, 2018 <snippage> By testing not On I am explicitly testing for everything other than On. It is the job of the programmer to know what they are doing. In traditional programming languages it is normal to not explicitly test for everything and have a final clause that catches everything else. For example: Not quite correct yet You are still testing for "On". It will not find Fast On, Off, or any other signal. 'NOT ON is a test for the On signal but running Else when it becomes true.
tjkintz Posted February 1, 2018 Posted February 1, 2018 I think I am done with thread since it seems to be going in circles and has ventured from its origin. I am probably responsible for the drift. I already have a program that does what I want. I have always had a program that does what I want. I chimed in on this thread to discuss the pros and cons of testing status vs. control. From there we got into an educational (at least for me) explanation of what I had observed but didn't know why. That was that the only way a program would even run was if a key press was exactly what was being tested for. It was a surprise to me that attempting to catch any other key press via an Else clause would never work because the program would not even run for those key presses. Despite multiple posts after I got it, phrases from my post built upon the fact I got it seem to be missed and subsequent posts assume I still don't get it. Trust me, I get it!
MWareman Posted February 1, 2018 Posted February 1, 2018 I was always under the impression that 'Control' is the trigger condition (ie: hitting the paddle is a control event) then the 'switched on' is a test of the condition... So - you would be able to effectively do a 'control any' by: (untested) If Control 'Switch' is switched On Or Control 'Switch' is not switched On This is the reason for program conditions like this (commonly recommended to get control of things): If Control 'Switch' is switched On And Control 'Switch' is not switched Off ..so that only If is run on an On paddle. That being said - I just tried testing for Control Dim - and it does not trigger.. odd...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.