Mystery Light Turning On

[apostolakisl]

I have noticed that consistently when the cleaning people come, the light over our breakfast room table turns on as soon as they head upstairs and start doing stuff. Nothing upstairs is linked to this light so it shouldn't turn on. It has happened other times as well when the kids go upstairs, but every time it happens by the time I notice it and go to ask who did what when, everyone is like "huhh?". And the log never says anything about that light turning on but it does seem to only happen when the upstairs hall scene is turned on.

 

Today I just happened to think "open the ISY console and put it in level 3" just as the cleaning people started up the stairs. And it happened.

 

Facts:

1) The light that turns on is 1b.23.50, a 2477d dual band dimmer, it never shows up in the log.

2) This light is not sending a status change when it turns on in this fashion.

3) Here is the really weird thing. Starting from the light being on 100% after it erroneously turns on, and the ISY console still says it is off, I push and held the up dim. Then I checked the ISY console, it said 25%. I puhsed it some more and it went up some more. The light was actually on full bright the whole time however.

 

 

I believe it has something to do with the upstairs scene that you can see starting off the log below. There are 3 2476d's in that scene plus a kpl. I can never seem to get it to do it when I go up and turn it on myself. Just the cleaning people and every once in a while one of my kids.

 

The light turns on fast rate to 100%. The switch itself doesn't seem to realize it is on and never sends a status update to ISY. Then when directly pressing the up paddle on the switch for dim up, the light still doesn't realize it is actually on 100% and reports that it is gradually brightening (but the load is actually 100% bright the whole time).

 

What the heck?

 

Thu 05/03/2012 07:47:59 AM : [iNST-SRX    ] 02 50 0D.16.85 00.00.01 CB 11 00    LTONRR (00)
Thu 05/03/2012 07:47:59 AM : [standard-Group][0D.16.85-->Group=1] Max Hops=3, Hops Left=2
Thu 05/03/2012 07:47:59 AM : [   D 16 85 1]      DON   0
Thu 05/03/2012 07:47:59 AM : [   D 16 85 1]       ST 204
Thu 05/03/2012 07:47:59 AM : [  16 13 94 1]       ST 204
Thu 05/03/2012 07:47:59 AM : [  16 40 E4 1]       ST 204
Thu 05/03/2012 07:47:59 AM : [iNST-TX-I1  ] 02 62 00 00 1F CF 11 00
Thu 05/03/2012 07:47:59 AM : [   0 7B 38 3]       ST 255
Thu 05/03/2012 07:47:59 AM : [iNST-ACK    ] 02 62 00.00.1F CF 11 00 06          LTONRR (00)
Thu 05/03/2012 07:48:02 AM : [iNST-SRX    ] 02 50 16.46.1E 00.00.01 C7 11 00    LTONRR (00)
Thu 05/03/2012 07:48:02 AM : [standard-Group][16.46.1E-->Group=1] Max Hops=3, Hops Left=1
Thu 05/03/2012 07:48:03 AM : [  16 46 1E 1]      DON   0
Thu 05/03/2012 07:48:03 AM : [  16 46 1E 1]       ST 155
Thu 05/03/2012 07:48:03 AM : [iNST-SRX    ] 02 50 16.46.1E 19.75.34 41 11 01    LTONRR (01)
Thu 05/03/2012 07:48:03 AM : [standard-Cleanup][16.46.1E-->ISY/PLM Group=1] Max Hops=1, Hops Left=0
Thu 05/03/2012 07:48:03 AM : [iNST-SRX    ] 02 50 16.46.1E 19.75.34 41 11 01    LTONRR (01):  Process Message: Ignored
Thu 05/03/2012 07:48:03 AM : [standard-Cleanup][16.46.1E-->ISY/PLM Group=1] Max Hops=1, Hops Left=0
Thu 05/03/2012 07:48:08 AM : [iNST-SRX    ] 02 50 16.44.9B 00.00.01 CB 11 00    LTONRR (00)
Thu 05/03/2012 07:48:08 AM : [standard-Group][16.44.9B-->Group=1] Max Hops=3, Hops Left=2
Thu 05/03/2012 07:48:09 AM : [  16 44 9B 1]      DON   0
Thu 05/03/2012 07:48:09 AM : [  16 44 9B 1]       ST 255
Thu 05/03/2012 07:48:09 AM : [iNST-SRX    ] 02 50 16.44.9B 19.75.34 41 11 01    LTONRR (01)
Thu 05/03/2012 07:48:09 AM : [standard-Cleanup][16.44.9B-->ISY/PLM Group=1] Max Hops=1, Hops Left=0
Thu 05/03/2012 07:48:09 AM : [iNST-SRX    ] 02 50 16.44.9B 19.75.34 41 11 01    LTONRR (01):  Process Message: Ignored
Thu 05/03/2012 07:48:09 AM : [standard-Cleanup][16.44.9B-->ISY/PLM Group=1] Max Hops=1, Hops Left=0
Thu 05/03/2012 07:48:09 AM : [iNST-SRX    ] 02 50 16.47.2B 00.00.01 CB 11 00    LTONRR (00)
Thu 05/03/2012 07:48:09 AM : [standard-Group][16.47.2B-->Group=1] Max Hops=3, Hops Left=2
Thu 05/03/2012 07:48:09 AM : [  16 47 2B 1]      DON   0
Thu 05/03/2012 07:48:09 AM : [  16 47 2B 1]       ST 255
Thu 05/03/2012 07:48:10 AM : [iNST-SRX    ] 02 50 16.47.2B 19.75.34 46 11 01    LTONRR (01)
Thu 05/03/2012 07:48:10 AM : [standard-Cleanup][16.47.2B-->ISY/PLM Group=1] Max Hops=2, Hops Left=1
Thu 05/03/2012 07:48:10 AM : [iNST-SRX    ] 02 50 16.47.2B 19.75.34 46 11 01    LTONRR (01):  Process Message: Ignored
Thu 05/03/2012 07:48:10 AM : [standard-Cleanup][16.47.2B-->ISY/PLM Group=1] Max Hops=2, Hops Left=1

