LeeG

wswartz What ISY firmware is being used? EDIT: Sorry, I should have included this initially. There is a problem with setting the Local values (On Level and Ramp Rate) under 3.2.3. The SwitchLincs have to be power cycled for the new settings to take effect.

Battery RF devices in general have to be added using New INSTEON Device, entering the Insteon Address, Name, and selecting the Device Type from the pulldown. The TriggerLinc must be put into linking mode manually by pressing the Set button until the LED blinks continuously. Otherwise the RF device is asleep to save battery life, not being able to respond to commands when asleep.

"In the administration console, devices are not responding to 'on' commands. Only 'fast On' works to turn on devices." This sounds like the device has been assigned a long Ramp Rate value. The On command works, it just looks like it does not because it takes awhile for the device to ramp up. This can be verified by running Tools | Diagnostics | Event Viewer with Level 3-Device communications events selected (most important). Click the On button, then the Fast On button, then the Off button. Post the event trace. It will not be very long. What is the device type of the device that does not appear to turn On with the ON button? “I can't test a program using 'RUN' commands anymore.†Is Run (If) or Run (Then) being used. What does the Programs | Summary page show for Last Run Time for the Program. Please post the Program.

Insteon does not propagate/cascade Scenes. The TriggerLinc as a Controller with Switch A as a Responder only affects Switch A. The fact that Switch A is a Controller of a different Scene does not cause Switch A Responders to react when Switch A is turned On/Off by the TriggerLinc. That would be cascading or propagating Scenes which Insteon does not support. What you need is to have one ISY Scene. The TriggerLinc is a Controller and Switch A, B, C are at least Responders. If the switches should also be able to turn each other On/Off as the TriggerLinc does then Switch A, B, C should be added to the one ISY Scene as Controllers along with the TriggerLinc. If the SwitchLincs were added to the ISY before upgrading to 3.2.3 they have to be Deleted and added back to the ISY under 3.2.3. The SwitchLincs should be Removed from any Scenes before doing the Delete. Then add the SwitchLincs to the Scene after adding them back as devices under 3.2.3. New SwitchLincs are I2CS devices (expansion of Insteon protocol). They have to be added to the ISY under 3.2.3 for them to function correctly.

When Start Linking is clicked a modal popup window should appear. This window has a Finish button as the only functional button and being a modal popup will block access to any other ISY function. This popup is not displaying which allows access to other ISY functions which result in the "discovering nodes" message. Once in that situation the ISY and PLM must be power cycled to clear the situation. The underlying problem is generally an AV issue that is preventing the ISY from pushing data out to the Admin Console. Temporarily shut down AV and firewalls. This should allow the Start Linking popup to display. Avast and Kaspersky are two common sources of problems. See the following link … viewtopic.php?f=3&t=2049&p=63154&hilit=Avast#p63154

I think the decision on which link database management technique (I1 versus i2) to use may have to be separated from the decision on which device configuration to use. Except for devices that had no I1 option, all link management has been done with I1. However, many devices have been configured using I2 for a long time. KeypadLinc configuration, SwitchLinc configuration just to name a few will be broken if device configuration is forced back to I1. The requirement to power cycle the newer SwitchLincs to get the Local values to take affect is only the tip of the ice berg. I suspect KeypadLinc configuration involving buttons is broken using I1 for device configuration.

I don't know. Will have to wait and see if a new Query Insteon Engine solves the problem. I hope so. Otherwise the device would have to be deleted and added back.

andyf0 That SwitchLinc supports I2 but not I2CS. Before there was I1 and I2. Now there is I1, I2 and I2CS. It appears the Query Insteon Engine function considers only two options, I1 and I2CS. This leaves the newer but pre I2CS devices regressed to using I1 with all its limitations and short comings. 3.2.4 should be out sometime next week. Let’s hope this is resolved in that image. Lots of things will stop working when regressed to using I1.

gviliunas I power cycled my SwitchLinc and it picked up the new Local Ramp Rate of 6.5. That is one of the issues with the I1 method. The newer I2 method does not require a power cycle. Don't know if it will work with your v.27 SwitchLinc.

gviliunas That looks like a bug. It is using the old I1 Peek/Poke method to set the Local Ramp Rate. I see the same results on a v.36 SwitchLinc where it should be using the I2 method.

mrobles Is the Sensor node being right clicked? That is the primary node which has the Replace option. The other nodes do not have the Replace option.

gviliunas Right click SwitchLinc node, select Diagnostics | Query Insteon Engine. Run Tools | Diagnostics | Event Viewer with Level 3-Device communications events selected (most important). Set the Ramp Rate (applied locally) slider on the SwitchLinc node display and post the event trace. Be sure a Progress Bar displays when the slider has been dropped to a new location.

