oberkc

Well, I did get ambitious. I created a simple program, consisting of two control ON statements, joined by a logical AND. If control device1 is switched on and control device2 is switched on This program evaluated FALSE every time, suggesting that with a logical AND (even with both are control statements) both conditions must be true. From this, I tend to conclude that a program such as: if control device1 is switched on and control device1 is not switched off both conditions must be true. Furthermore, I tend to continue to believe that "control xx not switched off" will always evaluate TRUE except at that point in time when an OFF command is received.

I did not know this. I assumed, in this case, they BOTH had to be true, looking simultaneously for receipt of an ON command while simultaneously confirming a failure to receive an OFF command (not OFF). While I understood the second statement is triggered only by an OFF command (evaluating false when triggered), I thought it would evaluate as true at all other times. Furthermore, a program such as: if control device1 is switched on and control device2 is switched on would ALWAYS evaluate as false (I thought) because it is not possible to simultaneously receive two commands. This would not happen if the ISY treated this as a logical OR. If I get ambitious (50/50 chance) I will run some experiments for my own gratification.

Yes, both must be true. Yes, if first one is true, second one will be true. However, purpose of the second condition is to look for OFF commands (not ON). This is the condition that drives the ELSE path. Without the second condition, this program would never trigger FALSE.

You could do that, but you could also simply change the program to look for an OFF status, rather than ON. Of course, you may have other uses for the sensor which may make this approach less desirable. The bigger point is that if your program is looking for an ON command to indicate open, yet your garage door sensor says OFF when open. Obviously there is a mismatch and something has to change.

To the previous explanations, allow me to offer an additional, if subtle, difference. A CONTROL statement will only be recieved when the device is activated locally. For example: if control switchlinc is switched on This will trigger only when someone walks up to the switchlinc and presses the button. Another difference in a CONTROL ON statement is that it will trigger upon each reciept of an ON statement, regardless of whether it is, currently, on or off. Compare this to a STATUS. A status will trigger upon a change in status, regardless of what caused the change. So if a switchlinc is changed not by direct action, but in response to a scene command from another device, it will trigger (unlike a CONTROL). Furthermore, if a device is already on, and someone presses the on button, a STATUS will not trigger (unlike a CONTROL).

no I assume the same. I don't believe there is any need to link it to anything if your only purpose is to use it as a repeater of insteon commands.

I agree with TJF1960 that your "wait" statement is not effective as used. I think, too, that a few experiments around the house may help isolate this. Open an event viewer and have someone walk around the porch. Do you see lots of ON commands from your IOLinc? If so, this tends to suggest that the beam/IOLinc configuration is extremely sensitive for some reason. Also if so, I believe your were on the right track (if not the right solution) with the approach of introducing a time delay in an attempt to solve this problem programmatically. Perhaps an alternaitve approach, with an additional program would work. New program: if then wait 20 seconds run this program (else path) else One could use this program as an indicator of whether it is in the 20-second wait period (program status is TRUE) or not (program status is FALSE). If easier to comprehend, one could even create a variable as indication, rather than using program status. Once created, an update to your current program would be necessary: If Control 'My Sensors / Front Porch-Sensor' is switched On and status of new program is false (indicating not in wait period) Then Send Notification to 'Text' content 'Front Porch Motion' run new program (then path) (initiates wait period) Else - No Actions - (To add one, press 'Action') Hopefully, you recognize that the program I suggested is conceptual only. The exact program language would be different. There may be a benefit to using a variable, rather than a progam, in retrospect. Such an approach may offer a benefit of reduced program activity in the background. This is probably not a practical concern, but some may percieve this as having value.

Given that you posted this in a UDI forum, I assume you have one of the ISY controllers. The fact that only one switch controls the load suggests to me not a wiring problem, but that you have created no "scenes". Is this correct? All insteon devices communicate with each other via powerline or RF signals. In order to enable one (or more) insteon devices to control another, one must link them via scenes. In the ISY admin panel, create a new scene, and add each device (as controller) that you want to be in your three-, four-, or X-way circuit. Once added, any switch in that scene will control all the other switches in that scene. You may want to check out the UDI wiki, and ISY user manual before going too much further.

