oberkc

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.

I think some of my older keypads are v2.D. I have never had any luck getting LED brightness of the older keypads changed via the ISY (regardless of software level).

There are Lots of internet-enabled thermostats out there, but I suspect that the fact that rschneid posted his question on a UDI/insteon/ISY-994 forum suggests interest in integration with the ISY-994. Recommendations for thermostats without such capability are, in my estimation, non-responsive.

if you simply want to turn hot water off at 1am and on at 430am, a simpler approach might be: if time is from 1am to 430am (same day) then turn hot water off else turn hot water on One benefit of this approach is that it is more tolerant of power failures during the period between 1 and 430.

For whatever reason, I found the morninglinc to be more marginal in communication than the rest of my devices. Perhaps your problems are completely unrelated to setup or firmware version. Have you tried temporarily moving the morninglinc closer to your PLM?

In addition to the access point suggestion by LeeG (which I second), there may be benefits to using a "program" rather than a "scene" to control brightness, but this has no effect on what you need to purchase. While you did not mention it, is integration with your Elk system important? If so, be aware that this requires an additional "purchase". There is an add-on software module required with the ISY-994.

The most common methods are: a) ensure you have communication between legs of your electrical system. This is typically assured by using two dual-band devices and verifying on opposite legs via the process described in the user manual identification and elimination of devices which interfere (either actively or passively) with insteon communication. There is no easy way to do this. First is to identify suspect problem-causers. Unplug suspects and see if communication improves (if so, filter that device). Initially, consider computer equipment, including UPS and surge suppressors, TVs and AV equipment. c) addition of insteon devices, to repeat signals to distant locations. d) reading of prior posts on this forum to learn the various methods and ideas.