From: Marc M. <ma...@me...> - 2009-05-08 02:45:02
|
I was looking at http://misterhouse.wikispaces.com/Insteon, and it says "automatic retries (in the event that the Insteon peer retry fails)" I don't think this means what I wrote in the subject line, but that made me think that it could mean that. If the PLM can be configured to pass ACKs that aren't for it, up to mh, mh should see switch1 tell lamp1 to turn on (it already sees that and logs it), and then it could see if lamp1 acks switch1. If that ack is not received, it could then poll lamp1 for its status and resend it the message it was supposed to get, possibly with a higher retry count and/or more interval between the retries. The reason I'm thinking about this is that despite having tried to make my home network as clean as possible, I still have occasional messages that get dropped. When they come from the PLM, that's fine since the PLM will retry enough (in number of times and clock time) that the message will get there, but from KPL to KPL, it sometimes looks like they maybe retry once and give up, or at least their retries are not as reliable as the ones coming from the PLM. If the PLM could log those KPL to KPL acks, it could then resend the commands that didn't get acked. For now, I have code that listens to state toggles and have the PLM resend them 1 second later, no matter what, but this scheme has flaws: - not happy with quick device on/off toggles - creates additional traffic that usually wasn't necessary - I can't request_status before sending the maybe lost command, because that would generate traffic too. What do you think? Doable? Crackpot idea? other? Thanks, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: <w20...@wo...> - 2009-05-08 03:15:46
|
Marc MERLIN wrote: > I was looking at http://misterhouse.wikispaces.com/Insteon, and it says > "automatic retries (in the event that the Insteon peer retry fails)" > > I don't think this means what I wrote in the subject line, but that made me > think that it could mean that. > > If the PLM can be configured to pass ACKs that aren't for it, up to mh, mh > My understanding is that the PLM will only report (via the serial interface) either DIRECT messages to it, or other messages with from ids that are in it's link table and for which it is marked a responder. |
From: Marc M. <ma...@me...> - 2009-05-08 03:25:12
|
On Thu, May 07, 2009 at 10:15:08PM -0500, w20...@wo... wrote: > Marc MERLIN wrote: > > I was looking at http://misterhouse.wikispaces.com/Insteon, and it says > > "automatic retries (in the event that the Insteon peer retry fails)" > > > > I don't think this means what I wrote in the subject line, but that made me > > think that it could mean that. > > > > If the PLM can be configured to pass ACKs that aren't for it, up to mh, mh > > My understanding is that the PLM will only report (via the serial > interface) either DIRECT messages to it, or other messages with from ids > that are in it's link table and for which it is marked a responder. Right, that's definitely what it does by default. I was hoping it might have some kind of promiscuous mode so that it could see other traffic. But eh, this might just be wishful thinking too :-/ Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Gregg L. <gr...@li...> - 2009-05-08 03:37:50
|
Marc MERLIN wrote: > On Thu, May 07, 2009 at 10:15:08PM -0500, w20...@wo... wrote: >> Marc MERLIN wrote: >>> I was looking at http://misterhouse.wikispaces.com/Insteon, and it says >>> "automatic retries (in the event that the Insteon peer retry fails)" >>> >>> I don't think this means what I wrote in the subject line, but that made me >>> think that it could mean that. >>> >>> If the PLM can be configured to pass ACKs that aren't for it, up to mh, mh >> My understanding is that the PLM will only report (via the serial >> interface) either DIRECT messages to it, or other messages with from ids >> that are in it's link table and for which it is marked a responder. > > Right, that's definitely what it does by default. I was hoping it might have > some kind of promiscuous mode so that it could see other traffic. > > But eh, this might just be wishful thinking too :-/ It has that mode. Someone else would need to completely rewrite the insteon libs to take advantage. I have no desire to walk down that trail. Gregg |
From: <w20...@wo...> - 2009-05-08 03:35:57
|
Marc MERLIN wrote: > I was looking at http://misterhouse.wikispaces.com/Insteon, and it says > "automatic retries (in the event that the Insteon peer retry fails)" > > I don't think this means what I wrote in the subject line, but that made me > think that it could mean that. > > If the PLM can be configured to pass ACKs that aren't for it, up to mh, mh > should see switch1 tell lamp1 to turn on (it already sees that and logs it), > and then it could see if lamp1 acks switch1. > If that ack is not received, it could then poll lamp1 for its status and > resend it the message it was supposed to get, possibly with a higher retry > count and/or more interval between the retries. > > The reason I'm thinking about this is that despite having tried to make my > home network as clean as possible, I still have occasional messages that get > dropped. > When they come from the PLM, that's fine since the PLM will retry enough (in > number of times and clock time) that the message will get there, but from > KPL to KPL, it sometimes looks like they maybe retry once and give up, or at > least their retries are not as reliable as the ones coming from the PLM. > If the PLM could log those KPL to KPL acks, it could then resend the > commands that didn't get acked. > > Well, I'm not sure I've seen this behavior in practice, but the dev guide says transmitters will first transmit with max hops set to 1 (or was it zero) and then increase and re-transmit if they don't see an ACK. If the devices do manage to communicate with a low max hops count, the PLM might never see the traffic at all if the two devices are "far enough away". (It seems to me from what I've seen that the all-link message is always sent with max hops of 3, then the individual device cleanups use the increasing max hops formula.) Of course, with the PLM in the "scene", it should get the group and cleanup messages, so it could go after and check up on the devices, since MH knows the link tables anyway. I have no idea if it already does or not, mind you. >> My understanding is that the PLM will only report (via the serial >> interface) either DIRECT messages to it, or other messages with from ids >> that are in it's link table and for which it is marked a responder. >> > Right, that's definitely what it does by default. I was hoping it might have > some kind of promiscuous mode so that it could see other traffic. > > But eh, this might just be wishful thinking too :-/ > Even if the PLM has a device address in it's link table and is set as a responder, it doesn't seem to send the ACK/cleanup messages thru the PLM to MH because the TO address does not match, /and the security feature of the PLM says it should therefore never allow that/. Yup, that's a feature. And although I've seen some tricks for "figuring out" information about other devices on the network without knowing their address, I don't believe there is /any/ sort of promiscuous mode possible without re-writing the internal software -- and maybe not even with that depending on the hardware setup (I may be thinking of the PLC when thinking there was a possibility of re-written software allowing it). |