LeeG

Trigger an ISY Program with the Sensor and have the Program turn the Scene On. There will a slight delay getting the Program started and Scene invoked (around 1 second). Also the Open/Close Sensor has an alternate two node mode (remove internal jumper) which causes On commands only to be issued to each node which would turn On the Scene but not turn it Off.

What error is being seen when loading a new image? Remember the ISY requires the ISY image be the original ZIP format. It should not be unzipped including being unzipped by the OS as Mac often does.

A device (node) can be a Controller of one Scene only. Insteon does not create a structure where a device (node) can control multiple Scenes, therefore it is important to define a device (node) as a Controller in the appropriate Scene. A device (node) can be a Responder in multiple Scenes.

oberkc - I think it is great to have multiple examples posted for evaluation. Keep up the good work!

It is the Status check that is creating the problem. When ever Status changes the Program is triggered. A Program that changes the Status of the device being checked in the If section often creates a problem. Program 1 If Control 'remote e' is switched On Then Run Program 2 (If section) Else Program 2 - must be marked Disabled to prevent change in Status triggering this Program If Status 'light' is not Off Then Set 'light' Off Else Set 'light' On

The 2413 PLM supports a maximum of 992 link records. A count of 1050 is the result of what Xathros has already mentioned, any Insteon traffic reaching the PLM during the Show PLM Links Table processing will produce a false high or low count. As Xathros has described, run the Show PLM Links Table/Count several times until the same number is obtained on multiple runs. No Insteon traffic must reach the PLM during the Show PLM execution. Also as Xathros has indicated, a PLM will accumulate duplicate and no longer used link records. A Restore Modem (PLM) will compress out these records leaving only active records. This should be done before running the Show PLM function. It is possible the PLM link record count is not an issue.

The exact previous state cannot be stored and reused today. Perhaps in a few months Variables will be updated with that capability but that is only speculation at this point. The best you can do is use a set of Programs ... If Status 'xxxx' => 20 and Status 'xxxx' <= 40 ..... Then do the flashing Set 'xxxx' 30%

Either the MobiLinc is sending a Scene Off which turns the KeypadLinc button Off immediately or if a Scene On is issued the KeypadLinc button as a Responder to the Scene name is set to 0% On Level. If a Scene On is being issued click the Scene name under the Admin Console and check the KeypadLinc On Level.

Dimarc67 I think there is confusion due to the differences between how Scenes work with the I/O Linc Relay and how Direct commands work with the I/O Linc Relay. The variations of which commands control the I/O Linc Relay based on Momentary mode apply ONLY to Scenes. Using Momentary A where the Relay responds to either On or Off command but only one command applies when a Scene is driven such as when the KeypadLinc button is pressed. Using a Direct On command either from the Admin Console or from MobiLinc to the I/O Linc Relay always turns the Relay On. It does not matter which Momentary mode is being used. A Direct On command always turns the Relay On. Because any Momentary mode turns the Relay Off automatically the Direct Off command has no affect. A Direct Off command to the Relay turns it Off but since Momentary mode has already turned the Relay Off a Direct Off command is essentially a NOP. If you want MobiLinc to work the same as pressing the KeypadLinc button the Scene has to be turned On from MobiLinc

It is the latest level of Java. Either move to 4.1.2 or add the ISY IP address to the Java Exception Site List

That would be correct. The factory reset would clear the device link database which makes the attempt after the reset look like the first.

The 'retries' is associated with I2CS devices only. With the I2CS protocol an I2CS device as a Controiller can have the number of times a Group Cleanup Direct message will be retried defined for each Responder. The Group Cleanup Direct message is sent to each Responder which insures a button/paddle press action is recognized by each Responder. Before I2CS the device would issue the Group Cleanup Direct message up to 3 times. This has no affect on the reliabilty of an ISY Scene invoked from the Admin Console, an App, or an ISY Program. It does not affect Direct commands issued from the PLM. The PLM itself is not an I2CS device. It could improve reliability of a KeypadLinc button press to a particular Responder for example. It can also generate extra Insteon so it should be used with consideration.

