Basic Program Question

[shannong]

Greetings.

 

I'm relatively new to ISY and HA in general. I have an ISY setup with about 50 Insteon devices and have several scenes setup, a few programs for control, etc. Now I'm working on IR integration with my universal remote.

 

I have the IR integration working where I can press a button on the remote and the ISY recognizes it. I'd like this particular button to toggle on/of a Lamplinc. I do not want to have one button for on and another for off. I could use a long and short press if I must but would prefer simple toggle.

 

I struggle with implementing conditional logic in ISY due to the IF conditions always being evaluated when any of the statements are affected by a change.

 

This pseudo-code represents the first try:

 

If

IR_01 is PRESSED

And LampLinc is OFF

 

Then

Set LampLinc On

 

Else

Set LampLinc OFF

 

As you probably already know this didn't work. When it's off, the command to turn it on is sent but as soon as this happens the logic now changes and is then turned off by the Else statement after revaluation because the light is now on.

 

I realized I could easily add an Integer Variable to the mix to track the state between on and off if that was the only thing happening. However, that's not a viable solution since there are many other scenes and programs that will turn the LampLinc on/off. Therefore, the use of variable would be messy and complex to manage it would have to be updated all.

 

Your help and suggestions are appreciated.

[bbotts77]

I am also new to ISY programming. So, if there's a better way to do this, please correct me.

 

What I would do is remove the button press from the IF statement in the program you posted and save it as just a toggle program. Then, write another program for your button with the button press in the IF statement.

 

Something like this

If
  LampLinc is OFF

Then
  Set LampLinc On

Else
  Set LampLinc OFF

IF
  IR_01 is PRESSED

Then
  Run Program 'Toggle LampLinc' (If)

Else
  - No Actions

[apostolakisl]

You have to write 2 programs. Having the "status" of the lamp in there will force unwanted triggers of the else clause.

 

Here is one of my examples.

 

If
       IR 'IR_003' is Pressed
   And Status  'Family Room / Family Room-Ceiling L' is Off

Then
       Set Scene 'Family Rm Ceil S' 100%

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

 

If
       IR 'IR_003' is Pressed
   And Status  'Family Room / Family Room-Ceiling L' is not Off

Then
       Set Scene 'Family Rm Ceil S' Off

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

[apostolakisl]

I am also new to ISY programming. So, if there's a better way to do this, please correct me.

 

What I would do is remove the button press from the IF statement in the program you posted and save it as just a toggle program. Then, write another program for your button with the button press in the IF statement.

 

Something like this

If
  LampLinc is OFF

Then
  Set LampLinc On

Else
  Set LampLinc OFF

IF
  IR_01 is PRESSED

Then
  Run Program 'Toggle LampLinc' (If)

Else
  - No Actions

 

This works too, but remember that the first program needs to be set as "disabled". I kind of like my way better because it is faster to write. Since the programs are almost identical, once you write the first one, you just copy it and make the couple edits. And you don't have to disable anything which comes in handy if you ever need to "disable all programs" when trouble shooting something. When you re-enable, you have to remember which ones to not re-enable.

[bbotts77]

This works too, but remember that the first program needs to be set as "disabled"...Since the programs are almost identical, once you write the first one, you just copy it and make the couple edits.

Good points. Like I said, I'm pretty new to this thing. I didn't even think about the need to keep the toggle program disabled. Thanks for clarifying that for both of us.

[shannong]

 

This works too, but remember that the first program needs to be set as "disabled".

 

I didn't realize I could disable a program but still call it from another program. Very useful to know. Thanks for the unsolicited tip!

[shannong]

Thanks to you both for the suggestions. I can work with that.

 

I figured it should be simple but didn't get around to the idea of nested programs as I was brainstorming.

 

I'm really struggling with programming in the ISY due to the non-linearity of programs that are constantly evaluated and triggered anytime one of the IF conditions changes. It's a different way of looking code execution. I'm used to scripts and code where everything is linear and the only way to run the same code again is via looping, gotos, calling subroutines, etc.

[apostolakisl]

Thanks to you both for the suggestions. I can work with that.

 

I figured it should be simple but didn't get around to the idea of nested programs as I was brainstorming.

 

I'm really struggling with programming in the ISY due to the non-linearity of programs that are constantly evaluated and triggered anytime one of the IF conditions changes. It's a different way of looking code execution. I'm used to scripts and code where everything is linear and the only way to run the same code again is via looping, gotos, calling subroutines, etc.

 

 

It is different and it upsets a lot of people because they want it to be the same thing that their brain is already use to. They have something of a point. But this works well in the environment it was designed to function in.

 