[ELA]

Hello apostolakisl,

I agree that a mystery event is very frustrating to understand having just experienced one myself.

 

When people are going up the stairs would they be activating any switches or motion sensors?

 

I attributed my mystery event to ESD. Any chance this could be ESD related? Cleaning people toughing power line connected lamps/etc and discharging?

 

Or another thought I had was multiple scenes being activated at the same time resulting in data collisions/corruptions?

 

Maybe we should update all of our devices to i2CS and no more worries

[LeeG]

It does not matter if a switch is physically On, Off or in-between, when the On paddle is pressed and held a Begin Manual Change message is sent followed by a Stop Manual Change message when the paddle is released. The ISY is showing an increase in On Level based on the interval between those messages. With the ISY thinking the switch is Off the On Level displayed is increased based on what the ISY thinks is happening. This aspect of the symptom is expected/normal with the ISY not knowing the switch was physically On.

 

Switch 0D.16.85 paddle was pressed On initiating an Insteon Scene On sequence from that Controller. An ISY Program responded with an ISY Scene On (Scene/Group number 0x1F). This aborted the Insteon Scene On initiated by 0D.16.85.

 

Switch 16.46.1E paddle was pressed On initiating an Insteon Scene On sequence from that Controller. This Insteon Scene probably completed, at least far enough for 16.46.1E to send a Group Cleanup Direct message to the PLM.

 

Switch 16.44.9B paddle was pressed On initiation an Insteon Scene On sequence from that Cont0roller. This Insteon Scene probably completed, at least far enough for 16.44.9B to send a Group Cleanup Direct message to the PLM.

 

