oberkc

A non-dimming switchlinc will work for basic functionality AND can send dim and bright commands. The only downside that I can tell is that the LED indicators won't show a dimmed level. Otherwise, it will work in this capacity just like a dimmer.

It does seem as though garage doors are one of the common themes. In my mind, the "ideal" setup is in the wiki, but I agree with LeeG that personal preferences and setup can vary quite a bit. Given that a measurable number appear not to read the wiki, dedicated forums, or even the user manual, I hold little hope that a sticky topic will fare much better.

Depending on how the scenes and programs are established, toggle modes for the KPLs, and configuration of the IOLinc, it is not hard to get them out of sync. One clue would include whether the status, as shown by the ISY admin panel, is the same or different than that of the actual KPL.

No, I don't believe so. Your "typical day" code is triggered only by time. Changing thermostat values will not retrigger the program, thus will not interrupt on-going wait statements. If it does what you want, then it is good. Whether using four programs versus your approach is better?...well...the only thing that I can think of is power failure. Do you get many (even short ones)? If a power failure occurs, it may interrupt an on-going wait statement and halt executing programs. Perhaps four programs would be more tolerant of this possibility. I also suspect that making schedule modifications, should the need arise, to be a bit more straightforward with four separate programs. However, if you place value on minimizing the number of programs in your ISY, then your approach has merit.

I think it good practice that when one has a large quantity of electronic gadgets in one place, one should add a filter. It is pretty easy to use a single filterlinc to power the various UPS, surge suppressors, and power supplies normally associated with today's home office environment. The cost of a filterlinc is money well spent for this purpose, in my mind.

If you have the motion sensor as part of your ISY system, it is trying to communicate with the PLM, as a minimum.

I am sorry, but I have no idea what you are asking

I assume that the purpose of the variable is to allow closing of the door, but not opening. This program WILL behave differently because of the variable. When called (triggered) by mobilinc, the path it takes will be based upon the value of the variable.

given that list of equipment (esp UPS), and your experience, I believe comm problems are your cause, not router or firewall. How long can your ups support operation of your system? Can you temporarily unplug it and see if your insteon system improves? My experience, and perception from this forum, is that you will need a filter on all that stuff in your closet for best insteon performance.

While I don't know enough about such things to rule out such a possibility, I would first suspect other issues. This is your statement that concerns me: Do you use any filters? Where, and into what, is your PLM plugged? I am concerned that the networking closet is full of equipment that messes with insteon communication. To perform a quick test, get an extension cord and plug it into an outlet not on the same circuit breaker as your network closet. My preference would be to plug it into the outlet formerly used by the ISY with success. Plug the ISY (PLM, actually) into the extension cord. Does this solve your problems?

In general, programs can be triggered by a few things. One is that the program includes at least one condition that, itself, triggers the program. Another is that it can be triggered by a call from another program (run program xxx if path). A third is that it can be triggered manually through mobilinc. Under the latter two options, the integer variable condition will be evlauated. I don't believe so. A program condition is, I understand, simply an indication of which path it last ran.

I believe that the ISY- software does have a few limitations regarding scheduling. While it CAN do any day, or combination of days, per seven-day week, it cannot do a given day each month or a given day each year, or a given week/month each year. Your problem, however, may be reasonably doable with variables. If I were tackling this problem, I would define a variable (integer type, I think), and assign values based upon which day of your 21-day (7+2+8+4) cycle it is. Value 1-7, 10-17 is a work day...8, 9, 18-21 is an off day. Once defined, you could then create a program with logic something like: if time is whatever you want for a work day actions and integer variable is 1-7 or 10-17 then take workday action add 1 to the integer variable else if time is whatever you want for a nonworkday action and integer variable is 8, 9, 18, 19, 20, or 21 then take nonworkday action add 1 to the integer variable else if time is middle of the night when nothing else is happening and integer variable iis > 21 then set integer variable to 1 I don't have exact syntax memorized for all these steps, so I propose only the logical construct. I am confident, however, that these logical steps can be accomplished with ISY programming. Hopefully, this concept can give you some ideas how to start. If you have trouble with converting this logic to ISY-speak, post back.

At Lowes and Home Depot are wall plate combinations where one could create a three-gang plate with one blank. I believe a better option would be to take advantage of the now-empty spot, including an insteon switch or keypad and add control for some whole-house scenes.