Regarding disabled programs: Disabling ONLY stops a program from self-triggering. It can still be hit with a "run if" "run then" or "run else". It just won't do anything of its own volition.

[Michel Kohanim]

shannong,

 

Please note that our tech support is available to walk you through some of these concepts. In case you are interested, simply create a ticket and we'll schedule a call most convenient for you to give you some pointers.

 

With kind regards,

Michel

[shannong]

shannong,

 

Please note that our tech support is available to walk you through some of these concepts. In case you are interested, simply create a ticket and we'll schedule a call most convenient for you to give you some pointers.

 

With kind regards,

Michel

 

Thanks. I wasn't aware that tech support was available to assist with basic training in programming with the device.

 

I've now read through a lot of the docs, tutorials, and posts. I'm sure I'll have many more programs I will need assistance with, but I think I have the basics down now. Usually I appreciate the asynchronous, offline support that a forum provides. Also, you'll often get more than one response with different approaches which I find more valuable than a single answer. You'll even get feedback from others on the advice provided by another to better understand the pros/cons.

 

I think there needs to be an updated "tips and tricks" for the current software that has just the most basic stuff to get started. The official doc is too light. Some of the Wiki articles are too old. Some of the stickies are too dense and too old. I'm thinking things like what I learned here on this thread that you can disable a program so it doesn't trigger yet it can still be called. Very useful! That would've saved me an hour the day before noodling through a problem had I known that. Or that EVERY device must be in a scene for the ISY to really be "managed". Explanation of Insteon devices, communications, link tables, and how ISY participates in that (great sticky for that once I found it). That combined with real world examples for all the usual stuff most users will need. 3-way scenes (that one is in user guide), making Off scenes, using motion detectors with a time to turn off lights, use of KPL scene buttons especially with fans, etc) That would make the initial use and config for new users quick and easy and they would learn the basic programming options by doing as well as have a reference source when making their own.

 

I realize documentation is the most unfun part and there never seems to be enough time. However, if tech support is available to take calls to provide 1:1 training on the basic concepts then they could instead invest some of that time to create enhanced documentation that would result in fewer calls. Even if one person spent 2 hours a week within a month or two the documentation would be greatly advanced. Using tech support itself as a source, they could use call statistics to decide what items to most include based on how often that problem comes up. And of course investing small chunks of time on a regular basis would provide updates for the docs along with updates for the software.

 

I realize you're well aware of all these things already. Just a reminder and a "vote" from me to push my agenda.

 

Your direct participation in the forum has been extremely valuable and appreciated.

[Michel Kohanim]

Hi shannong,

 

All very valid points and all noted. We did actually hire a professional technical writer who helped us with the updated User Guide and cleaned up a little bit of the Wiki. This said, and as you noted, there are too many old articles that we really do not know what to do with since a) they provide useful information but they lack the context of the present capabilities.

 

The major obstacle is that ISY is a product in a constant flux; we just have to figure out a better way of handling the flux!

 

Thanks so very much for your feedback and with kind regards,

Michel

[shannong]

You need a flux capacitor!

[Michel Kohanim]

[MaddBomber83]

As you probably already know this didn't work. When it's off, the command to turn it on is sent but as soon as this happens the logic now changes and is then turned off by the Else statement after revaluation because the light is now on.

 

The solutions in this thread provide you an answer for this problem, but I would like to offer a third solution that you may find useful in other situations.

 

I handle flow control through the liberal use of variables. I will apply this to your situation (only mine will be Xmas Lights).

 

The basis of this 'rule' I follow is defining Variables as both States and Integers.

- A state will trigger an If statement when it changes, where an Integer will not.

 

For each of my switches and other variables (such as temperatures and setpoints) I define:

If
       Status  'Xmas_Lights' is On
Then
       $Xmas_Lights_Integer  = 1
       $Xmas_Lights_State  = 1
       $Xmas_Lights_Integer Init To 1
       $Xmas_Lights_State Init To 1
Else
       $Xmas_Lights_Integer  = 0
       $Xmas_Lights_State  = 0
       $Xmas_Lights_Integer Init To 0
       $Xmas_Lights_State Init To 0

If
       IR_01 is PRESSED
Then
       $IR_01_Integer = 1
       $IR_01_State = 1
       $IR_01_Integer Init To 1
       $IR_01_State Init To 1
Else
       $IR_01_Integer = 0
       $IR_01_State = 0
       $IR_01_Integer Init To 0
       $IR_01_State Init To 0

In this way, I know the status of this switch, and on reboot of the ISY the position (Init To) will be remembered.

 

