LeeG

I do not think the addition of Access Points will make the duplicate messages worse. Unfortunately there is no objective information to support that since we don't know the 'why' of all this. Add an Access point or two and see if it gets worse. Improving overall Insteon network reliability should be a good thing. In theory it should not be necessary to do any of these Queries if the Insteon Network was reliable. As far as spacing the Queries between different I/O Lincs, not sure that will help after seeing the FanLinc test results. The I/O Linc is Queried twice, once for Sensor status and once for Relay status when either node is queried. I don't think a duplicate message from one I/O Linc will interfere with the Query of a totally different I/O Linc because the Insteon address would be different in the duplicate message. .

Take a look at this possibility. It primes itself at 1AM (arbitrary time). So long as the TriggerLinc sends an On or Off message within 23 hours wait period nothing happens beyond the Program being retriggered with new Wait 23 Hours after each TriggerLinc message. When 23 hours pass without any message from the TriggerLinc the Notify is executed. I picked a 23 hour wait (could be 23 hours 55 minutes) so the 1AM trigger would not start a new Wait cycle possibly preventing the Notify. The Program will send a Notify every 23 hours until the TriggerLinc becomes active again. If Time is 1:00:00AM Or Control 'TriggerLinc1-Opened' is switched On Or Control 'TriggerLinc1-Opened' is switched Off Then Wait 23 hours Send Notification to 'ALL' Else - No Actions - (To add one, press 'Action')

No. TriggerLinc does not have low battery notification.

You will need a Scene for a KeypadLinc button to control the I/O Linc Relay. That Scene can be used from MobiLinc. I guess you could trigger a Program on the KPL button press and control the Relay with the Program but I see no advantage to that approach. I do not use MobiLinc so have no experience to draw on to know the advantages of Direct versus Scene from MobiLinc. I'm sure there will be folks that use MobiLinc and can recommend an approach.

Is the I/O Linc Relay being controlled directly from MobiLinc or is a Scene with the Relay as a Responder being controlled? If a Scene is used the problem is Momentary B mode is not being used. If controlling the Relay directly I saw a post from MobiLinc that said there is a list of commands that apply. All but the On command can be deleted so only On commands are issued. Direct On command always turns the Relay On in any of the Momentary modes. It is Scene commands that are sensitive to which Momentary mode is being used.

I would add only one point to the discussion a few posts back. If you want the I/O Linc Relay to respond to both On and Off commands from the KPL button (which is independent of the Relay Status) use Momentary B mode. Momentary A mode will respond to either an On command only or an Off command only, but not both. Again this does not matter if the Relay has an ISY Status of On or Off.

JSP0511 It was Xathros that provided the last round of information. He is very good with Programming (and many other things).

Yes

The Heat Ctl node indicates the thermostat has called for heat, not that it is in Heat Mode. Check the thermostat main node for a Status of Mode Heat to determine the thermostat has been put into Heat mode.

I checked the If Control and the MorningLinc is not even allowed as a selection. Did not understand the security concern but a change was implemented. Since the MorningLinc Status often does not reflect the actual state of the lockset anyway, perhaps a Variable could be used to represent the last command sent to the MorningLinc. EDIT: please ignore my If Control comment. The MorningLinc nodes are Responder Only nodes so they would never have been an option in an If Control statement.

I would strongly recommend using a pair of Access Points for coupling. In wall Dual Band devices do not have the RF range of an Access Point that is not hindered by wiring inside the box which affects RF coverage. If you happen to have metal boxes RF range is even more restricted. The Motion Sensor will likely talk to the Dual Band SwitchLinc being so close but Motion Sensor placement relative to the SwitchLinc could make a difference. I would not count on the SwitchLinc providing coupling if the ISY PLM is not on the same phase. Depends on distance, number of walls in between, number of floors in between, obstructions, etc. That is why a recommend Access Points for coupling.

