ok…still getting my feet wet.
After reading the Insteon Developer’s Guide (btw…I got all insteon docs for FREE from insteon rep…they’re quite nice folks!) I started getting a little confused regarding “who” was ultimately responsible for reliability and after several weeks of coding I do believe it is ME and not insteon protocol itself.
I believe you are wrong in stating “Insteon is not 100%” as it is the devices which need to have more memory for buffering/blocking. PowerLine communications can be reliable if CRCs and retries are employed…no?
When reading docs it mentions retries (until hops are 0) but I don’t see a means myself to determine this synchronously on sending (as with caddx nx8e security panel) so you could end up doing some fairly complex code gymnastics when several layers are each trying to provide reliable messaging.
This is only troubling when it comes to deployment of Insteon motion detectors. Here I will be expecting (or wanting) reliability equivalent to a security system…but it sounds like this may not be possible.
Given I will need some form of sleep between sends I guess I will add this to my Writer thread and have it only process cmds for writing when there’s been some form of delay between last write/send.
I only have 4 insteon lights, Ezrain, controller and ezsrve in my house…am about to add another 8 light switches and probably 4 motions when avail…I’ll prob’ have to tune again when this occurs. I could easily see more devices changing code timing/characteristics.
I am already at level of having full send/event support and am getting down into deeper insteon configuration (links setup, etc.) so this s/be helpful knowledge-wise on protocol specs.