Single events, statused, timings

[Guy Lavoie]

Hello. I'm just getting started with a ISY994i and PLC that I bought used for almost nothing. I'm a long time ADI Ocelot user and some will recognize my name if you remember the ADI forum. I got the ISY994i because it was such a bargain, and thought it would be a fun thing to try out, and possibly add functionality to my Ocelot based X10 system. They might complement each other nicely since the ISY994i has networking features. Anyways, I'm just trying to get a sense of how the if/then programming works, compared to the Ocelot. In particular, how tests for single events vs static statuses works, and which ones it supports. The Ocelot is particularly versatile in that regard, and allowed triggering on raw X10, command pairs, status change, and existing status. For example:

If X10 A/1 is received...  (if raw X10 address or command is received)

If X10 A/1 ON command pair    (if a command pair is received)

If X10 A/1 Turns ON     (if the status for that X10 address changes from Off to On)

If X10 A/1 Is ON      (if the status is currently On, often used with AND statements)

This is very versatile, but also allows for mistakes, such as if you use "Is ON" instead of "Turns ON" to then send other commands: it sends continuously because the test is that of a static condition.

 

From the bit of exploration I've done with the ISY994i, a statement such as "If A/1 Status is ON", it actually means if the status "becomes" ON, not a static condition. I'm deducing thing from the fact that the programming allows a THEN statement to send commands, and also a ELSE statement to do that. Similarly, the ELSE statement seems to imply the opposite status of the same test becoming true (so it's not an ELSE IF, just ELSE).

I also don't see any timers, or haven't found an equivalent yet. For example, with the Ocelot I could look for a X10 command pair, and start a timer (that increments every second). Then have another program section look for reception of that same command pair while the timer is running, and finally a third program section stop the timer if it reached a certain value, say 5 seconds. This allows me to look for the reception of a X10 command pair, and if I receive it again within the time interval (by double tapping a X10 transmitter), then trigger a second action. I use this to turn off all the kitchen lights if the switch is tapped twice. Can the ISY994i do this kind of thing?

Thanks!

[Geddy]

@Guy Lavoie welcome to the Universal Devices forums. A lot of what you're asking can be found in the "ISY Cookbook" that's found in the UD Wiki pages (https://wiki.universal-devices.com/Main_Page).

The ISY994 has been discontinued (thus probably the reason you were able to get it "cheap"). It still works and is operational at many levels. Some of the documentation/examples in the ISY Cookbook are from older firmware versions for IoX (formerly ISY). Just know official support from Universal Devices is no longer offered. However, the user-to-user help on the forums is always available to help troubleshoot and give guidance.

I'm not familiar with x10 signals, but many here are. Hopefully they can help with some of the specific questions you might have. 

There isn't a "simple" way to make a timer like you're thinking, but there are options. I searched on the wiki and found this topic:

https://wiki.universal-devices.com/ISY-99i/ISY-26_INSTEON:Programs_as_Variables:_SwitchLinc_Emulates_Countdown_Timer

(Note the link at the top to a different document as well)

One thing to note about ISY programming...the "IF" statement is always being evaluated. Therefore, when your program triggers "TRUE" it will trigger the "THEN" portion. Otherwise, when "FALSE" it will trigger the "ELSE" command. Many programs will only have a "THEN" portion. 

If you have specific programming questions head over to the IoX Program Support area and post in there.

https://forum.universal-devices.com/forum/438-iox-program-support/

Be sure to let us know what you're trying to accomplish and read how to post programs to the forums. Posting programs as text is the preferred method.

Again, welcome to the forums. Good luck learning! 

[Guy Lavoie]

Interesting, thanks for the pointers. I like to learn by writing and testing small examples. 

I do see a "wait" action. I suppose a timer could be implemented by setting a variable to a non-zero value, and have a separate program that as long as the variable is non-zero, waits one second (or whatever granularity you want) and increments the variable by one. I just might test that as one of my first experiments.

[Geddy]

@Guy Lavoie just be aware that if using "wait" should the program turn false while waiting the program will stop running (or run the "else"). If you're going to use the wait sometimes it might be better to break it into multiple programs. You can have programs that have nothing in the "IF" statement and you can use the trigger program to process the "THEN" or "ELSE" of another program. In that other program would be the "wait" portion and not be impacted should the "IF" of the first program be re-evaluated and turn false. 

Good luck!

[Guy Lavoie]

I just tested it, and works perfectly. I created a state variable called Timer1, and created a standalone program that tests if it's greater than zero (which will always test true as long as it isn't reset to 0), waits one second, and increments the variable by 1. I now have a timer and can be used in a composite conditional situation, such as if a trigger occurs, and another trigger occurs within a time interval. I've used this on the Ocelot for that double tap function I mentioned in my first post. Another use is for a bathroom fan timer. You might want to turn on a bathroom fan that will automatically turn off after so many minutes. Using "wait" confines you to a fixed value, while using a timer like this allows you to add time by retriggering the same or a different event. Here is the logic, in pseudo code:

 

IF turn_on_bathroom_fan trigger

AND Timer = 0                                      (if fan first turned on)

    THEN fan_ON action

    THEN fan_time = 600      (default of 600 seconds)

    THEN set Timer to 1        (start the timer)

IF turn_on_bathroom_fan trigger

AND Timer > 0                                      (if fan is already running)

    THEN fan_time = fan_time + 120     (add 120 seconds to run time)

If Timer > fan_time

    THEN fan_OFF action      (turn off the fan)

    THEN Timer = 0               (stop timer)

 

[paulbates]

Hi @Guy Lavoie, I do remember you from my ADI Ocelot days! It's part of my ha lineage and a lot of hair ago. I believe udi and the isy will resonate with your Ocelot experience... Powerful yet relatively easy to do and maintain

[Guy Lavoie]

Hi Paul. Oh yes, my days of participating and moderating the ADI forum will always remain as great memories, as the number of people I've exchanged with. My Ocelot is still running strong and isn't going anywhere, especially with the expansion modules. I sort of happened upon the ISY box my chance, and because it supports X10 too, I thought it was interesting and worthwhile to check out. It seems to be what a next generation Ocelot could have been. The used one I bought has the X10 and Networking modules in it, which perfectly fits the bill for me. It also has a "Open ADR" module, for which I can find configuration documentation, but nothing about what it actually does. The networking module is of interest to me, because I could integrate it to my current setup of the Ocelot and HA bridge, which provides Alexa functionality. I created my own HA bridge to X10 bridge program using VB and a CM11A, but maybe the ISY could now do that.

What I'm doing at this time is simply familiarizing myself with the ISY programming model. Like the Ocelot, it's a PLC style language, using ladder logic (which is what drew me to the Ocelot in the first place). However it seems to be trying to look like a somewhat higher level language, breaking up the long loop into separate "programs", and from what I can see so far, tries to "idiot proof" the user by allowing only single triggering events for IF statements. If it was me, I'd replace "Is On" by "Turns On" to reflect triggering on the status change. Minor stuff really, and doesn't take anything away from the functionality, and that I'll quickly get used to. I've already solved the missing timers issue!

So I'm looking forward to figuring out and trying things...and exchanging with other users!

[Guy Lavoie]

One question comes to mind. The same options appear for a device status, whether it's a IF statement or AND statement. For example:

IF

            Hall light Status is On

AND  Door light Status is On

 

Knowing that the IF statement is actually looking for a status change, does this mean that the AND statement is also looking for a status change (and not just the current, static status)? This would be impossible to do because they cannot really change status simultaneously. Is there a way to check just the current status? A workaround would be to have a separate program look for the door light status change and set a variable value, then have the above code AND with the variable. That would be rather clumsy. Seems it would make more sense for IF statements to show "Status changes to" instead of just "Status", and let AND statements check current status. Maybe I'm just not seeing it correctly either...

That's the kind of thing I'm trying to learn.

[Techman]

Anytime a condition in the IF statement changes, the IF statement is reevaluated.

If all the IF conditions are true the THEN clause would run. If not all of the IF conditions are true the ELSE clause would run

 

[Guy Lavoie]

6 hours ago, Techman said:

Anytime a condition in the IF statement changes, the IF statement is reevaluated.

If all the IF conditions are true the THEN clause would run. If not all of the IF conditions are true the ELSE clause would run

 

Thanks, but that doesn't answer my question...

Let me rephrase it. Here is a quote from page 127 of the cookbook:

8.2.14 Using ‘If Control’ versus ‘If Status’ in Programs16 The reason to use control condition is that a control will trigger a program evaluation upon EACH receipt of the anticipated command. Unlike control, a "status" condition will trigger an evaluation only after a CHANGE in status. If a device status is off, and you turn it off again, the status has not changed and no program evaluation will take place.

 

I understand that to mean that "control" will trigger the program every time the activating command is actually received, like getting a X10 "A/1 On" command pair, regardless of the fact that it might have been already turned on.

"Status" means it triggers if the internal status table for that device changes from off to on because this is the first time a X10 "A/1 On" command pair is received since it was last turned off.

But what if I only want to check if the status is currently on or off? Just the static condition of the internal status table (no received commands at this time)? In my example above I'd like to trigger if the status of the hall light goes from off to on (it's status changes) AND the door light is already on.

