Author |
|
jeffw_00 Super User
Joined: June 30 2007
Online Status: Offline Posts: 929
|
Posted: September 21 2021 at 19:15 | IP Logged
|
|
|
see below
Edited by jeffw_00 - September 22 2021 at 10:57
|
Back to Top |
|
|
jeffw_00 Super User
Joined: June 30 2007
Online Status: Offline Posts: 929
|
Posted: September 22 2021 at 07:11 | IP Logged
|
|
|
see below
Edited by jeffw_00 - September 22 2021 at 10:57
|
Back to Top |
|
|
jeffw_00 Super User
Joined: June 30 2007
Online Status: Offline Posts: 929
|
Posted: September 22 2021 at 10:29 | IP Logged
|
|
|
So I have an IOLInc tied to my garage door sensors. When the
door goes up it triggers other Insteon traffic. As a result, if the
garage door goes back down too quickly, the messages from the
IOLINC to the PLM sometimes get lost. I see that the IOLINC
sends only 2 "on" or "off" followed by one Group Success/Fail. Not
a lot of messages, and so seems like they can be stomped on.
I think the problem is that, for this IOLINC, I see the Controller link
has Ctlr & Resp Link status as VERIFIED, but for Responder, the
Ctrlr Link Is VERIFIED, and the Resp. Link is "FLAGGED
CREATE".
This is a recent IO Linc (rev 2.7),with I2CS engine selection.
: I looked at the stats and I have 1 NAK but 89 ACKs, and it's
happened more than once.
I found this thread which appears on point
http://www.myx10.com/forum/forum_posts.asp?TID=10755
But "clear failed" is not colored for the IOLinc. PLM seems happy
with its communication, but I'm not getting the ACK/NAK and two
way communication of the group cleanup command. I have been
able to hard-reset the module, rebuild the links via PH successfully
several times (apparently), but to no avail.
QUESTION: How do I build/rebuild the links in the IOLINC to get
the 2-way communication going (and VERIFIED Link status?)
I tried a rebuild while the IOLINC was in link mode (longshot)- didn't
work. I've tried more than one IOLINC with the same results, I
can't figure out how to get the responder link to VERIFIED :-(
Thanks!
/j
Edited by jeffw_00 - September 22 2021 at 15:26
|
Back to Top |
|
|
dhoward Admin Group
Joined: June 29 2001 Location: United States
Online Status: Offline Posts: 4447
|
Posted: September 22 2021 at 23:00 | IP Logged
|
|
|
Jeff,
When an Insteon device sends a message (the IOLinc input sensor is triggered, a switchlinc is manually turned on/off, etc), the device will send a
group broadcast message. This is not to a specific address and is a global message that goes to all units with the originating device address and group
number. Each device that hears the group broadcast message will search it's database and if it has a match for that device and group #, will then
perform the settings that were setup in the link. The group broadcast is NOT acknowledged or retried since it's a global message. It is usually sent
more than once but that is dependent upon the device itself (most battery operated devices seem to send the group broadcast at least 3 times).
After the group broadcast is sent, the device will then send group cleanup messages (in the order that the responder devices appear in its database).
These are direct messages to each device and would be acknowledged and retried if necessary. However...(and this is a big however), if another Insteon
device (including the PLM) sends an Insteon message, the group cleanup commands are terminated. So it you have alot of traffic, it is possible that NO
group cleanup commands will be sent. If the traffic is moderate, you might get 1 or 2 group cleanups (this is why the order in the database is
important with lower record numbers being sent first) before the cleanup is interrupted and halted.
Now you said the stats on your IOlinc were 89 ACKs and 1 NAK...this is actually very good. A NAK means that the message got through, but could not be
performed (for whatever reason). What you want to also look at are the timeouts. A timeout occurs when a command is sent and the sending device does
not receive a response before the timeout period (this is irrelevant for group broadcasts since these commands are not ACKed). If you have alot of
timeouts, then that is an indication of the message not getting through.
With that out of the way, you definitely want all of your links verified. Whenever a link is created (controller or responder), there are two halves
with one half stored in the device that is the controller and the other half stored in the device that is the responder. You can see which individual
pieces are store in each device but looking at the color coded columns on the Links tab. So a single link needs to be written to two different devices
in order to be complete. If you create a link in the "Controllers of Current device" window, then the "Ctlr Link Status" column is for the other device
that is controlling the current device. The "Resp Link Status" refers to the half of the link that is created in the current device. If links are
created in the "Responders of Current device" window, then these roles are reversed (you can easily tell by the color coding of the columns).
If you have links that are directly controlling other Insteon devices, you typically want them in the database first. If you primarily depend upon
PowerHome firing a trigger, then you typically want the PLM to be the first link.
For your IOLinc, you either want to send to the PLM or another Insteon device when your IOLinc has the sensor "switched. These would be links created
in the Responders of Current device. In this case, you want the Ctlr Rec # for this link to be 1 or as close to 1 as you can get. You can control this
by putting values in the "Ctlr Sort" column and rebuilding to force PowerHome to recreate the links in an order of your choosing.
When creating links, I typically prefer to work with the Current device acting as the controller (in your case the current device would be the IOLinc)
and creating the appropriate links in the Responders of Current Device window. If I need to create links where the IOLinc is the responder, I can do it
by using the Controllers of Current device window but I typically set the Controller (an Insteon device that is going to control the IOLinc) as the
Current device and then create the link with the IOLinc as the responder in the "Responders of Current device" window. You can do it whichever way
makes the most sense for you though because the links are all created the same and will show in the appropriate windows.
To rebuild your links (after you've got them configured the way you want). You need to make sure that all the devices being linked are arent flagged as
Failed (the ID will show as a red background on the Devices tab) AND you need to make sure that the Disabled column (a yellow background if it isnt
already COMM failed) isnt checked on the device in the Devices tab. Be sure and save your changes.
Once the devices no longer have a Red or Yellow background, you need to make sure "Enable Pending" at the top of the screen is checked as well as
having a Poll Interval > 0 (I usually change the poll interval from the default of 10 to 0.1 in order to rapid fire the link creation and changing back
to 10 when the links are done).
To start the rebuild, on the links tab, make the current device whose links you want to rebuild and press the "Rebuild" text and then press "Save".
This will rebuild the links (the halves that show up in Blue column headers for both Controllers and Responders of current device) for the current
device only. If you're showing a "FLAGGED CREATE" or something other than VERIFIED in the a Link status column with a header color other than Blue,
you'll need to make that device the current device and then do the Rebuild/Save from that device.
I think I covered all the points in your post and I know it's alot to read with alot of background but once you understand how it all works, it will
start to make sense.
Dave.
|
Back to Top |
|
|
jeffw_00 Super User
Joined: June 30 2007
Online Status: Offline Posts: 929
|
Posted: September 23 2021 at 08:15 | IP Logged
|
|
|
Hi Dave - many thanks for all the thorough explanations. Filling in
the blanks...
My Timeout count on the IOLinc is 0. There are no failed matches,
and it is not flagged anywhere as failed. (no special colors). I
have been doing the linking by selecting the IOLINC as current
device (not Disabled, Enable Pending checked, poll interval=3). I
click Rebuild and I can see the links pushed out successfully. (I
then click Save but nothing visible happens). So I think I'm doing
everything properly. (see example in
http://www.kwcpa.com/ph/links.JPG - it was too big to upload)
I tried something this morning - I selected the offending IOLINC
Responder link and clicked on ReVerify. After it completed I had a
correct (all VERIFIED) responder link, along with another one that
had some FLAGGED CREATE and empty fields. So I dragged the
weird link left to remove it, and now the link screen for the IOLINC
looks good with everything Verified. (
http://www.kwcpa.com/ph/postReverify.JPG )
However, when I test the IOLINC, Operation is the same as before.
I don't see any additional messages. When it's activated, I still see
2 Group Broadcasts (On or Off) and one Group Broadcast (Grp
Broadcast Success/Fail). But no cleanup messages :-(
Should I see cleanup messages? If so, what should I try next?
I'm sorry to be such a bother here.
Best
/j
--------------
Unrelated question: When I look at the links for my PLM. Th efirst
8 sets or so of Controller links are labeled "[ID NOT FOUND].
Probably old devices I long since removed? Not sure it I should
care or if I should, how to remove the entries. Thanks!
Edited by jeffw_00 - September 23 2021 at 09:19
|
Back to Top |
|
|
dhoward Admin Group
Joined: June 29 2001 Location: United States
Online Status: Offline Posts: 4447
|
Posted: September 24 2021 at 21:43 | IP Logged
|
|
|
Jeff,
Sounds like you got the FLAGGED CREATE fixed by doing a Verify. What happens is that when you verify a link, it reads that particular link for
the unit and if it matches, then it will create the VERIFIED link. In the case of the PLM as a responder, the half of the link that is written
to the PLM is different from a standard Insteon device because it has "Linked List" database vs a standard device "Linear" database. All that
really means is that PowerHome never really tries to create a responder link in the PLM and it is added a different way and should be
automatically verified. If you actually want to rebuild the links in a PLM, you do it from the Setup tab and first do a "Clear PLC/PLM
Database" followed by an "Add Full". It doesnt hurt to do that to confirm that the responder links for the PLM are there.
Unless you've got alot of Insteon traffic, I would expect you to see cleanup messages. Any Insteon traffic (from any device including the PLM)
that is placed on the line (regardless of the type of traffic or who it may be addressed to) will block the cleanup messages. The greatest
chance of having cleanup messages sent is to make sure the half of the link that is in the IOLinc as a controller for the PLM as a responder
(the link will appear in the "Responders of Current Device" window), should have a record number of 1. That means the "Ctlr Rec #" column
(header colored blue) should have a value of 1. That is the best chance of getting a cleanup record but still not a guarantee if other Insteon
traffic on the line.
What you may want to try is a factory reset of your IOLinc followed by a "Rebuild" to get all the links recreated. There have been plenty of
times where everything appears good but doing this clears some memory problem and often will fix things.
The [ID NOT FOUND] means that the database links were scanned and the ID that was scanned was not found in the Devices tab list. This could be
due to a device that was previously valid and that was removed. It can also be there because a scan was done and the data that was returned was
corrupted (yeah, I know this isnt supposed to happen but unfortunately, the Insteon protocol isnt as reliable as they would like to believe).
Usually the ID may be off by just one of the bytes in the ID address. Since you say these are Controller links (devices controlling the PLM),
they are most likely devices that used to exist that no longer do. In that case, you can either ignore them or to get rid of them, just drag
them to the "Remove" button and then press "Save".
Hope this helps,
Dave.
|
Back to Top |
|
|
jeffw_00 Super User
Joined: June 30 2007
Online Status: Offline Posts: 929
|
Posted: September 25 2021 at 08:31 | IP Logged
|
|
|
Hi Dave - So I cleared and re-loaded the PLM (Add Full), manually
reset, and relinked (Rebuild) the IOLINC. The links and CtrlRec #
seem good (see attached). I set things so that after the IOLinc was
triggered, there was NO other INSTEON traffic for more than 10
seconds. In that time window I see the IOLinc send its On
message, along with it's Group Broadcast Success/Fail, and
nothing else (no cleanup messages :-( ).
I re-read your description where you said that any other traffic
aborted the cleanup messages, and I'm starting to understand that
what I am looking for may not exist. I.e., for a <sensor> sending a
trigger to the PLM, there isn't a 100% guaranteed handshake even
if everything's working properly. Even if things worked as one
expects, it's possible for a sensor message to be lost and the
sensor doesn't keep trying until someone says "I heard you". If
that's really true, and normal traffic would bury the handshake
anyway, then I'm surprised, but I think I've taken this as far as I
could, and -Thanks- for the education.
Once I get 2.2 running I can also detect on the Group Broadcast
Success/Fail and that message rarely doesn't show up. I also am
replacing my homemade filters on the Garage Door motors (which I
think are much of the reason the original On/Off messages don't
get through) with Filterlincs that arrive today I'm happy to try
something else if you think of something, but right now I think after
2.2 is running I should be in good shape. Thanks for all the
education and help!
/j
|
Back to Top |
|
|
jeffw_00 Super User
Joined: June 30 2007
Online Status: Offline Posts: 929
|
Posted: October 03 2021 at 13:00 | IP Logged
|
|
|
although - the next best thing is to be able to Poll the sensor and I
figured out how to do this in
http://www.myx10.com/forum/forum_posts.asp?
TID=10932&PN=1&TPN=1
|
Back to Top |
|
|
|
|