A question for the braintrust of programming

[mitch236]

Here's the problem. We have an alarm and it sends info to the ISY by way of the REST interface. In order to keep the ISY and the alarm in sync, every time the alarm has any change to its status, it sends three commands: Run Program Alarm Away (Then or Else path), Run Alarm Stay (Then or Else path), and Run Program Disarmed (Then or Else path). The Then or Else path would be dictated by the status of the alarm. If the alarm were armed away it would run the Then path for Alarm Away and the Else path for the other two.

 

What we need is a way to keep the ISY sync'ed with the alarm without sending the Run Programs because every time a Run Program is sent, the ISY re-evaluates the Folder that is True and resets all the devices to their programmed settings regardless of whether the user has changed the device locally or not. This makes the interface useless as it is now. I'm sure someone can come up with a solution to keep the ISY sync'ed without running programs to do so.

[Goose66]

I don't think I understand the problem. You say "every time a Run Program is sent, the ISY re-evaluates the Folder that is True and resets all the devices to their programmed settings."

 

What is "the Folder that is True," and are you suggesting that the ISY sets the status of the devices in this folder to some defaults without a specific command or function request to do so, i.e. "every time a Run Program is sent?" If so, sounds like a bug in the REST interface. I would suggest logging a support bug.

[Sub-Routine]

Hi Mitch,

 

I have an idea. I'll try to flesh it out in the morning. The sun is rising in LeMans.

 

Rand

[mitch236]

I don't think I understand the problem. You say "every time a Run Program is sent, the ISY re-evaluates the Folder that is True and resets all the devices to their programmed settings."

 

What is "the Folder that is True," and are you suggesting that the ISY sets the status of the devices in this folder to some defaults without a specific command or function request to do so, i.e. "every time a Run Program is sent?" If so, sounds like a bug in the REST interface. I would suggest logging a support bug.

 

No bug in REST. If you create a folder that has the If statement "If Program Alarm Disarm is True" then whenever the program is true, the ISY will evaluate the folder's programs and run whatever programs need running. Say you have a hall light that is On from Sunset to Sunrise the following day in the Then statement and hall light Off in the Else statement in that Folder. Whenever the ISY gets a statement that the status of the alarm is Disarm, it will act on the hall light. If the user (or his wife!!) turns on the hall light during the day and someone opens and then closes the front door, the ISY gets the Disarmed statement and runs the hall light program and turns off the light.

 

That's the problem. The issue is in the DSC interface. There needs to be a way to keep the ISY in sync with the DSC without the DSC sending commands to the ISY.

[IndyMike]

Hello Mitch,

 

I tried to explain this function in one of your other posts (poorly).

 

The alarm interface is being treated as a "control" function. As such, the ISY will re-evaluate the condition each time your "alarm disarm" occurs.

 

What you need is a "Latch" to keep the program from re-executing if the input does not change state. You can do this with a simple dummy program.

 

The following uses the program "toggle" to latch the control input. On it's first pass, program toggle is False and the condition evaluates to true.

 

On a second pass, Program toggle is true and the condition evaluates to false. This prevents successive "control on" events from executing the program multiple times.

 

If
       Control '11.1F.DB.1' is switched On
   And Program 'Toggle' is False

Then
       Set 'BSMT Fam Cans' On
       Run Program 'Toggle' (Then Path)

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

 

The opposite condition is shown below. Note that you will need to "initialize" the dummy program "toggle". It's state will be indeterminate when the isy is restarted.

 

If
       Control '11.1F.DB.1' is switched Off
   And Program 'Toggle' is True

Then
       Set 'BSMT Fam Cans' Off
       Run Program 'Toggle' (Else Path)

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

[Algorithm]

Hello Mitch,

 

Is it possible that you are misunderstanding, and that you are thinking that whenever a folder becomes True, that this will cause the programs within that folder to run.

 

In fact, when a folder becomes True, this fact does not cause any actions at all, it simply allows contained programs the ability to run, based on each program's If conditions.

 

If a folder's conditions are True, and some event causes a re-evaluation of the folder's conditions but the folder's conditions remain True, this will not, in and of itself, cause any programs within that folder to run. The only way those programs would run again based on that trigger which caused the folder to be re-evaluated, is if such a program itself also contained that same trigger condition in its If.

 

Now when a folder's conditions become False, on the other hand, all running programs within that folder will immediately stop running.

[Goose66]

Mitch,

 

I setup a test scenario to test this functionality, and I can confirm Darrell's comments. I established a status program Test Status with no code, a folder Test Folder with the following IF statement:

If
       Program 'Test Status' is True

Then
  Allow the programs in this folder to run.

and a program Test Program inside of the folder with the following:

If
       From    Sunset
       To      Sunrise (next day)

Then
       Set 'Outdoor / Front Lanterns' 65%

Else
       Set 'Outdoor / Front Lanterns' Off

I then set the status of Test Status via the REST interface with the following:

http://isy//rest/programs/0011/runThen (or runElse)

 

I can confirm that setting the Test Status program True or False via the REST interface does enable the folder Test Folder and schedules or unschedules a Next Run Time for the program Test Program in the Test Folder. However, the Test Program is not executed. Perhaps if you post your actual code, we can find the reason why your program is executing upon change in status of the parent folder.

[mitch236]

I'm embarrassed to post this but I did figure out why this was happening. The isyDSC interface that io_guy wrote had the issue. I was trying to have my alarm communicate with the ISY and the isyDSC interface was written to do that. But the way the interface stayed in synch with the ISY caused problems. Whenever the alarm had any status change, even if a door was opened and then closed, the isyDSC would send commands to the ISY. The commands caused the problem. If the alarm was disarmed and ready it would send:

 

Run Program 'Disarmed (Then path)

Run Program 'Armed Away (Else path)

Run Program 'Armed Stay' (Else path)

 

So every time I opened and then closed any door, my Disarmed Folder would run its Then path.

 

I have communicated this issue with io_guy and we are working towards a solution that keeps the ISY synched with the DSC without running any programs.

 

 

Thanks all!

[Goose66]

Good to hear.

 

However, there is still the fact that running the THEN path of the Disarmed program will not cause programs located in a folder with an "If Program 'Disarmed' is True" condition to run, unless the programs also have the status of the Disarmed, Armed Away, or Armed Stay programs in their own If conditions. I think it is important to point that out for future readers of this thread.

[mitch236]

Unfortunately, I need to add those If commands to my Folder Programs to get them to run when the condition of the alarm changes. IOW, when arming the alarm to Armed Away, I need the ISY to make changes to my lighting system to reflect the fact that nobody is home. I have my HVAC units reset, lighting turned off (with some random programs). When I return home and disarm the alarm, I need the ISY to reinstate the programs in the Disarmed Folder to get all the devices up to speed. It's really a programming dilemma!