[Techman]

Control - when a device is manually turned on or off

Status - is the current state of the device.

If you wanted to check the status of a device and perform two diffenent functions depending on its state, then you would need two programs. One that would equate to true if the device was on, and a second program that would equate to true if the device was off.

The following program will will trigger the THEN statement in the program if the light switch is physically turned on at the switch, and the door light is currently on.  

   IF

         Door light status is ON

         and

          Hall Light is switched ON

THEN

        do whatever

ELSE

 

 

[Guy Lavoie]

Thanks Techman. That's the way I see the meaning of "Status". It's just that it seems to be contrary to what the cookbook says:  

Unlike control, a "status" condition will trigger an evaluation only after a CHANGE in status

According to that quote, if the door light was already on, then the IF statement will test false because no status change occurred.  IF (false) AND (true) = false, and won't trigger...

Unless "trigger an evaluation" actually means "trigger an action" if the whole logic test (IF/AND/OR...) is true. It just might be the wording.

 

In my experience with Programmable Logic Controllers, logic tests are ALWAYS evaluated, and actions (THEN...) are only taken if the resulting test is true, and any ELSE if false.

 

Edited July 27 by Guy Lavoie

[larryllix]

7 minutes ago, Guy Lavoie said:

Thanks Techman. That's the way I see the meaning of "Status". It's just that it seems to be contrary to what the cookbook says:  

