LeeG

"I am using the on option" Sorry, I don't know what option is being referred to. The Relay will be On when the Sensor turns On (or Off based on type of magnetic switch and trigger reverse option) when controlled by ISY and phone. If Status 'iolinc-relay is Off And Control 'iolinc-sensor is switched On Then send message - door operated manually The Relay will be operating in one of the Momentary modes so the Relay Status will normally be On all the time. It will be necessary to turn the Relay Off with an ISY Program a few seconds after the ISY turns the Relay On to Open/Close the door. EDIT: this example does not work in all cases. it will take some thought to put together a Program that covers opening and closing manually

Program Lock - locks the configuration, prevents accidental changes Key Beep - beeps when Set button pressed LED on TX - LED blinks when I/O Linc sending Ready Follows Input - relay turns On when Sensor turns On Send X10 Send on (or Off) - enables X10 Trigger Reverse - reverses commands sent by Sensor - Sensor On sends Off command The I/O Linc User Guide covers these Relay options in detail ---- Latching: Continuous - relay remains On until explicitly turned Off Momentary A: Triggered by either on or off - relay turns Off after timeout interval expires for these options Momentary B: Triggered by both on and off - each momentary mode reacts to On/Off commands Momentary C: Trigger based on sensor input - differently

A KeypadLinc Secondary button must be turned On/Off with a Scene rather than a Direct command. An Insteon Direct On/Off command does not have a placeholder that identifies which button to act on. Define an ISY Scene with KeypadLinc button C as a Responder. Turn the ISY Scene Off to Off button C. EDIT: Backlight level sets the On/Off brightness level of all buttons on the KeypadLinc.

"Is there a way to edit the INSTEON addresses manually?" No. If the old KPLs work enough to add to the ISY add one and Replace it.

The full event trace shows the problem. The additional Queries of the Relays was caused by a 4 second delay in getting the response from the device. It is a those something is keeping the EZIO8SA from sending a response. On the third Relay Query the response was immediate and the ISY went on to Query the Inputs. This Query Input received two responses. There is a Variable update (marked in Red) and then the ISY adjusts the Relay Status using the Query Input response. Of course the Query Input response does not reflect the actual Relay Status so the Relays are marked with the wrong information. Do not know if this is caused by the extra Query Input response, the Variable being updated, or something else. The next Query Relay returns the actual Relay status which brings the Relay Status back to normal. Sun 03/09/2014 07:33:14 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 - Query Relays Sun 03/09/2014 07:33:14 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:18 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) - Relay 2 & 4 On after 4 second delay Sun 03/09/2014 07:33:18 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:23 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 - Query Relays Sun 03/09/2014 07:33:23 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) - Relay 2 & 4 On after 4 second delay Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 - Query Relays Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:32 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) - Relay 2 & 4 On with no delay Sun 03/09/2014 07:33:32 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 - Query Inputs Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Sun 03/09/2014 07:33:33 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Sun 03/09/2014 07:33:33 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:34 AM : [ Time] 07:33:45 0(0) Sun 03/09/2014 07:33:34 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 49 30 RINPUT (30) Sun 03/09/2014 07:33:34 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 03/09/2014 07:33:35 AM : [VAR 2 58 ] 1887 Sun 03/09/2014 07:33:37 AM : [ 23 8D 7C 2] ST 0 - Relay status changed based on the Query Input response Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 4] ST 0 - marks Relay 2 & 4 Off even though Relays 2 & 4 On Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 5] ST 255 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 6] ST 255

There are three Queries each of which have the same response. The second Query has a duplicate response record with a Hops Left=0. This is same situation seen with I/O Lincs and the duplicate message has the correct command code and same indication regarding which relays are On. Query 1 of Relays – relay 2 & 4 On Sun 03/09/2014 07:33:12 AM : [ Time] 07:33:23 0(0) Sun 03/09/2014 07:33:14 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:33:14 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:18 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:18 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Query 2 of Relays – relay 2 & 4 On Sun 03/09/2014 07:33:23 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:33:23 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Query 3 of Relays – relay 2 & 4 On Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:32 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:32 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Query of Inputs Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Sun 03/09/2014 07:33:33 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Sun 03/09/2014 07:33:33 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:34 AM : [ Time] 07:33:45 0(0) Sun 03/09/2014 07:33:34 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 49 30 RINPUT (30) Sun 03/09/2014 07:33:34 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 03/09/2014 07:33:37 AM : [ 23 8D 7C 2] ST 0 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 4] ST 0 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 5] ST 255 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 6] ST 255 The Query of Inputs has a duplicate Hops Left=0 response but the command code is correct and both responses show the same Input pattern. If the event trace is not too large posting that would be a good idea. I’d like to see if any of the duplicate messages exist with bad command codes.

INST-SRX = Standard Response – 02 50 15.BB.62 24.1B.FE 2B 08 00 INST-ERX = Extended Response – 02 51 15 BB 62 24 1B FE 10 F7 C0 66 DF C0 03 EE FE 81 44 01 0A 0D 3A AA 7D The new PLM seems to have eliminated the odd messages with invalid command codes. Only snippets are posted but none of the posted trace has similar invalid commands as seen in the old posts Fri 02/07/2014 02:24:13 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Fri 02/07/2014 02:24:13 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 49 00 06 RINPUT (00) Fri 02/07/2014 02:24:13 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 49 30 RINPUT (30) Fri 02/07/2014 02:24:13 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:15 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 21 89 0F (0F) Fri 02/07/2014 02:24:15 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 The relay status changes from older traces showed invalid commands. The new trace entries have the expected commands and what I would assume is valid relay status. Perhaps this was a finger check. I do not see a trace entry for “the related one at 7:23:22†“three queries in a row being sent out without responses.†What are the time stamps. I do not see a query without a response.

