mikek Posted March 20, 2018 Posted March 20, 2018 In a situation where two programs are giving conflicting instructions, is there a simple way to prioritize or define which takes precedence?
oberkc Posted March 21, 2018 Posted March 21, 2018 Depends on the factors that drive the prioritization. Only the operator can decide what those factors are. If the factors are those which can be tracked by the ISY (such as time, status of other devices, temperature, moisture, weather, etc...) then I don't see why programs could not be developed to reflect the operator's priorities.
larryllix Posted March 21, 2018 Posted March 21, 2018 8 hours ago, mikek said: In a situation where two programs are giving conflicting instructions, is there a simple way to prioritize or define which takes precedence? Can you post examples? This could be real interesting to many here.
mikek Posted March 21, 2018 Author Posted March 21, 2018 I have a Homeseer HS-WS200+ wall switch. Unlike the dimmer in the same series, the switch only has one indicator LED. This LED has several configuration parameters associated with it, and I use a program to set those parameters based on time of day, a motion detector and a timer. That all works well. I have another program that controls those same parameters (but configured differently) based on the status of a handful of door/window sensors. That also works well. Both programs end with setting the parameters back to my default status. I'm trying to figure out what to do when the conditions of both programs are met. I'd like to somehow define one program as primary and the other as secondary, and allow the primary to override the secondary. So if the primary program is triggered and active, ignore the secondary. And if the secondary is already active, and the primary is triggered, abort the secondary and enable the primary. I think I can accomplish this with nested conditions, but I was hoping to keep the two programs independent and simply tell the ISY which one takes precedence.
Bumbershoot Posted March 21, 2018 Posted March 21, 2018 I have one of these, only it's a dimmer (Homeseer WD-WS200+, with the 7 LEDs), and solved what I believe is a similar problem using both variables and by disabling/enabling programs. My problem might be slightly more complicated that yours, in that I have to choose which LED to illuminate on this dimmer. The problem was straightforward except that I have two garage doors that I wanted to monitor the status of using the same LED on the dimmer. This proved to be trickier than I initially thought, and it took nine programs for me to accomplish this (I'm sure there's an easier way, but I got it to work so I've left it alone for now). The solution involved setting variables in programs, then disabling/enabling other programs that would set the same variable to a different value, based on which (or both) garage doors are open or closed. This might be an approach you could use. 1
lilyoyo1 Posted March 21, 2018 Posted March 21, 2018 Bumbershoot's example is what I would do to. If the condition of the most important thing is met, disable the program for the least important.
larryllix Posted March 21, 2018 Posted March 21, 2018 (edited) Sounds like a variable state stack process starting here. UDI! Can we have stack type variables where we can push and pull values in/out of a stack type variable? We should only require a depth of up to 32? Edited March 21, 2018 by larryllix
Michel Kohanim Posted March 21, 2018 Posted March 21, 2018 Hi larryllix, Not sure it's feasible with our current resources and everything else we need to do with 5.0.x (such as supporting string variables). With kind regards, Michel 2 1
larryllix Posted March 21, 2018 Posted March 21, 2018 1 minute ago, Michel Kohanim said: Hi larryllix, Not sure it's feasible with our current resources and everything else we need to do with 5.0.x (such as supporting string variables). With kind regards, Michel Well, the stack thing was a bit of a jest and probably not worth all the effort, but it is good to know about the strings in progress. I have used shifting list algorithms in ISY before with up to 10 variables. A small ISY program handled it satisfactorily.
apostolakisl Posted March 21, 2018 Posted March 21, 2018 (edited) Without the program details it is hard to say. However, if you are currently only using the "then" section of each program, then you should be able to use the "else" clause and merge the two programs into a single program. The "then" and "else" clause would contain your outcome priority 1 and priority 2 actions respectively. This would likely require using some well thought out "and's", "or's" , "nots" and "()". Also, it might be easier to disable both programs but otherwise leaving them as is. Then add a third program. The third program contains in its "if" 1) the trigger conditions, and 2) the conditions that differentiate the other two. Populate the "then" section with a "run if" on program 1, and the "else" with a "run if" on program 2. Edited March 21, 2018 by apostolakisl
oberkc Posted March 21, 2018 Posted March 21, 2018 5 hours ago, mikek said: I have a Homeseer HS-WS200+ wall switch. Unlike the dimmer in the same series, the switch only has one indicator LED. This LED has several configuration parameters associated with it, and I use a program to set those parameters based on time of day, a motion detector and a timer. That all works well. I have another program that controls those same parameters (but configured differently) based on the status of a handful of door/window sensors. That also works well. Both programs end with setting the parameters back to my default status. I'm trying to figure out what to do when the conditions of both programs are met. I'd like to somehow define one program as primary and the other as secondary, and allow the primary to override the secondary. So if the primary program is triggered and active, ignore the secondary. And if the secondary is already active, and the primary is triggered, abort the secondary and enable the primary. I think I can accomplish this with nested conditions, but I was hoping to keep the two programs independent and simply tell the ISY which one takes precedence. mikek, is the likelihood of primary and secondary programs becoming true simultaneously something that we need to worry about? (I assume not, based on your description.) It seems to me the simple approach is, conceptually:, adding a condition to the secondary program: if existing secondary conditions are true and primary program is false then run secondary actions else nothing Does the secondary program have any "wait" or "repeat" statements? If not, aborting the program has no meaning. If so, simply add an action in the primary program to halt the secondary program. 1
mikek Posted March 21, 2018 Author Posted March 21, 2018 apostolakisl - I think your option #2 is just what I need. Keeping the programs separate and triggering one or the other with a third program. Thanks! oberkc - There is nothing preventing the two programs from triggering simultaneously, but the likelihood is low enough where I wouldn't concern myself with it happening. Thanks for the idea about the added conditions. Yes, the secondary program does have a wait.
apostolakisl Posted March 21, 2018 Posted March 21, 2018 2 minutes ago, mikek said: apostolakisl - I think your option #2 is just what I need. Keeping the programs separate and triggering one or the other with a third program. Thanks! oberkc - There is nothing preventing the two programs from triggering simultaneously, but the likelihood is low enough where I wouldn't concern myself with it happening. Thanks for the idea about the added conditions. Yes, the secondary program does have a wait. Hope it works. Please note: if you have any "control" trigger conditions, these will need to be deleted from your two downstream "if' sections. A control condition is only true at the instant it happens, so the ever so slightly delayed "run if" won't still be true. For example, "if light x is switched on" will always be false in one of your secondary (disabled) programs.
Recommended Posts