Switch 16.47.2B paddle was pressed On initiation an Insteon Scene On sequence from that Cont0roller. This Insteon Scene probably completed, at least far enough for 16.47.2B to send a Group Cleanup Direct message to the PLM.

 

The only thing unusual is the very first Insteon Scene On from 0D.16.85 that was aborted by the ISY Scene On for Scene/Group 0x1F. Perhaps the overlapping traffic caused a problem for 1b.23.50. I would add a 1-2 second Wait before the Program turns ISY Scene 0x1f On.

[apostolakisl]

It does not matter if a switch is physically On, Off or in-between, when the On paddle is pressed and held a Begin Manual Change message is sent followed by a Stop Manual Change message when the paddle is released. The ISY is showing an increase in On Level based on the interval between those messages. With the ISY thinking the switch is Off the On Level displayed is increased based on what the ISY thinks is happening. This aspect of the symptom is expected/normal with the ISY not knowing the switch was physically On.

 

 

Curious. I was under the impression that every time you altered a switch, it sent a status report. So all of those values between 0 and 256 you listed next devices in the log is an assumption made by ISY rather than actual?

 

Switch 0D.16.85 paddle was pressed On initiating an Insteon Scene On sequence from that Controller. An ISY Program responded with an ISY Scene On (Scene/Group number 0x1F). This aborted the Insteon Scene On initiated by 0D.16.85.

 

What is 0x1F? I don't know what you mean by that or how to track down what it is or where it is in the log.

[LeeG]

I use a REST command to display the Scenes when I need to know Scene/Group number. Note the deviceGroup tag value is decimal. The 0x1F would be decimal 31

 

http://192.168.2.2/rest/nodes/scenes

 

11318

SceceSecondaryOff

34

G15

-

8 49 E7 7

 

The Start and Stop Manual Change messages are unique in that they are Group Broadcast messages only. There is no Group Cleanup Direct follow up as it would make controlling a list of responders impossible. The amount of bright or dim is an estimation based on time between Start and Stop Manual Change messages.

 

EDIT: sorry I missed this. It was in a post attempt that failed. Forgot to add it back the next time around. The ISY Scene/Group number is in red.

 

Thu 05/03/2012 07:47:59 AM : [iNST-TX-I1 ] 02 62 00 00 1F CF 11 00

[apostolakisl]

That program that triggered the scene 31 to turn on sets a kpl light to turn to just let me know that any number of about 15 lights are on. It is just a list of load bearing switches and if any one of them has status not off it turns the scene on that contains that kpl button.

 

I could add that kpl as a responder to every scene that contains one of those switches, but that would require a lot of scene additions. I'll try putting a delay in there as well.

 

So am I to understand that a scene being activated might kill a scene that is in the process of being activated?

 

Incidentally, I have checked all the links records for all the devices involved here and they are all correct.

 

One other point that I just discovered. I found that a program was erroneously listing the breakfast room table as it's trigger when it should have listed the load switch on the upstairs hall scene (the scene that starts off the log activity above). Then I realized the reason was that the breakfast table switch was originially part of the upstairs hall scene and that I had swapped two switches as part of my re-organization for better dual band rf coverage.

 

After making the switch, I factory reset the swapped devices and restored them as per the new location. I am suspecting that perhaps there is some ghost of the old link in there that might be causing this? But shouldn't the breakfast room switch still have sent a status update after responding to the scene, even if it really shouldn't have responded to the scene? Perhaps I should factory reset all the switches in that scene and restore them?

[LeeG]

“So am I to understand that a scene being activated might kill a scene that is in the process of being activated?â€

 

Yes. Insteon supports only 1 Scene active at a time. Normally there is no visual effect of this situation as the initial Scene Group Broadcast causes all the Responders to react. Any Group Cleanup Direct message that is not issued would have an effect only if the powerline is marginal and the Scenes overlap to begin with.

 

“But shouldn't the breakfast room switch still have sent a status update after responding to the scene,â€

 

