LeeG

"I thought all I needed to do was to wake the RemoteLinc by toggling one of its switches just prior to linking with the ISY. " All battery devices have to be put into linking mode with their Set button before the ISY (or any app) can communicate with it. Otherwise the device is asleep and cannot receive commands.

I’m not sure how to explain the extra message. It has the EZIO8SA address but the Max Hops count, command code and the cmd2 value being evaluated as relay status do not match either of the last two Query calls. In the I/O Linc case the extra message matches an earlier Query except for a smaller Hops Left count, making the message look like a duplicate. There is so much information in this message that does not match the real EZIO8SA condition it raises the question as to whether it is actually from the EZIO8SA. I think another level 3 trace is needed to see if the extra message has any similarities between cases.

I found a bad sequence that explains why the relays have the wrong status but not sure what to do about it. There is an extra message with the EZIO8SA address after the Input Query response that the ISY analyzes and marks several relays with the wrong status. Something similar to what we see with an I/O Linc but different enough that it requires more analysis. Fri 02/07/2014 02:24:13 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 4F 02 Fri 02/07/2014 02:24:13 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 4F 02 06 IOCTL (QUERY) Fri 02/07/2014 02:24:13 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 4F A8 IOCTL (A8) – 4 & 6 & 8 On - Ok 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: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 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 1] ST 255 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 2] ST 255 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 3] ST 255 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 6] ST 0 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 8] ST 0

Also double check the .88. are eights and not B's.

Nothing but putting the Mini Remote into linking mode before adding it to the ISY (using Set button as you described). With it in linking mode the next area would be is it near a Dual Band device that has good communication with the PLM.

The Mini Remote like all battery devices has to be put into linking mode with its Set button just before doing the add to the ISY. Otherwise the device is asleep (turned RF Off to conserve battery) and cannot receive commands. The event trace is showing device 26.88.6C did not respond to the three attempts to send it a command. This is what happens if the battery device is not put into linking mode.

Was the Mini Remote put into linking mode before adding to the ISY and is the Mini Remote close to a Dual Band device? EDIT: put the event viewer into LEVEL 3 to see the actual commands issued and what the response if any is.

The reuse of the deleted record is what I expected. Was Start Linking or New INSTEON Device used to readd device after the delete? I have to make a run out of town this afternoon; will see what my PLM does once I know which approach was used to readd the device. Also what level firmware is in the PLM, Tools | Diagnostics | PLM Info/Status?

The ISY issues a command to have the link record deleted. It is up to the PLM to perform that action and I do not know what affect the deleted link record would have if/when the device is added back. The command to mark the link inactive is in Red Wed 02/05/2014 07:13:54 PM : [1D 38 0 1 ] Link 1 : 0FF0 [620122800B010001] Saving [62..............] Wed 02/05/2014 07:13:55 PM : [1D 38 0 1 ] Link 0 : 0FF8 [220022800BFF1F01] Saving [22..............] Wed 02/05/2014 07:13:55 PM : [MNG-LNK-RSP ] 02 6F 80 E2 00 1D 38 00 01 20 40 06 Wed 02/05/2014 07:13:55 PM : [1D 38 0 1 ] Start : Removing device from ISY Wed 02/05/2014 07:13:55 PM : [1D 38 0 1 ] Finish : Removing from ISY was Successful Wed 02/05/2014 07:13:56 PM : [All ] Writing 0 bytes to devices

That entry means the ISY thinks the device was On and the Scene turned it Off. All device changes marked after a Scene On or Off are what the ISY believes should happen based on the Scene definition. Of course a Scene Off will mark any device as Off the ISY currently believes is not Off when the Scene Off is issued. The Scene Test uses a different PLM command so there are actual device responses for a Scene Test

The devices in an ISY Scene On/Off are marked according to how they should react, not how they actually reacted. There are no ACKs associated with an ISY Scene being turned On or Off. Suggest running a Scene Test with the All On/Off Scene with the event viewer running at LEVEL 3. That will give some indication of the general reliability of the devices associated with that Scene. From one of the earlier traces one of the KeypadLincs has poor communication with the PLM with a Hops Left=0 from a button press. There may be other areas the Scene Test will show.

Invoke Java from OS Control Panel. Select Security tab. The Exception Site List is one of the fields on the Java Security tab. The newest Java update has a new requirement that is satisfied with 4.1.2 or it can be satisfied by adding the ISY IP address to the Exception List.

Move to 4.1.2 or add the ISY IP address to the Java Exception Site List.

