IndyMike

Hopefully Paul has been active on the forum since this post. His SWL V.35's are likely the issue he is chasing, not the AP's.

Hello MarkGram, MarkSanctuary nailed the explanation - I am requesting a status update of the members of my "Outside sunset" scene. If one of these devices comes back with a Status of > Off, it will trigger the second program to turn them off after 2 minutes. I do this to ensure that I don't have outside lights burning during the Day (infuriates me). As I had stated previously, this is a backup (may not be required for most installations). If the insteon system is working properly, the ISY will know whether the lights are on without the separate Query. I did this because I am using dimmable CFL's for my outside lights. These bulbs generate a lot of noise at lower Dim levels. The noise also varies with outside temperature. I had a number of occasions during the past winter when the Switches would not respond to the initial off command due to morning temperatures below -10F. The query program is a backup to repeatedly sample/turn off the lights prior to my returning home from work (saves on burst blood vessels in my brain).

Hi Mark, During the daytime I run a query on my outside lamps. If one is inadvertently switched on, the periodic query will pick it up and trigger the Daytime Status program. Note that this is really a belt and suspenders approach. It the Switches are communicating properly, the Daytime Status Program should detect the on condition itself and shut the lamps down after 2 minutes. Outside Daytime Poll If From Sunrise + 1 minute To Sunset - 10 minutes (same day) And Time is Last Run Time for 'Outside Daytime Poll' + 30 minutes Then Set Scene 'SC Outside Sunset' Query Else - No Actions - (To add one, press 'Action') Daytime Status Off Program If From Sunrise + 1 minute To Sunset - 10 minutes (same day) And ( Status 'Entry Deck' > Off Or Status 'Mud KPL 1 - Entry Garage' > Off Or Status 'Entry Patio' > Off Or Status 'Entry Porch' > Off ) Then Wait 2 minutes Set Scene 'SC Ouside Night' Off Else - No Actions - (To add one, press 'Action')

Hello Mark, In your program below, when you set the bathroom light to off your "if" condition will become false (i.e the bathroom light status is no longer "on"). The remainder of your then statements may not execute. Try using a control condition for your if statement instead (i.e. If bathroom light is switched on). This should prevent the statements in your "then" loop from re-triggering the program.

Rand, That's a slick approach. Effectively using the 5 minute wait to make sure that the condition persists - I like it. I'm assuming that your WB update rate is less than the 5 minute wait period (1 min?). At present, my WB update is set to 30 minutes. Regardless, I am going to use your 5 minute wait as a precaution for those times when I'm playing with the WB update. Thanks, IM

Sorry Brad, I was mixing your post with IO_Guy's. I missed the fact that you were installing a Whole House Fan (thought you were activating the furnace fan for circulation). Your 220V fan sounds rather massive. Are you sure you require a unit this size? I have a 120V whole house fan in the second floor of my 4500 sq foot house. During the spring I run this for roughly an hour prior to "sleepy time" to cool the second floor and attic. Don't remember the CFM rating, but I need multiple windows open a significant amount to prevent loading the fan. Your approach of monitoring window status with the Elk is a nice touch to ensure you have some makeup air. However, this won't tell you how far your windows are open - i.e. a cracked window may provide an open status. If you have insufficient makeup air the airflow will be drawn from sources you don't intend (septic vents, bathroom vents, etc). If you have double hung windows (I have casements), you could monitor a second "open" position to guarantee minimum open area. Sorry, I don't have any experience with the Venstar thermostats. IM

Hello jerlands, I apparently missed your post originally - my apologies. I test drove CFL's from four manufacturers years ago for use with my X10 system. Of the bulbs that I evaluated (GE, Sylvania, Neptune, Feit) the Feit were the wost for turn on transients. They also had the annoying habit of combining (harmonic addition) to produce frequencies in the X10 range (120 Khz). This is a situation where the 2nd or 3rd harmonic noise from multiple bulbs "aligns" to create noise that is effectively the sum of the various bulbs. This noise would knock my X10 devices off line and would presumably have detrimental effects on Insteon devices as well. This "phenomena" sounds very similar to your warmup in that it took some time to occur. It's been a number of years, but at the time I selected Sylvania CFL's (non-dimming) for use. I've continued to use these with my Insteon relay units with no detrimental effect. I have never found a dimmable CFL that is completely compatible with a X10 or Insteon Dimmer. Noise tends to increase with decreasing dim level and will eventually take the device off-line. No experience with LED bulbs. IM