That was a great question Xathros raised about would the problem be seen on other device types. Ran the same test against a FanLinc with the same results. The event trace below shows the FanLinc Motor being marked On because of a duplicate response to a FanLinc Light Query. The FanLinc Light is full On (FF), the FanLinc Motor is Off. The trace entry in Blue is the ISY marking the FanLinc Motor On as the duplicate FanLinc Light response changed the FanLinc Motor Status. Tue 07/16/2013 10:44:27 AM : [iNST-TX-I1 ] 02 62 14 9E F5 0F 19 00 Tue 07/16/2013 10:44:27 AM : [iNST-ACK ] 02 62 14.9E.F5 0F 19 00 06 LTSREQ (LIGHT) Tue 07/16/2013 10:44:28 AM : [iNST-SRX ] 02 50 14.9E.F5 22.80.0B 2B 00 FF (FF) Tue 07/16/2013 10:44:28 AM : [std-Direct Ack] 14.9E.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 07/16/2013 10:44:28 AM : [iNST-TX-I1 ] 02 62 14 9E F5 0F 19 03 Tue 07/16/2013 10:44:28 AM : [iNST-ACK ] 02 62 14.9E.F5 0F 19 03 06 LTSREQ (03) Tue 07/16/2013 10:44:28 AM : [iNST-SRX ] 02 50 14.9E.F5 22.80.0B 23 00 FF (FF) Tue 07/16/2013 10:44:28 AM : [std-Direct Ack] 14.9E.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Tue 07/16/2013 10:44:28 AM : [ 14 9E F5 2] ST 255 Update: added a 1 second delay between the Queries to see if that made a difference. This time the Query of the FanLinc Motor node produced the duplicate entry. This is a pretty simple case. The next Query command had not been issued because of the 1 second delay. The duplicate with Hops Left=0 was not recognized as a duplicate by the PLM. Tue 07/16/2013 11:30:47 AM : [iNST-TX-I1 ] 02 62 14 9E F5 0F 19 00 Tue 07/16/2013 11:30:47 AM : [iNST-ACK ] 02 62 14.9E.F5 0F 19 00 06 LTSREQ (LIGHT) Tue 07/16/2013 11:30:47 AM : [iNST-SRX ] 02 50 14.9E.F5 22.80.0B 2B 00 FF (FF) Tue 07/16/2013 11:30:47 AM : [std-Direct Ack] 14.9E.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 07/16/2013 11:30:47 AM : [iNST-TX-I1 ] 02 62 14 9E F5 0F 19 03 Tue 07/16/2013 11:30:48 AM : [iNST-ACK ] 02 62 14.9E.F5 0F 19 03 06 LTSREQ (03) Tue 07/16/2013 11:30:48 AM : [iNST-SRX ] 02 50 14.9E.F5 22.80.0B 2B 19 00 LTSREQ (LIGHT) Tue 07/16/2013 11:30:48 AM : [std-Direct Ack] 14.9E.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Tue 07/16/2013 11:30:48 AM : [iNST-SRX ] 02 50 14.9E.F5 22.80.0B 23 19 00 LTSREQ (LIGHT) Tue 07/16/2013 11:30:48 AM : [std-Direct Ack] 14.9E.F5-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

Insteon has no concept of Scene On Level, Scene Ramp Rate, Scene Status. Since every Responder can have a unique On Level and/or Ramp Rate that information is at the device level.

Xathros No room in the ACK message for a node (group) indicator. The Query returns a link database Delta number in cmd1 field and On Level (On/Off) in cmd2. That is a good question about the FanLinc. I'll set up the same test I ran against the I/O Linc.

I have two rev 1.0 (hardware revision) TriggerLincs that work fine. They have v.28 firmware. Suggest adding them to the ISY and testing before using two sided tape to mount. What ISY firmware level is being used?

