oberkc

I would not expect two panels to be a big issue (many hear report having more than one), but theory and reality are often at odds with one another. So long as you are confident you have both legs coupled, I would think two, properly located access points would be enough. Still, my recollection is that some report using four access points in 2-panel systems. Even if you are confident that yours are located properly, it is pretty easy to try different locations to see if this solves (or has any affect at all on) your problems. It is always possible that you have a faulty device (none of yours show up on the ISY device list as v35, do they?). If one assumes they are all good, any you have proper coupling of electrical legs, there is not much left but communication problems. The source of these are not always easy to identify, but if moving PLMs, access points, and plug-in modules to different locations tends to cause things to work better or differently, this tends to point to comm problems, in my mind.

The approach I have taken for this is to create a scene with the limited (you refer to them as "main") lights as responders and a few, select, keypad buttons as controllers. To this I add a program which watches for an "off" command from each of the main scene controllers. When triggered, the program simply turns off ALL interior lights (I have an ALL HOUSE INTERIOR scene, with no controller device defined), regardless of whether they are part of the main scene. Yes, this results in some devices being told twice to turn off, but I have observed no ill effects from this.

Have you tried temporarily moving your PLM to a different location and circuit (use extension cord if necessar) to see if that clears up any communication issues?

Not directly.

One must first set up a notification under tabs: configuration/email/notifications The second step is to create a program that sends the notification based on desired conditions.

If you want a couple of devices to be guaranteed off after power failures, could you not create a simple program to run at startup which simply states: Then set KPL off Set APL off Another possibility would be to send yourself a notification in the event of power failure, allowing you to remotely confirm or cnage your "away" status. This way, you can choose whether you want to be home or away whenever this happens, rather than just assume an "away" status. I was under the impression (confirmed by my experience) that insteon devices reverted to the status held before power failures. I am a little surprised yours are not. However, I don't much rely on this feature, so it is possible that mine don't and I have just failed to notice (power failures are pretty uncommon at my house.)

Perhaps you are correct. If you believe this to be a concern in your installation, perhaps this may be enough to justify staying with separate programs. I suspect, in the end, that these are not major considerations either way. I am still a little curious about the idea that these buttons don't respond while in the flashing mode. I use a couple of these as garage door indications and control. They are set for non-toggle off. Their status responds to garage door sensors. When I press one to open the garage door, the sensor sends out a signal while the button is flashing (at least that has been my perception). Even so, the button responds appropriately. Therefore, I am a little surprised that you are having this problem. Maybe there is someone around here that can confirm whether this is normal behaviour for these devices.

I don't expect that this would be any more traffic than had you accomplished the same thing with two programs. It is more traffic, however, than the earlier single-program example. Of course, there is no built-in delay.

Interesting. Yet...it is trigger by an "off" command from either of your two buttons(?). If you needed such a pause, then you could also insert a slight wait delay into your first program "then" statement. I would not expect to have this problem. Any time a condition changes that forces a re-evaluation of the program's condition, "wait" (and "repeat") statements are interrupted and the program restarts based upon the results of the most recent evaluation. Fair enough. There are many ways to do many things. Best of both worlds, then, may be:

You did this using the same approach as did I. I don't recall needing any wait statements, but this may be due to you having two controllers and I having only one. Still, I am surprised at the need for a wait statement to turn off the keypad, since this is the default (nontoggle off) condition. If you continue to need a wait statement, you could also simply add it to the first program, such as:

Tech support for Universal Devices can be found here: http://www.universal-devices.com/supp_contact.htm

