brianp6621 Posted July 16, 2015 Posted July 16, 2015 (edited) I understand and/or logic usually very well and use it often in excel/JMP but the ISY implementation is confusing. What i want to do is if a certain button is pressed(so on/off) AND it is nighttime, I want to do one set of actions (THEN). If the button is pressed and it is NOT nighttime, do the ELSE However my logic implemented below executes the ELSE at both the beginning and end of the window I specify, even when the button isn't pressed. How do I properly implement the logic I want? Edited July 16, 2015 by brianp6621
Jay Posted July 16, 2015 Posted July 16, 2015 I hear you Brian. Yes, Else isn't implemented in the way your intending this program to run. May I suggest you remove the ELSE on this program, duplicate the program (right-click COPY) and in the second copy of said program, reverse the time (so instead of sunset to sunrise, it's sunrise to sunset) and use the previous commands you had in ELSE statements as the commands you have in the new copied programs THEN statement. Leave ELSE blank on both. That should fix you up.
larryllix Posted July 16, 2015 Posted July 16, 2015 (edited) I understand and/or logic usually very well and use it often in excel/JMP but the ISY implementation is confusing. What i want to do is if a certain button is pressed(so on/off) AND it is nighttime, I want to do one set of actions (THEN). If the button is pressed and it is NOT nighttime, do the ELSE However my logic implemented below executes the ELSE at both the beginning and end of the window I specify, even when the button isn't pressed. isy.jpg How do I properly implement the logic I want? Time frame conditions are usually a little tricky in ISY logic at first. Time nodes will trigger re-evaluation of the complete logic statement and run the appropriate Then or Else section. To use a time frame as a condition and not trigger a program section it must be placed in a program that is Disabled (=no event trigger). Since your button presses demand triggers of a program, that program must be Enabled (=event triggered). This requires two programs to accomplish both conditions, enabled and disabled. Program 1 -------------- If control of button is switched On Or control of button is switched Off Then Run (If) program 2 Else -- Program 2 = disabled . We don't want sunrise to trigger else on it's own ------------- If time from sunset - sunrise (next morning) Then turn lights On Else turn lights Off Edited July 16, 2015 by larryllix
MWareman Posted July 16, 2015 Posted July 16, 2015 (edited) The ISY is event based. The 'If' is evaluated on triggers contained within it (the KPL switched on or off locally, the beginning and end of the window in your case). If the 'If' evaluates to true the 'Then' is run. Otherwise 'Else' is run. This results in what you see. At the beginning and end of the window, the If is evaluated - but the KPL buttons are not true. So, Else is executed. The other ways to solve it are move the window to a folder condition and remove from the 'If'. This will restrict the KPL button from triggering evaluation outside of the window. Or have a separate program update an integer variable based on time of day (these don't trigger 'If' evaluation on change) and then use the variable as a condition in your 'If'. Edited July 16, 2015 by MWareman
apostolakisl Posted July 16, 2015 Posted July 16, 2015 (edited) This issue is part of an ongoing discussion and strikes new users all the time. The issue is "unintended triggers". I have advocated for a checkbox next to each line of the "if" clause that allows you to activate or de-activate it as a trigger. In this program, you would de-activate the time conditions as triggers. It is the same concept as state and integer variables. In fact, you could eliminate integer variables if you had this feature since a de-activated state variable is a de-facto integer variable. Edited July 16, 2015 by apostolakisl
larryllix Posted July 16, 2015 Posted July 16, 2015 (edited) I like the addition of another section. The existing "If" section would be named "Trigger" to stay backward compatible with existing programs. The new section would be labelled "If" or "When" or "Condition" to take the place of the second, disabled programs, usually required, or folders performing the same thing but more obscure, and usually with time frames and device statuses in it. Same as apostolakisl above but different format and may force stricter code format. Will be interesting to see what v5.x brings. Edited July 16, 2015 by larryllix
apostolakisl Posted July 18, 2015 Posted July 18, 2015 I like the addition of another section. The existing "If" section would be named "Trigger" to stay backward compatible with existing programs. The new section would be labelled "If" or "When" or "Condition" to take the place of the second, disabled programs, usually required, or folders performing the same thing but more obscure, and usually with time frames and device statuses in it. Same as apostolakisl above but different format and may force stricter code format. Will be interesting to see what v5.x brings. That would work well. It would be sort of like Elk where the first line of a "rule" is the trigger and all other lines are conditions that are only tested after the first line triggers it. But what you are doing is allowing the "first line" to be as many lines as you like. Although my plan would not alter backward compatibility. When you first install the new firmware, all of your current lines of programs would default to having the "trigger box" checked. So functionality would be unchanged. And as you write new programs, the default would be to have the box checked, so someone who didn't notice the firmware update would keep going about their merry way with unchanged functionality.
larryllix Posted July 19, 2015 Posted July 19, 2015 That would work well. It would be sort of like Elk where the first line of a "rule" is the trigger and all other lines are conditions that are only tested after the first line triggers it. But what you are doing is allowing the "first line" to be as many lines as you like. Although my plan would not alter backward compatibility. When you first install the new firmware, all of your current lines of programs would default to having the "trigger box" checked. So functionality would be unchanged. And as you write new programs, the default would be to have the box checked, so someone who didn't notice the firmware update would keep going about their merry way with unchanged functionality. If a conversion app was written on a PC where the backup file was unzipped, massaged, rezipped, and then restored into the new firmware anything could be done during the conversion process. Individual trigger boxes may confuse the looks of the program trigger enable box. I could live with either. May be harder for programing the device/variable trigger engine list though, either way. Now you may have triggerable items and yet they don't need to trigger anything. eg. a State variable that is used in a program condition has a program If on it's checklist but doesn't trigger that program.
Recommended Posts