LeeG Posted May 21, 2011 Share Posted May 21, 2011 eximer168 Okay, I think I understand the question. Why did the ISY annotate that particular Group Cleanup Direct message with DOF 3 and did not annotate the Group Cleanup Direct messages before that one. I don't know what drives the ISY to log that message at that point when it did not for the other Group Cleanup Direct messages. I don't see any error condition that would explain the difference but I will lay out that trace in detail to see if I can determine why. What is the Insteon address of the IO Linc for the cat-feeder? Lee Link to comment
LeeG Posted May 21, 2011 Share Posted May 21, 2011 eximer168 I do not know why the ISY chooses to annotate some Group Cleanup Direct messages and not others. The Group Cleanup Direct messages that are annotated look the same as those that are not. I see the same situation on my system. I was able to screen capture one of the popups (banners). It is an outbound Fast Off command which would not normally be written anywhere. Perhaps something to do with the Beta but that is only a guess. Assuming the IO Linc address is 15.E5.18, the outbound command to turn the relay On was issued Fri 05/20/2011 11:45:01 AM : [iNST-ACK ] 02 62 15.E5.18 0F 11 02 06 LTONRR (02) with no ACK being received from IO Linc. Since the relay did not turn On I have to conclude the command did not make it to the IO Linc. Lee Link to comment
Michel Kohanim Posted May 22, 2011 Share Posted May 22, 2011 Hi LeeG, Perhaps I can shed some light here: Group cleanups are handled in the same way as an SRX; i.e. if send a group command through ISY (scene test), then there are four cases: 1. SRX was received so the device acked the command with no group clean up 2. SRX was received with group cleanup 3. SRX was not received but got a group clean up 4. SRX was not received and group clean up was not received The main thing to remember is that ISY does not use group commands to activate scenes so group cleanups should only be seen during Scene Test. With kind regards, Michel Link to comment
LeeG Posted May 22, 2011 Share Posted May 22, 2011 Thanks Michel The scenario being used and traced is a RemoteLinc button 3 Off press which sends Group Broadcast messages and a Group Cleanup message to the ISY PLM. Standard Group protocol sequence which is not in question. What the OP is looking at (I can recreate on my system) and considered a failure by the OP (which it is not) is sometimes the Event Trace has an additional DOF 3 entry in the trace following the Group Cleanup Direct message. Most of the time the DOF 3 message does not appear in the event log after the Group Cleanup Direct message .The Group Cleanup Direct messages themselves are valid and expected, just have not been able to determine why the additional DOF 3 message appears in the trace at times. It is going to be one of those embarrassing cannot see the forest for the trees once I figure it out. In the following Event Trace there is a RemoteLinc button 3 Off press with the expected Group Broadcast messages and a Group Cleanup message, all as expected. At the end of the sequence there is no DOF 3 message in the trace after the Group Cleanup Direct message. This is the case most of the time. If the RemoteLinc button 3 Off is pressed multiple times close together, sometimes the Event Trace contains a DOF 3 message added after a Group Cleanup Direct message. Sun 05/22/2011 04:12:24 PM : [iNST-SRX ] 02 50 11.AD.CF 12.9F.E4 41 13 03 LTOFFRR(03) Sun 05/22/2011 04:12:24 PM : [standard-Cleanup][11.AD.CF-->ISY/PLM Group=3] Max Hops=1, Hops Left=0 Sun 05/22/2011 04:12:24 PM : [iNST-ACK ] 02 62 0D.4B.82 0F 14 00 06 LTOFF-F(00) Sun 05/22/2011 04:12:25 PM : [iNST-SRX ] 02 50 0D.4B.82 12.9F.E4 2B 14 00 LTOFF-F(00) Sun 05/22/2011 04:12:25 PM : [standard-Direct Ack][0D.4B.82-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sun 05/22/2011 04:12:25 PM : [iNST-ACK ] 02 62 12.A9.F9 0F 14 00 06 LTOFF-F(00) Sun 05/22/2011 04:12:25 PM : [iNST-SRX ] 02 50 12.A9.F9 12.9F.E4 2B 14 00 LTOFF-F(00) Sun 05/22/2011 04:12:25 PM : [standard-Direct Ack][12.A9.F9-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sun 05/22/2011 04:12:25 PM : [iNST-ACK ] 02 62 12.B4.E1 0F 14 00 06 LTOFF-F(00) Sun 05/22/2011 04:12:26 PM : [iNST-SRX ] 02 50 12.B4.E1 12.9F.E4 2B 14 00 LTOFF-F(00) After the following Group Cleanup Direct message from the RemoteLinc there is an additional trace entry “DOF 3â€. Sun 05/22/2011 04:13:15 PM : [iNST-SRX ] 02 50 11.AD.CF 12.9F.E4 47 13 03 LTOFFRR(03) Sun 05/22/2011 04:13:15 PM : [standard-Cleanup][11.AD.CF-->ISY/PLM Group=3] Max Hops=3, Hops Left=1 Sun 05/22/2011 04:13:15 PM : [ 11 AD CF 1] DOF 3 Lee Link to comment
Michel Kohanim Posted May 23, 2011 Share Posted May 23, 2011 Hello LeeG, Thanks so very much ... I am not sure what is causing this issue either. It might have something to do with duplicate RF messages and perhaps we are not ignoring an echo as we should. I cannot reproduce; so, in your case, do you have to press an RL button multiple times before you see the erroneous DOF? Does the same thing happen with DON? With kind regards, Michel Link to comment
LeeG Posted May 23, 2011 Share Posted May 23, 2011 Michel It does the same thing with the On button. It is timing related, how quickly the button presses are done rather than the number of times pressed. I'll go through the trace again later today with fresh eyes. I’m sure this is not a functional issue with the ISY, simply an information message question. Lee Link to comment
Michel Kohanim Posted May 24, 2011 Share Posted May 24, 2011 Hi LeeG, Thanks so very much ... I do appreciate it very much. With kind regards, Michel Link to comment
Illusion Posted June 18, 2011 Author Share Posted June 18, 2011 It has been 3 months since I made the problem switch a controller of a test scene with a spare switch in it as the responder. The switch has not ghosted on since then. I have removed the spare switch from the system and the scene. I am interested if just making this switch a controller of a scene with no responders other than the PLM will also prevent the ghosting on phenomenon. I am assuming it will be the same as having another switch in there. As I understand it, the scenes we see in the ISY has the ISY as a responder to the scene, just like all the devices in said scene, right? So creating a scene with just this problem switch in it should be the same as having a responder switch in the scene as well? Link to comment
TJF1960 Posted June 19, 2011 Share Posted June 19, 2011 Hi Illusion, Thanks for keeping us updated. It will be interesting to see if the switch starts to ghost on now. Any bets? Tim Link to comment
Illusion Posted September 17, 2011 Author Share Posted September 17, 2011 3 more months. No ghosting on with just the switch in a scene as a controller with no responders. (Other than the PLM I which I assume is considered a responder, even though we do not see it) This brings me to another question. Even without this controller in a scene there is still a link to the PLM right? I am going to now remove the scene from the ISY. So I am going back to the condition that existed when this problem first manifested itself. How is having this device as a controller of a scene with no other devices any different than not having the controller in a scene? In both cases the device has a link to the PLM that does not show up in the GUI, right? When I first add a new device to the ISY a link is setup. If I do nothing else with this device, isn't that the same thing as adding the device as a controller of a scene with nothing else in it? In both cases the device has "scene" links to the PLM that the ISY does not show. Am I understanding this correctly? Link to comment
LeeG Posted September 17, 2011 Share Posted September 17, 2011 When the SwitchLinc was originally added to the ISY two link records were added to the SwitchLinc, a Controller and a Responder link record. The PLM also receives a Controller and Responder link record. The Controller record in the SwitchLinc and corresponding Responder record in the PLM are necessary for the ISY/PLM to receive a message when the SwitchLinc paddle is pressed. This is independent of any Scenes the SwitchLinc may eventually be associated with. The Controller record in the PLM and corresponding Responder record in the SwitchLinc allows the SwitchLinc to react to the All On/All Off commands directed to My Lighting. When the SwitchLinc is added to a Scene as a Controller the ISY writes a Responder link record in the SwitchLinc for the specific Scene/Group number. The SwitchLinc is assumed to be a Responder as well as a Controller. The responder link record is necessary for the SwitchLinc to respond to Scene On/Off commands directed to the Scene name. What all of this has to do with the results you have observed I do not know. Link to comment
Recommended Posts