IndyMike

CompKing, I share your concern regarding high humidity levels in winter. As well build tighter, more efficient homes it becomes increasingly difficult to control the humidity in winter and provide fresh air. Using setback thermostats compounds this problem. As the house temperature decreases the RH increases and you again have water puddled on your windows. I went down the path of "Reheat" humidity control 6 years ago with a Honeywell dedicated system that I set up myself. Nice sophisticated setup with outside temperature monitoring and automatic compensation for internal RH. I gave it up in the first year. 1) Running the A/C in the winter drove me nuts. Every time the A/C kicked in all I could think of was that I was paying for heating and cooling at the same time. 2) When running a setback thermostat, the system would tend to drive the temperature down to the low setpoint rather than letting the temperature "drift" down. An alternative to using the "Reheat" mode to lower the humidity would be to install a outside vent kit (motorized damper ducted outside). By bringing in the cold air and reheating it you achieve the dehumidification and ventilate your home at the same time. Since the heating systems are typically more efficient than A/C dehumidification, you are also saving money. The Venstar thermostats include a programmable output that could be used to control the damper motor on a outside air duct. Add a call for low speed furnace fan and you have a dehumidifier/ventilation system. To make this accurate you would also require an outdoor temp sensor, but it sounds like you've already taken that into account. You could make things fancy and activate your bath/range hood fans (Insteon) the exhaust stale air from the home. IM

MikeB, Yep, I agree with the "crazy comment". My Wife was initially looking for "new" motion sensors that were triggering lights as she moved around the house. I'm innocent, by the way. I haven't added to or modified by configuration since July of last year. Last firmware update was for V2.6.12. No I2 modules installed. No X10 addresses assigned, and no evidence of X10 transmissions in either the ISY log or my Cm15a log. In my experience, the probability of a valid X10 transmission being generated purely from noise is extremely low. I have seen valid X10 transmission become corrupted by noise and "morph" into an unintended command or house/unit code. The problem here is that there is no valid communication to corrupt. The probability of an Insteon command being spontaneously generated by noise is far lower still. I suppose I could ask my Wife (math professor) to calculate the probability of generating valid Insteon addresses, flags, commands and CRC's, but I have to believe her response would not be polite. In the face of all those odds against this occurring - then phenomena is real. Since I don't have my signal analyzer handy, I'm chalking this up to noise directly affecting the PIC in certain switches. This is not the first time that this has been reported, it is the first time that I've experienced the problem. Rowland has a thread related to a noisy PC causing the same type of problems: http://forum.universal-devices.com/viewtopic.php?t=1188&highlight= I should have made it clear that I really am not looking for troubleshooting help with this activity. I don't intend to operate power tools in my basement long term (my workshop is on a dedicated filtered circuit). I'm offering this up as another possible cause for "spontaneous lighting" in systems where I2 is not being used. IM

aLf, A 100W bulb should have no affect - if it does we're all in a world of hurt. Any other "linked" devices that may be operating inductive or capacitive loads?

alf, What type of device do you have connected to the SWL relay? There have been instances of noise sources making it through the filtering in the switches and activating them directly. I'm in the process of finishing my basement and have been using all manner of power tools. During that time my better half has noted several instances of lights coming on spontaneously. Each time that I have tried to track this down, the ISY showed no related communication (X10 or Insteon). Over the past few days my wife has gotten in the habit of informing me through the intercom when devices turn on spontaneously. By doing this I've been able to narrow the culprits down to a Porter Cable hammer drill, and a Bosch recip saw. Both tools are variable speed and double insulated (two wire connection to power). The twist is that I'm operating these on a completely separate 20A circuit in my basement. The noise generated by these tools is making it back through my electrical panel and affecting circuits on both phases (I suspect it's on the neutral). The message here is, if resetting your togglelinc doesn't work, try disconnecting the load from your SWL relay. If this eliminates the problem, there you may be able to filter the input to the load (depending on the type). IM