I was running a PLM with v.98 when this first surfaced. Switching to the v.9B PLM had no affect on the result. I'm not sure if this is an issue with the I/O Linc, the PLM or the overall Insteon Mesh Network. Without independent tools to analyze what is flowing over the powerline versus what is flowing over RF its difficult to point to any one element. In fact there is nothing that we as end users can look at to know if that Hops Left=0 message is a powerline message or an RF message or some combination of both. This could be a more general issue with the network that is seen only with an I/O Linc because it takes two Query commands to get the Sensor and Relay status. Although there are different cmd2 values outbound which identify whether the Sensor or Relay status is being asked for, the architecture of the response (the ACK) does not carry that Sensor/Relay identifier. The application can only assume the response provided by the PLM is the response to the last command issued. The three messages below, the first message is the response (ACK) from the Sensor Query, the second message is the response (ACK) from the Relay Query. They are exactly the same except for the last byte which shows Sensor Off (00) and Relay On (FF). The third is the duplicate Sensor Query response which looks just like the others except for the Hops Left bits which say nothing about whether this is a Sensor or Relay response. The duplicate message is a structurally perfect Insteon message seen on many networks. Mon 07/15/2013 03:09:25 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 00 (00) Mon 07/15/2013 03:09:25 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 FF (FF) Mon 07/15/2013 03:09:25 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 23 00 00 (00) That is a long winded response to the ISY question. The ISY has nothing to look at in the response to know whether it came from the Sensor or the Relay. When the duplicate message comes back as the response following the outbound Relay Query. The ISY has no choice but to take it as a Relay Query response even though it is believed to be a duplicate Sensor response message. The advantage to being human with the ability to look at the messages that flowed before and several messages that flowed after allow the conclusion the message is a duplicate but that is far beyond what the ISY can conclude based on last Query issued and next response received. My looping Program worked for several iterations before that duplicate message appeared and worked for several interactions after without producing another duplicate. It may be that adding a small amount of time between the Queries would help but that is all speculation. Nothing objective in the event trace supports that idea. Certainly worth trying.

The ISY Log only shows the result, not the cause but I can recreate an I/O Linc Relay having the Status marked Off falsely. It is the result of extra messages being presented to the ISY from the PLM/IO Linc. A duplicate message from the I/O Linc with Hops Left=0 (which is believed to come from the previous Query of the Sensor) comes in after the Query for the Relay is issued. It gives all the appearance of a valid response to the Query of the Relay even though it has the Status of the Sensor. You can see from this event trace the line marked in Blue indicates the Status of the Relay is being marked Off. The next Query in my looping Program marks the Relay back On because the Relay never actually turned Off. The last time this was analyzed I picked up a new PLM with firmware v.9B to see if the latest PLM firmware might have resolved this. It did not. It is assumed the extra message is coming from a long path (many Hops) back to the PLM so the PLM does not recognize it as a duplicate since a new outbound command has been issued. Unfortunately I cannot provide a solution. It appears to be an issue with Insteon Mesh Network losing track of duplicate messages but that is only supposition at present. Mon 07/15/2013 03:09:25 PM : [iNST-TX-I1 ] 02 62 1C FD D5 0F 19 01 Mon 07/15/2013 03:09:25 PM : [iNST-ACK ] 02 62 1C.FD.D5 0F 19 01 06 LTSREQ (01) Mon 07/15/2013 03:09:25 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 00 (00) Mon 07/15/2013 03:09:25 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Mon 07/15/2013 03:09:25 PM : [iNST-TX-I1 ] 02 62 1C FD D5 0F 19 00 Mon 07/15/2013 03:09:25 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 23 00 00 (00) Mon 07/15/2013 03:09:25 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Mon 07/15/2013 03:09:25 PM : [iNST-ACK ] 02 62 1C.FD.D5 0F 19 00 06 LTSREQ (LIGHT) Mon 07/15/2013 03:09:25 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 23 00 00 (00) Mon 07/15/2013 03:09:25 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Mon 07/15/2013 03:09:25 PM : [ 1C FD D5 2] ST 0 Mon 07/15/2013 03:09:25 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 FF (FF) Mon 07/15/2013 03:09:25 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Mon 07/15/2013 03:09:28 PM : [iNST-TX-I1 ] 02 62 1C FD D5 0F 19 01 Mon 07/15/2013 03:09:28 PM : [iNST-ACK ] 02 62 1C.FD.D5 0F 19 01 06 LTSREQ (01) Mon 07/15/2013 03:09:28 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 00 (00) Mon 07/15/2013 03:09:28 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Mon 07/15/2013 03:09:28 PM : [iNST-TX-I1 ] 02 62 1C FD D5 0F 19 00 Mon 07/15/2013 03:09:29 PM : [iNST-ACK ] 02 62 1C.FD.D5 0F 19 00 06 LTSREQ (LIGHT) Mon 07/15/2013 03:09:29 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 FF (FF) Mon 07/15/2013 03:09:29 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Mon 07/15/2013 03:09:29 PM : [iNST-TX-I1 ] 02 62 1C FD D5 0F 19 01 Mon 07/15/2013 03:09:29 PM : [iNST-ACK ] 02 62 1C.FD.D5 0F 19 01 06 LTSREQ (01) Mon 07/15/2013 03:09:30 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 00 (00) Mon 07/15/2013 03:09:30 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Mon 07/15/2013 03:09:30 PM : [iNST-TX-I1 ] 02 62 1C FD D5 0F 19 00 Mon 07/15/2013 03:09:30 PM : [iNST-ACK ] 02 62 1C.FD.D5 0F 19 00 06 LTSREQ (LIGHT) Mon 07/15/2013 03:09:30 PM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 2B 00 FF (FF) Mon 07/15/2013 03:09:30 PM : [std-Direct Ack] 1C.FD.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Mon 07/15/2013 03:09:30 PM : [ 1C FD D5 2] ST 255 If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat Every 5 seconds Set 'IOLinc I2CS-Relay' Query Set 'IOLinc I2CS-Sensor' Query Else - No Actions - (To add one, press 'Action')

