Triggers and Conditions

[dnl]

I am very new to ISY programming and have a great deal to learn but I do want to add my voice to those who are requesting the ability to have separate tests for triggers and conditions. In the short time I have been writing ISY programs I have encountered more challenges from this than anything else. This feature would be more helpful than anything else and I can think of.

 

I know there are ways to program around the problem. This is not about what is possible or not possible, it is about what can make programs easier to develop and debug.

 

Others have suggested possible extensions or new features that could address this need. May I add one more way to approach this?

 

At present, the basic program structure is

If
   TESTS=True
Then

Else

where the TESTS operate both as events that trigger program execution and and conditions that control whether the Then clause or the Else clause is executed.

 

If changes in the ISY affect how the IF clause is processed, I believe there is a risk that existing programs could be broken by the change. If conditions are added outside the if/then/else structure, the same problem could occur.

 

But if we could be given a new feature inside the Then and Else clauses, I believe we could have what we want and minimize (or even avoid?) the chance of breaking existing programs.

 

An example of how this might be implemented looks like this:

If
   TESTS=True
Then
   Where
       CONDITIONS#1=True
   Do

   Otherwise

Else
   Where
       CONDITIONS#2=True
   Do

   Otherwise

The choice of the words where/do/otherwise is arbitrary. I just chose them to be something other than if/then/else to minimize possible confusion. It could be if/then/else.

 

The use of where/do/otherwise would be optional (it might not even appear on the programs detail page unless a user requests it) or it could be structured like the current if/then/else where the structure is always shown but the clauses are blank.

 

The if/then/else part of the structure would operate exactly the same as it does now. The CONDITIONS in the where/do/otherwise structure would be conditions only for controlling execution in the Do and Otherwise clauses. They would not be triggers.

 

Given this extension, we could manually modify our programs to take advantage of the new conditions. The Otherwise clauses would be much more useful that the existing Else clauses.

 

I believe this approach has at least one attractive feature, which is that existing programs could fit into the new structure with actions only in the Do clause. The "where" and "otherwise" clauses would be blank. The new structure should not break any existing program.

[oskrypuch]

But with that construct, you still have the ambiguity of execution between condition and event at the level of the IF clause.

 

I think the ON TRIGGER construct suggestions earlier are better, as they would step around that issue. But, in the absence of the ON TRIGGER clause, the statements would execute just as before.

 

But this whole issue deserves some thought and discussion, and perhaps in the end there will be some changes made by the clever developers.

 

* Orest

[dnl]

Hi orest,

 

You are correct if the IF clause in an existing program is left unchanged. No change in code, no change in operation. That is necessary if existing programs are not to be broken.

 

The proposed new structure allows you to write new programs with only triggers in the "if" clause and only non-trigger conditions in the "where" (or whatever you want to call it) clause.

 

Existing programs could be converted by keeping triggers in the "if" clause and moving all conditions that you do not want to be triggers into the new "where" structure.

[Goose66]

I submit that even in the "ON TRIGGER" or "WHEN" format that has been mentioned before, a simple conversion program could be written that would extract the triggers from the existing IF condition and place them in the WHEN clause such that existing programs would not be broken. This conversion program could run as part of the upgrade process to the new firmware version (I'll alpha test it thorougly).

 

Overall, I think the WHEN format is the most intuitive as to the way new ISY users (and old event-based programmers like me) think. WHEN A happens, IF B is true, THEN do C, ELSE do D.

[dnl]

Hi kingwr,

 

I agree with you. I have read your suggestions (even with screen shots of the proposed changes) and I have read suggestions by others and I would prefer almost any of them to what I have proposed. Yes, conversion could be automated.

 

So why did I make my proposal? I have not seen any indication from UDI that they are actively considering any of them. I feel pretty sure that they have not ignored them but it appears that none of those proposals will be implemented any time soon.

 

Here is what I am speculating:

• 1. The logic that processes the IF clause is a significant part of the ISY firmware and is the most complex part of it.
  2. UDI does not want to do anything that has significant risk of breaking any existing program.
  3. Any change that affects the logic that processes the IF clause introduces a significant risk of breaking an existing program.
  4. All proposals I have seen except for mine and a recent one by ergodic (see below) affect the logic that processes the IF clause.
  5. As a result, UDI will be very, very cautious and take considerable time before it implements any of those proposals -- maybe never?

In other words, I offer my proposal not because I believe it is better than what you or others have proposed but because I believe it may have a better chance of being implemented.

 

I believe ergodic offered his suggestion for similar reasons, which was a request for an uninterruptable program (sorry I do not know how to insert links into these messages but you can find his post by a search). I believe the changes needed to implement his suggested feature also have little or no risk of breaking existing programs.

 

I would be happy if ergodic's suggestion was implemented. That would be a big help and could reduce the need for other proposals. But I offer mine because I believe it can provide what we all want and offers even more flexibility than the uninterruptable program.

[apostolakisl]

4. All proposals I have seen except for mine and a recent one by ergodic (see below) affect the logic that processes the IF clause.

 

My suggestion does nothing to the "if" logic. It only changes the gui. As I mentioned, two programs is what it takes to separate the triggers from the non-trigger conditions. I have several programs written that way now. Zero change in logic necessary.

 

It does require changing the gui to make it appear as though the two programs are one and at the same time elliminating from view the components of the second program that are not necessary.

 

ISY logic is 100% untouched as are all of the programs already written.

[dnl]

Hi apostolakisl,

 

Sorry if I mischaracterized your suggestion. I think you have proposed one of the best solutions (write two programs with one disabled) for the current state of the art.

 

I am not certain where the boundary is between ISY internal logic and the GUI logic. It just seemed to me that any modification that would take what appears to the user to be one program and save it as two programs with one disabled (and do the reverse -- retrieve two programs and display them as one) would likely have to touch the part of ISY logic that processes the IF clause. My uncertainty comes from not knowing how the ISY and the GUI are implemented, particulary how they imlement program enablement.

 

In any case, I am not partial to what I have suggested. I would be very content if UDI implemented your proposal or kingwr's or orest's or ergodic's or ... developed something else entirely, as long as they would give this higher priority than appears to be the case at present. They could be working feverishly on this -- I don't know -- I just haven't seen anything that suggests it is being given much priority.

 

From what I gather after reading a lot of posts, I believe a fair number of people think this among the most important changes that UDI could make. After only a very short time writing programs, I agree.

[apostolakisl]

dnl,

 

I agree, I don't think UD has this as their top priority and perhaps rightfully so. It simplifies the user experience, but does not add functionality. I think they are prioritizing functionality at present.

 

I personally prefer added functionality since I know exactly how to create separate triggers and non-trigger conditions as is. But, for example, I can not create better integration with my Elk.

 

Of course if UD had a much larger R and D dept we might get both at break-neck speed. Big R and D comes from big sales, big sales come from a good product. Does functionality or usability have the greatest impact there? Kind of the chicken/egg thing. You need sales to get money to develop your product, you need a developed product to get sales.

 

Lou