How to get rid of unwanted link

[Illusion]

I have a 2411T IRLinc Trasmitter. It has 24 nodes. One of those nodes is the IR code for play/pause on my iPod. I put some fanlincs in, and created some scenes for these. One of these scenes is called Livingroom Fan High.

 

This scene has 4 members

IR RX-Liv Fan H (a 2411R IRLinc Reciever) as a controller

a secondary KPL button as a responder

another secondary KPL button as a controller from a different KPL

Living room Fan-motor (of course)

 

This scene works fine when controlled from either of the member controllers; however, when I trigger it from the ISY it causes my IR Tranmitter 2411T to send the code to play/pause my iPod. It should have nothing whatsoever to do with this scene. So I figured errant half link or something. So I tried adding the iPod Play/Pause node of the IR TX to the scene, then delete it, but it persists. But only when triggered from the ISY.

 

So I tried adding every node of the IR TX to the scene, then deleting it. Same thing the ISY initiation of the scene cause the Play/Pause node of the IR TX to fire.

 

Thoughts?

[LeeG]

Determine the Scene (Group) number of the ISY Scene. A REST command can be used for that.

 

http://192.168.2.2/rest/nodes/scenes

 

35008

SceneFanSpeedMed

46

J05

-

14 9E F5 2

 

Then do a Show Device Links Table on the 2411T and look for that Scene (Group) number in the second byte of a link record in the IR 2411T. Note the deviceGroup tag is a decimal value. The 2nd byte in a link record is hex.

[Illusion]

Okay did the rest thing. Came up with this:

 

33176

Livingroom Fan High

49280

91

16 7C 18 6

12 F5 69 11

14 9D 29 2

F C1 DE 3

 

So I am looking for the number 91 (5b?) in the second byte of a link record.

 

In this example what value is the second byte? 06?

 

0CD0 : A2 06 16.7C.18 00 00 1A

[LeeG]

The Scene (Group) number is 91 0x5B. For the 2411T to react to that ISY Scene there has to be a link record with a 0x5B in the 2nd byte (where the 06 is) and the ISY PLM address in the 3rd, 4th and 5th bytes. If the link record is there the first two bytes of the line are the address of the link record

 

0FF8: A2 5B xx yy zz - where xx yy zz is ISY PLM address - the 0FF8 is arbitrary

 

Once the link record is located then do a Compare and see if the ISY thinks the link record should be there at that address.

[Illusion]

Here are the link records that have a 5b but not all have the PLM address.

 

 

0F28 : A2 5B 13.24.AA 00 00 0D

0E90 : A2 5B 13.24.AA 00 00 22

0E88 : A2 5B 13.24.AA 00 00 01

0E70 : A2 5B 13.24.AA 00 00 0A

0E58 : A2 5B 13.24.AA 00 00 0F

0E40 : A2 5B 13.00.AA 00 00 05

0E28 : A2 5B 13.24.AA 00 00 13

0E10 : A2 5B 13.24.AA 00 00 0E

0DF8 : A2 5B 13.24.AA 00 00 03

0DE0 : A2 5B 13.24.AA 00 00 24

0DC8 : A2 5B 13.24.AA 00 00 08

0DB0 : A2 5B 13.24.AA 00 00 07

0D98 : A2 5B 13.24.AA 00 00 21

0D80 : A2 5B 13.24.AA 00 00 1F

0D68 : A2 5B 13.24.AA 00 00 1D

0D50 : A2 5B 13.24.AA 00 00 14

0D38 : A2 5B 13.24.AA 00 00 15

0D20 : A2 5B 13.24.AA 00 00 16

0D08 : A2 5B 13.24.AA 00 00 17

0CF0 : A2 5B 13.24.AA 00 00 18

0CD8 : A2 5B 13.24.AA 00 00 1A

0CC0 : A2 5B 13.24.AA 00 00 1B

0CA8 : A2 5B 13.24.AA 00 00 1C

0C90 : A2 5B 13.24.AA 00 00 12

0C78 : A2 5B 13.24.AA 00 00 23

 

I did the compare and came up with two record mismatches:

[Record mismatch]0E40 : A2 5B 13.00.AA 00 00 05 Device link table

0E40 : A2 5B 13.24.AA 00 00 05 ISY link table

 

[Record mismatch]0CF8 : A2 11 00.F5.69 00 00 17 Device Link Table