Unlike control, a "status" condition will trigger an evaluation only after a CHANGE in status

According to that quote, if the door light was already on, then the IF statement will test false because no status change occurred.  IF (false) AND (true) = false, and won't trigger...

Unless "trigger an evaluation" actually means "trigger an action" if the whole logic test (IF/AND/OR...) is true. It just might be the wording.

 

Insteon, and most other, devices are updated by events that happen at the sensing end.
For Insteon lightswitches and many other Insteon devices, status is the current status of the electronic dimmer circuit and sends updates when it changes,
 "control switched" is the current status of the actual switch paddle and sends updates when it changes (pressed).

Querying a device asks for the current status of that particular circuit or part and the paddle switch  would always send "not pressed" so is not supported with a "status" control.

IOW, it is two devices in one box and uses two different styles of update syntaxes to identify which one you want.

[Techman]

5 hours ago, Guy Lavoie said:

According to that quote, if the door light was already on, then the IF statement will test false because no status change occurred.  IF (false) AND (true) = false, and won't trigger...

 

 

In the example I gave your earlier, The IF statement looks at the existing state of the door light. If the door light is ON and the light swtch is turned on by pressing the switch paddle (control), the IF clause would be true.  Both statements in the IF clause would have to be TRUE for the THEN clause to run.

If you turned the Hall Light switch OFF or if the door light is OFF when the Hall Light is turned ON or OFF,  the IF clause would be False and the ELSE clause would run assuming that it was populated.

 

 

[Guy Lavoie]

Ok, that's great if this is the case. It simply appears that the text in the cookbook is poorly written and seems to imply that a CHANGE in status is needed to have a status test true and trigger.

Thanks!

[Techman]

Best way to work through this is to write some test programs using your Hall Light and Door Light.

[Guy Lavoie]

2 hours ago, Techman said:

Best way to work through this is to write some test programs using your Hall Light and Door Light.

