LeeG

Right click the EZFlora primary node (zone 1) and select Disable.

The Beep can be done this way. Note that Beep is not very loud and the duration has no affect. Some day SmartLabs may support duration but for now the device firmware ignores duration. If Control 'MotionSensor2-Sensor' is switched On Then Repeat 5 times Set 'KeypadLinc v41' 100 (Beep Duration) Else - No Actions - (To add one, press 'Action')

Define an ISY Scene. Add KeypadLinc button A and SwitchLinc Outside Lights to Scene as Controllers. Operating KPL button A, SwitchLinc paddle will control the outside lights and the KPL button LED and SwitchLinc LEDs will stay in sync. I do not use MobiLinc but it is my understand that if you click the SwitchLinc or KPL Icons MobiLinc will operate the Scene the two devices are Controllers of which will keep the devices in sync. If you operate the SwitchLinc as a device from MobiLinc only the SwitchLinc will change state and the KPL button LED will not follow. That is the way Insteon works. To keeps both devices in sync MobiLinc has to operate on the ISY Scene.

The MorningLinc must have been sending an RF signal all the time. All the lock codes are stored in the locksets themselves not the MorningLinc. The MorningLinc functions as nothing more than a battery button remote would function. That is why the MorningLinc can be Insteon Factory Reset without affecting the relationship between the MorningLinc and the lockset. I have two MorningLincs and have not seen that behavior. I'm wondering if there was a power surge or similar that affected both the PLM and the MorningLinc.

Add a few second Wait before issuing the Set Scene xxxxx Off. The Program triggers on the first message coming from the KPL. There are several more messages that flow from the KPL from the button press. The KPL sending messages at the same time the PLM is sending messages can be a problem. One Insteon device will not purposely step on an Insteon message that is already on the powerline but there can easily be a physical conflict when two devices send at approx the same time. Of course there could be comm issues. Turn On the various basement devices and manually run the Program. If devices turn Off reliably when the Program is manually run comm is ok.

Upgrading to the latest ISY firmware for the 99i would get the ISY to 3.3.10. That includes having the UI (admin console) at 3.3.10. If the newest KPL was added with this combination it would not work. If the URL to the Admin Console was then changed to 4.0.11 it will still not work as the KPL was added under 3.3.10. Simply using a later UI after adding the device under 3.3.10 does not solve the problem. The KPL would have to be deleted and added back while running 4.0.11 Admin Console.

Also was the KeypadLinc that did add (the one with a single node) added to the ISY after moving to the 4.0.11 UI?

The KeypadLinc that does add and does show as a KeypadLinc on the right side... Is there a small +/- box to the left of the only node you are seeing?

Click Help | About and verify that Firmware shows 3.3.10 and UI shows 4.0.11. Click on the node. What does line 2 on the right side display for device type? Was the device added "after" moving to 4.0.11?

I have had no issues with dishwasher, two different sets of washer/dryer and two different refrigerators. So much is being added to appliances now days, IP connections, various electronic controls, etc it is hard to say with absolute certainty that any given appliance will not cause an Insteon Mesh Network issue. For the dishwasher and washer/dryer it is easy to evaluate. If comm is good until one is running then it is a good bet the appliance that is running is a problem. The refrigerator is not as easy because it cycles on its own. It can be turned Off or unplugged for an hour or more with no concern over losing cold items. It is the hardwired devices that can be hard to evaluate.

Use the magnetic switch Brian identified in his past post. Use the Red and Black wires connected to the same I/O Linc points the current magnetic switch is connected to. Does not matter which wires (Red or Black) are connected to which I/O Linc magnetic switch connection points. Turn Off Trigger Reverse. No other changes should be necessary. The majority of folks think using a NC magnetic contact (current garage kit package) is the wrong switch.

It is the use of Trigger Reverse that causes the problem you are seeing. Trigger Reverse reverses the commands the I/O Linc sends when the I/O Linc Sensor changes state. Normally the I/O Linc sends an On command when the Sensor turns On and an Off command when the Sensor turns Off. With Trigger Reverse the commands are reversed. The I/O Linc sends an On command when the Sensor turns Off and an Off command when the Sensor turns On. The use of Trigger Reverse has become common when Smarthome changed the magnetic switch from a combination NO/NC switch to NC only. The issue is Trigger Reverse DOES NOT affect the Query response. A Query always returns an On when the Sensor is On regardless of whether Trigger Reverse is in use. This means the 3AM Query All causes the Sensor state known to the ISY to change. The best solution is to change the magnetic switch from a NC to a NO switch (or go back to what the garage kit was shipped with in the past which is a combination NC/NO magnetic switch). Thanks Tim. Normally the forum lets me know when another post has been done ahead of mine. Missed it this time.