Hello Brad, Rather than directly switching the input to your fan relay, could you parallel off the "fan request" from your thermostat? Most of the thermostat outputs that I have seen would allow this (open collector output). It would allow you to use a low voltage switch and keep the furnace "logic" for fan overrun timing, etc. intact. Note - this approach will not work with the newer "communicating" thermostats. IM

Thought I would share an example of how poor automation programming can lead to physical damage. I came home last week to find that my 1 1/2 inch sprinkler line had ruptured between the house and the sprinkler valve. Fortunately, the system had only been on for 10 minutes. This amount of time created a pond between my house and the walkway. Had this happened the previous week while a was away on vacation, the results would have been catastrophic. Other than a manual shutoff inside the house, there is no way of shutting down the leak. On inspection, I found 2 sections of the 1 1/2 inch line were "light duty" PVC schedule 20 or lighter while the remainder of the system was schedule 40. I replaced the two sections with schedule 40 and everything appeared normal. I then tried to convince myself that 9 years of service combined with yearly "blowouts" with my 2-stage compressor had simply worn that pipe out... Since the water "event" I've reviewed the automation log and have formed a new opinion of the root cause of failure. A number of programming errors had created rapid cycling of the sprinkler valve. This produced water hammer in the line and eventually lead to its failure. System setup I'm using a Hunter sprinkler controller with an IOLinc wired across the rain terminal input. I have sprinkling programs loaded into the Hunter and simply enable/disable the IOLinc at specific times based on Weatherbug data. Program 1 (Evening Sprinkler Control) The following was my starting program. I ran this for approx. 2 months, but never looked at the log file in detail. If From 5:15:00PM To 8:30:00PM (same day) And Module 'Climate' Rain Today is 0 " And Module 'Climate' Temperature <= 90 °F And Module 'Climate' Wind Speed Average < 15 mph Then Set 'Sprinkler-Relay' On Else Set 'Sprinkler-Relay' Off In coding the above, I had ignored my own advice - never use Weatherbug data to directly control a device. I should have used this program as a flag (true/false) and used a separate program to monitor it's status and control the sprinkler relay. Problems with Program 1: 1) The above program triggers whenever Weatherbug data is available. I had my update intervals set at 30 minute intervals so the program would send on or off commands to the IOLinc every 30 minutes, 24 hours a day (powerline pollution). I understood this, but chose to use the program anyway due to lack of time. 2) What I did not realize is that Weatherbug data is parsed as individual entries. In my above program the Temperature and Wind conditions are what I would call "High Rate" variables. These are updated each time Weatherbug data is retrieved. Since they are parsed separately, the program is triggered twice for each weatherbug update. The following is an example of my sprinkler program being triggered twice during a single W weatherbug update: Sun 07/25/2010 11:12:10 AM : CLI-WBug: Connecting to datafeed.weatherbug.com Sun 07/25/2010 11:12:11 AM : CLI-WBug: Successfully Processed WBug Response Sun 07/25/2010 11:12:11 AM : [MOD 2 2 1 1] 739000.000000 Weather - Temperature = 73.9 °F Evening program Trigger (false) on Weatherbug Temperature: Sun 07/25/2010 11:12:11 AM : [iNST-ACK ] 02 62 13.32.8B 0F 13 02 06 LTOFFRR(02) Sun 07/25/2010 11:12:11 AM : [iNST-ACK ] 02 62 13.32.8B 0F 13 02 06 LTOFFRR(02): Process ACK: duplicate ignored Sun 07/25/2010 11:12:11 AM : [MOD 2 2 1 6] 510000.000000 Weather - Humidity = 51 % Sun 07/25/2010 11:12:11 AM : [MOD 2 2 1 10] 550000.000000 Weather - Dew Point = 55 °F Sun 07/25/2010 11:12:11 AM : [MOD 2 2 1 11] 30000.000000 Weather - Wind Speed = 3 mph Sun 07/25/2010 11:12:11 AM : [MOD 2 2 1 12] 70000.000000 Weather - Wind Average Speed = 7 mph Sun 07/25/2010 11:12:12 AM : [MOD 2 2 1 13] 30000.000000 Weather - Wind Direction = NE 2nd program Trigger (false) on Weatherbug Wind Speed: Sun 07/25/2010 11:12:12 AM : [iNST-ACK ] 02 62 13.32.8B 0F 13 02 06 LTOFFRR(02) Sun 07/25/2010 11:12:12 AM : [iNST-ACK ] 02 62 13.32.8B 0F 13 02 06 LTOFFRR(02): Process ACK: duplicate ignored Sun 07/25/2010 11:12:12 AM : [MOD 2 2 1 18] 259000.000000 Weather - Light = 25.9 %/h Sun 07/25/2010 11:12:12 AM : [MOD 2 2 1 19] 62000.000000 Weather - Light Rate = 6.2 %/h Program 2 (Morning Sprinkler Control) July rolled around and I found that I needed a morning cycle of the sprinkler system to keep up with evaporation. I copied the evening program, changed the time constraint, and added prior day rainfall monitoring. The addition of this program is where I caused the damage to my system. If From 3:35:00AM To 6:15:00AM (same day) And Module 'Climate' Rain Today is 0 " And Module 'Climate' Temperature < 88 °F And Module 'Climate' Wind Speed Average < 15 mph And Program 'Rain Yesterday' is False Then Set 'Sprinkler-Relay' On Else Set 'Sprinkler-Relay' Off Problems with the Combination of Programs 1 & 2: 1) The combination of the Morning and Evening programs created a conflict when one program was within its time range and the other was not. If the Morning program evaluated to "true" it would send the ON signal to the IOLinc and enable the system. The Evening program would necessarily evaluate to a false (since it would not meet the time constraint) and would send an off command to the IOLinc. 2) Through sheer dumb luck, the system appeared to work correctly. The order of events were such that the system would enable at the correct time and run. 3) The parsing of the Weatherbug data, and the multiple triggering per event is were I feel the real damage was done. I had increased my Weatherbug update rate to 5 minute intervals which further compounded the problem. The following log shows the overlap of the two programs which caused rapid cycling of my sprinkler valve at 5 minute intervals. With two on/off cycles every 5 minutes and roughly a 1.5 hour run time (90/5*2) I was hammering the system 36 times each time it ran. The pipe failed within two weeks after my adding the Morning program. As I indicated, I was on vacation over one of those weeks. It would seem that dumb luck was again on my side. I've never considered myself a lucky person. Based on these events, I may have to re-evaluate things. Corrected Programs: As i alluded to above, Weatherbug conditional programs should not be used to directly control devices. Instead, the program should be used as a "Flag" or variable and monitored by another program that controls the actual device. The first correction was to change my Monring and Evening programs to "Status" programs: Morning Status: If From 3:35:00AM To 6:15:00AM (same day) And Module 'Climate' Rain Today is 0 " And Module 'Climate' Temperature < 88 °F And Module 'Climate' Wind Speed Average < 15 mph And Program 'Rain Yesterday' is False Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') Evening Status: If From 5:15:00PM To 8:30:00PM (same day) And Module 'Climate' Rain Today is 0 " And Module 'Climate' Temperature <= 90 °F And Module 'Climate' Wind Speed Average < 15 mph Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') The above programs are then used as "Flags" or conditions for two programs that actually control the Sprinkler valve. This prevents the high rate cycling of the valve. Sprinkler enable: If Program 'Evening Status' is True Or Program 'Morning Status' is True Then Set 'Sprinkler-Relay' On Else - No Actions - (To add one, press 'Action') Sprinkler disable: If Program 'Evening Status' is False And Program 'Morning Status' is False Then Set 'Sprinkler-Relay' Off Else - No Actions - (To add one, press 'Action') Other Corrections: I encountered a condition this weekend where the wind speed was toggling above/below the 15 mph limit of my program condition. As a workaround I slowed the Weatherbug update to 30 minutes. I'm considering separate programs for monitoring windspeed/temperature and Rainfall. The effect that I am going for is 1) If windspeed/temperature are within limits, then run the program and ignore future updates (don't shut down the system while it's running). 2) If it begins raining while the system is running, shut it down. As you might imagine, I'm approaching this cautiously. I consider myself extremely lucky that my mistakes only lead to a split piece of PVC. This amounted to a few dollars worth of plumbing and an hour of "quality time" with a shovel. It could have easily resulted in a flooded basement or a fried pump (~$1200). I am by no means a programmer by nature. I cannot "see" faults in a program through mere inspection. I need to run/observe the operation to determine the functionality. Obviously, I did not perform "due diligence" in my testing of the above. Please do not repeat my mistakes. You may not be as fortunate as I was. After making changes to your system, monitor both your event viewer and log files. If you have questions/concerns, post them here. The ISY team is excellent and there are numerous members who are both "ISY programming savvy" and willing to actually test programs. IM