Thanks for posting. I have a couple of thoughts going through my head on your programs, but think you said all is working, so why try to fix something that is not broken. Post back if you run into anything strange or unexpected.

we have all been there

http://forum.universal-devices.com/viewtopic.php?f=26&t=5764

You must also include a statement to turn off the light If From Sunset + 20 minutes To Sunrise - 20 minutes (next day) Then Set 'Front Porch Light' On Else Set 'front porch light' off

One of the reasons that I asked about your purpose for the variables (I missed your response to this) was out of suspicion that you have other programs in place that may also be triggered by these variables. I also asked about how you intend to open and close the door (I missed this response, as well) wondering whether you have other programs or scenes that could trigger the type of behaviour you describe. Suspecting that I am having trouble seeing the entire picture here, one thing that has gone unspoken about your program: if $armhouse is 1 then run program close-garage I assume this is a paraphrase of your actual program. In your actual then statement, does your program include something like "(then path)", or "(IF path)"? If so, make sure you run IF path. Some things you can check to aid in troubleshooting is to watch the value of the variables as the door opens and closes, to make sure that these are tracking correctly. Have you confirmed the variable is 0 when closed and 1 when open? Otherwise, I don't see anything in the programs you presented which I can identify would result as you describe.

To expand upon LeeGs comments: The motion sensor works fine because it (the motion sensor) is initiating contact with the ISY. You are correct that motion sensors save battery by communicating ONLY when they decide, as triggered by motion. This is an example of communication with the motion sensor initiated by the ISY (rather than by the motion sensor). In this case, the motion sensor is not in listening mode (to save battery) and does not respond to the ISY. As I understand it, motion sensors are in listening mode only while in linking mode, or within a short time period after sensing motion.

I am with LeeG on this one...something is not quite right. I cannot help but suspect I am missing part of the puzzle here. How do you inend to actuate the doors when at home or arriving/leaving? Existing button? Insteon keypad or switch? Phone app? What purpose does the "garage door open/close" variable serve? Are these state or integer variables? Assuming that I correctly understand what you are trying to do, perhaps the better approach would be: a) ensure that the garage door status variable is an INTEGER variable. (Integer variables do not trigger program evaluation.) update your close program: if status $garagedoor = 1 then set garagedoor open-close on (the relay)

No, I dont believe so. At least, not without extraordinary effort.

A FASTON or FASTOFF is a quick, double press of the insteon switch. If the switch is a dimmer, a FASTON will always bring the local level to 100%, regardless of preset ON levels. If the switch is a relay, both ON and FASTON bring the switch to 100%. Given this, a program based on switch "status" will react no differently to ON or FASTON with a relay device, but could react differently for dimming devices if the ON levels are something other than 100% and your program is designed to recognize this. A program based on switch "control", however, can recognized the difference between ON and FASTON.

Mobilink can. I dont know about the others.

I can only think of the obvious things. Are you putting the remotelincs into linking mode? Are you choosing the option in the ISY admin panel to write the changes to the battery-powered devices? Have you checked the batteries? What other RF insteon devices do you have? Access points?

To LeeG's response, I wish to specifically state that status field represents results when the program was last triggered. This can also include being triggered by other programs, and can be affected when a program is disabled.

I find this an interesting request. On one hand, I have been quite happy with my success using the ISY. On the other hand, I know (nor care about) anything Java or external processes. Do you believe such knowledge is required to get an ISY-based insteon system to work? Certainly, I don't.

I am sure that the nest is a wonderful thermostat. No doubt. I assume the same can be said of the ecobeee. I also find the honeywell prestige to be pretty nice. For my purposes, I am VERY hesitant to invest in a thermostat that requires routing through a cloud service to be fully functional. I think this eliminates the honeywell and nest units.

I don't think you can do this with "scenes". In case it was unclear from LeeG response, this likely requires a program. The program could trigger from an insteon device of your choice and cause your spa ready and heater could come on in proper order, with a small wait period between.

Is "Main: Basement Control" or "Main: Trigger Drive-Opened" part of the scene "Basement 3Way"? If so, then your program execution causes a re-evaluation of your conditions, halting execution at earliest wait statement.

This is EXACTLY how "status" conditions work. They trigger on any change of status, execute TRUE (then path) if the change of status matches stated condtion, otherwise execute FALSE.