larryllix Posted September 30, 2014 Posted September 30, 2014 Attempting to reduce some of the background Insteon traffic congestion I set up a test program and used an Insteon MS for a trigger. I found my test lamp turning On-Off-On-Off with each test wave of my hand in front of the MS so figuring the MS needed another factory reset or another one has gone defective I switched to a Remote KeyPad and the multiple trigger problem stopped. Now I brought another MS into the equation to determine if I had a bad MS. The second MS did the same thing On-Off and then repeat. Next I set the retries, in the PLM Communications settings, to 0. Now I get only one test light On-Off as one would expect. I have recorded the traffic in the events(3) logger and saved it for analysis here. I can read some of it but something strikes me as wrong here and I don't have enough decoding skills to understand what it is so would appreciate somebody having a look. - why am I getting two MS On commands and about 2 seconds apart. - does this mean the communications back to the ISY are bad so that it cannot ACK, but I am getting the trigger activating my test program and output responses??? - Are these Insteon MS units displaying bad engineering or defects? I didn't test any of my other two units yet. - Does this seem right? or is there something else going on? Thanks. ISY-Events-Log.v4.2.15_retries=2.txt ISY-Events-Log.v4.2.15__Retries=0.txt
LeeG Posted September 30, 2014 Posted September 30, 2014 (edited) Normal device Insteon Scene traffic starts with of a Group Broadcast message (in Red) that all linked responders normally see and react to. This message has no responder Insteon address (as there could be many responders) so no responder can ACK this message. Knowing this message is not ACKed a device then sends a Group Cleanup Direct message (in Blue) to each responder, one at a time. This message is ACKed so if an ACK is not received it is repeated a few times expecting an ACK on one of the retries. Normally the ISY ignores the Group Cleanup Direct messages. In this case the Program that is triggered by the initial Group Broadcast immediately puts Insteon traffic on the network so the Group Cleanup Direct message is received very late. In an Insteon Scene world this would normally mean the Group Broadcast was not received so the Group Cleanup Direct takes its place (as is designed by SmartLabs) and triggers the Program. Normal solution is to Wait 1 or 2 seconds in the Program before sending Insteon traffic. In the latest I2CS world devices can be told how many retries to perform. Setting the retry count to 0 suppresses all the Group Cleanup Direct messages so a second Program trigger is prevented because there is no Group Cleanup Direct message. Only I2CS devices have this control over retries. Tue 09/30/2014 04:21:45 PM : [iNST-SRX ] 02 50 28.40.E7 00.00.01 C7 11 01 LTONRR (01) Tue 09/30/2014 04:21:45 PM : [Std-Group ] 28.40.E7-->Group=1, Max Hops=3, Hops Left=1 Tue 09/30/2014 04:21:45 PM : [D2D EVENT ] Event [28 40 E7 1] [DON] [1] uom=0 prec=-1 Tue 09/30/2014 04:21:45 PM : [ 28 40 E7 1] DON 1 Tue 09/30/2014 04:21:45 PM : [D2D-CMP 0080] CTL [28 40 E7 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Tue 09/30/2014 04:21:45 PM : [D2D-CMP 007D] CTL [28 40 E7 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Tue 09/30/2014 04:21:45 PM : [D2D-CMP 006E] CTL [28 40 E7 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Tue 09/30/2014 04:21:45 PM : [D2D-CMP 009D] CTL [28 40 E7 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Tue 09/30/2014 04:21:45 PM : [D2D-CMP 0009] CTL [28 40 E7 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Tue 09/30/2014 04:21:46 PM : [iNST-TX-I1 ] 02 62 26 D2 CE 0F 12 00 Tue 09/30/2014 04:21:46 PM : [iNST-TX-I1 ] 02 62 00 00 12 CF 11 00 Tue 09/30/2014 04:21:46 PM : [ Time] 16:22:02 0(0) Tue 09/30/2014 04:21:46 PM : [iNST-ACK ] 02 62 26.D2.CE 0F 12 00 06 LTON-F (00) Tue 09/30/2014 04:21:46 PM : [ Time] 16:22:02 0(0) Tue 09/30/2014 04:21:46 PM : [ Time] 16:22:02 0(0) Tue 09/30/2014 04:21:46 PM : [ Time] 16:22:02 0(0) Tue 09/30/2014 04:21:46 PM : [ Time] 16:22:02 0(0) Tue 09/30/2014 04:21:46 PM : [ Time] 16:22:02 0(0) Tue 09/30/2014 04:21:46 PM : [ Time] 16:22:02 0(0) Tue 09/30/2014 04:21:46 PM : [iNST-SRX ] 02 50 26.D2.CE 2A.1C.95 23 12 00 LTON-F (00) Tue 09/30/2014 04:21:46 PM : [std-Direct Ack] 26.D2.CE-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Tue 09/30/2014 04:21:46 PM : [iNST-ACK ] 02 62 00.00.12 CF 11 00 06 LTONRR (00) Tue 09/30/2014 04:21:47 PM : [iNST-TX-I1 ] 02 62 26 D2 CE 0F 14 00 Tue 09/30/2014 04:21:47 PM : [D2D EVENT ] Event [26 D2 CE 1] [sT] [255] uom=0 prec=-1 Tue 09/30/2014 04:21:47 PM : [ 26 D2 CE 1] ST 255 Tue 09/30/2014 04:21:47 PM : [iNST-SRX ] 02 50 28.40.E7 2A.1C.95 41 11 01 LTONRR (01) Tue 09/30/2014 04:21:47 PM : [Std-Cleanup ] 28.40.E7-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Tue 09/30/2014 04:21:47 PM : [iNST-ACK ] 02 62 26.D2.CE 0F 14 00 06 LTOFF-F(00) Tue 09/30/2014 04:21:47 PM : [D2D EVENT ] Event [28 40 E7 1] [DON] [0] uom=0 prec=-1 Tue 09/30/2014 04:21:47 PM : [ 28 40 E7 1] DON 0 Tue 09/30/2014 04:21:47 PM : [D2D-CMP 0080] CTL [28 40 E7 1] DON op=1 Event(val=0 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Tue 09/30/2014 04:21:47 PM : [D2D-CMP 007D] CTL [28 40 E7 1] DON op=1 Event(val=0 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Tue 09/30/2014 04:21:47 PM : [D2D-CMP 006E] CTL [28 40 E7 1] DON op=1 Event(val=0 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Tue 09/30/2014 04:21:47 PM : [D2D-CMP 009D] CTL [28 40 E7 1] DON op=1 Event(val=0 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Tue 09/30/2014 04:21:47 PM : [D2D-CMP 0009] CTL [28 40 E7 1] DON op=1 Event(val=0 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Edited September 30, 2014 by LeeG
larryllix Posted October 1, 2014 Author Posted October 1, 2014 Thank you LeeG! If I understand this correctly, every Insteon device I have will send two complete sets of status updates unless: - I install one or more scene links in each device to cause another device to ACK the message. or - I set Retries=0 for each possible status that can transmit updates. If this is the case why would the PLM not ACK any message that is received by it as a responder? This sounds like a good way to bog down Insteon communications.
LeeG Posted October 1, 2014 Posted October 1, 2014 (edited) Sorry, I do not understand the two conditions. Every Insteon device sending an On/Off command sends a Group Broadcast message and a Group Cleanup Direct message. Insteon has worked this way from the beginning 2005. The Group Cleanup Direct message is normally ignored. Wed 10/01/2014 10:48:13 AM : [iNST-SRX ] 02 50 1C.FD.D5 00.00.01 CB 13 00 LTOFFRR(00) Wed 10/01/2014 10:48:13 AM : [std-Group ] 1C.FD.D5-->Group=1, Max Hops=3, Hops Left=2 Wed 10/01/2014 10:48:13 AM : [D2D EVENT ] Event [1C FD D5 1] [DOF] [0] uom=0 prec=-1 Wed 10/01/2014 10:48:13 AM : [ 1C FD D5 1] DOF 0 Wed 10/01/2014 10:48:13 AM : [D2D EVENT ] Event [1C FD D5 1] [sT] [0] uom=0 prec=-1 Wed 10/01/2014 10:48:13 AM : [ 1C FD D5 1] ST 0 Wed 10/01/2014 10:48:13 AM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 41 13 01 LTOFFRR(01) Wed 10/01/2014 10:48:13 AM : [std-Cleanup ] 1C.FD.D5-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Wed 10/01/2014 10:48:13 AM : [iNST-DUP ] Previous message ignored. Wed 10/01/2014 10:48:13 AM : [iNST-SRX ] 02 50 1C.FD.D5 13.01.01 CB 06 00 (00) Wed 10/01/2014 10:48:13 AM : [std-Group ] 1C.FD.D5-->13.01.01, Max Hops=3, Hops Left=2 Wed 10/01/2014 10:48:13 AM : [iNST-INFO ] Previous message ignored. The Group Cleanup Direct was not ignored in your situation because a Fast On, Scene On and Fast Off were issued by the Program delaying the Group Cleanup Message to the point where it looks like another On scenario. For I2CS devices the retry count can be set. This is for the IO Linc I used in my trace. I think rather than adding a Wait or changing the retry count your Program could be split into two sections. The first Then invokes Program 2 which does a Disable of Program 1 so the command activity generated by Program 2 will not allow the delayed Group Cleanup Direct from triggering Program 1. Edited October 1, 2014 by LeeG
larryllix Posted October 1, 2014 Author Posted October 1, 2014 Sorry, I do not understand the two conditions. Every Insteon device sending an On/Off command sends a Group Broadcast message and a Group Cleanup Direct message. Insteon has worked this way from the beginning 2005. The Group Cleanup Direct message is normally ignored. Wed 10/01/2014 10:48:13 AM : [iNST-SRX ] 02 50 1C.FD.D5 00.00.01 CB 13 00 LTOFFRR(00) Wed 10/01/2014 10:48:13 AM : [std-Group ] 1C.FD.D5-->Group=1, Max Hops=3, Hops Left=2 Wed 10/01/2014 10:48:13 AM : [D2D EVENT ] Event [1C FD D5 1] [DOF] [0] uom=0 prec=-1 Wed 10/01/2014 10:48:13 AM : [ 1C FD D5 1] DOF 0 Wed 10/01/2014 10:48:13 AM : [D2D EVENT ] Event [1C FD D5 1] [sT] [0] uom=0 prec=-1 Wed 10/01/2014 10:48:13 AM : [ 1C FD D5 1] ST 0 Wed 10/01/2014 10:48:13 AM : [iNST-SRX ] 02 50 1C.FD.D5 22.80.0B 41 13 01 LTOFFRR(01) Wed 10/01/2014 10:48:13 AM : [std-Cleanup ] 1C.FD.D5-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Wed 10/01/2014 10:48:13 AM : [iNST-DUP ] Previous message ignored. Wed 10/01/2014 10:48:13 AM : [iNST-SRX ] 02 50 1C.FD.D5 13.01.01 CB 06 00 (00) Wed 10/01/2014 10:48:13 AM : [std-Group ] 1C.FD.D5-->13.01.01, Max Hops=3, Hops Left=2 Wed 10/01/2014 10:48:13 AM : [iNST-INFO ] Previous message ignored. The Group Cleanup Direct was not ignored in your situation because a Fast On, Scene On and Fast Off were issued by the Program delaying the Group Cleanup Message to the point where it looks like another On scenario. For I2CS devices the retry count can be set. This is for the IO Linc I used in my trace. I think rather than adding a Wait or changing the retry count your Program could be split into two sections. The first Then invokes Program 2 which does a Disable of Program 1 so the command activity generated by Program 2 will not allow the delayed Group Cleanup Direct from triggering Program 1. This was only a test program to understand Insteon congestion vs ISY program decision speed. Normally an Off would not be sent this fast and the On-Off-On-Off sequence would not be seen. My question was about methods to eliminate some of this Insteon traffic for events like MS to lights that don't need to be that secure. The extra transmission ever time 2 seconds later seems like a waste of bandwidth and I have events that take up to 20 seconds to respond at times. That's annoying when a beeper is alerting me to perform a certain device Off scene and it takes that long or never seems to complete. It's real weird to trigger a SwitchLinc and have the first line of a program code function 20 or 30 seconds later. Now I do have an X10 beeper and I had several programs that are all trying to turn off that beeper simultaneously. In view of this delay I have tried a status check program to avoid multiple X10 Off signals but it occasionally thinks the beeper is already off and won't send the Off command. Sometimes the X10 beeper just won't turn off for some reason but it seems that X10 doesn't play well with Insteon on the PLM. It seems X10 transmissions can clobber Insteon and vice versa. I have since incorporated a 2 second delay after every X10 command and sequenced them to make allowances for the clash. This definitely helps things work more reliably. Rethinking some of this, with your inputs, my question is; will linking a MS with a device give an ACK to stop the retry of MS transmission and relieve some of the Insteon congestion?
LeeG Posted October 1, 2014 Posted October 1, 2014 Only PLM comm can have the retry count adjusted. A Scene link between a MS and Responder will always generate at least one Group Cleanup Direct message. If ACKed that would be the end of the Group Cleanup Direct messages. If not ACKed the Responder would receive another Group Cleanup Direct message. These are messages that have been used forever which makes me think they are not responsible for a 20 second delay in traffic.
larryllix Posted October 1, 2014 Author Posted October 1, 2014 (edited) Only PLM comm can have the retry count adjusted. A Scene link between a MS and Responder will always generate at least one Group Cleanup Direct message. If ACKed that would be the end of the Group Cleanup Direct messages. If not ACKed the Responder would receive another Group Cleanup Direct message. These are messages that have been used forever which makes me think they are not responsible for a 20 second delay in traffic. Does my Retries=0 file not show that the MS is not sending the commands more than once? I thought it hadn't resent the On and Cleanup a second time? http://forum.universal-devices.com/index.php?app=core&module=attach§ion=attach&attach_id=3558 Edited October 1, 2014 by larryllix
LeeG Posted October 1, 2014 Posted October 1, 2014 Setting the PLM retry count to 0 does suppress the Group Cleanup Direct traffic to the PLM. Your second trace shows no Group Cleanup Direct was sent to the PLM.
larryllix Posted October 1, 2014 Author Posted October 1, 2014 (edited) I tried setting Retries=0 and then I tried setting the MS sleep after detection for 0.5 minutes in order to stop multiple motion triggers with no detectable changes in events recorded for either setting. Next I recorded events with the MS linked to the Switchlinc in a direct link scene. Only one program trigger event happens using this method. It seems the MS sends a different pattern to the ISY in this case and only causes a single event trigger. I am surprised the PLM and the MS don't have a similar link to make the MS act the same as when linked to a Switchlinc. This could avoid a lot of ISY CPU time processing useless repeated signals. This also doesn't happen with the RemoteLinc keypads or X10 keypads. Note: Time lines were removed. Wed 10/01/2014 05:29:46 PM : [iNST-SRX ] 02 50 2D.67.81 00.00.01 C7 11 01 LTONRR (01) Wed 10/01/2014 05:29:46 PM : [std-Group ] 2D.67.81-->Group=1, Max Hops=3, Hops Left=1 Wed 10/01/2014 05:29:46 PM : [D2D EVENT ] Event [2D 67 81 1] [DON] [1] uom=0 prec=-1 Wed 10/01/2014 05:29:46 PM : [ 2D 67 81 1] DON 1 Wed 10/01/2014 05:29:46 PM : [D2D-CMP 0067] CTL [2D 67 81 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Wed 10/01/2014 05:29:46 PM : [D2D-CMP 006F] CTL [2D 67 81 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Wed 10/01/2014 05:29:46 PM : [D2D-CMP 0023] CTL [2D 67 81 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Wed 10/01/2014 05:29:46 PM : [D2D-CMP 007E] CTL [2D 67 81 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Wed 10/01/2014 05:29:46 PM : [D2D EVENT ] Event [29 C3 DB 1] [sT] [255] uom=0 prec=-1 Wed 10/01/2014 05:29:46 PM : [ 29 C3 DB 1] ST 255 Wed 10/01/2014 05:29:46 PM : [D2D EVENT ] Event [2D 67 81 1] [sT] [255] uom=0 prec=-1 Wed 10/01/2014 05:29:46 PM : [ 2D 67 81 1] ST 255 Wed 10/01/2014 05:29:47 PM : [iNST-SRX ] 02 50 2D.67.81 00.00.01 C7 11 01 LTONRR (01) Wed 10/01/2014 05:29:47 PM : [std-Group ] 2D.67.81-->Group=1, Max Hops=3, Hops Left=1 Wed 10/01/2014 05:29:47 PM : [iNST-DUP ] Previous message ignored. Wed 10/01/2014 05:29:48 PM : [iNST-SRX ] 02 50 2D.67.81 2A.1C.95 41 11 01 LTONRR (01) Wed 10/01/2014 05:29:48 PM : [std-Cleanup ] 2D.67.81-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Wed 10/01/2014 05:29:48 PM : [iNST-DUP ] Previous message ignored. Wed 10/01/2014 05:29:49 PM : [iNST-SRX ] 02 50 2D.67.81 11.02.01 C7 06 00 (00) Wed 10/01/2014 05:29:49 PM : [std-Group ] 2D.67.81-->11.02.01, Max Hops=3, Hops Left=1 Wed 10/01/2014 05:29:49 PM : [iNST-INFO ] Previous message ignored. Wed 10/01/2014 05:29:50 PM : [iNST-SRX ] 02 50 2D.67.81 11.02.01 C7 06 00 (00) Wed 10/01/2014 05:29:50 PM : [std-Group ] 2D.67.81-->11.02.01, Max Hops=3, Hops Left=1 Wed 10/01/2014 05:29:50 PM : [iNST-INFO ] Previous message ignored. Edited October 1, 2014 by larryllix
LeeG Posted October 2, 2014 Posted October 2, 2014 "no detectable changes in events recorded for either setting." Check the Motion Sensor link table for a FF 00 01. My MS stops sending Group Cleanup Direct with retry=0
Recommended Posts