If the breakfast room switch is part of the Scene driven by the paddle press it would but that would not appear in the ISY trace as the ACK would be sent back to the switch where the paddles is pressed. The ISY trace only shows ACK messages that are directed at the PLM itself. If the breakfast room switch is part of Scene 31, no. An ISY Set Scene xxxx On issues a Scene Group Broadcast message only which is not ACKed.

 

“Perhaps I should factory reset all the switches in that scene and restore them?â€

 

That can’t hurt. However, if the ISY has a remnant of the link in the ISY database a Restore will put it back after the Factory reset. If there is a half link it should react the same all the time rather than be an intermittent situation.

[apostolakisl]

If the breakfast room switch is part of the Scene driven by the paddle press it would but that would not appear in the ISY trace as the ACK would be sent back to the switch where the paddles is pressed. The ISY trace only shows ACK messages that are directed at the PLM itself. If the breakfast room switch is part of Scene 31, no. An ISY Set Scene xxxx On issues a Scene Group Broadcast message only which is not ACKed.

 

 

Doesn't the PLM also receive that ack and update the status as listed on ISY? Or does the ISY only respond to the initial command and just assume it happened?

 

Perhaps I should factory reset all the switches in that scene and restore them?â€

 

That can’t hurt. However, if the ISY has a remnant of the link in the ISY database a Restore will put it back after the Factory reset. If there is a half link it should react the same all the time rather than be an intermittent situation.

“So am I to understand that a scene being activated might kill a scene that is in the process of being activated?â€

 

ISY database does not have any wrong links. I checked the listed controller/responders and they are correct. This assumes that the actual Insteon coded links that Insteon writes to devices are tied to what is listed in the controller/responder list. When I poll the links table from the devices it does match with ISY. But, is it possible that despite what the device reports when its links are querried, could there be some trace left in there that gets picked up at times? Kind of like a deleted file isn't really deleted until you overwrite it.

[LeeG]

"Doesn't the PLM also receive that ack and update the status as listed on ISY?"

 

If asking about the paddle press initiated Scene, the PLM would be expected to see a Group Cleanup Direct which did not happen. That is why I concluded the paddle initiated Scene had been aborted by the ISY initiated Scene.

 

This is from the original posted trace. The device status is updated after the Group Broadcast from the paddle On press.

 

Thu 05/03/2012 07:47:59 AM : [iNST-SRX ] 02 50 0D.16.85 00.00.01 CB 11 00 LTONRR (00)

Thu 05/03/2012 07:47:59 AM : [standard-Group][0D.16.85-->Group=1] Max Hops=3, Hops Left=2

Thu 05/03/2012 07:47:59 AM : [ D 16 85 1] DON 0

Thu 05/03/2012 07:47:59 AM : [ D 16 85 1] ST 204

Thu 05/03/2012 07:47:59 AM : [ 16 13 94 1] ST 204

Thu 05/03/2012 07:47:59 AM : [ 16 40 E4 1] ST 204

 

If asking about the ISY initiated Scene, no. There are no ACKs as there are no Group Cleanup Direct messages with a Set Scene xxxx On/Off.

 

A half link would not be intermittent.

[apostolakisl]

Is it accurate to say that ISY can not write a half link? Wouldn't it only be a result of a failure to properly remove an unwanted link?

[LeeG]

I would not agree with that. Links are written to device A, the link writes to device B are not successful because of powerline issues, RF devices that are asleep. I would expect to see either a red ! or a green Icon. However, the forum has topics where half links exist. The emphasis is how to get rid of the half links rather than a retrospective analysis of how that happened. Too many times rules are not followed. The ISY is rebooted in the middle of processing , devices are deleted, any number of things that should not have been done.

[apostolakisl]

What I meant to say, is the ISY would not write a half link purposefully.

 

In other words, if you querry a devices links table and it matches ISY's expected links, then there are no half links.

