LeeG

ryarber If you can post an Event Viewer trace with Device Communications Events selected during the device add it may be helpful. The ISY is trying to write to the new device to insure there are no active link records. Sounds like it cannot communicate with the device. Combine that with the possibility it could not communicate with the old device there may a communication problem with the install location. Does the SwitchLinc paddle manually control the load correctly? If not a communication problem per se perhaps some issue with the wiring to that specific switch location. The Event Trace will show what commands are failing. Lee

For device to device control, Scenes are the solution. That is for example, KPL button B turns On/Off a LampLinc. No latency associated with invoking an ISY Program with the Program issuing the On/Off commands and device to device control with a Scene is the most reliable protocol Insteon has to offer, the Controller automatically retries. For Program control of Secondary KPL buttons, a Scene must be used. Secondary KPL buttons do not respond to Direct commands. I/O Linc Relay must be controlled with a Scene to use Momentary mode. Direct commands turn the relay On and Off without regard to the characteristics of an active Momentary mode. I/O Linc Relay command reversal (On command turns relay Off, Off command turns relay On) is accomplished with a Scene. A Scene between devices works even if the ISY is down for maintenance. ISY is most reliable but I prefer as much of the house to work without assistance. Where circumstances dictate the use of an ISY Program to begin with, such as when a Motion Sensor is involved and more than an absolute Off after a fixed time is desired, Scenes or Direct commands can be used. Scenes – Plus All Responders react simultaneously Scenes – Minus May require more than a single Scene On/Off statement if powerline is not good Direct – Plus PLM automatically retries Direct commands up to three times with no Program intervention Direct – Minus Multiple devices respond sequentially rather than simultaneously Cannot control ramp rate Linked devices get out of sync This is not an all encompassing answer. The more time and people think about this the more ideas and opinions will be expressed.

It could take two FilterLincs. Some folks have reported a single FilterLinc not being enough to block all traffic. When the Show PLM Links Table (with count) produces the same number 3-4 times the number can be considered accurate.

Insure there is NO Insteon traffic when looking at PLM link records. It has been determined through testing that Insteon messages received by the PLM while the link records are being read will reset the "Next Record" pointer causing PLM link records to be skipped or duplicated. A 2412 PLM does not have memory large enough to hold 2065 records.

Zick I do not use the option to keep existing links so some of this will be speculation. Not speculation is that a single ISY Scene is made of multiple Insteon Scenes. When pulling links from a device only the physical device link relationship can be identified. Logically how those links might fit into an ISY Scene is unknown. Scenes that are created this way are numbered as the ISY has no way of assigning meaningful Scene names. Keeping existing links preserves the links in the device but does still requires assigning names to the Scenes. The following is speculation. Likely devices that are cross linked, where a single ISY Scene consists of multiple Insteon Scenes (that part is not speculation) will result in multiple numbered Scenes which are the individual Insteon Scenes. The few devices I have tried that option with just to see what happens generated that result. The logic to try and construct a single ISY Scene from the complexities that exist when looking at Insteon Scenes purely from the physical link perspective is not part of keeping existing links. There is just no way to tell from the physical link record what Insteon Scenes should be combined into an ISY Scene let alone which ISY Scene it might relate to. More reasons why creating the ISY Scenes after the devices have been readded without links is a better choice. Easy for me to say, I’m not doing the work. Lee

Zick Sorry the air gap approach did not work. Michel is correct in that if your system is not broken don't fix it. However, I really disagree with leaving it alone. Some folks install today, use as is and never tweak, expand, change, advance, improve, you get the point. On the other hand many folks using an ISY got the device to tweak, expand, change, advance, improve. That is the great thing about the ISY. Advances can be done incrementally. Programs generated to do new things, approaches tweaked to make them more useful in your specific environment. To that end, hardly a week goes by that the question is not asked, what firmware level is the device(s). Is it late enough to have the feature in question, as long as the v35 SwitchLinc problem has been around it is still being uncovered. When a problem surfaces can it be traced to a particular firmware. Knowing the device firmware level is too important not to know it if possible. As painful as it will be, take whatever action is necessary to identify the firmware level in the devices now. Yes, you can wait until the question has to be answered. That normally means doing things during diagnosis that one would prefer not to do. When a problem surfaces the last thing one wants to do is make wholesale changes simply to collect information, IMO. I have never understood why the device firmware level is not obtained when the Device Type is specified (assuming the device will supply it). The ISY issues the command to pull that information when Auto Discover is specified, that same command can be issued when a specific Device Type is selected (soap box, sorry). Bottom line, the choice is yours. Again, sorry the air gap did not help. Lee

Zick Try pulling the air gap switch and then Delete. This will create a comm error during delete because the device cannot be access to clear the link database. Never tried that but if the Delete does complete as far as the ISY is concerned , then add it back with the option to keep existing links. Try one device only to see what the results are. Lee

