IndyMike

Michel, The compare feature is absolutely not a rush item. With your new context menu I can easily bring up a device link table and the ISY table side by side. Not quite as convenient, but it will certainly do for now. Thank you for the offer, but please focus on the many other requests that we forum members are posing for the team.

UDI team, Thank you again for all the effort. You really should take more credit for the fixes and enhancements you make in the product: Bug Fixes - 369: Contextual menu does not work when event viewer is in the way Confirmed - this was a big one for me. It's rare that I don't have the event viewer open, and on level 3. Previously, I was constantly moving the viewer around to allow the context menu to function. Enhancements - 222: Immediate level setting for dimmers (in addition to Dim/Bright buttons) Very nice - I've used this extensively already. I've been mapping the power curves of both incandescent and CFL lights. By clicking below the setting "bar", I can adjust levels in 1% increments using the cursor keys. A huge time savings. - 370: Event Viewer levels are now in a list (instead of a popup dialog) I'm a keyboard person - I really appreciate the use of lists rather than constant popup's. Nicely done. - 391: Diagnostics context menu on nodes This item is the real reason for my post: 1) Right clicking on a device brings up a menu that now includes diagnostics (show device links and show ISY links). 2) Right clicking on a scene again brings up a menu including diagnostics. For scenes, this allow you to perform a "scene test". This little improvement has quite simply made my day. I can't tell you how many times I used the drop down menus to search for a scene (scene test) or device (show device links) only to grab the wrong one. Being able to select from the tree will cut down significantly on my incorrect selections and subsequent trips to the refrigerator (while waiting for the wrong scene test/link table display to complete). I can feel my health improving already. Unfortunately, it doesn't appear to be 100% good news. I have not been able to get the "compare" function to work in the "show device links" function. Nonetheless - thank you your never ceasing presence on the forum and all the hard work on the product, IM

I thought I remembered where the dimmers were rated for magnetic LV loads - I can't find any evidence of that now. I may be remembering the X10 line. One comment on the overshoot near the zero crossing - this is substantial and I have not seen this with capacitive loads. I'd be interested in how this is referred to the line input of the switch. It would be occurring in the area (time frame) where Insteon messages are located.

Hello ergodic, Thank you for the plots. I haven't tried a dimmer output into an inductive load. As I was staring at my ongoing test setup this weekend, I came to two conclusions: 1) My plots above were generated with a 0.1u capacitive load. 2) I didn't have the proper load for your application 3) You've already performed the "acid test" when you hooked up your transformer and monitored the temperature. Sorry, I should have posted back earlier.

Hello CLU, Welcome to the forum. If you are using a dimmer, you could set the ramp rate to allow you to exit the area (1 minute or so). This would not require program intervention. If you want full brightness for 10 seconds your could use the maximum dim interval (9 minutes on some devices). You would then use a "fast off" command in your program. If Control "bathroom" is switched off Then wait 10 seconds set "bathroom" fast off I don't have a good solution if you are using a relay - there isn't a way to override the local switch function. You could install a Keypadlinc near the switch and use a secondary button (and program) to turn off the relay.

In that case I'll try the output of a newer SL dimmer. I've just put one on a long term power consumption test. These newer units appear completely different than my older models. This particular model isn't even registering on my Kill A Watt (previous units drew ~1W). A quick look at the components shows some significant changes as well. The old models had some rather large electrolytic and ceramic caps. These are gone on the newer models. The inductor appears to have at least 2x the turns on the newer units. I'm hoping the output performance is improved on these units. I'll try to get you some plots by the weekend.

Hello Ergodic, The following shows a pretty healthy DC content from a LampLinc. Don't remember what the Dim level was. This was likely from my "old" V1.0 LampLinc that I typically use for test purposes. It's possible that later units or SWL's preform better (since the SWL's are sometimes used for fan control). What type/version device are you using.

Hi Darrell, From the men-of-few-words department - Thoroughly , but that's my problem not yours... Exactly correct. As I posted in the "other" thread, devices with good PF are friendly to powerline communication and the utilities. Devices with poor PF (CFL's and such) cause problems with both powerline communication and long term problems with utilities. In the past, the current draw from these devices was below the radar. This is beginning to change. Other countries have adopted PF and HD (harmonic distortion) requirements for consumer devices. This will cost more in the short run, but should save us money (infrastructure-ultilities-tax dollars) down the road. So much for the few words attempt. Tried it, couldn't make it work. IM