With the rule followed, you would write your program as you wanted:

If
       $IR_01_State is 1
   And $Xmas_Lights_Integer is 0
Then
       Set 'Xmas_Lights' On
Else
       Set 'Xmas_Lights' Off

 

This accomplishes what the examples above did, with an extra program and 4 extra variables. So why would I do this instead? Once done, it really adds to the flexibility of your programing. In every future program you have, you may now reference the status of any button / light as a state or an integer.

 

Take the below program called 'Equalize' as an example. Every Temperature in it is an Integer. I would like to keep my whole house fan running when any individual room is above my Heating/Cooling Setpoint. I also have a $SP_Fan_State that is set based on our fan override button. When we press this, I want the fan on (separately, it will go back to 0 an hour later).

If
       (
            $Temperature_KhloeRoom > $SP_Cooling
         Or $Temperature_KhloeRoom < $SP_Heating
         Or $Temperature_Living_Room > $SP_Cooling
         Or $Temperature_Living_Room < $SP_Heating
         Or $Temperature_Office > $SP_Cooling
         Or $Temperature_Office < $SP_Heating
         Or $SP_Fan_State is 1
       )
   And Status  'Thermostat- Main' is not Calling for Heat
   And Status  'Thermostat- Main' is not Calling for Cool

Then
       Set 'Thermostat- Main' Fan On
       Wait  10 minutes 
       Run Program 'Equalize' (If)

Else
       Set 'Thermostat- Main' Fan Auto
       Wait  10 minutes 
       Run Program 'Equalize' (If)

Here you can see, that the only things that will run this program is that $SP_Fan; and if my Heating/Cooling kick on. The program self loops by calling itself every 10 minutes. In this way, a false condition on a temperature will not cause the Fan to go back to auto. It must first wait out its 10 minute timer and then check the temperatures.

 

Bah, Pizza is done!

 

As mentioned, in programming there are several ways to skin the cat; above is another way that may make it easier in the future if you went very complex with your programs (short/long press, double taps, ectra).

[shannong]

As you probably already know this didn't work. When it's off, the command to turn it on is sent but as soon as this happens the logic now changes and is then turned off by the Else statement after revaluation because the light is now on.

 

The solutions in this thread provide you an answer for this problem, but I would like to offer a third solution that you may find useful in other situations.

 

I handle flow control through the liberal use of variables. I will apply this to your situation (only mine will be Xmas Lights).

 

The basis of this 'rule' I follow is defining Variables as both States and Integers.

- A state will trigger an If statement when it changes, where an Integer will not.

 

 

Thanks for the additional info and approach. For this one I used the approach of two simple programs with Then-only actions.

 

I have started using both Integer and State variables and yours is a good example of that. I used a combo of both kinds of variables when setting up a simple garage door control from my KPL plus a program to detect a "close" event that failed to render the door sensor off thus indicating a problem and "error" state.

[qkb333]

Hello, still a newbie with no real programming experience. Is there a good guide for helping someone even begin to understand variables? The UDI wiki still assumes a level of experience. I need a variables for dummies version. I have built scenes and programs involving notifications. I am ready to get to the next level but am having trouble making the leap.

 

For example, I have a program that monitors doors via "or" statements and alerts me if any are opened. I now want the system to tell me which door has been opened. I also want lights to turn off when the house is unoccupied, etc. Thanks much.

[oberkc]

To answer your specific question, the only documentation of which I am aware is the wiki and the user guide. I know of no other formal documentation.

 

As an alternative, I see nothing in your examples that require the use of variables. Personally, I have very limited need for variables. Unless there is a use that I cannot accomplish without them, I find (for me) variables to be an unecessary complication.

[toflaherty]

To answer your specific question, the only documentation of which I am aware is the wiki and the user guide. I know of no other formal documentation.

 

As an alternative, I see nothing in your examples that require the use of variables. Personally, I have very limited need for variables. Unless there is a use that I cannot accomplish without them, I find (for me) variables to be an unecessary complication.

Agreed. Variables seem to be over used only because they are there. I have many programs and the only variables i have ever needed are the ones that are used in the leak sensor program that someone else wrote.

[Teken]

To be clear variables are great to track how long something has been on, running, off, etc. It is also a fantastic method to count an action / event.

 

With the above a summary email can be sent out which really helps in seeing the big picture.

 

Using the summary page to confirm an action / state is great if you're there. But it's impossible to do over long periods.

 

Hence a tracking variable with reports.

 

 

Sent from my iPhone using Tapatalk

[oberkc]

Yes, for counting (whether time or events) they are wonderful. For simple true/false calculations, I find them overused.