LeeG

An ApplianceLinc does not have the capability to function as a Controller. Perhaps this is something the ISY fixed along the way.

Is the 158% value approximately 2 X the Humidity value displayed on the actual thermostat?

The suggestion was to specify the To date as 2020.

As far as an RF receiver simply plug it in. An Access Point is not linked to anything. If you are verifying the Access Point is on the opposite 120V leg to the Dual Band PLM to insure correct 120V leg (phase) coupling, follow the Quick Start guide instructions. Pressing the Set button on the Access Point the described number of times starts the Access Point transmitting an RF signal. Then look at the LED on the Dual Band PLM to see if it is receiving the RF signal and is in fact on the opposite 120V leg. The color/blinking pattern of the Dual Band PLM LED indicates whether an RF signal is being received and if the Access Point and the Dual Band PLM are on opposite 120V legs. This procedure only insures the devices are on opposite 120V legs. It does not link the Access Point and the Dual Band PLM. Also this procedure is not necessary if you do not care if the Access Point and the Dual Band PLM are on opposite 120V legs (you already have coupling).

I looked at the antenna arrangement in the TriggerLinc. Is your TriggerLinc mounted horizontally or vertically. I think you will have better range if it is mounted vertically as that positions the antenna vertically. May not make any difference. The new Access Point should resolve the problem either way.

I don't know of a work around. Just checked the IO Linc online User Guide to be sure. The Input Sensor can be linked as a Controller but the output relay can be linked only as a responder. The output relay has no logic to function as a Controller.

Just as an ApplianceLinc does not send an Insteon message when the device is manually turned On/Off (including load sensing) the I/O Linc does not send Insteon messages when the output relay changes state. Only Input Sensor state changes are sent to the linked responders. The relay shows On all the time because the last command sent to the relay is an On command. Momentary mode turns the relay Off which does not result in an Insteon message being sent to any responder.

When two Insteon devices are linked together Group (Scene) commands are always used (not discussing HA devices, PLM/SmartLinc, etc). I know of no Insteon device (again excluding HA devices) that can send an Insteon Direct command for control. There are Set button linking sequences that use Direct commands (because links have not yet been established) and of course Direct commands are often used by HA. As far as device A sending a command to device B in response to paddle/button/sensor state change they are always Group (Scene) commands.

Scenario 1 – The TriggerLinc is not getting an ACK from the responder (PLM). Same thing happens with older KPLs. KPL button flashes when the responder does not ACK the button command. Smartlabs has dropped that flashing button function from later KPLs (sorry to say). Assumption is TriggerLinc distance to Dual Band PLM is too far. Anecdotal evidence suggests the Dual Band PLM does not have as much RF range as an Access Point. I have not done tests of this but there are posts on other forums about this. Scenario 2 – TriggerLinc and PLM are within RF range of each other. The PLM is not able to communicate with the ISY over the Serial Port connection. There is a cable length limit on a Serial Port connection with a PLM. This is a Serial Port connection not a network connection. Cannot compare network and Serial cable lengths. I can put a PC NIC card on the end of a 100’ cat5e cable and have IP access with the router. I don’t know what the specific cable length limit is for a Serial Port connection but it is something far less. Scenario 3 - TriggerLinc and PLM are within RF range of each other. The PLM and the ISY are within the cable length limit for a Serial Port connection.

Some KPL revisions have a command that will cause the device configuration information to become active. For other KPL revisions the same command does not activate the changes so a power cycle is necessary. My experience with Secondary button linking to the local load is primarily related to PowerHome2. Because Secondary button linking (to the same KPL local load) is not done with convention links PH2 has a KPL specific GUI to define which Secondary buttons (if any) will control the local load. Actually not sure how that is accomplished using the ISY GUI. Of course if a Secondary KPL button is controlling the load of a different KPL conventional linking is used. That falls in the category of standard Controller to Responder linking. When a KPL button is pressed the link database is searched for responders linked to that button. Even if a link record was written for the KPL Secondary button it would have an Insteon responder address of itself since the responder is really button A (or ON if 6 button mode). No Insteon device can communicate with itself over the powerline. In fact if the KPL issues a command and the command finds its way back to the KPL due to Hops it is considered a failure as the responder failed to send the required ACK.