eseelke This Program Enables a Program when an On command is received from the RemoteLinc button. It Disables a Program when an Off command is received. Substitute whatever controller button is desired. Also the Enable/Disable conditions can be reversed simply by swapping the commands in the If or the Action statements in the Then/Else. Program AAAA would contain the Motion Sensor/light control logic. If Control 'REMOTELINC-2 / REMOTELINC-2 - 3' is switched On And Control 'REMOTELINC-2 / REMOTELINC-2 - 3' is not switched Off Then Enable Program 'AAAA' Else Disable Program 'AAAA' Lee

The ISY User Guide describes the linking of the RemoteLinc. Under Link Management | Link a RemoteLinc, the RemoteLinc is put into linking mode, followed by a popup that looks much like the New INSTEON Device popup with the RemoteLinc Device Type already filled in. My RemoteLinc shows v00 which I believe is the result of having the Device Type field filled in (requirement of RemoteLinc). I do not think there is a reason to delete and add the RemoteLinc again as it will still be v00.

"Do you think I will lose my links if I delete a device" Yes. I've seen a post by UDI that indicates Deleting a device marks the first link record with the 00 End of File marker which effectively removes all link records. The device will look empty should the link record database be read later on.

It should be an event driven process. The Motion Sensor and TriggerLinc send an Insteon message to the ISY that can trigger Program execution. Sensing motion or contact closure/open cause the respective device to send either an Insteon On or Off message. Motion Sensors and TriggerLincs cannot be polled for current status as battery powered RF devices turn Off Off the RF portion of the circuitry to conserver battery life. These devices would not see any command sent to it most of the time. These are not meant to be security devices. My security motion sensors have tamper proofing and redundant IR processing to prevent false indications. A conventional security system with all its built in protection can be used to talk to the ISY and generate an email. The ELK system can do this. Although these are battery devices the base Insteon devices they communicate with are not functional should power be interrupted. Just depends on how secure the security system needs to be.

Deleting a device involves removing all references in Programs as well as Scenes (Controller and Responder). Either there were references to the KPL (Program and Scene) or perhaps communications problems that resulted in consistent timeouts and retries to complete the Delete. The V35 SwitchLincs are likely candidates for replacement. They are well documented sources of communications problems.

Zick The v00 is generally the result of selecting the Device Type when adding a device rather than using Auto Discover. I think it best to use Auto Discover except for those devices than must be added specifying the device type such as the Simplehomenet devices for example. Motion Sensors and TriggerLincs are more examples of devices that require the Device Type be selected when adding them to the ISY. Lee

Illusion The duplicate Beep Echo is not your PLM. I get the same thing on mine. Wed 07/13/2011 12:24:13 PM : [ Time] 12:24:47 0(0) Wed 07/13/2011 12:24:13 PM : [iNST-ACK ] 02 62 15.9A.F9 0F 30 FA 06 BEEP (FA) Wed 07/13/2011 12:24:13 PM : [iNST-ACK ] 02 62 15.9A.F9 0F 30 FA 06 BEEP (FA): Process ACK: duplicate ignored Wed 07/13/2011 12:24:13 PM : [iNST-SRX ] 02 50 15.9A.F9 12.9F.E4 2B 30 FA BEEP (FA) Lee

Illusion The question you raised about the possibility of a PLM problem, the PLM generated two Echo messages (or the ISY issued the PLM command twice). More likely the PLM generated two Echo messages. Wed 07/13/2011 09:39:09 AM : [iNST-ACK ] 02 62 18.32.DE 0F 30 BE 06 BEEP (BE) Wed 07/13/2011 09:39:09 AM : [iNST-ACK ] 02 62 18.32.DE 0F 30 BE 06 BEEP (BE): Process ACK: duplicate ignored Lee

Either the tact switch for the button is bad or the link records for that specific button have been lost or corrupted. If both On and Off fail to indicate anything it is likely a link record issue. Put the RemoteLinc in linking mode by pressing Dim/Bright buttons together until LED blinks. Right click on RemoteLinc node in my lighting tree and select Restore Device. If only On or only Off fail it is likely the tact switch. Could also try new batteries. EDIT: regarding new batteries, I had a specific button stop working. Don't remember if it was On or Off but only one. I moved the responders to an open button. Eventually the RemoteLinc developed other problems which resulted in batteries being replaced. With new batteries the button that had stopped working for a week worked fine and has worked fine for months with the new batteries.

In the second Program, it should be To Sunrise -10 minutes (next day) If From Sunset + 10 minutes To Sunrise - 10 minutes (same day) As coded the To time is before the From time

They flash when traffic is detected. Something is putting traffic on the powerline. If you have the Venstar tstat adaptor unplug it. If that does not resolve the problem unplug and turn Off devices by pulling air gap switches until the flashing stops. Any ISY Program changes of late that could be looping.

