Spontaneous Linking

[thruster999]

I’d like to check with the forum and see if others have experienced the following; and see if anyone has figured out the issue and a solution

 

Spontaneous links get created between controllers and different responders – and it appears to be random.

 

For instance, after several weeks of flawless ISY operation, all of a sudden, when my downstairs Hallway Motion Sensor was triggered ON, my Hallway light turned ON, but then so did my Dining Room Table light, which is on a different floor altogether, has its own motion sensor and in its own Scene.

 

The Dining Room Light was clearly not setup in ISY as a responder in the Hallway Scene however the links appear in the PLM Table.

 

Later, my Dining Room Table Motion Scene, which only has a Motion Sensor and a single light (Dining Room Table light) also triggering my Kitchen light ON and OFF when, in my ISY setup, the Kitchen light is not part of that scene.

 

Today I found my Dining Room Motion Sensor turning on one of my Second floor lights (the light over my Pool Table) when, as I indicated before, only the Dining Room Table light and it’s corresponding Motion Sensor are the only devices in the scene.

 

In each case the links do appear to have been created in the PLM.

 

I had to correct each case by making the rogue light part of the Scene triggering it and then remove it.

 

So, any ideas as to what could be causing this spontaneous linking to occur? Is this a problem with the PLM, just acting crazy, or with the ISY corrupting the PLM links table?

 

Thanks

[LeeG]

Do you mean the Show PLM Links Table displays a "Controller" link record pointing to a device that was not in the Scene that was turning the responder On. You have to use Group numbers to correlate Scene link records to devices as the PLM should have a Controller link record in the PLM for every device that is a responder, just not for the Group number in question.

 

It is the responder that is reacting so even if the PLM grew a link record it should not have the responder should not react unless it has a matching responder link record for that particular Group number. I don’t think the PLM is the first place to look for a hardware failure.

[thruster999]

Hi Lee

 

I should of thought of saving the results. I will post them the next time this occurs.

 

But maybe this might be helpful.

 

The last example I provided:

I created a Scene called 'Dining Room Motion'.

The Scene has a Motion Sensor as a controller and a Dimmer as a Responder.

 

When the issue was taking place where the Dining Room Motion Sensor was triggering my Pool Table Light - I could press the Set button of the Dining Room Motion Sensor and turn the Pool Table light off and on. Even though the Pool Table light was never added or was currently part of that scene.

 

My first attempt to rectify this was to remove both the Dining Room Motion Sensor and the Dining Room Table Dimmer from the Scene Dining Room Motion. I did a Restore on both devices after removing them from the Dining Room Motion Scene.

 

Then I added the Motion Sensor and Dining Room Table Dimmer back to the Dining Room Motion Scene.

 

Each step of the way I experienced no issues.

 

But, once my Dining Room Motion Scene was re-setup the Motion Sensor was still triggering my Pool Table light

 

I did this several times with the same result - including doing a restore on the Pool Table Light when the Dining Room Motion Scene was empty. But still the issue occurred.

 

I finally added the Pool Table Light to the Dining Room motion Scene, and then removed it - which fixed the issue.

 

I'd assume that the link was in the Scene because 1) The Motion Sensor did not trigger the Pool Table light when removed from the Scene and 2) the link appeared to remain in the Scene "hidden" during this process.

 

Anyway, if this only happended once I would not have posted it but this is the third time in as many weeks with different devices.

[LeeG]

Thanks for the added information. This is not a PLM issue unless there is an ISY Program involved that has not been discussed. With the Motion Sensor On command turning on the Pool table there must be a responder link record in the Pool table that matches the Motion Sensor address and Group 1. When the Pool table is added as a responder and then removed from the Scene the erroneous link record in the Pool table is deleted. Do not know how this link record is being created or why. The next time this happens do a Show Device Links Table of the responder that is reacting when it should not. I would expect to find a Responder link record with the address of the Controller and Group 1 where a Motion Sensor is the controller. The Group number would be different if the controller was the ISY itself. Coming from a Motion Sensor it will be Group 1 that is of interest in the Responder link database.

[thruster999]

Thanks again Lee

 

I'll check when this occurs again

 

But I have no programs that do anything with my dining and pool table at the same time. All of their programs are independant. And this issue seems to be random ie Downstairs Hallway linked to Dining Room Table and Dining Room Scene also linked to Kitchen lights.

 

What could possibly be creating links on the fly? Especially ones that do not appear in the device and scene table on the Main Tab?

 

At different parts of the day I modify (adjust Scene) the light level of these different rooms. For example at sunset I set the Pool Table to 100%, the Dining Room to 40%, the Hallway to 100%. All of these, any many others, run at sunset.

 

Could this be the issue? Could runnung these programs to adjust scenes, many of them runnung at the same time, cause random linking?

 

btw isn't the only way to create links a manual process? iow programs can't create links?

[LeeG]

I don't know of any way an ISY Program can create a link record.

 

The idea about the ISY Program was the Pool table was not responding to the Motion Sensor directly but indirectly because a Program was running when it was not expected to. An Event Viewer at change level 3 would show it an independent command was being issue agains the Pool table.

 

Without knowing what the Pool table link table looks like when it is turning On incorrectly it is hard to say if changing Bright levels or Ramp rates through Programs has anything to do with the result. That activity does alter the link database records so it cannot be dismissed. Perhaps a new link record is not being written but an existing link record is being changed in ways not expected or programmed to happen. We know that reading PLM link records sequentially can be adversely affected by Insteon traffic to the PLM. Have never seen a device link database get corrupted that way but I don't change link record Bright Level and Ramp rate values on the fly with any regularity. That is one of those things that can be done but I’m not sure Smartlabs envisioned that activity happening on a regular basis. Just too many commands, too slow to be done regularly. That may not have anything to do with the symptom you are seeing. Hopefully the device link database will offer some clues the next time it surfaces.

[LeeG]

thruster999

 

I think it would be a good idea to do a Show Device Links Table on the devices that were turning On when not expected while they are working correctly. Then do the same when they are turning On incorectly. That way the two displays can be compared to see the difference. That way there would be no guess work between working and not working.

 

Lee