No association with UDI. Have been using Insteon for along time. A KeypadLinc device (primary node) is queried, not each individual button.

The Sensor aspects of the I/O Linc is a Controller Only node. Its state cannot be changed with a Program. I do not consider it a bug in the I/O Linc as it has worked this way for all the years the I/O Linc has been marketed. You can post a Product Request on the Smarthome forum. I don't think SmartLabs will change it after working this way for years. The time horizon for a design change of a SmartLabs product would be measured in years. It is not an ISY bug as the ISY has no control of the design of the I/O Linc. See my last post. It has the Smarthome Item number and manufacturer number of an alternative magnetic switch which supports using a Normally Open (NO) magnetic switch rather than the Normally Closed (NC) magnetic switch now being used. You can Disable the 3AM Query Program but it serves a good purpose to bring devices and ISY in sync in case there have been Insteon Mesh network issues in the previous 24 hours. You can write your own Scene with all devices except the I/O Linc and have the 3AM Program use that Scene. You can stop using the Sensor as a Controller. Write an ISY Program that is triggered by the commands flowing from the Sensor (If Control 'iolinc sensor' is switched On, If Control 'iolinc sensor’ is switched Off) and have the Program turn the KeypadLinc button On and Off as desired. The Query will not affect 'If Control' as the Query does not result in commands flowing from the Sensor. The simplest and best solution is to change the magnetic switch from NC to NO which has the same effect as using Trigger Reverse so the Trigger Reverse option is not necessary.

The Query can be tested by right clicking the I/O Linc Sensor node and select Query. That is the same Query issued at 3AM except it is only doing a Query of the I/O Linc. The magnetic switch the garage kit came with in the past is item # 7455B SECO-LARM SM-226L-3. It is a wide gap switch which means it works even on doors that have play between the door and the magnetic switch. This switch has three wires. Use the Black/Red wires for the I/O Linc Sensor to be On when the door is open, Off when the door is closed. Using the Black/Red wires has the same effect as using Trigger Reverse except Trigger Reverse is not used so Query and I/O Linc Sensor are in sync. Changing the Trigger Reverse option does not immediately change the Sensor state. The garage door has to be cycled open/close to see the result of changing Trigger Reverse.

When I discuss the I/O Linc Sensor and using NO rather than NC I am referring to the characteristics of the magnetic switch that is connected to the I/O Linc Sensor. The NO and NC I/O Linc Relay contacts have nothing to do with the Sensor being On or Off. Of course the Relay moves the door which changes the state of the magnetic switch but I am referring to whether the magnetic switch is closed (NC) when the magnet is next to the switch or the magnetic switch is open (NO) when the magnet is next to the switch.

The device that is blinking Red is receiving the RF test signal and is on the same phase as the Dual Band device where the 4 tap test was initiated. The SwitchLinc not reacting (is that the correct interpretation?) is not receiving the RF test signal. It has to do something other than its normal state to indicate it is receiving the RF test signal. The status LED may blink On and Off, it may blink dim to bright, but it has to do something when receiving the test RF signal. Otherwise how would one know the RF signal is being received. In wall devices can behave oddly. I have a Dual Band SwitchLinc that does not receive the RF test signal from my ISY PLM unless I am standing near the SwitchLinc. My existence at the SwitchLinc is having an effect on the RF signal. Likely reflecting off my body back to the SwitchLinc since the ISY PLM is located physically behind the SwitchLinc. That is why I much prefer and do use Access Points for coupling.

