How to turn a device OFF for 6 hours then back ON?

[stef2]

I have an Denon Amp that is controlled by an Appliance Link.

 

I am trying to write a program that will do the following:

 

If time of the day is 11h45 PM and the amp is ON,

Then turn the amp OFF, and then turn it back on automatically at 7h00 AM the next day. (so it stays off during the night).

 

If the amp is OFF, then leave it OFF (unless I turn it on manually).

 

The part that I am unable to do is the part that will turn it back on at 7h00 AM if it is turned OFF by the program at 11h45 PM.

 

My programming skills with the ISY99i are very limited. This is probably easy to do, But I could not figure it out.

 

Can someone please help?

 

Stephane

[wwat]

Hi Stef2,

 

You can use 2 programs for this. Here is an example.

 

Regards,

 

[AmpOff]

 

If

Time is 11:45:00PM

And Status 'AMP' is On

 

Then

Set 'AMP' Off

 

Else

- No Actions - (To add one, press 'Action')

 

 

 

[AmpOn]

 

If

Time is 7:00:00AM

And Status 'AMP' is Off

 

Then

Set 'AMP' On

 

Else

- No Actions - (To add one, press 'Action')

[stef2]

The problem is, I don't want the amp to turn ON in the morning it it was OFF at bedtime...I just want it to turn back on if it was ON at bedtime...

[Sub-Routine]

Thanks wwat,

 

stef2, if you only want it to turn on if the program turned it off you need one more line.

 

[AmpOff]

 

If

Time is 11:45:00PM

And Status 'AMP' is On

 

Then

Set 'AMP' Off

 

Else

- No Actions - (To add one, press 'Action')

 

 

 

[AmpOn]

 

If

Time is 7:00:00AM

And Status 'AMP' is Off

And Program AmpOff is True

 

Then

Set 'AMP' On

 

Else

- No Actions - (To add one, press 'Action')

 

Rand

[oberkc]

As one who is yet to understand the details of program status, how long does Ampoff program remain true, and under which events or conditions would it become false?

[Sub-Routine]

The AmpOff program will maintain it's state until it runs again, in this case at 11:45PM. It will be True if all the Conditions are met (amp is On) and False if the amp is Off.

 

If you had a From/To in the Schedule it would become False when the To time is reached no matter the state of the amp.

 

As one who is yet to understand the details of program status, how long does Ampoff program remain true, and under which events or conditions would it become false?

[stef2]

I've tried adding the line "and program AmpOff is true" to the AmpOn program. Unfortunately, as soon as the amp is turned off by the AmpOff program, the AmpOff program becomes false (it is only true for a fraction of a second when it is exactly 11:45:00PM) and the AmpOn program cannot turn the amp ON in the morning...Did I miss something?

 

 

The AmpOff program will maintain it's state until it runs again, in this case at 11:45PM. It will be True if all the Conditions are met (amp is On) and False if the amp is Off.

 

If you had a From/To in the Schedule it would become False when the To time is reached no matter the state of the amp.

 

As one who is yet to understand the details of program status, how long does Ampoff program remain true, and under which events or conditions would it become false?

[ryarber]

There is another way I think you could accomplish this. If you remove the time from the program's "If" statement and then put the program in a folder. You add the time statement to the "If" statement of the folder. The program should remain true then, but it wouldn't execute until the folder condition turns true at 11:45.

[Sub-Routine]

Argh, My Bad.

 

The program turns false as soon as the time condition is not true.

 

How about a flag program?

 

AmpWasOn

If
  - No Conditions - (To add one, press 'Schedule' or 'Condition')

Then
  - No Actions - (To add one, press 'Action')

Else
  - No Actions - (To add one, press 'Action')

 

AmpOff

If
       Time is 11:45:00PM
   And Status  'Amp' is not Off

Then
       Set 'Amp' Off
       Run Program 'AmpWasOn' (Then Path)

Else
  - No Actions - (To add one, press 'Action')

 

AmpOn

If
       Time is  7:00:00AM
   And Program 'AmpWasOn' is True

Then
       Set 'Amp' On
       Run Program 'AmpWasOn' (Else Path)

Else
  - No Actions - (To add one, press 'Action')

[stef2]

This is great! it works fine now...THANKS!

 

Stephane

 

 

Argh, My Bad.

 

The program turns false as soon as the time condition is not true.

 

How about a flag program?

 

[auger66]

Flag program.

 