Hello Darrell, At one time I had a link to a really nice description of the Electro-mechanical power meter construction and theory. I can't find that now... With some quick searching, the best description I could come up with is the Wikipedia site - http://en.wikipedia.org/wiki/Electricity_meter These meters use totally analog current and voltage transformers to generate a magnetic force on the aluminum disk. Since it is a true analog system, the force is proportional to the Voltage and current at a particular instant in time. Power that is being drawn out of phase (high current/ low voltage) will create less magnet force on the disk. Power that is being drawn in phase (high current/high voltage) will create high force on the disk. In reality, you will have many devices in your home drawing power at various phase angles. The analog meter, being a true "averaging device", will sum all of these forces on the aluminum wheel and produce a "total in-phase" power equivalent. Being an old ****, I both love and trust the elegance of the analog design. When I read the descriptions of the new electronic meters, my brain begins to hurt. Hope I answered your question, IM

Hello midrar, Please see (some) answers below. Then statements will be executed in the order entered. Rather than executing a bunch of individual statements, you may want to create a "Scene" with multiple modules. You can then use one simple statement to turn the "Scene" on or off. The only place that I currently use "wait" statements is between X10 and Insteon commands. Here's an example of a "night" condition - The dim levels are for backlight control and are for the entire KPL (not individual buttons). Create a scene with the Keypadlinc button that you want to control (i.e. xxx program status). You will then be able to control the "Scene" from your then statement.

Sorry UpState, Just saw that you wanted you program to re-start immediately. I think that will require two programs. You'll also want to play with the wait times - this can put a pretty heavy load on your system. Query Timer If From Sunrise To Sunset (same day) And Program 'Query Program' is False Then Run Program 'Query Program' (Then Path) Else - No Actions - (To add one, press 'Action') Query Program If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Set Scene 'SC Outside Off' Query Wait 5 seconds Set Scene 'SC BSMT Game' Query Wait 5 seconds Run Program 'Query Program' (Else Path) Else - No Actions - (To add one, press 'Action')

Hello Upstate, I use the following to periodically poll my outdoor lights during the day. To do what you have described, you could query individual devices (with delays between) or scenes (again with delays between). Setting the "Last Run Time" will determine how often the program executes. Note that the "Last Run Time" is when the program STARTS execution. If you have a long query sequence (minutes) you'll need to be careful not to set the iteration time too short - I'm not sure what would occur (multiple instances or program re-starts and misses statements at the end). 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')

Exactly correct - although in this particular instance it would have made gallons of sense. I had viewed the "rain input" terminals on the Hunter controller as a simple program enable. What I failed to recognize is that, when the the irrigation programs were running, cycling the "rain input" would directly control the sprinkler valves. Rapid cycling of the valve led to repeated water hammer and the failure of the PCV. I have since been using Rand's suggestion of the 5 minute wait, which effectively filters input changes. I've been monitoring for over a month now and have not noticed any cycling (I can see that it should work, but I have to monitor to verify). I don't think I ever properly thanked Rand for his input, and wish to correct that now. Thank you Rand - for a guy who used to work the high steel, you are one heck of a programmer. IM

Hello Alf, To add a bit to Rand's comments (that I totally agree with), much of the life of an incandescent bulb is used during initial turn-on when the filament is cold. When the filament is cold it will exhibit a much lower resistance than in it's normal operating state. When used with a relay, this produces inrush current that can be 10 to 20 times the steady state current draw of the bulb. This creates and incredible thermal shock in the bulb filament. A typical bulb that is rapidly cycled will not last nearly as long as a bulb that is left on continuously. When an incandescent is use with a "soft start" dimmer, this inrush is greatly reduced and the bulb life greatly extended. I've never seen any estimates on how limiting inrush can improve bulb life. However, there are documented relationships for applied voltage and bulb life - a 5% reduction in applied voltage can double an incandescent life. A typical dimmer at 100% output does not supply 100% voltage (more like 98%). Dimming down further will further increase the life of the filament (again I don't have number - this is not a linear relationship). I have used both Insteon relay and dimmer units in my home since 2005. I have not noticed a reliability difference between the two. The big question is what type of load you intend to use. If you plan to convert to CFL in the future, you will need either a dimmer/dimmable CFL or a relay/standard CFL. Beware that the relay units are only rated for 480W Incandescent because of the current inrush. If you have large incandescent loads (chandeliers) you may not be able to use them. Since we mentioned CFLs (well I did anyway), be careful in calculating the payback on these units. My experience has been the the life of a CFL is overstated, while the life of an incandescent on a "soft start" dimmer is greatly understated. Since the cost of the incandescent bulb is a factor in the payback, consider that your bulbs will last much longer on a dimmer than advertised. IM

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 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