Separating Triggers from Actions

[Smile4yourself]

ref. viewtopic.php?f=26&t=5731

 

I waded through this very interesting post (above) and learned:

 

1. separate triggers to a state, from what should happen while in that state. This is because a trigger that began the program can occur if the same program is in a wait or repeat statement, in which case, it will abort the program and cause it to begin over again, thus giving you misleading or unexpected results.

 

2. A program that runs the "then path" will remain with a status "true"

 

3. A program that runs the "else path" will result in a program status of "false" These values can then be tested with an "If statement"

 

My question is if these principals are still valid now that the ISY has variables. I think the wonderful tutorial was written before variables were added to the ISY.

 

I used the first principal effectively and did get the expected results, It does work, but you end up breaking up each program into two.

[LeeG]

Variables have not changed the way Programs work as far as Then/Else and True/False. Before Variables Programs were often used as binary flags (True versus False). That is no longer necessary with Variables but is not precluded. There would have been a significant impact to existing Programs if Variables altered the way Programs have worked for years.

[ergodic]

LeeG is right - using program state as a true/false indicator is mostly obsolete.

 

There is a newer (and better) methodology using variables here:

 

viewtopic.php?f=26&t=6395

 

A number of people have made nice refinements to this since, regrettably I don't have those links but they should be easy enough to find.

[oberkc]

I still like PROGRAM STATUS as a program condition. In most cases, for me, program status is a natural check. Use of variables can contribute to the need for extra coding in some cases.

[ergodic]

For situations where you the the ELSE clause is useful, I'd agree.

 

The problem is that the semantics of the ISY ELSE also are a source of endless, baffling confusion. (As evidenced by yet one more current thread on its convoluted logic http://forum.universal-devices.com/viewtopic.php?f=27&t=12160 that would do Bertrand Russell proud.)

 

Most people's minds simply don't work this way. I've been programming the ISY for years, and I still have to sit there and think about "If On AND NOT Off..." Apparently so do many others.

 

What would be most helpful is to be able to simply delete the ELSE clause. Or just make that the default and allow one to add one.

 

This obviously wouldn't affect existing programs or the ability to use an ELSE if you want to. But programs with no ELSE would only evaluate their THEN clause and start or re-start execution if true as one would expect. A FALSE evaluation would have no effect. The ELSE is not used more often than it is used, yet as currently implemented a null ELSE affects execution in some often unexpected ways.

 

In this case one could define such a program as always TRUE. Or I think much more usefully as TRUE when it is executing and FALSE otherwise. So it could still be used as a status test.

[oberkc]

Most people's minds simply don't work this way.

 

I am in no position to dispute the workings of most people's mind. I can only say that mine seems to find the feature useful. I can say, also, that my programming needs appear less ambitious than many around here. Perhaps that affects my perception. Only recently, have I found a program that I could not do without variables. In most cases for me, inclusion of variables added lines of code. I get a kick out of minimizing lines and numbers of programs, so perhaps I am a little strange in more ways than just my affinity for program status.

 

The problem is that the semantics of the ISY ELSE also are a source of endless, baffling confusion.

 

My sense is that, rather than baffling, that in programming the ISY one must learn and pay attention to the details. Also, a sense of boolean logic is useful. Most of the endless questions on the subject are initiated by relatively new folks, I also percieve. Perhaps not intuitive? Maybe. However, my experience is that power and flexibility often comes with the cost of a need to read the manual (or, in this case, seek help and advice from others).

[ergodic]

All I can say is review again the endless, continual posts about it on this forum. Call it my opinion if you like, but I sense an awful lot of company. And I'm not exactly a newbie. When something has to be explained over and over and over and re-examined over and over it's a pretty good clue that something's not right in the basic design.

 

And understand, I'm not saying ELSE isn't useful. A bifurcated THEN-ELSE logic is great when you need it.

 

And when you don't need it, you get it anyway, and that is plainly confusing to no good purpose. Especially given the limited debugging available in the ISY. You own posts on that latest thread illustrate the complex subtleties of this, and you're hardly a newbie either.

 

I'm only saying is there should be the option to not have the ELSE. That's it. Keep doing it they way you are, nothing changes. But programs without an ELSE wouldn't self-cancel and so will work the way most people expect them to. Where's the harm?

 

I would pose a question: what percentage of successful consumer tech devices on the market these days require you to carefully "read the manual?"

[oberkc]

I would pose a question: what percentage of successful consumer tech devices on the market these days require you to carefully "read the manual?"

 

The first ones that comes to mind are cell phones and computers. (Yes, I know. I assume that most don't read the manauls.) But, if we can imagine a world where nobody has seen or used one of these devices and, suddenly, we are trying to fully exploit one, how full would a forum like this be? Even in the real world, have you been over to the iPad or android forums lately? It is amazing the number of questions that are asked...over and over. I would imagine, too, that most of us here play tech support roles in our extended family for these devices for when there is something that a family member wants to do but doesn't know how (should have read the manaul).

 

I opine that for those who want a "no manual" experience...get the hub (and live with the limitations). If instead, you want an insteon controller with near-complete flexibility, then a little manual reading is not too much to ask.

[ergodic]

What ISY manual would that be?

 

Again, if a simple design change can reduce confusion and make things more intuitive without affecting anything existing, where's the harm?

[oberkc]

What ISY manual would that be?

 

http://www.universal-devices.com/docs/p ... 5%20v2.pdf

 

Although, about the manual, I was speaking more liberally, to include seeking further guidance (including from this forum or the universal devices wiki) when it is not self evident how to achieve desired results.

 

Again, if a simple design change can reduce confusion and make things more intuitive without affecting anything existing, where's the harm?

 

No harm, unless there are unintended consequences.