Total newbie here and trying to learn the new ISY-way of doing things. I had flags in my previous program (HCA), but had no idea how to do it with the ISY. This will be a great help.

 

Thanks.

[Michel Kohanim]

Hi auger66,

 

At a high level, you can use the status of programs as flags that can be used in other programs.

 

Perhaps this example can better illustrate this concept:

http://www.universal-devices.com/mwiki/ ... down_Timer

 

With kind regards,

Michel

[apostolakisl]

Argh, My Bad.

 

The program turns false as soon as the time condition is not true.

 

[/code]

 

I am confused here. I have lots of programs listed as being "true" on the program summary page with time conditions even though it is not presently that time.

[Michel Kohanim]

Hi apostolakis,

 

In the program I was referring to, the condition was Anded with another condition. Please make sure that your condition is not Or-ed with another condition.

 

With kind regards,

Michel

Argh, My Bad.

 

The program turns false as soon as the time condition is not true.

 

[/code]

 

I am confused here. I have lots of programs listed as being "true" on the program summary page with time conditions even though it is not presently that time.

[apostolakisl]

All of my rules that stipulate a time only say "true".

 

For example

 

If time is 11:00:00pm

Then set scene 'foyer light' off

Else no actions

 

I have lots of simple rules like this and all are listed as true right now.

 

Also I have lots of rules stipulating an insteon switch that say true as well, for example

 

If control middle bedroom closet is swtiched on

then wait 10 minutes

set middle bedroom closet off

else no actions

 

A bunch of rules like this are listed as being true right now as well despite the lights being off.

 

Addendum to the above,

 

I just went through and asked all of these programs to run the if command, and they all switched to false. Exactly how is this true/false status supposed to work. If I had asked a program to use the status of another program (true vs false) would it have run the if command before deciding or just gone on what was listed in the program summary page? How does the status listed on the summary page get determined?

[markens]

I just went through and asked all of these programs to run the if command, and they all switched to false. Exactly how is this true/false status supposed to work. If I had asked a program to use the status of another program (true vs false) would it have run the if command before deciding or just gone on what was listed in the program summary page? How does the status listed on the summary page get determined?

It's very simple, but not what you think:

 

A program's status is simply the result of what happened the last time it ran. If the THEN ran, then program status is TRUE. If the ELSE ran, then it's FALSE. Nothing more complicated than that. It has nothing to do with what actions are taken within the THEN or ELSE parts.

 

In your example of a single time condition ("If time is 11:00:00pm Then ..."), the IF is automatically evaluated only at that time: the IF evaluates to TRUE, the THEN runs, and program status is TRUE. If you manually do a Run(If) some other time, then the IF evaluates to FALSE, the ELSE runs (empty in this case), and the program status is FALSE.

 

In a "From-To" time condition, it's evaluated automatically twice: at the start time (evaluates TRUE) and the end time (evaluates FALSE). But the resulting program status still depends on whether the THEN or ELSE was run, based on the logic of all the IF conditions.

 

--Mark

[Sub-Routine]

That was my mistake. If a program has only one condition it will remain True or False until that condition changes.

 

In this case:

If
       Time is 11:45:00PM
   And Status  'AMP' is On

 

When the status of 'AMP' changes the program is reevaluated. It will not be True if the time is not exactly 11:45:00PM. If an Or was used it would be true whenever the 'AMP' is changed to on Or when the time is 11:45:00PM.

 

All of my rules that stipulate a time only say "true".

 

It will use the status as listed on the Program Summary page.

 

If I had asked a program to use the status of another program (true vs false) would it have run the if command before deciding or just gone on what was listed in the program summary page? How does the status listed on the summary page get determined?

[Goose66]

I have to say that, as a programmer of 15 years, the programming model of the ISY 99i is confusing to me as well. It is nice that you can say something like "If Time is Sunset to Sunrise" Then "Turn Outside Lights On" Else "Turn Outside Lights Off." However, the fact that trigger conditions (conditions that occur that can initiate a program) and status conditions (conditions that represent the status of devices at the time a program is initiated) are in the same If statement throws me off. Also, status conditions also act as trigger conditions.

 

A future enhancement, at least IMO, would be for every program to have a set of triggers, e.g. "Time is" or "Command X (device, scene, etc.) received," and a seperate if statement, e.g. device staus, time of day, weather info, etc. The if condition would only be evaluated on the occurrence of one of the triggers, and the status of the program would be the last result of the evaluation of the if statement for the program run.

 

For example:

 