With Access Points installed and confirmed working on opposite 120v legs, the next thing to consider is what else was powered on the PLM circuit. The PLM should be plugged into an outlet and other electronics on the same circuit should be isolated with a FilterLinc. Surge/noise suppression power strips can degrade Insteon signals to the point where the signals are not reliable. Many of the devices mentioned are RF only which means they must be in range of Dual Band devices such as the Access Points or PLM.

The 99i does not support the Dual Band KeypadLincs. Apparently the Replace With function is not dependent on the different device cat/subcat value associated with the Dual Band KeypadLincs. The 99i does not support many of the new devices released since 3.3.10 was released. There is an update option to move to a 994i for $99. Do not know how long that option will be available.

I think using a different Scene versus changing the On Level depends on how often the values are changed. One or two times a day the Adjust Scene function is fine. Changing many times a day I would use a separate Scene. The On Level cannot currently be in a Variable. Variable usage is being expanded in future images. Do not know if On Level will be in that expansion.

Look at the "Adjust Scene" Program Action function. It is used to change the On Level and Ramp Rate for Scene members. The link record value for On Level and Ramp Rate is being changed so it is not something to be done a large number of times during a day. It might be better to define an additional Party Scene with the On Level/Ramp Rate values that suit the function. To turn the KeypadLinc button Off define a Scene with the KeypadLinc button as a Responder. Turn that Scene Off to turn a KeypadLinc Secondary button On/Off. Could set the button to non-toggle Off mode which causes the button to blink twice and turn Off when pressed, sending an Off command all the time. The Program would check for an Off command rather than an On command.

What devices were installed initially? Were Access Points installed to couple the 2 120v legs? Did they pass the 4 tap Set button test? The ISY would not cause the problem. It is also unlikely the PLM was the issue.

Take a look at this topic for possible solution ... viewtopic.php?f=27&t=13753&hilit=manifest

There would be no delay. A Scene would turn On/Off whatever I/O Lincs were appropriate for the particular message. One Insteon Scene command to control the 8 I/O Lincs. No different than a Scene controlling 8 different SwitchLincs. A single EZIO8SA/PLM is less expensive. However, since it does not satisfy the requirement (control x relays at once using ISY) the I/O Lincs are a functional alternative. EDIT: If 6 Relays are all that is necessary than the I/O Linc approach is not much more expensive.

I have a sensor for fully closed and another for fully open. They drive EZIO2X4 Inputs. My doors are not visible from the house so knowing they are fully open or fully closed has been helpful. They simply turn On/Off KPL buttons which is all I need for my situation.

Some Insteon devices such as a KeypadLinc can turn On multiple buttons at the same. Unfortunately the EZIO8SA stops when it finds the first responder link record. The ISY would have to add support for a new form of link record to add that capability to the EZIO8SA. I would think some TTL logic that takes inputs from 8 I/O Linc relays and drives 40 relays would be cheaper than moving to an ELK. With an I/O Linc an additional PLM per EZIO8SA is not needed reducing cost. I don't think an individual PLM chip cannot be purchased. If the voice box can be driven from TTL the 40 relays would not be needed.

The discussion of Scenes by ELA has nothing to do with how many Scenes the ISY/PLM support. There is a document on the Smartenit web site that discusses the various link record formats the EZIOxx family of devices support. Most of these are not supported by the ISY. Manually adjusting link records should be left to the folks who are familiar with link records and know the impact to the ISY environment when using unsupported formats. You can PM and I will take the conversation offline but would prefer not to add detail here. I strongly suggest not moving in this direction.

It will require separate Programs for each area. Same type of trigger, just different times. If totally past the time range nothing happens. If within a time range the variable will start the process and the To time ends it. If before the time range nothing happens until the From time is reached. If $statevar is On And From 7 PM To 9 PM Then Set Scene .... On Else Set Scene .... Off If $statevar is On And From 8 PM To 10 PM Then Set Scene .... On Else Set Scene .... Off

The Program is triggered at Sunset. If Sunset has passed before Folder is True the Program is not triggered. Change the Folder condition to If Status kplbutton is On Add a test for the variable being set ANDed with the current Time range in the Program

That cannot be done with the ISY. The event viewer will not display commands issued by the SHN Utility. Insteon does not work that way. Even knowing the command, which is described in a document on the Smartenit web site, the ISY cannot send it.

Post the Program sending the notification twice. It sounds like the Program is being invoked more than once. Right click on the Program name and select Copy to Clipboard. Paste in forum post.

drw I believe the problems are unrelated. The RX LED being On indicates the ISY is not able to communicate with the PLM. Since you do not have the RX LED On and it sounds like some diagnostics have been done regarding local LAN communication issue I don't see a relation between your symptom and not being able to talk to the PLM.

drw Is the RX LED on solid when this happens?

RX LED on solid indicates the ISY is not able to communicate with the PLM. Unplug the PLM for a few minutes and make sure the cable connections are fully seated. After PLM is plugged in again, reboot the ISY. If the RX LED remains on solid it indicates a bad PLM or bad cable.

Removing the battery stops the motion sensor. Install a weak battery but be careful as the motion sensor sends only one low battery message. The battery has to be low enough to report Low Bat but not so low as to prevent the motion sensor from working. How to generate smoke as a test can be interesting. Light a piece of paper and blow out the flame. May produce enough smoke to set off the alarm. Over heat some grease on the stove but that can result in a real fire so caution is advised. Find a neighbor that smokes.