Upstate, You've confirmed that the ISY maintained the links for the device. This is why you can communicate with the SWL directly from the GUI. I still don't understand why the restore didn't put the links back in the SWL. It's possible that the missing links in the PLM caused this to go awry. We'll definitely need Michel for this... I'm beginning to think that your "old" PLM was in fact OK. It was simply missing links to the devices much like your current SWL. The real question is why the links are missing.

Hello Upstate, Just to sum things up (make sure we have the facts correct): 1) Your ICON works fine from the GUI but doesn't report status in response to a local on. 2) The PLM does not show links for the device (Diagnostics: show PLM Links table 3) After a factory reset/restore, the switch has no links listed (Diagnostics: show device Link table). Please correct me if the above is inaccurate. Would you be kind enough to inspect the ISY Link table for this device? Since you can communicate with it directly, they ISY should have entries for it. If you have no entries for the device in the PLM, I don't believe the PLM will listen for device "local on" changes. You may need to restore your PLM (again). Please wait on Michel's input prior to doing this.

Michel and Upstate, I've been "lurking" for some time now as this thread developed. If I am correct, a missing link in the device/plm would cause the switch to malfunction 100% - correct. From the previous thread, Upstate had reported that the problem switch plugged directly into the PLM would "sometimes" register: http://www.forum.universal-devices.com/viewtopic.php?p=12926#12926 This has still has me scratching my head. I also have a V2.5 SWL relay (date code 0750) which does not exhibit the problem. I am in no way inferring that the problem is not with the switch, just questioning whether this is I2 related. If SH is mixing I1 and I2 firmware within switch revs and date codes - well I'm not sure what I'd do... Is it possible that the EEprom entries in the Switch itself were "badly programmed"? If the switch can't properly read it's own link table it would not transmit correctly for a local ON. A weak memory location shouldn't happen, but it's possible that the programming voltages for this unit are marginal or affected by local disturbances. Upstate - have you tried clearing and programming the SWL with it plugged directly into the PLM? IM