Sun 02/02/2014 03:00:23 AM : [iNST-TX-I1 ] 02 62 0F D4 91 0F 19 00 Sun 02/02/2014 03:00:23 AM : [iNST-ACK ] 02 62 0F.D4.91 0F 19 00 06 LTSREQ (LIGHT) Sun 02/02/2014 03:00:23 AM : [iNST-SRX ] 02 50 0F.D4.91 24.1B.FE 2B 0F FF PING (FF) Sun 02/02/2014 03:00:23 AM : [std-Direct Ack] 0F.D4.91-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 02/02/2014 03:00:23 AM : [iNST-TX-I1 ] 02 62 16 D9 56 0F 19 00 Sun 02/02/2014 03:00:23 AM : [iNST-SRX ] 02 50 0F.D4.91 24.1B.FE 23 0F FF PING (FF) Sun 02/02/2014 03:00:23 AM : [std-Direct Ack] 0F.D4.91-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 02/02/2014 03:00:23 AM : [iNST-ACK ] 02 62 16.D9.56 0F 19 00 06 LTSREQ (LIGHT) Sun 02/02/2014 03:00:24 AM : [iNST-SRX ] 02 50 16.D9.56 24.1B.FE 2B 0A FF LNK-OFF(FF) Sun 02/02/2014 03:00:24 AM : [std-Direct Ack] 16.D9.56-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Did the Front Light Companion Sw respond twice? Yes it did. However both responses indicate the device is On. The Front Inside Light = 16.10.F6 responded only once and it showed the device as Off. There is a problem with the Fade Down of 16.10.F6. Perhaps it was later in the trace but there is no Fade Stop to end the Fade Down. Issuing a Fade Up/Down without issuing a Fade Stop leaves the device in a bad state. That situation should not happen and cannot happen with hardware as there is always a Fade Stop when a paddle/button is released. The device may not react to the next command as expected. Here is a trace of a Fade Down followed by a Fade Stop. Note that the ISY does not mark the Status of the device until the Fade Stop is issued as the timing between the Fade Down and the Fade Stop establish the On Level (approx). Without the Fade Stop the ISY does not know the Status of the device. Sun 02/02/2014 05:50:57 PM : [iNST-ACK ] 02 62 1D.23.6B 0F 17 00 06 LTMCON (DOWN) Sun 02/02/2014 05:50:57 PM : [iNST-SRX ] 02 50 1D.23.6B 22.80.0B 2B 17 00 LTMCON (DOWN) Sun 02/02/2014 05:50:57 PM : [std-Direct Ack] 1D.23.6B-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 02/02/2014 05:50:58 PM : [iNST-TX-I1 ] 02 62 1D 23 6B 0F 18 00 Sun 02/02/2014 05:50:58 PM : [iNST-ACK ] 02 62 1D.23.6B 0F 18 00 06 LTMCOFF(00) Sun 02/02/2014 05:50:58 PM : [iNST-SRX ] 02 50 1D.23.6B 22.80.0B 2B 18 00 LTMCOFF(00) Sun 02/02/2014 05:50:58 PM : [std-Direct Ack] 1D.23.6B-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 02/02/2014 05:50:58 PM : [ 1D 23 6B 1] ST 71 ------------------------------------------------------------------------------------------------- The comm. from 17.A3.7B is also at the limit of function with a Hops Left=0 when button 8 was pressed. It worked this time but it might not work each time. Sat 02/01/2014 09:46:04 PM : [iNST-SRX ] 02 50 17.A3.7B 00.00.08 C3 11 00 LTONRR (00) Sat 02/01/2014 09:46:04 PM : [std-Group ] 17.A3.7B-->Group=8, Max Hops=3, Hops Left=0 Sat 02/01/2014 09:46:04 PM : [ 17 A3 7B 8] DON 0

Thanks KMan, I had not thought of that If combination.

Then one Program can do the job If Time is 7:00:00PM Then Set 'SwitchLinc Dimmer DB' On Wait 4 hours Set 'SwitchLinc Dimmer DB' 60% Wait 6 hours Set 'SwitchLinc Dimmer DB' Off Else - No Actions - (To add one, press 'Action')

Just ran a test on HouseLinc. If you set the SwitchLinc to Off before moving to the ISY the ISY will NOT turn the LEDs back on. There is a separate command to turn the LEDs physically Off and another to turn them back On. The ISY does not support that on SwitchLinc devices. A Factory Reset of the SwitchLinc device to get the LEDs physically On is needed. A Restore Device will also be needed to rebuild the link database after the Factory Reset.

It requires two Programs. One that triggers at Sunset and another that triggers at 5 AM. Sunset moves almost everyday so it is not possible to start at Sunset and then do something at 5AM in the same Program.

When set to 00 in HouseLinc does that physically turn the LEDs Off regardless of the state of the SwitchLinc? If so the ISY does not support that option so setting the BackLight level to some other level will not turn the LEDs back On.

The Backlight level was set to 191. If the device did not change to that level then it is a device question. What is the SwitchLinc firmware level shown on line 2 of the right side node display.

"I can do this by creating a scene where the mini is the controller, and the "H" key and the "couch light" are responders. And this works OK." This extra Scene is not necessary. ISY Scene xxxx KeypadLinc button H Controller Remote Mini button ? Controller ToggleLinc Controller This single ISY Scene will cross-link the devices so they stay in sync. The All On Scene now includes the individual devices. Add to this ISY Scene the KeypadLinc buttons as Responders. The KeypadLinc buttons will turn On as the other Responder devices.

"I recently restored my device" What device was restored? and why?

Need to to upgrade to 994i. The Dual Band KPLs (along with other new devices) are not supported on 3.3.10.

There are a number of ways to do that. Here is one approach. Program1 If Status 'SwitchLinc Relay' is Off And Control 'IO Linc-Sensor' is switched On Then Run Program 'Program2' (Then Path) Else - No Actions - (To add one, press 'Action') Program2 If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Set 'SwitchLinc Relay' On Wait 10 minutes Set 'SwitchLinc Relay' Off Else - No Actions - (To add one, press 'Action')

${sys.node.14 3A CB 1.ST} This link goes to the Wiki for details http://wiki.universal-devices.com/index ... _Variables