Hello rhughes, Here's my experience: 1) Triggerlinc - problems with RF range. Need to include the cost of additional accesspoints in the system cost. 2) I/OLinc - good little devices, but not inexpensive. Monitoring 10 contacts will run you $390 (they have a sale on 4-packs for $150 right now). 3) EZIO8SA - no experience. 4) other - ELKM1 with a serial to Ethernet adapter: Use the ELK to monitor switch contacts and communicate changes to your ISY via the LAN. You import your ISY units and scenes into the ELK and then trigger the devices using ELK "rules" in response to switch closures. Not inexpensive, but it's a nice central package that has plenty of expansion capability.

Hello gviliunas and Brian, Michel did in fact confirm that powerline activity interrupts the PLM Link count process. Sorry, I can't seem to locate that thread right now. In short, you are not having comm problems and you are not misusing the feature. In the past (when I've been serious about getting a link count) I've isolated the PLM behind two filter to prevent interruption. Things become even more difficult if you have a dual band PLM (I do not). You would likely need to remove accesspoints and disable other RF transmitters.

Hello atmit, To be honest, I'd pull the airgap on the "master" kpl to kill the circuit. Since your KPL is a dimmer it's feeding a rather ugly output voltage to your other devices. At best, they will behave erratically (as you've noticed). Until the wiring is corrected, I'd suggest disabling to prevent someone from inadvertently activating the KPL. IM

This sounds as if the "master" KPL is providing power to the other devices (very possible if the original switches were 3-way). The KPL and Inlinelincs need continuous (unswitched) power to operate correctly. This is normally done by inspection of the breaker panel. On most panels, the breakers alternate phase from top to bottom. Have a look at the Jeff Volp link that I provided above. He has an example layout for a typical panel. Not sure whether you want to try to correct this yourself or have your electrician back to correct. If you have the electrician back, explain that the switches require continuous power. Also ask whether the devices are on the same phase. Note that the devices "can" operate across the phases. Depending on the coupling through your transformer, operation will vary.

Hello atmit, Phase coupling, or communicating across the legs of your utility transformer, has been around as long as powerline communication (X10 powerline from the 70's). Most homes are supplied with "split single phase" power from a utility transformer. The are three connections to the transformer - 120V-Leg1, neutral, and 120V -Leg2. Many people refer to the "Legs" coming off the transformer as "phases" because they are 180 degrees out of phase. Measuring from either 120V Leg to neutral will show 120V. Measuring from 120V-Leg1 to 120V-Leg2 will show 240V. Your breaker panel distributes both Leg1 and Leg2 voltages throughout your home. Devices communicating from Leg1 to Leg1 will be able to communicate directly (same for Leg2 to Leg2). Devices that are trying to communicate from Leg1 to Leg2 must do so through the utility transformer. Because the transformer can be some distance from your home (and has internal impedance or "resistance"), signals crossing from Leg1 to Leg2 will be attenuated (reduced). Smarthome has developed accesspoints which communicate between the Leg1 and Leg2 devices via RF. This eliminates the signal attenuation the normally occurs through your utility transformer. There are other "hardwired" devices that can couple the communication across the Legs of the transformer. Jeff Volp put together a nice tutorial on the subject here: http://jvde.us/x10/x10_couplers.htm. While Jeff put this together for X10 applications, it applies to Insteon as well. Terminology - Where Jeff refers to "Phase A and B" I am using "Leg1 and Leg2) above. .

Hello Mitch, I tried to explain this function in one of your other posts (poorly). The alarm interface is being treated as a "control" function. As such, the ISY will re-evaluate the condition each time your "alarm disarm" occurs. What you need is a "Latch" to keep the program from re-executing if the input does not change state. You can do this with a simple dummy program. The following uses the program "toggle" to latch the control input. On it's first pass, program toggle is False and the condition evaluates to true. On a second pass, Program toggle is true and the condition evaluates to false. This prevents successive "control on" events from executing the program multiple times. If Control '11.1F.DB.1' is switched On And Program 'Toggle' is False Then Set 'BSMT Fam Cans' On Run Program 'Toggle' (Then Path) Else - No Actions - (To add one, press 'Action') The opposite condition is shown below. Note that you will need to "initialize" the dummy program "toggle". It's state will be indeterminate when the isy is restarted. If Control '11.1F.DB.1' is switched Off And Program 'Toggle' is True Then Set 'BSMT Fam Cans' Off Run Program 'Toggle' (Else Path) Else - No Actions - (To add one, press 'Action')

Hi mitch, It sounds as if the program conditional for your *Alarm Disarmed is acting as a control function not a status. Here's a simple example of the two with a SWL: Control - This will run every time the SWL is turned off regardless of the previous state. Multiple off sequences will cause the program to re-run. If BSMT_SWL is Switched off then Turn off basement lamplinc Status - This will run when there is a status change in the SWL to off. Multiple OFF sequences will not re-run the program. If BSMT_SWL is off then Turn off basement lamplinc Beyond that, alarm systems can be tricky. The tough situation is the *Alarmed Stay mode where you can have occupants momentarily opening doors and windows. You don't want to trigger events every time the system cycles. You may need to add some "persistence" to the inputs for this scenario. IM

Hello Michel, In a word - WOW. I did not realize that the newer KPL's were able to do this. I can clean up a LOT of programs that I'm using as "work arounds". Thanks, IM

Hello Bonanza, Some answers (and questions) below, I thought this was going to be an easy one. My recollection is that you cannot turn off the Main load button using a sub button on a KPL dimmer. The problem is, I just tried it and it worked. I'm using V2.7.15 on a ISY99. I can't explain why this works. Is it possible that you have the "B button" set in a "non-toggle Off mode"? This could be due to communication problems with the Switchlinc. Open the "event viewer" on level 3 (/tools/diagnostics/Event Viewer) and look for errors. I haven't seen a tact switch failure for a great while. Since you indicated this is a new unit, I very much hope it's not the switch. Does this unit control the load directly? If not (controlling a lamp through a scene), it's possible that the switch is again having communication problems and can't activate the scene responders. IM Edit: Michel beat me to the punch again. I must be one slow poster.

Alf, No I do not work for UDI or Smarthome. Just an aerospace engineer who's been around the block far to many times and is looking forward to a second career (I'm a ways past retirement age). If I remember correctly, you're a pilot. If that's the case, I'd wager that you could teach me a lot as well. I'd love to add you to the neighborhood - 1 - 80 year old "craftsman" : designs and builds staircases for 7 figure homes in the area. 2 - Transmission shop owner/drag racer 3 - Physics professor at Notre Dame. 4 - Commercial construction engineer/contractor. I really enjoy getting together with this diverse group (at my neighbors pole barn/pool table). I can't tell you how much I've learned over the years. If you'd consider moving to Indiana, we can offer...well - Corn. IM

Hello ergodic and alf, Alf has a bit different situation - he is using a relay unit to switch the transformer. The relay is rated for 15A (1800W) with a resistive load. SH has de-rated the relay to 480W for use with incandescent and inductive loads due to the surge current that these devices can draw. The surge current drawn by incandescent lamps is predictable if you know the temperature of the filament. My 50W floods show a resistance of 21 Ohms when cold. This bulb would draw a surge current of roughly 5.7 Amps when cold. If 9 of the 50W floods were on a circuit (total load 450W) the cold resistance would be 2.3 Ohms (9 - 21 Ohm loads in parallel). This would draw a surge current of roughly 51 Amps (ignores inductance and other factors). So, SH has concluded that the relay contacts can handle in excess of a 51 Amp load (for a brief period until the filament warms) without degrading the life of the relay contacts. Switching over to inductive loads - They do draw surge current and they store energy. This can result in overheating/arcing of the relay contacts at both turn-on and off. My earlier point was that the surge current of drawn by transformers is far less predictable. Max current draw occurs when the relay is switched during the powerline zero crossing and there is residual magnetism in the core. This is an exercise in probability. Relay arcing will occur (depending on the charge storage and contact speed) each time the relay is opened. I find it "conservative" that these inductive ratings are the same as the incandescent. Moving to the transformer itself - As stated earlier, most transformers are very efficient (98% is common). Looking at Alf's transformer, I think they are including the "de-rating" in the specification. Most manufacturers quote 400W input/400 W output after de-rating 80% (the transformers can actually handle 500W). It appears that this manufacturer has included the Max 500 W input rating along with the de-rated 400W output. Bottom line - I would expect that the transformer would draw an input power very close to the 12V load power (well below the 480W rating of the SWL). I also believe that the SWL inductive rating is conservative. Once again, this should not be a safety issue. It could be a wear-out issue where the relay contacts degrade over time. For the reasons stated above, I do not believe this will be the case. If I am wrong, PM me and I'll ship out a relay SWL (I don't plan on going anywhere) . IM

Alf, From your previous post, I think you meant that you have two channel outputs of "200" watts each (typo?). Also from your earlier post, you indicated that the transformer was 500W in/400W output. As jerlands indicated, transformers are normally pretty efficient devices - my earlier example of and 80% efficiency is extremely conservative (i.e. military style derating). I'm very surprised to see that the manufacturer is quoting this low an efficiency. Can you provide a model number so we can review the transformer specs? By the numbers you have a 80% efficient transformer with a 255W load on the output. input power consumption would be 255W/0.8 = 318W (well below the 480W rating on the SWL label). If you're concerned about expansion (additional lamps), I'd suggest measuring the actual consumption by the transformer with your planned 255W load. My educated guess is that both the SWL and the transformer ratings are very conservative and that your system would be reliable with the full 400 watt load on the transformer. If the worst were to happen (the load is in excess of the relay contact capability) this becomes a wear out issue with the relay contacts. It is not a safety issue. The relay contacts will simply wear out prematurely. IM

Hello Alf, I apologize, but I have to retract my earlier posts indicating that the relay units were rated for 15A inductive loads. This was a bad assumption based on the website information. Today I found an old photo that I had taken of a V2.5 relay unit. Based on the label, the inductive rating is the same as the incandescent.

Hello sfhutchi, If you are interested in true "occupancy" sensing you may need to step things up a level. There are devices available that incorporate dual IR/Ultrasonic sensing that might be able to accomplish your goal. A few caveats: 1) I do not know of any low voltage versions of "dual" sensing devices. Most are configured to directly control a load (120 V). 2) I've never used something like this in a bathroom (conference rooms yes - worked well). 3) Most of the devices I've seen are relay type outputs (non-dimming). A combined PIR/acoustic type sensor would presumably activate when motion was initially sensed. It would continue to "hold" until both the PIR and Ultrasonic sensors indicated that motion had ceased. The Ultrasonic sensor is capable of detecting motion that is not "line of sight". It uses a Doppler shift algorithm to detect hand motions and other motions that a PIR cannot see. Presumably, this would include motion within a shower from both the occupant and the shower head itself (turbulence from the water flow). As I indicated, my direct experience is with conference rooms at work. My job requires late night remote conferences with our partners on the West coast (my teammate is of the opposite sex and many years my junior -I'm trying to be PC here - it doesn't come easily). On numerous occasions, our "commercial grade" motion sensing system has plunged us into darkness. I sincerely hope that this was more awkward for me than my teammate (I found it uncomfortable). After a few episodes, I recommended the Leviton OSSMT-MDW to our electrician. Our electrician managed to push things through the system (Ugh) and installed these in three conference rooms. To date, we have great performance in two of the three conference rooms (no more awkward moments). The third conference room has two doors located on a busy hallway. Once triggered on, traffic on the hallways keeps the lamps burning most of the day regardless of activity in the room. I hate recommending products for applications that I do not have personal experience with (I'm breaking from tradition here). You could start slow by replacing an existing switch with the Leviton dual sensing switch. Documentation is here: Leviton OSSMT-MDW A general "occupancy sensing" guide is available from Pass and Seymore here: Motion Sensing Guide If you want to automate, the above have only 120V outputs. You would need a 120V capable sense sensing function (SWL with sense) to signal the ISY and other Insteon responders. If you want level control, things get further complicated... IM

sfhutchi, Bathrooms are tough. This is an area where you may want to sacrifice some automation efficiency to maintain harmony. As you indicated, motion sensor are going to have a tough time given the layout of most bathrooms. As you also noted, they can't know the intention of the occupant. There are ways of telling your automation system what the occupants intention is. Back in the X10 days, I used 2 motion sensors and a 6 button KPL attached to the bathroom fan to instruct my X10 controller on how the bathroom was being used. The various fan buttons would trigger a automation timer (10, 20, 30 minutes) so the user could effectively select the bathroom "mode". While the above worked well most of the time, I would sometimes get communication collisions between the motion sensors (being in a relatively confined area). As you well know, it only takes 1 Oh Sh$$ to erase a lot of atta-boys. That's how I would characterize this setup - 99%, but that 1% failure would really hurt. When I moved to the new house, I made the decision not to automate the baths. I installed CFL lighting and a hardwired Leviton fan timer. This setup is 100% to the bosses liking. IM

Brad, Sorry if we're slow in providing details. We're somewhat bound by the terms of the Alpha/Beta test agreement. Matt Randle is leading the testing from the SH side: mrandle@smartlabsinc.com