What are you using to couple the two 120v phases? If the SwitchLincs are expected to couple the two phases have the 4 tap set button test been run to confirm they are on opposite 120v phase. Appliances such as electric hot water heater, electric stove, electric dryer will couple intermittently. If the SwitchLincs are not on opposite phases you will not have reliable coupling which could explain why communication with the I/O Linc is intermittent.

If the I/O Linc Insteon address is 22.D3.80 the posted trace shows good communication between the I/O Linc and the PLM. Messages with Max Hops=3 have Hops Left=2 which is as good as it gets. Messages with Max Hops=1 have Hops Left=0 which is also as good as it gets. Of course things are working now. This also means the link records in the I/O Linc and PLM are not in question. The change in status at 3AM is the result of using Trigger Reverse. The Trigger Reverse option reverses the commands sent when the Sensor changes state. Sensor On sends an Off command, Sensor Off sends an On command. The Query issued at 3AM returns the true state of the Sensor not the command reversed state. The solution is to change the magnetic switch from NC to NO and turn Off Trigger Reverse. This has become an issue only since Smarthome stopped selling the garage kit with the combination NC/NO magnetic switch which allowed the user to select which switch produced the desired results. The trace shows inbound messages from the I/O Linc to the PLM are fine now.

Thanks for the trace data. The commands being issued by the KPL are correct. The trace shows a Start Manual Change (Down) followed by a Stop Manual Change. This was followed by a Start Manual Change (Up) and Stop Manual Change. Sun 07/14/2013 10:27:33 AM : [iNST-SRX ] 02 50 0E.26.EA 00.00.01 C7 17 00 LTMCON (DOWN) Sun 07/14/2013 10:27:33 AM : [standard-Group][0E.26.EA-->Group=1] Max Hops=3, Hops Left=1 Sun 07/14/2013 10:27:33 AM : [ E 26 EA 1] BMAN 0 Sun 07/14/2013 10:27:34 AM : [iNST-SRX ] 02 50 0E.26.EA 00.00.01 C7 18 00 LTMCOFF(00) Sun 07/14/2013 10:27:34 AM : [standard-Group][0E.26.EA-->Group=1] Max Hops=3, Hops Left=1 Sun 07/14/2013 10:27:34 AM : [ E 26 EA 1] SMAN 0 Sun 07/14/2013 10:27:34 AM : [ E 26 EA 1] ST 178 Sun 07/14/2013 10:27:34 AM : [ 14 CA B 1] ST 178 Sun 07/14/2013 10:27:38 AM : [iNST-SRX ] 02 50 0E.26.EA 00.00.01 C7 17 01 LTMCON (UP) Sun 07/14/2013 10:27:38 AM : [standard-Group][0E.26.EA-->Group=1] Max Hops=3, Hops Left=1 Sun 07/14/2013 10:27:38 AM : [ E 26 EA 1] BMAN 1 Sun 07/14/2013 10:27:39 AM : [iNST-SRX ] 02 50 0E.26.EA 00.00.01 C7 18 00 LTMCOFF(00) Sun 07/14/2013 10:27:39 AM : [standard-Group][0E.26.EA-->Group=1] Max Hops=3, Hops Left=1 What is different about a Dim/Bright sequence versus a normal On/Off message, there is no retry with the Dim/Bright sequence. A single message is sent on the powerline which can be recognized by multiple linked devices. No individual device can ACK the message because several devices could be reacting to the same Dim/Bright message. It is not possible for ACKs and retries with this sequence as the button Press/Hold/Release is very time sensitive. If Dim/Bright messages were ACKed and retried for each linked Responder the reaction of each Responder would be unpredictable. A simple On/Off message sequence is made up of several messages, one of which is sent specifically to every linked device. If the device does not respond to that message the Controller device retries several times. The net of it is a Dim/Bright message is a single attempt with no ACKs. An On/Off message sequence is made up of multiple messages which are retried if no ACK is received. I suspect the communication between the KPL location and the FanLinc location is not as reliable as it needs to be. On/Off works because there are ACKs and multiple retries. The single message associated with a Start Manual Change (Up/Down) is not reliable enough to get the FanLinc to react.