Agreed. I'll post about any findings that don't appear to be clear.

[oberkc]

13 hours ago, Guy Lavoie said:

Ok, that's great if this is the case. It simply appears that the text in the cookbook is poorly written and seems to imply that a CHANGE in status is needed to have a status test true and trigger.

I believe Techman was trying to make this point.  There are program triggers, and there are program conditions.  To use your example:

 

IF

         Door light status is ON

         and

          Hall Light is switched ON

Such a program has two conditions.  Either condition may be a trigger for the program to evaluate.  Once either condition is triggered (by a change of state), however, the entire IF statement is evaluated.  So...if door light status changes to ON and hall light was already ON, the program would trigger and evaluate TRUE (both conditions are true).  

[brians]

There should be an option to run multiple instances of an if/then statement in a program.

 

[larryllix]

On 7/28/2024 at 7:09 AM, oberkc said:

I believe Techman was trying to make this point.  There are program triggers, and there are program conditions.  To use your example:

 

 

IF

         Door light status is ON

         and

          Hall Light is switched ON

Such a program has two conditions.  Either condition may be a trigger for the program to evaluate.  Once either condition is triggered (by a change of state), however, the entire IF statement is evaluated.  So...if door light status changes to ON and hall light was already ON, the program would trigger and evaluate TRUE (both conditions are true).  

Not quite in this case.

It work would  the other way around but not when the Door Light status changes to ON status.

This is because any device's "switched ON" always evaluates to False, except when the program is invoked by that "Switched ON" line itself. The static status of the Hall Light itself is not relevant, or being tested, in the case of this "switched" construct.

Hall Light status is ON would allow the Door Light status changing to on the run Then.

[oberkc]

9 hours ago, larryllix said:

Not quite in this case.

I stand corrected.  I thought the were both STATUS conditions.  I need to get better glasses.

[Guy Lavoie]

Thanks for the responses. Well I finally got around to writing a test program. It turns out that the status test is a bit of both: a test of static condition and also of a status change. I wrote a simple two line program that tests the status of two X10 addresses, with an AND statement, and increments a variable if both are On, like this:

If A1 Status is On

AND A2 Status is ON

THEN variable1 =+1

 

The way it behaves is that if either device is on and I turn on the other one (changes from off to on), the variable increments. In that sense, the device that is already on is being tested for it's static condition only.

But if both are on and the test would be strictly about the static condition, then the variable would be incrementing wildly and continuously as long as that's true. As I mentioned in my first post, the language seems to be designed with "idiot proofing" in mind, and more specifically, it's the status of the WHOLE program that needs to transition to true to trigger the THEN statement(s), and transition to false to trigger the ELSEs. It's the status TRANSITION of the WHOLE program that makes it single triggering. Now I also see how the current static condition of the whole program can also be tested in other programs, with the IF Program... statement.

Now it's clear!

Edited July 30 by Guy Lavoie

[Techman]

When you do your testing keep in mind that a X10 device does not send its state back to the controller. The controller assumes the state of an X10 device based on the command sent from the controller. For your test programs it's best to use Insteon devices.

[Guy Lavoie]

Yes I know (from using X10 for 25 years now...) that most devices like switches don't send their status when manually activated. But that's secondary right now, because I was mostly trying to understand the programming model for the ISY994i. The same logic rules will apply to switch status, variables, etc. The thing I've determined is that all the logic tests (IF/AND/OR) within programs test static conditions, or single events like a control message being received, but if the whole resulting logic test of the program transitions from false to true, the THEN clauses are run, and if it transitions from true to false, the ELSE statements are run. That was the goal. 

[Jim P]

I haven't done any X10 with my UD devices, but I do remember there is no status info returned for X-10 devices and the best you can do is set an integer or state variable based on the command you send to the X10 device. This isn't a sure thing as you can never know if the X10 device responded to the command or not.  That being said my lighting that I controlled with X10 was adequate for my needs and worked well enough for what I needed.  If I remember my Oscelot ran programs basically like a ladder logic  program going from line or row 1 sequentially through each row of logic commands.  Where UD devices are able to run specific rows or programs based on other programs... ie.  program b is able to run if or then sections of program a or what ever program you want to call.