[LeeG]

“the ISY would not write a half link purposefully.â€

 

I agree completely!

 

“If you querry a devices links table and it matches ISY's expected links, then there are no half links.â€

 

I would not agree with that. If that were the case a simple Restore Device would resolve all half links. There are posts that document the need to add a device back to a Scene and then Remove the device to clean up links.

 

Folks run Admin Console code that is a year behind the running image. Not even in the same x.y.z stream. Who knows what running an Admin Console written a year ago never intended to run on the current image is doing. Who knows how much damage that can do or how long it will take for the damage to surface.

 

Plus the things I mentioned before. Folks get so use to Factory resetting individual Insteon devices, pulling the air gap switch, things that should never be done to an ISY unless all else fails, except these are some of the first things folks try with the ISY.

[apostolakisl]

Well I find this rather confusing.

 

If restoring a device could result in a half link, then ISY must have a half link in its own table.

 

So I guess the real question is, can ISY's tables contain half links? It would seem that you are saying yes, they can. This would then lead me to say that ISY could purposefully write a half link.

[LeeG]

I took the question about would the ISY purposely write a half link as that is something in the design of device add and/or Scene management that the ISY would deliberately write a half link.

 

This discussion has gotten so far from the original problem that we have detracted to word parsing. I don't believe I have anything more to contribute to this discussion.

 

Good luck with the original problem.

[apostolakisl]

I took the question about would the ISY purposely write a half link as that is something in the design of device add and/or Scene management that the ISY would deliberately write a half link.

 

This discussion has gotten so far from the original problem that we have detracted to word parsing. I don't believe I have anything more to contribute to this discussion.

 

Good luck with the original problem.

 

Well you certainly aren't obliged to answer anything but I would be happy to entertain an answer elsewhere.

 

The point being, if ISY can write half links because the possibility that a half link could exist in its own database, then I can't trust that my current ISY links table doesn't contain an error. This would lead one down a path of confirming the links table's accuracy rather than just reading the list of responders/controllers and saying it is correct and then assuming the links are correct.

 

It is a reasonable path to consider seeing as this device at one time was linked to other devices that may be at the root of the problem.

[Michel Kohanim]

apostolakisl,

 

I think the problem is that your conclusion cannot be derived from your hypothesis:

 

1. Can ISY purposely write half links: NO

2. Can ISY have half links in its own tables: NO if everything was done with ISY. If you crawled the network, then ISY will have whatever was brought in. ISY tries to find the other half, and if it can't, it will create a new scene for each half

