Program State Evaluation

[matapan]

According to the Wiki's Condition page:

 

"The program state is set to True when the program enters the Then path and False when it enters the Else path. Folder conditions can be set based on the program state. This state is also reported in the Status column in the program summary table."

 

I have some programs that are evaluated and run the Then path, yet their status shows as "False".

 

I am running firmware version 3.1.14.

 

Is there anything which would contribute to the program state being evaluated as "False" when it did run through the Then path in the program?

[LeeG]

The False Status normally indicates it ran the Else path after running the Then path. Can you post the Program.

[matapan]

LeeG: Here's one program that runs through the Then path, but evaluates to False on the summary page. It's my garage door opener program:

 

If

Status 'Garage -Sensor' is On

And

Control 'Keypadlinc Garage Door Button' is Switched On

 

Then

Set 'Garage - Relay' On

Wait 5 seconds

Set Garage -Relay Query

 

Else

- No Actions -

 

I know the program runs through the Then path because the relay is energized and the garage door opens.

 

Based on what I read in the Wiki, I think the program should evaluate to 'True' after execution. It does show up as False through in the Summary.

[LeeG]

When the Program Then clause turns the I/O Linc Relay On the door moves changing the Status of the I/O Linc Sensor. That change of Status causes the Program to be reevaluated at the Wait. Now the If is False so the Else clause is run.

[apostolakisl]

As Lee said. Be aware, that what is written after the wait is never happening (your query statement). As soon as that door starts moving, the program re-triggers, the wait terminates a split second later (never finishing), the program evaluates to false, the else clause runs (which is blank).

 

You don't need the query statement. Insteon devices always update the PLM when they change state. Only a comm failure would prevent that. So a query would only help if your comm was borderline and having multiple status updates helps the odds.

[LeeG]

apostolakisl

 

Of course you are right about the Query not being executed. However, it is useful if it had been because the IO Linc Relay Momentary mode will turn the Relay off in a few seconds. The Io Linc Relay is a Responder Only so it does not notify the PLM of the On to Off state change resulting from Momentary mode.

 

matapan

 

The standard solution to the reevaluation and no Query is to put the current Then statements in a second Program, changing the current Program Then to a Run second Program.

 

Lee

[apostolakisl]

apostolakisl

 

Of course you are right about the Query not being executed. However, it is useful if it had been because the IO Linc Relay Momentary mode will turn the Relay off in a few seconds. The Io Linc Relay is a Responder Only so it does not notify the PLM of the On to Off state change resulting from Momentary mode.

 

matapan

 

The standard solution to the reevaluation and no Query is to put the current Then statements in a second Program, changing the current Program Then to a Run second Program.

 

Lee

 

Thanks. As you may have guessed, I don't own any, I use my Elk's relays for that type of stuff. I don't understand why the io linc wouldn't have state reporting built-in like everything else, but, whatever.

 

I would have suspected then that the OP would have noticed the state being reported wrong in ISY since it's last command was to turn it on and the query never ran. Maybe he did and just didn't report it.

 

Although, I don't really see any use for having it report correctly in isy. I can't think of a situation where you would use that info in a program or otherwise if it were set to momentary.

[LeeG]

apostolakisl

 

The IO Linc Relay is like an ApplianceLinc and OutletLinc, they do not report locally initiated state changes.

 

I agree about the usefulness of the IO Linc Relay Status. It does not say anything about the state of the door nor dictate commands usage based on whether the Relay Status is On or Off. Some folks like to see the correct Status in the Admin Console and on mobile devices but it really does not mean anything.

 

Lee

[matapan]

Thank you LeeG for the explanation regarding program evaluation and when they occur.

 

I am still trying to wrap my head around event programming, especially evaluations and preventing infinite loops.

 

In a different example, say you want to check on a change of state several times before committing a device state change - taking multiple state samples.

 

In pseudocode, I imagine the logic would work like this:

 

if is ON

then turn on

else

wait 1 minute

check the

if the is still OFF

then turn OFF

 

 

So, in ISY, is this best done in 3 programs, where the first program sets the target device on if the trigger device is on, with the else clause passing off to another program, which evaluates the previous program state, along with the trigger device state, etc?

 