The difference in PLM response is due to the fact that the device has a link back to the PLM the second time so there is no need to go through the linking sequence needed by an I2CS device. The first Query Insteon Engine response indicates the device is I2CS and does not have link to the PLM. The ISY generates the sequence that links the I2CS device back to the PLM. This is why the PLM beeps as it must be put into linking mode to generate the device link. Sun 02/09/2014 01:45:57 PM : [1f 14 82 ] Added to list of devices to link to ISY Sun 02/09/2014 01:45:57 PM : [iNST-TX-I1 ] 02 62 1F 14 82 0F 0D 00 Sun 02/09/2014 01:45:57 PM : [iNST-ACK ] 02 62 1F.14.82 0F 0D 00 06 (00) Sun 02/09/2014 01:45:57 PM : [iNST-SRX ] 02 50 1F.14.82 22.80.0B AB 0D FF (FF) Sun 02/09/2014 01:45:57 PM : [std-Direct Nack] 1F.14.82-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 02/09/2014 01:45:57 PM : [iNST-TX-I2CS] 02 62 1F 14 82 1F 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 F6 Sun 02/09/2014 01:45:57 PM : [iNST-ACK ] 02 62 1F.14.82 1F 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 F6 06 LNK-ON (01) Sun 02/09/2014 01:45:57 PM : [iNST-SRX ] 02 50 1F.14.82 22.80.0B A3 0D FF (FF) Sun 02/09/2014 01:45:57 PM : [std-Direct Nack] 1F.14.82-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 02/09/2014 01:45:57 PM : [iNST-DUP ] Previous message ignored. Sun 02/09/2014 01:45:58 PM : [iNST-SRX ] 02 50 1F.14.82 22.80.0B 2B 09 01 LNK-ON (01) Sun 02/09/2014 01:45:58 PM : [std-Direct Ack] 1F.14.82-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 02/09/2014 01:45:58 PM : [LNK-BGN ] 02 64 01 00 06 Sun 02/09/2014 01:45:59 PM : [LNK-STAT ] 02 53 M(01) gid=00 1F.14.82 021E 41 Sun 02/09/2014 01:45:59 PM : [iNST-TX-I1 ] 02 62 1F 14 82 0F 0D 00 Sun 02/09/2014 01:45:59 PM : [LNK-END ] 02 65 06 Sun 02/09/2014 01:45:59 PM : [std MH ] Unexpected Ack imCmd=65 cmd1= 0x82 Sun 02/09/2014 01:45:59 PM : [iNST-ACK ] 02 62 1F.14.82 0F 0D 00 06 (00) Sun 02/09/2014 01:45:59 PM : [iNST-SRX ] 02 50 1F.14.82 22.80.0B 2B 0D 02 (02) Sun 02/09/2014 01:45:59 PM : [std-Direct Ack] 1F.14.82-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 At this point I deleted the device and added it again. This time the device reports it is I2CS and it has a link to the PLM, thus no need to go through the sequence to generate that link. Sun 02/09/2014 01:47:51 PM : [1f 14 82 ] Added to list of devices to link to ISY Sun 02/09/2014 01:47:51 PM : [iNST-TX-I1 ] 02 62 1F 14 82 0F 0D 00 Sun 02/09/2014 01:47:51 PM : [iNST-ACK ] 02 62 1F.14.82 0F 0D 00 06 (00) Sun 02/09/2014 01:47:51 PM : [iNST-SRX ] 02 50 1F.14.82 22.80.0B 2B 0D 02 (02) Sun 02/09/2014 01:47:51 PM : [std-Direct Ack] 1F.14.82-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 02/09/2014 01:47:51 PM : [iNST-TX-I1 ] 02 62 1F 14 82 0F 10 00 Sun 02/09/2014 01:47:51 PM : [iNST-ACK ] 02 62 1F.14.82 0F 10 00 06 ID-REQ (00) Sun 02/09/2014 01:47:51 PM : [iNST-SRX ] 02 50 1F.14.82 22.80.0B 2B 10 00 ID-REQ (00) Sun 02/09/2014 01:47:51 PM : [std-Direct Ack] 1F.14.82-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 02/09/2014 01:47:51 PM : [iNST-SRX ] 02 50 1F.14.82 02.1E.41 8B 01 00 (00) Sun 02/09/2014 01:47:51 PM : [std-Broadcast] 1F.14.82-->02.1E.41, Max Hops=3, Hops Left=2 Sun 02/09/2014 01:47:51 PM : [1F 14 82 0 ] Calibrating engine version

Each time the I/O Linc Sensor turns On a new 10 second Wait is started. If the full 10 seconds elapse the Program is called. If Control 'IO Linc-Sensor' is switched On Then Wait 10 seconds Run Program 'AAAA1' (Then Path) Else - No Actions - (To add one, press 'Action')

A "Repeat 1" is the correct coding to end the preceding Repeat. Repeat 0 did not work.

Here is a link to the Wiki section that covers Repeat. It says use a Repeat 1 to end the repeat loop. http://wiki.universal-devices.com/index ... EON:Action

Send a note to UDI with 99i and 994i UUID and all purchased modules will be activated on the 994i.