Unless Smartlabs has changed the way KPLs work in relationship to Secondary button control of the Primary load button, none of that is done with conventional button linking within the same KPL. If you follow the User Guide instructions for linking a KPL Secondary button to button A and then display the device link database you would not find any link records related to the Secondary button. All that cross-linking is done with settings in device configuration storage, not the link database. Some KPLs require a power cycle for the device configuration storage updates to take effect when set through HA software/firmware. That power cycle is not required if the Secondary button linking is done using the firmware in the KPL itself. Are you trying to use some partial 6 button configuration, large On button with small buttons where the large Off button location would normally be. Don’t immediately see the benefit if you are using the normal 6 button mode buttons in 8 button mode.

You should not mix/match Set button linking/unlinking and ISY linking/unlinking. The ISY does not know about the Set button unlink. Delete the ISY Scene that created the Motion Sensor link.

The initial command Get INSTEON Engine (0x0D) failed to get any response from the TriggerLinc .... Fri 09/17/2010 07:06:40 PM : [iNST-ACK ] 02 62 13.E7.32 0F 0D 00 06 (00) Fri 09/17/2010 07:06:44 PM : [13 E7 32 1 ] Failed getting engine version. Reverting to i1. This can happen either because the TriggerLinc was not in linking mode (which you indicated it was) or the TriggerLinc is not in range of an Access Point (or equivalent) so RF communication was not possible. Move the TriggerLinc near an Access Point (or equivalent) and be sure the TriggerLinc is in linking mode and has not timed out of linking mode. I just added a TrggerLinc under 2.8.2 successfully. EDIT: once the process reverted to I1 the process was over. The TriggerLinc does not have the Peek/Poke commands necessary for I1.

wpmjones I’ve had an email conversation with Michel and the question has come up over which Link Management | Advanced Options is selected. You should be running with the “Automatic†option and not the “Device Reported†option. This has to do with the way the ISY is attempting to write the link records in the ICON Appliance module. It should have nothing to do with the PLM link records. Lee

For sure something has happened to the link records in the PLM (unless it stopped at 2 records due to powerline activity). You could try doing a few Show PLM requests to see if it always shows only 2 links. The system cannot function correctly with those 2 link records. Scenes will not work and the ISY will not see device state changes except for that one device address listed in the 2 link records. Something wiped out the link records in the PLM. A factory reset of the PLM, a PLM failure, or something anomalous that we have not identified. Michel could very well be correct that the PLM is defective. I'm a techno junky so I would pursue the question but that is up to you. Simple answer might be get a new PLM. I'm happy to continue to pursue an answer as long as you want to. You can try a File | Restore Modem (PLM ) and see if that gets all the PLM link records restored. If that does not work then I would start from the beginning. Remove all the devices, add one back and Show PLM to verify link records are in the PLM for that device. Then add another device and Show PLM to verify that both devices have link records in the PLM, And so on. If you do that I would add the ICON Appliance devices last as I think there might be a problem with those devices. They support only 30 links which puts the link record addresses outside the range of the normal Insteon devices. I think that is why the link record address looks strange but is probably correct for a device that supports only 30 link records. The normal link database memory that is in every Insteon device does not exist in the ICON Appliance module. That is one of the reasons they are less expensive than the normal ApplianceLinc. The Event trace indicates the link record read from the ICON device was a duplicate and was ignored. It is not a duplicate from the trace records in the Event trace but the odd link record address may be causing a problem. That is why I would leave the ICON Appliance modules for last.

The PLM has only 2 link records at present. They are for 15.BC.7D which from the link records I think this is a ToggleLinc Relay at revision 3A. Did you do a Restore device for this device or recently add this device to the ISY? The remainder of the Event Log trace is trying to write link records into device 15.13.79 Bedroom – Jennifer’s Light and 15.14.AD Bedroom – Patrick’s Light. What type of device are these and at what revision? This activity is not part of the Show PLM. Probably something queued the ISY wants to complete but is not able to. The device response is odd as the link record address returned does not fall within the normal link database address range. Perhaps knowing what the device type is will help understand the device response. How many devices are actually defined to the ISY at this time?

