-
AuthorPosts
-
Anonymous
InactiveMay 9, 2009 at 7:06 amPost count: 35All of my insteon devices are setup to respond back to my EZServe/EZBridge and it works 100% reliably to my knowledge.
Every time I turn on a light or sprinkler my app gets notified and I voice log or whatever…just works.
Yet when I want to execute LstDevices at startup of my app to read initial state…it returns bad values. Stuff is marked on that isn’t and vice-versa.
This makes no sense as my own app when running can easily keep track of state and the EZServe is on 7×24…it should absolutely have 100% of all state for my devices.
What is going on?
LstDevices is contrary to what is returned from “Status Request” messages and this shouldn’t be the case.
I could swear it was working for past couple of days and all of a sudden is returning stale/bad values. It seems flaky…does v2 fix this stuff?
InactiveMay 9, 2009 at 8:13 amPost count: 35I was able to work around this by ignoring Status from this message and ONLY using it for device discovery purposes.
I instead issue StatusRequest to each device returned from LstDevices…but the only way this works is when I put a 100ms sleep in between the writes. This shouldn’t be required I believe as handshaking should take care of speed issues, no?
I haven’t tested with other sleep values…but is this expected? Is it documented?
I’m (ahem) pretty sure this isn’t a problem with my code as near equivalent code works rock solid for my caddx security panel.
Using Java I have setup the following fairly standard thread pattern:
Writer…this thread works off of a command queue and blocks until commands are received.
Reader…this thread reads/parses commands and puts them into message queue. It blocks on socket read until there is data.
Processor…this thread manages writer/reader and grabs available commands (blocking if none) from reader and notifies any listeners.InactiveMay 9, 2009 at 4:57 pmPost count: 1001I 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 FFInactiveMay 9, 2009 at 9:39 pmPost count: 35ok…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.
thx again.
-
AuthorPosts
- You must be logged in to reply to this topic.