Yes, I believe RL2 will be the same. Another view of a remotelinc is that is can be only a CONTROLLER and not a RESPONDER. Itself, the remotelinc has no status...it can only SEND commands.

Please note that this program is effective only for when switches are manually turned on. The program will not trigger when a switch is activated as part of a program or a scene.

A program such as: if control "switch" is turned on then wait some period of time turn off "switch" else

If I go with the ISY-994, what PLM do I require, 2413? Which interface, serial or USB (is this to communicate with the 994i, or my home computer)? Once I have these items, will I have everything required to get the system up and running? Thanks! Serial interface, I believe. You may also need a power supply for the ISY-994 (I forget whether they are included, or a part of a kit. Just make sure you are getting one somehow. The PLM communicates with the ISY, giving the controller access to powerline and RF for communication purposes. Communication with your computer is directly with the ISY, through a network cable and router (also giving you access to the internet). The PLM is the device that actually transmits the insteon commands over the powerline and airwaves. I believe it also stores the link records for the controller. Once you have these items, you will have your CONTROLLER up and running. You still need some insteon devices (outlets, switches, plug-in modules, motion sensors) for your controller to control.

I think it best I back out of this conversation.

These two statements conflict with each other, as I interpret it. Combining your newly-revealed requirements with your old requirements, it appears that if the fan (or fans) are off, you want them to stay off. If the fans are on low, you want them to stay on low. If so, then the only thing you end up doing is toggling the fan (or fans) between high and medium, based on the state of the AC. Given this (only two possible states), variables may not be needed. What method or device do you wish to use to "set" your fan mode to automatic or manual? A keypad button? Time? iPhone? How do you want your system to respond in each mode? I may not be smart enough to understand what it is you are trying to do.

Which fan?

Which "fan"? How do you manually control this fan? How else would this fan be set to "low"?

, Then you need, to start, a controller and a couple of outlets. While it may not be necessary to start, access points and a filter or two should be on your list of items to get sooner rather than later. . Cameras operate completely independent of insteon. Otherwise, add switches and motion detectors as you see fit. The ISY-994 provides for internet access. You will need to download an app for the iPhone. I use mobilinc, and it works fine. Sending text messages is within the capability of the ISY-994. Triggering a message from a camera is going to take some pretty serious tinkering, if it is even possible. (Perhaps someone has done this, but I don't recall any post on this forum claiming this ability). Triggering from motion detectors is child's play. Viewing cameras from an iPhone is completely independent from insteon, though I understand the iOS version of the mobilinc app includes the ability to view IP-enabled video cameras. Alternatively any other camera viewing app could be used.

I can't be sure, but is your third line of the THEN path turning on the device, or the scene (both have the same name)? You need to turn on the scene, and I thought scene commands had the syntax: set scene "xxxx" on Your fifth line in the THEN path is, I expect, NOT doing what you want. This is the statement used when you want to redefine the response levels to a device within a scene, not to turn on a device or scene. If you correct the third line, however, you will not need the fifth. If I am mistaken here, another possibility is that you have the ON response for the swamp cooler keypad at zero.

I was wondering if, somehow, you had #1 and #2 in a scene, with #1 as a controller, with #2 having ON levels at zero. I guess not. I suppose you could still check the admin panel device listing, choosing either #1 or #2, and further confirming there are no scenes with #1 and #2. But it sounds as if you are confident in this. Given no scenes involving #1, the only other explanation I can think of for a reaction to double-tap and no reaction to single tap is a program. But there are no programs. This continues to be inexplicable to me. The exceptions that I can think of: X10. Do any of your devices #1 and #2 have an X10 address? Did you ever create links manually between these two devices, separate from the ISY scene process? This is not inconsistent with a scene or program involving #1 and #2. I got nothing here. How far into your system are the tentacles of these three devices? How hard would it be to remove them from the ISY, perform a factory reset on the devices, add them back to the ISY and incorporate into your scenes and programs? I would check each step along the way, after factory reset, that this behavior is gone. Short of that option, you could try a "restore" device for switches #1 and #2. Perhaps there are some lingering links remaining in these two devices. I forget the exact steps, but there is also a way to compare link records in a device compared to what the ISY thinks should be there. If there is a mismatch, I believe restoring the device would solve this.

Like LeeG, I am also unsure how your variable is controlled. Is it an integer or state variable? How does it change value? You say I believe you are on the right track, however.