Not at present.

Michel I was thinking along the lines of an Extended Set/Get which has 14 bytes of extended data that is very device specific. The PLM B would pass a Set along to Computer B as the PLM plays no role in actual data content since it is device specific. An Extended Get could return 14 bytes of whatever. It is academic anyway since the ISY would need to add support for the PLM as a device on the powerline and I doubt there is much call for that arrangement compared to other things the user community is looking for. Lee

I don't think so. PLM B has to be defined to the ISY which exposes the ISY to all the PLM memory size issues the ISY has to deal with SHN devices today. The algorithm used to evaluate SHN device PLM memory size has not been applied to a native PLM device. Also for PLM B to fit into the one node for each separate Group number the PLM would have to have up to 255 nodes. Michel will correct this if I am wrong but I feel certain this is not possible today. As a side note, yes, two PLMs can talk to each other over the powerline as far as Insteon is concerned. The ISY PLM talks to an EZIO8SA external PLM. The EZIO8SA PLM is passing the Insteon messages on to the EZIO8SA device which is responding as any other Insteon device. That PLM could just as well be a PLM connected to Computer B which is programmed to react to basic Insteon and SHN device commands as a native EZIO8SA would. Don’t know if there is enough generality to support the command flow you are looking for.

Hi Andy You are right on! The KPL hardware that supports mutually exclusive buttons (button grouping) does exactly that. Turning one button in the group on turns any of the other buttons in the group off. This works only on the KPL where the button is physically pressed. If multiple KPLs are linked together only the KPL where the button is pressed will be mutually exclusive. KPLs linked as Responders will accumulate lighted button LEDs even if the Responder KPL has defined the same button grouping. I tested button grouping on a single KPL under 3.1.4 and it worked fine. Not sure why the ISY recommends not using the feature but I am sure that is from past experience. Perhaps because it works only for a single KPL and often multiple KPLs are involved. Might also present a problem in keeping track of button status as turning On a button also results in turning one Off which would require looking at the button grouping information for each KPL command received. Do not know why the button grouping popup recommends not using the function. As I wrote the above I realized I had not watched button status under Admin Console. Button status does not follow button grouping. Since the KPL only indicates that a button has turned On, and says nothing about another button turning Off as a result of button grouping, button status under the Admin Console and therefore Program Status is not accurate. The only way the ISY could compensate for this is to search through the KPL configuration. That would be time consuming for every command received from the KPL. Lee

Scenes are used for device to device control and normally do not require any Programs. Programs are required when special things have to be done as in this case. When a KPL button is pressed On (button LED lights up) an On command is sent. That is what you want for most situations but in this case the other KPL buttons in the "Group" need to be turned Off. Secondary KPL buttons cannot be turned Off with an On command thus a Program is needed to recognize the On command and issue a Scene Off to turn the other KPL buttons Off. The Lights that are being turned On to some bright level can be turned On with a Scene without Program activity. An ISY Scene is created with KPL button A as the Controller and whatever devices to be turned On are defined as Responders with whatever On Level is associated with the KPL button. Many devices can be turned Off with an On command simply by setting the Responder On Level to 0%. Secondary KPL buttons are the exception. They will not turn Off with an On command.

Denis There are a number of approaches depending on how many Programs and Scenes you want to produce and manage. Secondary KeypadLinc buttons cannot be turned On/Off with Direct commands, thus the need for Scenes. Lets use KPL Secondary buttons A,B,C,D as exclusive buttons. Scene X has all 4 KPL buttons as Responders. Scene X will be used to turn Off all the related KPL button LEDs. Scene A has KPL button B,C,D as Responders. Scene B has KPL button A,C,D as Responders. Scene C has KPL button A,C,D as Responders. Scene D has KPL button A,B,C as Responders. Program X triggers with Off commands from any of the 4 KPL buttons. The Then clause invokes Scene X with an Off command to turn Off all involved KPL button LEDs. Program A triggers with an On command from KPL button A. The Then clause invokes Scene A with an Off command to turn Off B,C,D. Program B triggers with an On command from KPL button B. The Then clause invokes Scene B with an Off command to turn Off A,C,D. Program C triggers with an On command from KPL button C. The Then clause invokes Scene C with an Off command to turn Off A,B,D. Program D triggers with an On command from KPL button D. The Then clause invokes Scene D with an Off command to turn Off A,B,C. Lee

If a single KeypadLinc is involved the KPL hardware Button Grouping can be used although the ISY recommends against using the feature. How many KPLs are involved? That is, are KPL buttons A,B,C,D (or whatever buttons are being used) to be linked to any other KPL. If so a Program is needed as KPL hardware button grouping only works where the KPL button is physically pressed. It does not apply to other KPLs that may be linked to those buttons.