The device must respond to the Insteon Engine query. It is the first command issued by the ISY with the returned data being critical to knowing what the device requires. An I2CS device has very different requirements than an I2 device and the Insteon Engine Query is the command that provides that data. The device does not respond either because the command did not reach the device or the device response did not reach the PLM (if a response was sent). If using a Dual Band PLM (2413) try moving the Mini Remote near the PLM. Can also try a Factory Reset of the Mini Remote.

Thanks for the additional trace data. There are some differences in this event but add to the overall picture. The entries marked in red are additional messages that should not be there. The command code (0xB0) does match either Query sequence and of course the cmd2 data (0xC7) is completely unrelated to the state of the EZIO8SA relays. Sat 02/08/2014 12:16:15 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 4F 02 Sat 02/08/2014 12:16:15 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 4F 02 06 IOCTL (QUERY) Sat 02/08/2014 12:16:15 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 4F 07 IOCTL (07) Sat 02/08/2014 12:16:15 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 02/08/2014 12:16:15 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Sat 02/08/2014 12:16:15 PM : [iNST-ACK ] 02 62 28.AD.BD 00 4F 02 06 IOCTL (QUERY) Sat 02/08/2014 12:16:16 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 20 B0 C7 (C7) Sat 02/08/2014 12:16:16 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=0, Hops Left=0 Sat 02/08/2014 12:16:16 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 20 B0 C7 (C7) Sat 02/08/2014 12:16:16 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=0, Hops Left=0 Sat 02/08/2014 12:16:16 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 20 4F 02 IOCTL (QUERY) Sat 02/08/2014 12:16:16 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=0, Hops Left=0 Sat 02/08/2014 12:16:25 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Sat 02/08/2014 12:16:25 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 49 00 06 RINPUT (00) Sat 02/08/2014 12:16:25 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 49 30 RINPUT (30) Sat 02/08/2014 12:16:25 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 This is looking more like an EZIO8SA issue than something happening due to Insteon network issues.

The Mini Remote being battery powered cannot be changed by the ISY without manually placing it in linking mode. Because of this buttons do not have the ability to change states remotely. Also all the buttons function in only one mode, not like a KeypadLinc where each button can be assigned a different mode. The Mini Remote does not have the features needed to work with FanLinc Fan speed adjustments. If set to 4 Scene mode where there is a separate On and Off button it works but that limits what else could be supported by the one device. Regarding the hang, is this a Maverick OS? There has been another issue reported with what looks to be a Java issue with Maverick.

Have not forgotten this question. I just realized the device I was testing had already been in the test bed at some point in the past which explains why I was not seeing any difference between what I thought was first and subsequent adds. I have to switch to a device that has never been used before.

Brian, thanks for the data. It could be an issue later but now the device is not responding to the first command which is asking for the Insteon Engine. Even old devices respond to this command with an I1 indicator. This Mini Remote is not sending any response as though it did not receive the command to begin with. This is what the beginning of the trace should look like... Sat 02/08/2014 01:31:36 PM : [1c 27 e3 ] Added to list of devices to link to ISY Sat 02/08/2014 01:31:36 PM : [iNST-TX-I1 ] 02 62 1C 27 E3 0F 0D 00 Sat 02/08/2014 01:31:36 PM : [iNST-ACK ] 02 62 1C.27.E3 0F 0D 00 06 (00) Sat 02/08/2014 01:31:36 PM : [iNST-SRX ] 02 50 1C.27.E3 22.80.0B 27 0D 01 (01) Sat 02/08/2014 01:31:36 PM : [std-Direct Ack] 1C.27.E3-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 The Blue message above is the device response that is missing from the OP device Sat 02/08/2014 01:31:36 PM : [iNST-TX-I1 ] 02 62 1C 27 E3 0F 10 00 Sat 02/08/2014 01:31:36 PM : [iNST-ACK ] 02 62 1C.27.E3 0F 10 00 06 ID-REQ (00) Sat 02/08/2014 01:31:37 PM : [iNST-SRX ] 02 50 1C.27.E3 22.80.0B 2B 10 00 ID-REQ (00) Sat 02/08/2014 01:31:37 PM : [std-Direct Ack] 1C.27.E3-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 02/08/2014 01:31:37 PM : [iNST-SRX ] 02 50 1C.27.E3 00.12.36 87 02 01 (01) Sat 02/08/2014 01:31:37 PM : [std-Broadcast] 1C.27.E3-->00.12.36, Max Hops=3, Hops Left=1 If the Mini Remote had responded to the first command it would be asked what type of device it is. This is where the cat/subcat/firmware is returned and could be an issue. This is an 8 button Mini Remote with a cat=00 subcat=12

"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