3. Is it possible for devices to have half links but ISY links are identical: yes (see #2)

 

So, going back to the original issue - on which I must agree with LeeG - none of the above cases explain what you are experiencing. You might have Phantom Links but that does not explain the fact that "no one" really knows what they did. In short, I do not think the problem is due to someone doing something to one/more switches but, rather, the problem is either the switch itself (which I have seen many times), noise, or KPL 2A and 2D which would certainly exhibit this problem (I call it Christmas effect: they would cause random on/off of random devices to which they might have ever been linked to). So, if you have any of those, please replace them.

 

With kind regards,

Michel

[apostolakisl]

Final Assessment:

 

ISY can write bogus links.

 

It came down to two devices, a 2476d and a 2477d. The 2476d would turn the 2477d on/off as though it were a responder. I removed both devices from all scenes, factory reset both of them after which they no longer affected one another.

 

I Restored the two devices and once again the problem returned. Neither device had a single thing under its controller/responder menu. Despite this, ISY was writing the one device as a controller of the other device.

 

I removed the 2476d device from ISY entirely and then reentered it. The problem persisted.

 

I removed the 2477d device from ISY entirely and then reentered it. The problem did not recur. Which points to ISY writing a responder link to the 2477d where no link should have been. It did not show the link in the responder/controller list for the device (as there were no controller/responders at all for either device). I don't really know if the links tables included the faulty link as I really don't know how to break down the tables.

 

In short, what ISY shows on the responder/controller list for the device is not necessarily what it actually writes to the device. If there is an error on those links, it would appear that it would be impossible to remove it short of clearing the device from ISY and starting from scratch.

[Teken]

Final Assessment:

 

ISY can write bogus links.

 

It came down to two devices, a 2476d and a 2477d. The 2476d would turn the 2477d on/off as though it were a responder. I removed both devices from all scenes, factory reset both of them after which they no longer affected one another.

 

I Restored the two devices and once again the problem returned. Neither device had a single thing under its controller/responder menu. Despite this, ISY was writing the one device as a controller of the other device.

 

I removed the 2476d device from ISY entirely and then reentered it. The problem persisted.

 

I removed the 2477d device from ISY entirely and then reentered it. The problem did not recur. Which points to ISY writing a responder link to the 2477d where no link should have been. It did not show the link in the responder/controller list for the device (as there were no controller/responders at all for either device). I don't really know if the links tables included the faulty link as I really don't know how to break down the tables.

 

In short, what ISY shows on the responder/controller list for the device is not necessarily what it actually writes to the device. If there is an error on those links, it would appear that it would be impossible to remove it short of clearing the device from ISY and starting from scratch.

 

I would also agree with this observation.

 

Teken . . .

[Michel Kohanim]

Final Assessment:

 

ISY can write bogus links.

 

 

I am very much dumbfounded as to how you came to this conclusion since NOTHING in the remainder of your post could point to this conclusion (or, say: sensational headline). Please read my post prior to your post and look at points 2 and 3.

 

With kind regards,

Michel

[apostolakisl]

Final Assessment:

 

ISY can write bogus links.

 

 

I am very much dumbfounded as to how you came to this conclusion since NOTHING in the remainder of your post could point to this conclusion (or, say: sensational headline). Please read my post prior to your post and look at points 2 and 3.

 

With kind regards,

Michel

 

There is no other way. You say that ISY can only get a half-link from a "crawl". But ISY never crawled anything in my house. Every single device was enrolled using ISY and every single scene was created using ISY. Nothing was ever done manually or with another controller. I always enroll devices using the option to erase any existing links as well.

 

The devices in question were actually once part of the same scene. I moved the 2477d as part of a plan to improve communications (getting the dual bands strategically placed). I used the "replace with" command as part of the process of moving things around. My suspicion is that there was an error during this process that left a link on the 2477d (and in the ISY links table) that shouldn't have been.

 

Furthermore, the ISY kept putting that link back on the device after factory resets/restore. To me this is the troubling part. ISY's internal link table (what it writes to a device during a restore) ideally would only have links that are matched to the responder/controller menu. If a link is there that it can't make sense of, it should somehow indicate that. I had completely removed both devices from every scene so neither had anything listed in the controller/responder menu and should have indeed been solo devices linked only to the plm. Yet, there was a link, the link was bogus, and the link was put there by ISY on multiple occasions after factory reset/restores.

 

This would indicate that the controller/responder menu is not cross checked to the links table. It would appear they are parrallel entities that should be the same, but should they ever get out of sync, the only recourse is to remove the device and start it from scratch.

 

Outline of Method Used to Correct Problem

Background:
-	Two devices were involved.  A 2476d and a 2477d.  They were on opposite sides of the house on different floors which challenged things.  
-	2476d was consistently controlling the 2477d, on/off
-	The level 3 viewer never recorded any activity from the 2477d when activated by the 2476d.  In other words, 2477d activity was not registering in ISY when the activity occurred as a result of the 2476d.
-	The 2477d had at one time been part of a virtual 3-way with the 2476d but was moved about 6 months ago for better dual band coverage.  The device was swapped with other devices in the house and the “replace with†command was used as part of the move process.
-	Every device I own was purchased by me, from SH, and enrolled using its Insteon address and the “remove existing links†option.  No manual links were ever made on any device and ISY was never asked to bring in any links from a device.
-	The two devices in question had their links tables queried and cross checked to ISY database and they passed.

Trouble Shooting/Correcting Process:
-	Both devices were factory reset => They no longer controlled each other
-	Both devices were restored => Back to the same old problem
-	Both devices were removed from every scene reset/restored => Same Problem
-	2476d was deleted from ISY and re-enrolled => Same Problem
-	2477d was deleted from ISY and re-enrolled => Problem gone
-	Both devices re-added to all the old scenes => Still working properly

Assessment:
-	2477d had an erroneously link causing it to respond to the 2476d
-	The link was also contained in the ISY database
-	The existence of the link was not included on the controller/responder menu
-	The link was not removed by removing the devices from all scenes
-	The link was partial
-	The link was created by ISY and perpetuated by ISY
-	The link probably was an error during a “replace with†activity
-	The link couldn’t be removed except by delete and re-add from scratch to ISY
-	I wish I had saved a copy of the links table prior to deleting the devices for analysis now.  But I didn’t.

[Michel Kohanim]

I still take issue with your all encompassing conclusion but there's no point in belaboring it. And, I am a little confused as to why you would use "replace" to move devices around physically. But, then again, there's no point in belaboring this.

 

The bottom line is that you are reporting a bug and we'll investigate: do you remember under which ISY firmware revision you did a replace (was it the one in 2009)?

 

With kind regards,

Michel

[apostolakisl]

I checked my SH order history, the dual bands were purchased Nov 23, 2011. I also replaced the PLM with a dual band at the same time. I was always up to date on the firmware so whatever firmware was the latest as of the beginning of December is what I would have been running when I did all this.

 

I used "replace with" because I introduced new switches into the locations of previously present switches and the new switches were to have the same links. After the initial placement of some of the dual band devices and observing the comm, I decided on different locations. Again, I didn't want to re-create the scenes, so I simply did a "replace with" again. I did have to use a spare switch at one point as a repository of links since ISY has no way of trading links between 2 switches.

 

I should also mention that the bad link was only first discovered after replacing of the switches, and the old switches had been there for perhaps 2 or 3 years, so I can't imagine that it would have gone un-noticed. I actually first commented on this problem on this forum about 4 or 5 months ago but I had other things that were higher on my priority list and never finished following up.

 

I am not trying to offend you or anyone. I am very positive and supportive of ISY and constantly trying to make it work better. But the logic stream in this case clearly points to an incorrect link on the device and nothing has ever created a link on any device I own except ISY.

 

I am quite curious to know how ISY generates its controller/responder menu and how it reconciles that list with the links table list. There is no doubt that ISY had a link in its table that did not correspond to anything in the responder/controller listings.

 

This is not the first time I have seen issues posted on this forum where the solution was "delete device and start over". It would seem that the only error this technique could rectify is an inaccurate links table. Since people have had success with this in the past, I suspect they must have had link table issues.

 

I am curious as to specfically which conclusion you don't agree with. The devices do not appear to have any hardware issue as they work correctly now. They consistenly mis-behaved every time the ISY wrote its links table to them and consistently did not mis-bahave when those links were removed from them. The link was not represented by any scene in ISY and there was no listing of it in the responder/controller menu. The links were not fully functional as the PLM was not included.

[apostolakisl]

I just recalled that I replaced the ISY 99i with the 994i a few weeks back and the old unit is still as I left it. I checked the device tables as they are currently (after being deleted, readded and then joined to the same scenes). You can see that there are a bunch of extra recrods on the ISY that are not on the device.

 

[LeeG]

Can the images be posted inline rather than hosted. Attempts to expand image makes them unreadable.

 

Note that some of the differences are the result of a Restore versus no restore. The link records are in a different order between the two systems which looks like many mismatches when it is really a different order.