Trigger: @ 11:45 PM

If: 'Amp' Status is On

Then: Set 'Amp' Off

Wait 7 Hours

Set 'Amp' On

Else:

 

Subsequent runs of the same program would cancel any pending waits in the previously executing program:

 

Trigger: Garage Motion 'On' Received

If:

Then: Set 'Garage Light' On

Wait 5 minutes

Set 'Garage Light' Off

Else:

 

Seperating these things out would make everything clearer (again, IMO) , may remove the confusion regarding the program status not reflecting what one may think it should be, and seems to me would make the programming engine easier to implement and maintain (although, too late for that advantage).

[apostolakisl]

Well I think I am getting this. I like kingwr thought process. I was definitely confused regarding how a condition of the program and the trigger of a program are both in the if section. Add to this that the status of the program as true/false is based on whether the if was true or not the last time the program was triggered and not based on current conditions is something you have to wrap your thinking around a bit.

 

Pretty much this means that any program with a single if statement is always going to be true since it will only be triggered in the event that it is true.

 

Addendum:

I now see that you can trigger the "if" to run from a different program forcing a program with a single "if" condition to become false.

[apostolakisl]

When I try to get something in my head I like to try writing an instruction sheet that someone else could hopefully understand. So I did that and included it here. Please tell me if I have made any errors. I would also suggest that something to this effect is put into the pdf owners manual.

 

 

Understanding True and False with ISY

 

True:

A program is “True†if the last time the program “if†section was triggered the condition(s) was (were) met.

 

False:

A program is False if the last time the program “if†section was triggered the condition(s) was (were) not met.

 

As you can see from above, for a program to have a "true" or "false" status, it must have considered the "if" condition(s). There are several ways a program “if†condition(s) can be considered or “triggeredâ€:

1) A program can be triggered from its own “if†section. In other words “if it is 10pm†will self-trigger the program to execute the “then†statement at 10pm. In addition to executing the “then†statement, the program will be designated as “trueâ€. The status of the program will stay “true†even after 10pm (and at all other times) unless the program is triggered via an external trigger (at any time except 10pm).

2) A program can be triggered via another program. In the “then†section of a program one can trigger another program by including a line with the command “run (if)†in the “then†or “else†section. In the event that the "if" condition(s) were not met, the status would become “false†and the “else†line would be executed. The status will stay “false†until the next time its "if" condition(s) are met and it self-triggers.

3) A program can be manually triggered from the program summary page by selecting that program and then initiating the “run if†command. This will execute the “else†command (if one is present) in the event that the “if†statement condition(s) are not presently met as well as change the program status to “falseâ€. If the conditions were met then the “then†section would be executed. This execution of the “then†section would be a repeat of the executed event that occurred when the conditions were first met and the program self-triggered.

 

Note: When a program includes the status of another program in its "if" section, the present status of the program is used as listed on the summary page. The "if" statement(s) are not triggered, the program status will simply be reported as it was the last time it was triggered.

[Sub-Routine]

Hello kingwr,

 

Thank you very much for your suggestions.

 

If you are willing to use From to Times Folders are an excellent way of implementing these conditions. Every program is triggered on the change of any of it's conditions unless it is in a disabled folder. Program contained in the folder will only be enabled during the specified conditions and so several programs of the same conditions can be written to only be enabled when specific conditions are true, such as a schedule, KPL button B is On, etc. I think this may emulate the nesting you are describing.

 

Everything in the ISY conditions are Boolean. Conditions can be Anded / Ored and nested using folders and parenthesis.

 

I hope this helps.

 

Rand

 

I have to say that, as a programmer of 15 years, the programming model of the ISY 99i is confusing to me as well. It is nice that you can say something like "If Time is Sunset to Sunrise" Then "Turn Outside Lights On" Else "Turn Outside Lights Off." However, the fact that trigger conditions (conditions that occur that can initiate a program) and status conditions (conditions that represent the status of devices at the time a program is initiated) are in the same If statement throws me off. Also, status conditions also act as trigger conditions.

 

A future enhancement, at least IMO, would be for every program to have a set of triggers, e.g. "Time is" or "Command X (device, scene, etc.) received," and a seperate if statement, e.g. device staus, time of day, weather info, etc. The if condition would only be evaluated on the occurrence of one of the triggers, and the status of the program would be the last result of the evaluation of the if statement for the program run.

 

For example:

 

Trigger: @ 11:45 PM

If: 'Amp' Status is On

Then: Set 'Amp' Off

