Jump to content

Responding


C Martin

Recommended Posts

In Insteon when a Controller other than the PLM turns a device On/Off as a Responder the ISY has no direct information that the Responder actually reacted. The ISY normally assumes it did based on the Scene definition and marks the Responder accordingly but once the Responder has been marked as not Responding the ISY needs a positive indication the device is working.

Link to comment
In Insteon when a Controller other than the PLM turns a device On/Off as a Responder the ISY has no direct information that the Responder actually reacted. The ISY normally assumes it did based on the Scene definition and marks the Responder accordingly but once the Responder has been marked as not Responding the ISY needs a positive indication the device is working.

 

 

So I can assume the converse is also the case.

 

In other words, if a switch that ISY had previously recognized as responding (no red exclamation point next to it) fails to respond to a scene command generated by another switch, ISY will assume it did respond.

Link to comment

"if a switch that ISY had previously recognized as responding (no red exclamation point next to it) fails to respond to a scene command generated by another switch, ISY will assume it did respond."

 

Yes. The Responder normally sends an ACK but only back to the Controller device (different when PLM is Controller of Scene). The Controller device would know that all the retries were unsuccessful (some devices blink when a responder fails to ACK) but none of that information is passed on to the PLM. The Insteon protocol makes no allowance for notifying other Responders (the PLM is a Responder to the Scene) that one of the Scene Responders failed to ACK. The ISY sees the Controller turn On/Off, that it is a Controller of Scene xxxx so the ISY marks the Scene xxxx Responders as though the Scene was successful.

Link to comment

And reading through this, it's a control from the ISY itself making the change not the device actually sending data AGAIN after the last time the ISY marked it as responding or not responding.

 

I would expect this to work that ANYTIME the device put's a result or causes a control event, that it would be marked as responding on the ISY, and when it gets a timeout and no ack (tosses the device not commincating error) then it marks it as non-responding.

 

I would envision using this in a program to watch a flaky device, and be able to get a notification or retry anytime it timed out on an event it was requested to do.

 

Alan

Link to comment
And reading through this, it's a control from the ISY itself making the change not the device actually sending data AGAIN after the last time the ISY marked it as responding or not responding.

 

I would expect this to work that ANYTIME the device put's a result or causes a control event, that it would be marked as responding on the ISY, and when it gets a timeout and no ack (tosses the device not commincating error) then it marks it as non-responding.

 

I would envision using this in a program to watch a flaky device, and be able to get a notification or retry anytime it timed out on an event it was requested to do.

 

Alan

 

It would have to be an ACK that the PLM is looking for. I don't think a failed ACK from a device when the PLM wasn't the controller will trigger ISY to update the responder/non-responder status.

Link to comment

I would be very surprised if any of this would be useful with motion sensors. Motion sensors cannot be responders. Motion sensors do not acknowledge anything. Based on what I have read here, it does not appear the ISY/PLM has any way of detecting a motion sensor being non-responsive.

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...