Reply To: Why is LstDevices flaky? 2017-12-21T17:40:08+00:00

HOME Forums Gateways EZSrve Why is LstDevices flaky? Reply To: Why is LstDevices flaky?

Anonymous
Post count: 1001

I think an important factor to keep in mind is Insteon is half duplex communication. I don’t know for sure but I would doubt that SmartLabs (owner of the Insteon architecture) has published absolute values for the maximum time it can take for a given command to be sent by a controller, received by the responder, the responder send an answer back to the controller and the controller pass it back to the application. Commands can be retried, commands can time out, how far is the responder device from the controller device, is the device on the same circuit, the same or opposite 120v leg, and so on. EZSrve is not a powerline manager, queuing up requests and sending them to the powerline when it thinks the previous interaction is complete and the powerline is free to accept the next sequence. Ultimately it is the responsibility of the application to decide how critical each operation is and build in the robustness to achieve the objective.

I doubt the 100ms sleep will cover all the exceptions that could happen to any given command. Then one decides if the general results are satisfactory. Is adding a longer sleep time worth the extra time it takes to deal with the exceptions? Do the exceptions occur enough to be a factor. Each application developer has to decide such things. The one thing that is absolute, Insteon is not 100% and never will be. After all, they are signals that are riding on an electrical signal. Compared to X10, Insteon is very reliable. There is command redundancy and command retry built into the Group command protocol. For controlling house lighting it is more than adequate to the task. From a programmer’s perspective, it is a different matter. It is anything but absolute and presents a challenge to any application that is trying to present it as such.

EDIT: the following is a trace at the PLM level for a Status command. There would be more time involved when considering the send and receiving of the associated xml.

2009-05-09 16:29:01.622 TX 02 62 04 56 50 0F 19 00
2009-05-09 16:29:01.638 RX SENTINSTEON=0F 44 DC 04 56 50 0F 19 00 06
2009-05-09 16:29:01.950 RX RECEIVEINSTEONRAW=04 56 50 0F 44 DC 2B 00 FF