0CF8 : A2 11 12.F5.69 00 00 17 ISY link table

[LeeG]

If 13.24.AA is the ISY PLM address all but one of the posted link records will react to Scene 91 (0x5B). The two link records that show mismatch could be a problem retrieving information from the 2411T. In one case (13.00.AA versus 13.24.AA) it looks like a 0x00 was returned which might not actually be in the device. I have seen Peeks return the wrong value. The other mismatch (00.F5.69 versus 12.F5.69) could be another case where Peek returned the wrong value. These two mismatches are not the real concern. It is the long list of links with the 0x5B Scene (Group) number the ISY thinks should be there (no mismatch).

 

A Restore Device to the 2411T will not fix this as the ISY believes these links should be there.

 

Unfortunately now that the problem has been defined I do not have a good suggestion to resolve it. A Delete and Factory reset is always an option but that would mean redefining all the IR codes.

[ELA]

Hello Illusion , LeeG,

 

I have recently been working with link commands and learning.

Reading this thread I am curious if the last byte of the link records shown ( data 3 byte) are the IRlink IR code number?

If so could a person identify which IR code # (data 3 byte) in the IRlink commands the IPOD play ( via the ISY) and then use that information to assist in identifying which link in the ISY could be the errant one?

(assuming there is an errant link?)

[LeeG]

ELA

 

I think LD3 is an index number into the IR code database which is located in a different area of memory. Similar in concept to the link database except it holds the IR codes which are more than a single hex byte. It was more than 3 years ago when I looked into this so recollection could be fussy but I remember using a Set MSB value to access higher memory locations to retrieve the specific IR code information.

[ELA]

Hi LeeG,

I probably worded my question poorly. Yes I meant an index byte to one of the 128 possible IR transmission codes. I did not mean the IR code itself.

 

So if you knew what index to look for wouldn't that be helpful in evaluating which link in the ISY was in question?

[LeeG]

There are actually some 20+ link records (IR codes) that are responding to ISY Scene number 91 (0x5B). The number of IR codes responding may give Illusion a clue as to the Scene that was originally defined which used that many different IR codes. To eliminate the 2411T reacting to Scene 91 all of the Responder link records with Group 0x5B have to be removed.

[ELA]

LeeG,

Understood that there are "20+ link records (IR codes) that are responding to ISY Scene number 91 (0x5B)".

 

My question revolved around identifying which one of those corresponded to the IPOD play? Perhaps that would not be helpful.

[Illusion]

If I delete the 'Livingroom Fan High' scene, should it also delete the offending link, since the ISY know it is there, even though it does not show in the UI.

 

There should be only one group 91 right. So deleting that scene should delete all the 5b link records that the ISY knows aobut?

 

This has gotten largely academic for me. I am not going to delete the device and re-add it back. As this should never have happened in the first place, as I never had that module as a responder to said scene, what is to say it would not happen again. It would be easier for me to modifiy my behavior than redo that module.

 

This does get me thinking. Group 91 seems kinda like a low number for how new the scene is and how many scenes I have. Is is possible that this was a scene of mine long ago, before I streamlined the IR TX scenes, that did include the IR TX.

 

Hypothetically, I have a scene. It gets assigned group #91. It has only the IR TX iPod Play/Pause node in it as a responder. I delete the scene during clean-up cause I find it is a duplicate or whatever. If the link record does not get deleted, at some point in the future group #91 would get reused by the PLM/ISY and the IR TX would respond, right?

 

But in my case, the ISY knows about the links that should not exist...

[Michel Kohanim]

Hi Illusion,

 

This is not good. It would be extremely helpful if you can summarize the history of this device and, if possible, firmware levels that were used (i.e. was it before 3.1.17 or after 3.1.17)? Also, please take a look at your Error Log and let me know if you see any -11000x errors with the file name being the address of this devices.

 

With kind regards,

Michel

[Illusion]

Device added under 3.1.5. Modified nodes and scene memberships a bit under 3.1.10

 

No -11000X errors to report.

[Michel Kohanim]

Hi Illusion,

 

Thanks so very much. This does make sense since those were the releases in which we changed the database handling routines.

 

With kind regards,

Michel

[Illusion]

Could you elaborate on that a little. Was this supposed to happen? Is this fixable? How do I stop the device from responding to scenes it is not a member of?

 

 

Sent from my iPhone using Tapatalk