Programs that are directly controlling devices do not use link records in the PLM or the devices. Only Scenes and recognizing device state changes require link records. Try Tools | Diagnostics | Event Viewer Change level: 3, then initiate Show PLM links. The trace should look something like this which is only the first few lines of my Show PLM links request,,,, Thu 09/16/2010 06:24:05 PM : [GET-LNK-RSP ] 02 69 06 Thu 09/16/2010 06:24:05 PM : [LNK-DATA ] 02 57 A2 01 01 DB DE 03 0D 00 Thu 09/16/2010 06:24:05 PM : [GET-NEXT-LNK-RSP] 02 6A 06 Thu 09/16/2010 06:24:05 PM : [LNK-DATA ] 02 57 A2 02 01 DB DE 03 0D 00 Thu 09/16/2010 06:24:06 PM : [GET-NEXT-LNK-RSP] 02 6A 06 Thu 09/16/2010 06:24:06 PM : [LNK-DATA ] 02 57 E2 13 01 DC 76 07 08 00 Seems like an odd PLM failure that it can communication with the powerline and devices okay but not hold link records.

It is a SwitchLinc and not an ICON switch. Also what is the revision level?

How are you adding the ToggleLinc to the ISY. I just did a New INSTEON Device specifying the Name, Address and Auto Discover. The process added the ToggleLinc with the necessary link records. This is a v3A ToggleLinc Dimmer running on 2.8.2.

Do a Show ISY links for that ICON. I think that is what the ISY thinks should be in the device. My guess is that has those 00.00.00 values so when the device is Restored the same bad link records are rewritten. Would be worth knowing answer.

You are correct. Those link records are bad. The 00.00.00 in the first two records should contain the PLM address. 0FF8 : A2 00 00.00.00 FF 1F 00 0FF0 : E2 01 00.00.00 FF 1F 01 The rest of the information in the link records is correct. EDIT: since it is the PLM address that is bad it raises the question about what happened when the PLM was replaced. Only way to know for sure would be to trace the PLM change process but it looks suspicious.

Smarthome did sell a water detection probe in an I/O Linc package but it was unreliable and was withdrawn. Don't think they have found a reliable sensor to put together another leak detection I/O Linc package but that would be one place to look. SH has lots of I/O Linc packages which now may contain a reliable leak detection device. Simplehomenet carries a Dakota Alert Universal Transmitter/water sensor combination that was working well for me. I used it to detect high water washing over the dock to prevent a pump from being damaged. I've since relocated the pump so I no longer use that combination anymore but it was working well during tests. It is a somewhat expensive combination if you do not already have a Dakota Alert system to receive the RF signal from the Dakota Alert Universal Transmitter. It is also battery powered so you have to remember to replace the 9V battery about once a year. I wanted a battery based solution in case power to the dock was lost due to a GFCI trip.

It is only a guess at this point but I'm thinking something does not complete fully during that PLM change. Every link in every device that points to the PLM has to be rewritten to change the Insteon address to reflect the new PLM address and of course the links in the new PLM itself have to be established. If something in this process does not occur on either end the Insteon device will not be able to communicate paddle/button activity to the PLM. I would feed your configuration information into the UDI tool for estimating PLM link record counts to see if it exceeds the 1000 number for the 2413 PLM. You may have to Restore the other devices that no longer communicate paddle/button activity.

However, the end result is hard to explain. Deleting the KPL should have freed up the link records associated with the KPL. Adding it back would have written the new link records back into the same slots or maybe other deleted slots. It would not push otherwise active links out. Have you replaced the PLM lately.

Maybe. There is a UDI tool that estimates the number of PLM link records. Run the tool with your configuration and see what the tool estimates the link record count to be. http://www.universal-devices.com/tools/insteon/calc_plm_links.htm