Or, is there a better way?

 

As a debugging aid, is there a good way to get the program summary page to refresh automatically when program states change?

[LeeG]

matapan

 

Is the objective to determine if state device has been turned Off and not been turned back On during that 1 minute before turning Off the target device?

 

Or simply wait 1 minute before turning Off the target device if the state device is Off after 1 minute?

 

Lee

[matapan]

The general objective is to qualify occupancy, to discriminate between a quick in and out of a room vs. true occupancy in the fastest way possible.

 

"Buffering" checks using a motion sensor on entry and exit seems to be one approach. Not sure if there are any better ways. I've coded the exit check in two programs:

 

Program Test1:

If

Status 'Sensor' is On

and 'Target Device Controlled' is Off

Then

Set 'Target Device Controlled' On

Else

-- No Actions --

 

 

Program Test2:

If

Status 'Sensor' is Off

and Program 'Test1' is False

Then

Wait

Set 'Target Device Controlled' Off

 

 

Same kind of program for entry check, but that's not optimal; for lights, that might be okay, since most people turn a paddle on by themselves manually. For climate control, a buffered entry check isn't optimal because it takes a while for the temp to adjust, and the shorter the wait time, the better.

 

I'm wondering what a better entry check might be, to discriminate between a quick in and out of a room and a true occupancy scenario.

[oberkc]

I'm wondering what a better entry check might be, to discriminate between a quick in and out of a room and a true occupancy scenario.

 

I wonder if determining room occupancy, and whether such occupance is quick or otherwise, will be difficult to implement with door sensors unless you have confidence that open door = occupancy and closed door = gone. (My life experience suggests that there is little relationship between doors and occupancy.)

 

Given that creating a program to predict the future is difficult, I would suggest that the only way to determine if an occupancy is longer than "quick" is, simply, to wait for quick to be over, then reach the necessary conclusion. I also suggest taking advantage of the built-in capability to halt program execution during periods of wait or repeat.

 

In hyperpseudo code:

 

if

status "sensor" is occupied (however you define it)

then

wait "quick"

do something

else

return system to nominal condition, whatever that is

 

If the status of the sensor changes from "occupied" to "unoccupied" during the wait period, the program execution will halt before it gets to "do something".

[matapan]

OberKC: I was actually think more along the lines of a motion sensor, not a contact sensor for a door, for the same reasons you cited.

 

The closest I've been able to come to is trying to find a countdown period which eliminates the false readings but which isn't too long so as to be energy inefficient, then adding a manual override condition in the form of a third program which just checks to see if the circuit was manually turned off or not and adding the logic to the other two programs accordingly.

 

I'm curious if anyone has found better occupancy check that more closely follows the user's intent and optimizes energy savings without becoming a detriment to the equipment being controlled (minimize on/off cycles as much as possible).

[TJF1960]

The closest I've been able to come to is trying to find a countdown period which eliminates the false readings but which isn't too long so as to be energy inefficient, then adding a manual override condition in the form of a third program which just checks to see if the circuit was manually turned off or not and adding the logic to the other two programs accordingly.

 

I'm curious if anyone has found better occupancy check that more closely follows the user's intent and optimizes energy savings without becoming a detriment to the equipment being controlled (minimize on/off cycles as much as possible).

 

I remember reading a post, that I have not been able to find, where the OP was going to set up the motion sensor in occupancy mode and create a program to increment a variable by +1 every time the motion detected motion within a given amount of time. Once the variable reached a certain level another program would turn the light on. If that level was not reached in a given amount of time the variable would reset. Sounds good in theory, don’t know if they ever implemented/refined it or not though. My feeling is if I walk into a dark room I want the light to turn on now not after multiple motion senses.

 

My laundry room is the main path from inside the house out into the garage/workroom where I am most of the time. I had the motion trigger the light every time someone entered that room. I soon changed the programming to require manually turning on the light then one minute after motion stopped the light would turn off because most of the time the light was not needed for just passing thru. That works great for that room and I don’t miss the light turning on automatically at all. However in all of the other rooms in the house the respective lights will turn on when entering that room and stay on x amount of time once the motion stops or the light is turned off manually. This setup has worked best for us out of the countless different ways I have tried. But everyone is different…..