[Michel Kohanim]

The original problem was case of missing links especially when one changed scene attributes through programs. To fix that, during the 3.1.x beta, we went through a revamp of database handling. No, it should not happen. Yes, it's fixable but, unfortunately, not without removing the device and adding it back (in your case, this is going to be quite challenging).

 

With kind regards,

Michel

[Illusion]

Ouch. Not good news, but thank you for the explanation.

 

 

Sent from my iPhone using Tapatalk

[apostolakisl]

I'm trying to understand how ISY manages links tables:

 

It seems as though it is only capable of removing links from a device/its own tables when the links are part of an ISY scene?

It seems as though ISY does not do any "house cleaning". In other words, it does not try to reconcile its links tables with its known scenes. So if an extra link exists in its table, there is no way to access that link since it will only delete links that are part of scene memberships as known to ISY.

 

It would be nice if there were a way to have ISY clear the links table, then rebuild the links table using the device's scene memberships. In this way, any orphan links would be removed without having to remove and rebuild the device manually.

 

Ideally, a single button press "rebuild device" would do the job of clearing the links table from isy and device, then repopulate the links table from the list of scene memberships, then write the links to the device.

[ELA]

In an attempt to learn more from this thread I retrieved my IRlinc- links ( below). 1b,fd,23 being the PLM.

When I compare them to Illusions I am now a bit confused?

Illusions show to be responder links whereas mine are controllers. I found the same associated (22) links in the PLM but as responder links.

This arrangement seems to make sense to me since I send IR commands from my remote to the IRlinc device and it then sends control commands to various loads. The PLM never controls the IRlinc?

 

So what am I missing? Why are Illusions responder links with the PLM address in them? Please be gentle, I am rookie and learning

 

e2 1 1b fd 23 ff 1f 1

e2 18 1b fd 23 ff 1f 18

e2 19 1b fd 23 ff 1f 19

e2 1a 1b fd 23 ff 1f 1a

e2 1b 1b fd 23 ff 1f 1b

e2 26 1b fd 23 ff 1f 26

e2 27 1b fd 23 ff 1f 27

e2 1c 1b fd 23 ff 1f 1c

e2 1d 1b fd 23 ff 1f 1d

e2 20 1b fd 23 ff 1f 20

e2 1e 1b fd 23 ff 1f 1e

e2 1f 1b fd 23 ff 1f 1f

e2 21 1b fd 23 ff 1f 21

e2 28 1b fd 23 ff 1f 28

e2 29 1b fd 23 ff 1f 29

e2 2a 1b fd 23 ff 1f 2a

e2 2b 1b fd 23 ff 1f 2b

e2 2c 1b fd 23 ff 1f 2c

e2 2d 1b fd 23 ff 1f 2d

e2 23 1b fd 23 ff 1f 23

e2 24 1b fd 23 ff 1f 24

e2 25 1b fd 23 ff 1f 25

[LeeG]

That should be the difference between an IRLinc R and an IRLinc T. The IRLinc R receives IR signals and controls Insteon devices in response. This makes the link records in the IRLinc R Controller (E2) link records to be able to control other devices. The IRLinc T receives Insteon commands from other devices making the IRLinc T a Responder which requires Responder (A2) link records.

[ELA]

Thanks LeeG,

Somehow I knew there was an obvious answer that I was missing

 

From what I have been able to attempt to understand about Illusions problem ... he thinks there is an errant link in the PLM, is that correct, or in the IRlink?

 

If it were in the PLM, and the unwanted link had been identified, could a person use the "0x6F" - Manage All-link Record command and terminal program to remove the unwanted link?

 

And then follow up with a backup of the PLM into the ISY?

Or are there complications that would prevent doing that?

[LeeG]

The unwanted link(s) are in the IRLinc. The 6F is the correct command if it were a PLM issue. There is no means of directing the ISY to replace its information with that currently in the PLM. The Restore Modem (PLM) goes the other way and would defeat the effect of the 6F. Anyway, the problem is with the IRLinc link database.

[Illusion]

I have solved this issue. I built another scene, moved all the nodes to the new scene, and deleted the old scene. I suppose I should have left the problem scene in the ISY with no responders so the issue does not come up again when I create a new scene and the ISY re-uses that group ID #. Ah well, next time it comes up I will do that.

 

Much easier to have abandoned scene in a holding pen than to reprogram the IR TX module!