IndyMike

oberkc, The query response below is an example of extended messaging. The ApplianceLinc reference was a mis-type on my part. I meant Accesspoint. I've checked my accesspoints (V1.0) and they do repeat the extended message commands. Loose connections can certainly contribute to signal loss, particularly if you have a signal absorber on the downstream side.

oberkc, A few observations - 1) Your new Lamplincs utilize Insteon Extended messaging for programming and queries (evidenced in your previous log posts). Extended messages may not be repeated (amplified) by your other Insteon units making the programming sequence more susceptible to noise/absorption. Your difficulty adding these devices to scenes is further evidence of this programming problem. 2) These devices use standard Insteon commands for on/off and scene activation. The fact that you are having difficulty with these functions implies that the programming was incorrect (corrupted by noise/absorption as Michel stated). 3) While the Insteon Filters do a good job of isolating/blocking noise from most devices, others require different "low pass" filters. Please try plugging one of your Lamplincs directly into the PLM and perform a factory reset/restore. This should ensure that the programming is correct. Move the device back to it's original location and (hopefully) verify proper scene operation. If the above works, you can try a variation with the second Lamplinc (if you're game). Unplug all of your possible noise/absorption offenders on the circuit. Install a Accesspoint on the circuit. Perform a factory Reset/Restore. If this programming functions properly you should be able to plug your devices back in and still have scene functionality. If the above works, it's a temporary solution. Until, you track down the possible noise/absorption source (or boost your signal level) you will have difficulties each time you attempt to modify the programming of these devices. Let us know how things are progressing, IM

Hello NewTech, The scene test feature (Tools/Diagnostic/Scene Test) is intended to be a "worst case" test of the cleanup responses after a scene is activated. There's a Wiki page on the subject here: Scene_Test When operating under "Direct Control" Insteon commands are sent to a device. The device is then required to respond with an acknowledge (or negative acknowledge). If the recipient does not respond to the command, the sender retries xx times. Scenes are a bit different. The sender sends out 1 command to activate the scene causing all of the recipients to go to their respective levels. The sender then issues a "cleanup command" to determine whether all of the devices responded properly. The Scene Test is designed to check this cleanup command/response. There are a number of limitations related to cleanup commands: 1) Both the command and response are limited to 1 Hop (1 rebroadcast). This may not be enough in some installations (direct and scene commands are 3 HOP). 2) Cleanup responses may be aborted due to other Insteon traffic on the powerline. 3) Some devices (Lamplincs with local control enabled) will not respond if no load is attached (or if the load is switched off). Note that the items above don't stop the scene from working. It's just that under certain circumstances a scene member may not respond. Since there are limitations to the device response after a scene, the ISY is forced to use a predictive status (the device is on because I just turned it on). Since your scene is intermittent, you may have better luck querying the devices or turning them on directly from the device GUI. This uses the direct protocol and will indicate any errors in the device response. Can you give us some more details on the devices and loads in your Great Room? In newer homes the lighting circuits are typically wired separate from the outlets. Devices having problems on a lighting circuit may indicate noise problems due to CFL's, Fan Motors, Low voltage lighting, etc. Devices having problems on outlet circuit could be due to signal absorption/noise from plug in devices (TV/Stereo/Computer). IM

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