It depends on whether they are causing problems. I have an LG washer and dryer that are not causing any problems. Why are you asking about these specific appliances? There are many things that may need a FilterLinc. UPS, various chargers such as cell phone and lap top chargers, some CFLs have been known to cause problems. Find the source of the problem(s) and then evaluate if a FilterLinc can resolve. The washer/dryer should be easy to evaluate. Are comm problems only when the washer/dryer are in use? A FilterLinc cannot normally be used on a dryer anyway since they are usually 240v.

After getting Help | About to show 3.3.10 for both Firmware and UI, Delete the SwitchLinc and add it back to the ISY. Assuming the SwitchLinc Dimmer is new it is an I2CS device which 3.2.6 would not handle correctly. Once added to the ISY using 3.3.10 add the SwitchLinc to the Scene and run a Scene Test. I believe the NAK from the SwitchLinc during the Scene Test is the result of the I2CS requirements not being established by 3.2.6.

The URL invoking the Admin Console is still pulling a back level version of the Admin Console. What is being used to invoke the Admin Console?

The Scene communication with 24.6E.E8 failed with a NAK. What type of load is connected to the SwitchLinc? Can you clarify what is meant by never have failed commands. Are these X10 commands that never fail. An X10 boosterlinc can cause Insteon comm problems. Need to know what Help | About displays for Firmware and UI particularly with a new upgrade. The Java cache has to be cleared and the URL for invoking the Admin Console adjusted.

"Clicking on the device in the tree the ramp is set to 59% , it says "set locally"" The "applied locally" applies to when the paddle on the SwitchLinc is operated locally. It has nothing to do with how the SwitchLinc responds to a Scene. Single click the Scene name, the SwitchLinc should be displayed on the right side. Setting the Responder Ramp Rate slider is what needs to be set. The fact that the Scene Test fails indicates a problem. That has to be solved. Run the Scene Test and post the Event Viewer trace. That is the popup that shows 'failed'. Also click Help | About. What is displayed for Firmware? What is displayed for UI? Do you have a pair of Access Points coupling the two 120v legs. The 220 volt controller is RF so your two 120v legs may not be coupled since this is an X10 install.

"When I test the scene it fails." Is this running an actual "Scene Test" or just using the Scene?

For the benefit of others who may come to this topic in the future, the EZIO8SA should be power cycled (or powered off) when a 2413 PLM is connected. This was not a problem with the 2412 PLM because it usually powered the EZIO8SA. Now that an external power supply must be used with a 2413 PLM it is possible to connect the PLM to the EZIO8SA without the necessary PLM initialization occurring. Without this initialization the PLM does not interface to the EZIO8SA correctly. Connecting the PLM to the Serial port does not send a notification to the EZIO8SA.

I sent an email back. The trace is correct showing the 2413S as I2CS and the ISY writing the link records at the correct location. The first attempt results posted sounds like the EZIO8SA was not powered On or the EZIO8SA did not recognize a new PLM had been connected. The unsupported device would be the result of the PLM responding with its device type rather than the EZIO8SA responding with its device type. Like the PLM did not receive the initial commands from the EZIO8SA to setup as something different than a normal PLM. The PLM connected to the EZIO8SA functions as an internal PLM normally would. In the EZIO8SA case it happens to be mounted in a separate box.

Need to see an Event Trace at LEVEL 3 of adding the EZIO8SA with the 2413S. The EZIComm that works for ELA reports as an I2CS device. Do not know if the v.9B 2413S reports as I2CS or I2. If it reports as I2 the SmartLabs algorithm will be used to evaluate memory size. If it reports as I2CS an Extended message with the ALDB command will be used to obtain memory size. The two methods could report different results. The algorithm is evaluating the physical memory size. The ALDB command is reporting what the PLM expects which may well be different from what the physical memory could support.

I believe that could be an exposure, particularly if the path to the ApplianceLinc is marginal. The PLM could retry the Query a few times before getting an answer. I suspect that would allow the second Program time to execute. I don't think doing a Run for the second Program is actually needed. If the Status of the ApplianceLinc is changed as a result of the Query the second Program will naturally trigger without need to invoke it from the Query Program.

Sorry, I don't know.

According to the specs the Insteon On/Off Module 2635-222 is Dual Band and does have Controller capability. Thanks bsobel

An ApplianceLinc can be queried with If Time is 12:15:00PM Then Set 'ApplianceLinc' Query Run Program 'xxxx' (If) where Program 'xxxx' checks the Status of the 'ApplianceLinc' If Status 'ApplianceLinc' is On Then do something Else do something You are correct in that an ApplianceLinc does not have Controller capability so changing its On/Off state locally is not sent to the PLM (ISY).