Steve, The exterior wall routing isn't that good, but it's not all that uncommon either. You most likely have an "open" design on your first floor. The plumber got first dibs for drains and supply lines. The HVAC guys got what was left (the exterior walls). I've been fortunate in that I had a hand in designing both of our houses. We included 6" interior walls at certain locations on the first floor to accommodate ductwork. Even after detailed planning, a last minute "shift" in the design of my current house forced ductwork into a garage wall to feed my sons room (similar situation to what you've described). We tried to compensate for the bad routing by running two vents to the room (above the garage) but cooling the the summer was horrible (heating wasn't all that bad). My workaround was to add a 6" inline boost fan that was triggered off the zone control. These are typically 110V fans so you would need a relay (24V input) off your furnace to switch the 110V to the fan. The fans are available at most hardware stores (I think I got mine at Menards ~$30). Downside is that these can be noisy. You can insulate around the fan to minimize noise in the basement, but it can echo through the ductwork (into the bedroom). The message here is don't overdo things. If you have space, a section of flex duct can help dampen the noise. Past that, most newer thermostats have a programmable "circulate" mode. This turns on the blower at low speed (if available) to redistribute the heat/cold in the house. If your boost fan is triggered off the main blower, it would also activate. If you wanted to get fancy, you could install temp sensors to monitor the differential between the bedrooms and the main thermostat location. If the temperature exceed XX degrees issue a call for fan only, XX+YY call for heat/cold. I'm not all that well versed on the capabilities of the Insteon thermostat adapters. Maybe another forum member can help here. Bottom line is you will be tuning your system to work with the existing ductwork. Take things in small steps and take time to evaluate the results. IM

Steve, Welcome to the forum. You've picked a rather complicated task for automation. In my opinion, while your goals can be accomplished, I would not choose any automation technology to implement it. You situation is complex because you have an existing system. Your ductwork, vents, and cold air intakes have all been sized to provide the proper airflow across the heat exchanger in your furnace. If you begin to shut off sections of the ducting via zone controls, you will reach a point where the airflow is insufficient across the heat exchanger and it will overtemp and shut down. At best this is inefficient. At worst you will continually overtemp the exchanger and cause premature failure. This becomes more complex if you have A/C. A/C coils also require a minimum amount of airflow across them to prevent freezing the unit. The problem here is that the cool air is heavy and doesn't want to be pushed to your second floor. Normally a furnace will use a 2-speed blower to overcome the heaviness of the cold air. If you implement a zone system to for more air to the second floor, you risk reducing the airflow below the minimum level. If coil freeze up does occur you can feed liquid freon back to the compressor (outside) and destroy it. Retrofit zoned systems typically include a "barometric bypass" (dump zone). This is essentially a vent that opens when the system is constricted (zones closed) in order to provide enough airflow across the heat exchanger/A frame. Next come the "Zone Control Panel". This dedicated panel interfaces to the multiple thermostats, controls the zone dampers, and monitors the furnace temperatures to prevent over stress. This is the piece of the puzzle that I would not trust to automation. The next step is the thermostats themselves. Here you have the latitude to use HA. For your problem with the fireplace you could use an Insteon compatible thermostat and simply monitor the room temp. When the room rises above a certain temperature (heat mode) turn on the circulating fan to warm the rest of the house. No much, but it will help. Give us some more details on your heating distribution problems. Is the upstairs cold during winter and hot during summer? You may need more insulation in the attic or "tuning" of your existing vents. Sorry for the "downer", but this isn't a simple job. IM

Eddy, I don't believe there is currently a method for copying an entire scene at the scene level. You can, however, perform a copy of all the units within a scene. 1) Create your "new" scene. 2) Select the units (highlight) that you wish to copy from your "master" scene. You can use the "shift - left mouse click" method to select a list of units or use "Crtl - left mouse click" to select specific units. 3) Once highlighted, press "ctrl" and "left mouse click" on the units. Drag them to your new scene. In response to the above, the ISY will prompt you with your list of units and inquire whether you want to make them controllers/responders. The ISY will copy the unit attributes (level/ramp rate) from your master scene. It will not copy the "scene attributes".

Is "deleting the temporary files" from the Java Control Panel the same as "clearing the classloader cache" from within the Java Console?? Honest question, I really don't know. If the classloader cache is not being cleared, it would explain a number of jtara92101's problems. Have you tried clearing your Java cache after the update? Yes, I did. That is, assuming that "clearing your Java cache" means "go to the Java Control Panel and delete the temporary files". (Yet another documentation issue...) As well as power-cycled the device and rebooted from the telnet console. None of this worked.

Rich, As Mike B has indicated, I have not needed delays when using Insteon only Scenes. I have required delays when mixing Insteon and X10 protocols. It's possible that one or more of your devices have "stray" X10 codes left over from factory testing. This might interfere with your scene execution (your Family Room Light or outletlincs may be communicating X10 when your scene is activated). You can check for X10 activity within the ISY admin console. Go to "tools" and select the "event viewer". Activate your "Family Room Light" and watch for X10 communications. I am very curious whether this is the cause. I would expect that the PLM would "hold off" communication while X10 is present. I am sure, however, that there is a limit to this hold period. If you had two or more devices with X10 codes transmitting, you might exceed a timeout period. Please get back with us. Regards, IM

johne, As Brian indicated, I believe your transceivers are both manufactured by X10. That being the case, my theory of the "3 cycle gap" protocol doesn't hold water. It is possible that your "old" RR501 is in fact dying, as Brian has suggested. You mentioned that you had "both devices" installed and that things were functioning. Could you possibly plug your "old" unit into the "new" unit location? If your system works with this configuration, I'd suggest that you have a new signal absorber in your home. In my experience, the PLM does a pretty good job receiving X10 signals (sensitivity). The CM11a may, however, have better X10 sensitivity (or AGC) that allows it to receive when the PLM cannot. IM

Johne, I'm curious what model transceiver you replaced (TM751?) and what you replaced it with. It's possible that your "old" device was not allowing a 3-cycle gap between X10 transmissions. My Smarthome "Testerlinc" regularly flags X10 brand devices for not providing the correct gap between successive X10 commands while my Switchlinc devices (X10 mode) do not generate this error. I have read that certain Elk devices will completely ignore "X10 brand" communications for the same reason. IM

Joe, Welcome to the forum. You are correct that the ISY User Guide is a bit out of date. The fault lies with "WE" the forum members and Users of the system. We've kept the ISY people busy with our constant requests for additions. To our amazement, the ISY team has been fielding these requests and implementing them. Unfortunately, this has come at the cost of documentation updates. Fortunately, you've come to the correct place for answers. I, and many other forum members, share your X10 background. The ISY support for X10 has improved significantly since the release of the Users Guide. Have a look at the following categories: X10 : http://www.forum.universal-devices.com/viewforum.php?f=29 Beta Enhancements: http://forum.universal-devices.com/viewtopic.php?t=930. UD Wiki: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:Using_X-10_Motion_Sensors For specific questions, please let us know what current components you have in your system (modules, controllers, couplers, etc). If a forum member can't help, one of the ISY team probably can (they spend many hours on this forum). IndyMike

Chris, Thank you as well. I've been on the road a lot lately and missed the 2.6.6 folder condition update. Very nice! Can't wait to get home and give it a try.

aLf, Your posted code will enable the folder but your program lacks a trigger to start it (unless you are calling the program from another program). Each program requires an "Event" or a specific call from another program to start. The following will trigger if any of the "somethings" change state to ">0". You do not need the repeat loop here since the program will trigger if any of the monitored devices transitions from the off state. If status "something1" is > 0 or status "something2" is > 0 o o o or status "somethingx" is >0 Then Wait 15 minutes Set Scene 'All OFF' Off Else - No Actions - (To add one, press 'Action') Regarding your question about your "old" version - Yes this can make a difference. Firmware Version 2.6.4 corrected a problem related to status updates for disabled folders. Here's a thread on the subject - http://www.forum.universal-devices.com/viewtopic.php?p=8687#8687 Bottom line is, if you are running firmware older than 2.6.4, you may want to update. IM

Brad, Welcome to the forum. As of firmware version V2.6.5, there is a much easier way to monitor X10/Insteon communication (doesn't require telnet). Try opening the "Event Viewer". You can find this under the "Tools/Diagnostics" menu. The default level (0) will provide X10 communication monitoring. Increasing levels will provide increasing Insteon communication detail. I'm providing the above as an easier method for monitoring X10. Using this will not "fix" anything. If you did not see X10 indications in your logs there is a communication problem somewhere. Try your experiment again with the X10 device plugged into the PLM. Watch the PLM LED while sending commands with your controller. The LED should flash as it recognizes the X10 traffic. If the PLM LED does not flash in response to X10 traffic (I'm assuming it does for Insteon) you may want to check your X10 controller. If the PLM LED does flash, but you do not see traffic in the ISY event viewer, try cycling power to the PLM (10 seconds off). I've had instances where the PLM will become "deaf" after a power spike (storms/lightning). The device will send commands but not receive. IM

Dave, I'm assuming that the thread you are referring to was the one posted by Tracy. http://www.forum.universal-devices.com/viewtopic.php?t=1359&highlight=drapes From what I understand, the difference in your setups is that Tracy was using KPL's to manually activate his drapes, whereas you are using a Controlinc. Controlincs are, from my understanding, send only devices. They really can't be queried and should be used as "control" devices in your programs. I'm not quite sure how you are using your controlinc to activate your drapes (non-toggle= on/on or toggle on/off). It would really help if you could post your code. It sound as if you need a "status Program" to indicate whether your controlinc has opened/closed the drapes unbenownst to your timer program. Stealing from Tracy's post (shameless plagiarism), the following program would open/close your drapes in response to successive "ON" presses from the controlinc. Your timer routines can then "test" the status of this program to determine whether your drapes are open or closed (true = open, false = closed). Program "drapes open" If Control 'SWITLINC RELAY DRAPE' is switched On And Program 'Drapes Open' is False Then Turn Drape appliancelinc ON Wait 19 seconds Turn Drape appliancelinc off Else Turn Drape appliancelinc ON Wait 19 seconds Turn Drape appliancelinc off Morning Schedule If Time is [i][b]morning[/b][/i] and Program "Drapes open" is false then "open drapes" Night Schedule If Time is [i][b]night[/b][/i] and Program "Drapes open" is true then "close drapes" Note that the above will not prevent your "loved ones" from stopping the drapes in mid travel (half open). This state would be indeterminate (and very likely given my "loved ones"). Hope this helps, IM

Tracy, If your KPL's are linking you could change your condition to: If Status 'DRKL Drape Switch' is On AND Status 'MKL Drape Switch' is On Then Set 'Drape AL' On Wait 19 seconds Set 'Drape AL' Off If you've already changed to the "if Control DRKL Switched on, I'd leave things as is. Since Control functions can only be initiated at the switch (manual press) is would stop other scenes and programs from inadvertently activating your blinds. Thanks for the update. Please do post your code when you're satisfied with the operation. I'm sure you're not the only one automating drapes. IM

tcster, Nicely done. I don't see any problems with what you've posted (although testing is always in order). One additional comment - It appears that your KPL buttons are set to "toggle Mode". If that's the case you could synchronize the buttons so they both indicate the status of your drapes (my apologies if you have already done this). In order to accomplish this - 1) Change your "status" conditions to "control conditions". If 'DRKL Drape Switch' is Switched On Or 'MKL Drape Switch' Switched On This will prevent a scene of program from activating your program (it can only be activated from the KPL's). 2) Create a Scene "KPL drapes" with both of your KPL's as controllers Scene KPL Drapes DRKL as control MFL as control With the above, pressing one of your KPL buttons will activate the associated button on the "other" KPL and will trigger your program. Let us know how things progress, IM

tcster, From your description, its sounds like you are using the KPL's to directly control the appliancelinc. Could you instead use the KPL's to trigger a "Drape Controller" program in the ISY? The status of this program could then be used to indicate the position of your drapes. IM

Drew, I replied to your "other" post regarding the ISY being in safe mode. It sounds as if your PLM may have "locked up" and is not communicating with the ISY. Please try cycling power to the PLM (10 sec power interrupt) to see if it recovers. If you are using a ISY-26, remove power from the ISY first. IM

ResIpsa, I believe I'm talking "apples and apples". I have one (one) V1.65 KPL that I can program the backlight level with the ISY (no intervention required). I have 3 V1.6 KPL's that will accept the backlight programming "after a 10 Sec air gap". Please note that the V1.65's weren't plentiful when I purchased mine (SH is purging stock). The V1.65 that I received was one unit in an order of four (2 - 6 button, 2- button). I purchased the KPl's on 4/8/08. The V1.65 was a 6 button unit. I have no guess as to when "only V1.65's" are in stock. IM

Clark, The feature is implemented within the ISY. It may or may not be implemented on your KPL depending on the version. KPL Revision V1.0 to V1.4 : Not implemented. V1.55 to V1.6 : Implemented, but requires an "Air Gap" of the KPL to register. V1.65 : Fully implemented, backlight is completely controllable with the ISY. I do not have a V1.5 KPL, it may respond the same as the V1.55-V1.6 units. I suspect that it does, but don't have first hand experience. Hope that helps, IM