Wait 7 Hours

Set 'Amp' On

Else:

 

Subsequent runs of the same program would cancel any pending waits in the previously executing program:

 

Trigger: Garage Motion 'On' Received

If:

Then: Set 'Garage Light' On

Wait 5 minutes

Set 'Garage Light' Off

Else:

 

Seperating these things out would make everything clearer (again, IMO) , may remove the confusion regarding the program status not reflecting what one may think it should be, and seems to me would make the programming engine easier to implement and maintain (although, too late for that advantage).

[Sub-Routine]

When I try to get something in my head I like to try writing an instruction sheet that someone else could hopefully understand. So I did that and included it here. Please tell me if I have made any errors. I would also suggest that something to this effect is put into the pdf owners manual.

 

We hope the owner's manual is only a beginning and users will refer to the Wiki for the most up-to-date information and more information.

 

Understanding True and False with ISY

 

True:

A program is “True†if the last time the program “if†section was triggered the condition(s) was (were) met.

 

False:

A program is False if the last time the program “if†section was triggered the condition(s) was (were) not met.

 

As you can see from above, for a program to have a "true" or "false" status, it must have considered the "if" condition(s). There are several ways a program “if†condition(s) can be considered or “triggeredâ€:

1) A program can be triggered from its own “if†section. In other words “if it is 10pm†will self-trigger the program to execute the “then†statement at 10pm. In addition to executing the “then†statement, the program will be designated as “trueâ€. The status of the program will stay “true†even after 10pm (and at all other times) unless the program is triggered via an external trigger (at any time except 10pm).

 

You could include in your sunrise program a Run Else to turn the program False if you do not want to check the conditions using a Run (If)

 

2) A program can be triggered via another program. In the “then†section of a program one can trigger another program by including a line with the command “run (if)†in the “then†or “else†section. In the event that the "if" condition(s) were not met, the status would become “false†and the “else†line would be executed. The status will stay “false†until the next time its "if" condition(s) are met and it self-triggers.

 

True enough. You may need to create Programs to specifically be Flag programs.

 

3) A program can be manually triggered from the program summary page by selecting that program and then initiating the “run if†command. This will execute the “else†command (if one is present) in the event that the “if†statement condition(s) are not presently met as well as change the program status to “falseâ€. If the conditions were met then the “then†section would be executed. This execution of the “then†section would be a repeat of the executed event that occurred when the conditions were first met and the program self-triggered.

 

Programs can be Run(If), True/False depending on the Conditions; Run(Then) for always True; and Run (Else), always False. So you can steer programs to use the conditions or to be true or false.

 

Note: When a program includes the status of another program in its "if" section, the present status of the program is used as listed on the summary page. The "if" statement(s) are not triggered, the program status will simply be reported as it was the last time it was triggered.

 

Rand

[apostolakisl]

I did some searches for a narritive on the true/false situation and couldn't find anything like what I just wrote.

 

It seems to me that this sort of info is not really going to change with firmware changes and might be nice to put into the owners manual. It is nice to be able to have a printed reference while working on this sort of stuff. Notes in the margin and being able to look at this stuff in print while using the computer to write the programs always seems best to me.

 

I also think a little additional comment on the triggers bullet number 1.

 

When a program has multiple conditions in the "if" section, then whenever any of those conditions are met or change value the program self triggers. For example "if it is 10pm" and "if light xyz is switched on" will trigger the program every day at 10 pm and every time light xyz has a status change. So this program would trigger and become "false" every time someone changes light xyz (on/off/bright/dim/etc) provided it is not currently 10pm.

[Goose66]

That's my point about triggers and status conditions being the same thing in the current implementation. There are some things I want to be triggers for programs (like time of day, commands, and, yes, maybe status changes), but other things I just want to check without having it trigger the program.

 

In a more primitive implementation (or more advanced, depending on your viewpoint), I would assign triggers to a script (they would be inherently ORed), and then in the script I could execute as many If statments and commands desired.

 

The current implementation may remove a lot of redundancy from programs, e.g. a list of triggers and a list of if conditions may be the same:

 

Triggers: Status change of X, Status change of Y, Status Change of X

If: X = Off AND Y=Off AND Z=Off

Then: A OFF

Else: A On

 

But, I just think seperating the two would be a cleaner way of thinking about programs.

[Sub-Routine]

I hope this helps: ISY-99i/ISY-26_INSTEON:Scope,_Precedence_and_Execution_Order.

 

Rand