This looks like the same as one of the previous traces. 1C.F3.17 was put into linking mode and responded with an ACK. The PLM was put into linking mode which should have generated an exchange with the ApplianceLinc where the Insteon address, cat/subcat and firmware should have been sent from the ApplianceLinc to the PLM which would have resulted in an 02 53 response. The PLM is not hung as it presented an message from 14.71.EE. I’ll repeat the same sequence on my ApplianceLinc when it gets here Monday. Should have been here Saturday but either it was late getting to FedEx or the holiday has delayed delivery until Monday. The sequence works correctly after the factory reset so I would think this is an ApplianceLinc issue. Thu 04/05/2012 06:57:21 PM : [iNST-ACK ] 02 62 1C.F3.17 1F 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 F6 06 LNK-ON (01) Thu 04/05/2012 06:57:22 PM : [iNST-SRX ] 02 50 1C.F3.17 1B.FD.23 2B 09 01 LNK-ON (01) Thu 04/05/2012 06:57:22 PM : [standard-Direct Ack][1C.F3.17-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Thu 04/05/2012 06:57:22 PM : [LNK-BGN ] 02 64 01 00 06 // Garage PIR sensor , turning off Thu 04/05/2012 06:58:16 PM : [iNST-SRX ] 02 50 14.71.EE 00.00.02 CB 13 02 LTOFFRR(02)

mrobles Run Help | About. Does the Firmware line and the UI line both show 3.2.3? If not clear the Java cache and be sure to use the URL for accessing the 3.2.3 Admin Console. Are there multiple Motion Sensors installed. There has to be more than one for the Replace option to work.

Cycle the door. Trigger Reverse will have an affect the next time the I/O Linc Sensor changes state and sends a command.

The Smarthome garage door kit comes with a magnetic switch that has a NO (normally open) contact and a NC (normally closed) contact built into the same magnetic switch. Sounds like this is not the Smarthome garage door kit or they have changed the content of the package. I believe the correct approach is to use a magnetic switch (either NO or NC) that results in the I/O Linc Sensor being Off (green LED Off) when the door is closed and the Trigger Reverse option not checked. As a temporary measure you can change the Trigger Reverse option which will reverse the commands issued by the I/O Linc and thus reverse the state of the KeypadLinc button LED. As mentioned before I don't recommend using Trigger Reverse because the Query run at 3:00 AM every morning returns the true state of the I/O Linc sensor which is opposite to what the On/Off commands indicate. It is fine for the short term but the magnetic switch should be changed to give a Sensor On/Off that matches the door open/closed.

What is the status of the Green Sensor LED on the I/O Linc itself in regards to the garage door being open or closed. If the Green LED is On when the door is closed use the other wire combination. Red/Black or Green/Black, the opposite to what is being used now. That will reverse the I/O Linc Sensor state. If the Green LED is Off when the door is closed check the I/O Linc options. The Trigger Reverse is set such that the I/O Linc sends an On when the Sensor is Off and an Off when the Sensor is On. Turning Off Trigger Reverse will put the Sensor state and the commands issued in sync. It is preferable not to run with Trigger Reverse in any situation as the Trigger Reverse only swaps the commands issued. If the I/O Linc is Queried the actual state of the Sensor is returned which will be opposite to the commands issued.

Without an event trace it is only speculation but it sounds like the ApplianceLinc does not respond to the PLM when it entered linking mode (the second time). The ISY issued the PLM command and is waiting for the 0253 command response that never comes. Not sure if this is a planned part of I2CS security or not. Would have thought the PLM would timeout eventually. I'll try a few times with the I2CS FanLinc. The I2CS motion sensor I have is not a good candidate to test this sequence since the MS it manually put into linking mode. I have a new ApplianceLinc ordered so that should allow a second test point for the ApplianceLinc.

Not that I can find. I guess I could go to a backup but that seems a little extreme. I’ll wait until the UI is fixed in some later beta release.

I've never used Folders in the Main tab but did create one. A right click on the Folder name does nothing.

If the ToggleLincs and SwitchLincs are the same type (dimmer versus relay) the Replace xxxx with … Function can be used. Add the SwitchLincs to ISY, any “Name†will do as the Name will be deleted later. Right click on the ToggleLinc node and select Replace ‘togglelinc name’ with ….. which will display a list of functionally similar devices. Select the SwitchLinc that replaced the ToggleLinc. ISY will rewrite all the necessary Scene links with the new SwitchLinc Insteon address, delete the ToggleLinc node, and assign the ToggleLinc Name to the SwitchLinc. When adding the ToggleLincs back to the ISY when installed in their new location be sure to use the Remove Existing Links option. I prefer to do a factory reset along with using the Remove Existing Links option which insures the device link database is clear of any old links. A KeypadLinc cannot be replaced with a SwitchLinc using the “Replace xxxxx with …†function because of the discrepancy in the number of nodes. Assuming the KeypadLinc will serve a different purpose in its new location it should be Removed from all the Scenes it is assigned to. It the KeypadLinc buttons will do the same things in the new location, just physically moved to a different location, then nothing but the physical move has to happen. A KeypadLinc Dimmer cannot be “replaced†with a KeypadLinc Relay because of potential issues with Scene responder On Levels that would be valid for a Dimmer but not valid for a Relay. The KeypadLinc Dimmer should be Removed from all the Scenes it is assigned to. If all of this is too difficult to follow, Remove the devices from all the Scenes before doing anything. If you just Delete a device and then add it back it can come back into the existing Scenes. By Removing the device from all the Scenes the device is getting a fresh start.

Brian, wouldn't that be great! Might change the question to, What is I2CS?, but one would know for sure something was different. Right now there is an open question about new OutletLincs being I2CS. Almost to the point where everyone should go to 3.2.x if any question about adding a device.

The backlight level of individual KeypadLinc buttons cannot be changed. Setting the backlight level applies to the entire KeypadLinc.

wswartz The new ApplianceLinc is an I2CS device. Requires 3.2.x for I2CS support. 3.2.3 is the latest beta. EDIT: once on 3.2.3 the ApplianceLinc will have to be Deleted and added again under 3.2.3/

ELA Exactly right. The ApplianceLinc has a link record containing the PLM address. That is why it accepted the GetEngine command and returned the 0x02 (I2CS) with an ACK.