I wonder if there is not a slight logic problem in your program. Using "AND" construct, all conditions would have to simultaneously be true for the program to be true. I suspect it is hard to have a simultaneous "off" and "fast off". Try: if status "bathroom motion flag" is true and status "bathroom light" is off and ( control "bathroom light" is not switched off or control "bathroom light is not switched fast off ) then set "bathroom light" to 80%

I noticed that. It looked like it would be less work to simply assume that there are missing links and to restore the PLM than it would be to feed the calculator. There was no known insteon traffic whcn I peformed the original count. All was quiet. Nobody was home. No programs were scheduled.

Thanks for the feedback. I could do the calculator thing, and it will give me a number. This, I assume, will give me a ballpark sense of whether my count is close. If not, I assume the remedy it to...what...restore PLM? I am thinking that I might as well restore the PLM regardless. Besides the time and interruption to household functions, is there a downside to this approach?

I assume you are speaking in the context of doing this via the ISY-99. Create a new scene. Add both switches AS CONTROLLERS. This is the same as manually cross-linking both devices. When you get the motion sensor, simply add it to the scene, also as a controller (I believe this is the only option for motion sensors.) I believe you need to configure the motion sensor to activate only during dark conditions, and to control the off-timing. If you want to introduce a finer level of control with the motion sensors, you could create a program. The program could include multiple conditions (darkness, sunset, sunrise, status of manual control), and the program could control the length of time it would stay on. I suspect this is the option most people prefer.

About 70, counting keypads as one each.

I am no expert at this, but I understand that the ISY is pretty good at configuring DLink routers. Mine is a DLink router, and all I did was enable the internet access from the ISY-99 admin console. I thought the ISY did all the router configuration stuff. I did nothing further to the router initially, and was able to access the ISY using the address provided. Make sure you use the "My URL" address when trying to access when on your home network LAN. However, when you are outside your home network, use the address "Internet Access". Both are displayed under Help>about. There is ONE thing I subsequently did from the router....I reserved the IP address for the ISY. I understand that routers can assign different addresses at times such as power failures, so I wanted to be sure to keep this one. Hopefully, you will get a more learned response soon.

It shows 352 links. I don't know if that is good or bad. I am starting to see a couple devices get out of sync, but am not sure if this is the result of my recent power interruption or something else. I will continue to watch these devices and restore those that continue to be a problem.

At about 830 last night, all (most actually...a couple stayed on) turned off. I have no programs set to run at that time, so I was a bit surprised. In an attempt to diagnose the problem, I tried logging onto "My Lighting" based on the memorized shortcut from my desktop (the one I always use). No good...error. I then went to my bookmark from the UDI site and "find ISY". This found the ISY, but no devices or programs or login appeared. I then unplugged the PLM and, after 20 seconds or so, plugged it back in. Suddenly, all appears to be working normally again. Some, but not all, of the lights normally on at this time of the day even came on again. At no time did I see any unusual LED indication on the front of the ISY. The log shows no event at the time the lights went off. Any ideas what this may indicate, if anything. Should I be ordering a spare PLM?

I have a couple of override programs, but they are intended simply to delay the automatic turning of lights off at the end of the day. Adding this condition is relatively straing forward.... if time is 1100p and status "keypad button" is off then turn lights off Alternatively, you could create a folder with the keypad off being the folder condition. That is the easy part. The more interesting part is what you want to happen when you turn the override button off. Do you want it to revert to the condition it would be in were the program executing on the normal schedule? Another question to answer is what you want to happen when you turn the button on, with the lights (or heater) currently off. Do you want your device to come on? If so, perhaps you could consider like a conditional program such as: if time from xx:xx to yy:yy then else Then add the next two programs maintain, or revert back to, a scheduled condition: if status "conditional program" is true and status KPL button is false then turn lights on else and a third program: if status "conditional program" is false and status of KPL button is false then turn lights off else Then adding, perhaps, a fourth program to ensure that the light (or other device) is on any time that the override button is on: if status KPL button is true then turn on light else I suspect there are more elegant solutions, but something like this should work and I don't have enough brain cells to quicly figure it out.

That is also consistent with my recollection, but a more authoritative source would be better.

I understand that there are hardware versions and software versions, and that it is the version that shows up on the ISY amin console that should give you concern if it is v35. It sounds like you may have an issue with the v35 devices.

Without explanation of the difference between control and status, I suggest the following changes to your program: If control 'Front Door Walkway - Sensor' is switched On and Status 'Front Porch Light' is 30% Then Run timer program (then path) Else -No Action Eliminate the second program and keep the third and fourth: If Time is Sunset Then Set 'Front Porch Light' 30% Else -No Action If Time is Sunrise Then Set 'Front porch Light' Off Else -No Action Create a program folder, where the conditions are: if From sunset to sunrise (next day) Then run the programs in this folder In this program folder create the "timer program" referenced in the first program: if then Set 'Front Porch Light' On Wait 10 minutes Set 'Front Porch Light' 30% else One problem may occur....if the front porch light is manually controllable, this whole scheme can fall apart if someone comes along and dims or brightens your light. For example, if someone comes along and dims your light to something less than 30%. All of a sudden, your program will never evaluate as true (until manually set to 30% or next sunset). If such a possibility concerns you, you may consider an alternative to your first program: If control 'Front Door Walkway - Sensor' is switched On and Status 'Front Porch Light' is not off Then run timer program (then path) Else -No Action I hope this works out for you.

OK, so the light brightens (suggesting that the program executes) but does not dim back (suggesting that the program halts execution). I note that your program still relies on motion sensor "status" rather than "control". I think changing to "control" will (as suggested by J0rdan) will solve most of your problems. I expect that you will still have a potential problem at sunrise. I will provide more detailed program suggestions when I get more time.

Who are "They"? Did they tell you how to control speed? I see nothing on the fantech web page suggesting anyting with regards to insteon. Since you did not say which particular model of fantech you installed, I can only assume that this is some type of electric motor-driven device. My understanding is consistent with Brian H: there is no insteon device rated to control speed of inductive loads, such as an electric motor. You could use a relay to control on and off only. Any of the insteon relay devices would work, assuming that they meet the needed power ratings. You could use the ISY to automate on-off cycle times.