IndyMike

Michel, Thank you for the reply. I hadn't thought of the switch itself transmitting an incorrect record. I can see how that would throw a wrench in the link table. Since not all users are experiencing problems, I'm making the rash assumption that this is influenced by the powerline environment. I had planned on trying some tests varying noise/signal absorption (therapy work). Your new tools in the event viewer will come in handy - I had been exporting the records to excel to compare the link lists and calculate "Hops remaining". Thank you very much for this addition. IM

dss, I believe the repeating problem was something that we theorized awhile back. Unfortunately the nature of forums is that information is often taken out of context, repeated, and misquoted and before long becomes fact. I've been searching and have not been able to locate where a SH or UDI representative has stated that I2 messages are not repeated by I1 devices. GregoryX quoted Steve Lee as saying that the I2 communication might be more sensitive to noise: http://www.forum.universal-devices.com/viewtopic.php?p=16776#16776. This is not at all the same as saying that I1 devices won't repeat I2 commands. Another questionable conclusion has been made regarding "corrupted" link tables and I2 CRC. From what I've seen, corrupted link tables are comprised of duplicate entries or entries for groups that are no longer reflected by the ISY. I haven't seen a post indicating "garbage" data in a link table (invalid format). If you look at the old I1 peek/poke method of programming you can see that the ISY was in total control of the process. Each of the 8 locations in the link table was individually peek/poked until the entry was completed. Each communication is sent with a max HOPs of 3 and retry logic is applied. In short, there is a lot of handshaking going on with a simple 8 byte programming sequence. If/when problems occurred the ISY could recognize them and recover. As I understand the I2 programming sequence, the switch is an active part of the programming. The entire 8 byte link record is written in one fell swoop. Note: the following is pure speculation. What I do not know is how the switch responds to a "completed" sequence. If the PLM/ISY for some reason can't hear the switch indicating a ""link record complete" transmission, it's possible the ISY will retry and thereby create a duplicate record. The ISY and switch are now out of synch. At present I don't have any devices that the ISY recognizes as I2 programmable (2 units on the way). If someone can provide the Hop count used during I2 programming acknowledge I'd be very interested. As of Version 2.6.14 UDI has given use the ability to easily monitor Max Hops and Hops remaining using Mode 3 in the Event Viewer. IM

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