IndyMike

Upstate, Another possible solution would be to change the controllers in your large scenes to responders and then use program control to activate the scene ( If Control XX is switched on/off then turn scene on/off). Adding a controller to a scene greatly increases the number of links (doubles??). A side benefit is these scenes are far easier (more reliable) for the PLM to program. Edit - Sorry, I had things backward. Adding a controller will only add 1 additional link to the PLM. It adds 1 link to each of the members of the scene (that's where I was getting the 2x links from). I'm not sure how feasible this is for your installation. You've got a long way to go to reduce down to 416 links...

Upstate, I was thinking along the same lines. I would think you would have a better chance of maintaining the Link position in the PLM if you used the Replace option.

In a word - Wow. Maybe we can chalk that up as problem 4. From what I can tell from your post, all of the correct links are in your Switch/PLM/ISY for proper local switch operation. Your links are in a different order from those in my devices (not sure if that matters). Does the ISY register local switch operation now? I tried checking my PLM links 3 times as you described (clearing cache in between). My PLM registers a consistent 287 links each time. Edit: never mind the following. I checked several of my other switches and link order does not appear to be important. Could you check some other Functioning switches for the following order? It seems that the following links should be in the first two addresses since they would be created during the initial linking of the switch. E2 00 (listen to PLM group 00) A2 01 (talk to PLM group 01) 00 00 000000

Upstate, I'm focusing on your "old" switches that don't report. From your description, your stair unit is one of these. Please check your switch, PLM and ISY for the E2/A2 codes that I posted previously. Based on the lack of codes in the various locations, perform a device restore, PLM restore, or device delete/add back. Note that if your Switch is a relay unit, it has a different factory reset procedure than dimmer units. Current relay units are reset as follows: 3. Press and hold the Paddle Top for 10 seconds -- then release. 4. Tap the SET Button all the way in -- then release. 5. Push the SET Button all the way in and hold for 10 seconds -- then release. 6. A few seconds after you let up on the SET button, SwitchLinc Relay will turn the light it is wired to fully ON, indicating that the factory reset is complete. SwitchLinc Relay is now reset to all the default settings and ready for fresh programming and use. This is a bit different from what I remember - your older units may be different (hopefully another member can confirm if there is an old method). Another handy feature the ISY "link read" window provides is the ability to Save (to file) and Load (from file) the displayed link table. I used this feature to save my device/plm/isy links before and after correcting my link problem. Afterward I was able to load the link tables from file to compare what had changed.

Upstate, After pouring back over this and your previous post, I believe your difficulties are due to the fact that you are tackling three (maybe more) problems at the same time. Problem 1: Missing Links in your PLM 1) Your PLM had developed some missing links to your switches. From what I can see, the PLM must have a A2 01 in order for it to "hear" transmissions from the Switch. 2) Your devices are restored for the PLM (observation on my part). Since the PLM is missing the A2 01 entry, a simple restore doesn't work. 3) In the above case, the A2 01 link was intact in the ISY. You recovered this information when you restored the PLM and your switches began transmitting back to the PLM. Problem 2: Missing Links in your ISY 1) If the A2 01 doesn't exist in the ISY, you're out of luck with that Switch. Device and PLM restores will not work because the info doesn't exist. This is the problem I encountered yesterday. It is also the problem I believe you are having with your "Stair Switch". 2) Recovery requires you to A)Delete the switch from the ISY. B)Factory reset the switch (note that this procedure is different for relay units). C)Re-link the switch to the PLM/ISY At this point your devices should contain the following links: Switch Links E2 00 (listen to PLM group 00) A2 01 (talk to PLM group 01) 00 00 000000 PLM Entries: A2 00 (control switch group 00) E2 01 (listen to switch group 00) ISY Entries (Same as PLM): A2 00 E2 01 Problem3: I2 protocol Your recent problem switches that don't communicate local presses. Unfortunately (or maybe fortunately) I don't have any of these recent animals. To be honest, I probably couldn't help if I did have these units. Fortunately we have the ISY team on the job (I think we're in pretty good hands here). The bottom line here is that you have a mixture of "old" problems with old firmware switches (I1) mixed in with new I2 problems. Separate the variables. Fixing the old I1 problems requires a restore, PLM restore, or device delete/re-add (not a restore). IM

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