One IO Linc activating all other IO Lincs (not in a scene)

[johnnyt]

One of my IO Lincs when its relay activates cause all my other IO Lincs to activate (all control some HVAC related stuff). They are not part of a scene and they are not set to respond to X10 addresses. (FWIW, I did set the misbehaving one to *send* an X10 address at one point but I removed it and see no evidence of X10 going out on the line - but still the other IO Lincs aren't set to respond to an X10 address so this should be irrelevant)

 

I replaced the misbehaving IO Linc with a new one (using ISY) and the behavior continues with the new one (indicating it's not a h/w problem) so I checked the device links file for a couple of the "other" IO Lincs and noted one record related to the misbehaving IO Linc (17.78.CF).

 

The (sole) record is A2 01 17.78.CF 00 00 00 in both other devices. Can someone tell me what that means? Am guessing it's a remnant from a scene I might have toyed with that is not longer around but didn't get deleted for some reason. Or it's some kind of linking sequence gone bad where all IO Lincs somehow got linked to the one. Assuming that's the case, how do I delete the record?

 

Any info / other suggestions as to what might be happening would be appreciated.

[LeeG]

"The (sole) record is A2 01 17.78.CF 00 00 00 in both other devices."

 

This is a Responder link record. It means the device containing this link record will respond to a Group 1 On/Off command from 17.78.CF. If 17.78.CF is the Insteon address of an I/O Linc, Group 1 is the input Sensor. The I/O Linc containing this link record will respond to the I/O Linc input Sensor with the Insteon address of 17.78.CF.

 

If all else fails, delete the I/O Linc, perform a Factory Reset on it, add it back to the ISY.

[johnnyt]

This is a Responder link record. It means the device containing this link record will respond to a Group 1 On/Off command from 17.78.CF.

A responder link for an IO Linc? Two things seem weird to me about the programming that has entered in these IO Lincs. One, the other IO Lincs would react to my pushing the set button, which is inconsistent with the behavior of an IO Linc - the other IO Lincs I have certainly don't broadcast a manual push or sensor input change. (I have to query them for ISY to know they changed.) Why is this one doing it?

 

Also, I've removed the offending IO Linc by manually adding a new one to every scene the other one belonged to and replacing the old one for the new one in every program then DELETED the offending IO Linc (17.78.CF) yet a record remains in the other IO linc devices and in the main links table...

 

What's going on? How do I kill this mummy? Do I have to remove and re-add every "other" IO Linc manually? (yuk) I assume just doing a device restore will only add the responder link back in...

 

Thanks

[LeeG]

"A responder link for an IO Linc?"

 

A Responder link record in an I/O Linc is associated with the Relay aspect of the I/O Linc. The Controller (with Insteon address 17.78.CF) sends a Group 1 On/Off command and the I/O Linc containing the Responder link record will turn the Relay On/Off in response. Depends on the Relay mode (latching, versus momentary) what the relay will actually do.

 

With the last three bytes of the posted link record being 00 00 00, and the last three bytes of link records the ISY wrote to my I/O Linc being FF 00 00, I conclude the link record was created by the Set button method.

 

"(I have to query them for ISY to know they changed.) "

 

An I/O Linc that is not sending an indication to the ISY that the Sensor has changed state has a link record problem. Either missing or corrupted in the I/O Linc or missing or corrupted in the ISY PLM. This link is established when the I/O Linc is added to the ISY. With an indication that a link was established with the Set button in one of the I/O Lincs it sounds like a Set button link is in conflict with what the ISY established.

 

"One, the other IO Lincs would react to my pushing the set button, which is inconsistent with the behavior of an IO Linc"

 

If other I/O Lincs are reacting to the relay activity of one I/O Linc it might be the way the I/O Lincs are wired rather than being commanded to do so.

 

There is so much wrong, link record that should not be there, I/O Linc not reporting a Sensor state change, I suggest deleting the I/O Lincs, Factory reset the devices, add them back to the ISY and DO NOT connect the wiring to any of the relays. Verify that the ISY sees the Sensor state change of all the I/O Lincs. Then verify that turning the Relay on one of the I/O Lincs does or does not have an effect on any of the other I/O Lincs. If things work correctly, connect the Relays and see what happens.

[LeeG]

After the link records have been cleaned up, if there is still unexpected interaction between the I/O Lincs, please describe the situation with some additional detail.

 

What is the actual interaction between the I/O Lincs? Relays turning On uncommanded, input Sensor changing state, etc

 

If it is Relays turning on uncommanded does a Query indicate the Relays are On?

 

What I/O Linc options are in effect? Latching mode versus Momentary mode, Relay follows Input, Trigger reverse, etc.

 

Are the I/O Linc Relays controlled with Direct commands from an ISY Program (no Scenes)?

 

How/what are the input Sensors connected to?

 

How/what are the Relays connected to?

[johnnyt]

I've since tried completely removing the problematic IO Linc (I'll call it IO Linc "A") from ISY but the responder record for it remained in at least 2 of the other IO Lincs. (Am only checking 2 of the 5 "other" IO Lincs but all of them behave in the undesired way.) Then I tried re-linking IO Linc A since the last step in that process is to "remove existing links".

 

Even after removal of IO Linc A, which is supposed to remove all links, and re-linking it, which is also supposed to remove all links, the "responder" record entry remains in the other IO Lincs.

 

When I tap the set button on IO Linc A the others all go ON / OFF in sync with the activation state of IO linc A.

 

All these IO Lincs are related to HVAC stuff (Furnace Fan High Speed, HRV High Speed, HRV Low Speed, Humidifier, Motorized Dampers). I used the sensor input of IO Linc A to monitor a furnace AC call with a low voltage detector probe and believe the problem stems from a scene I created for the purpose of querying all the devices periodically (since manual activation and sensor activation wasn't updating ISY). I added the input sensor of IO Linc to the scene intended for this query and it added it as a controller (I had no choice in the matter - I would have chosen responder if given the choice since the intent of the scene was to query the devices, not control them)

 

The problem of IO Linc A activating the other ones must have started happening after that scene was created (I'm not sure). In my attempts to fix the issue I think I likely reset/restored the IO Linc, removed and added the device, and I don't know what else but I did struggle with it for a while myself.

 

The bottom line, though, is that a responder record remains to this day in 5 IO Lincs and gets updated by ISY to match a new IO Linc device address however doesn't similarly delete the record when I delete the device.

 

All the IO Linc are configured per the attached screen shot. The offending IO Linc (A) was configured with "Relay follows Input" at first but that was removed later. This doesn't prevent the activation of IO Linc A from activating the other IO Lincs.

 

I likely messed up something in my attempts to recover after the scene I created did the unexpected/unwanted but something else is messed up and the record has gone rogue on me.

 

Is there a way (e.g. command line?) to surgically remove a record from a device?

[Michel Kohanim]

Hello johnnyt,

 

On the responder IOLincs, if you go to Tools | Diagnostics | Show ISY Links Table for each, does the controller IOLinc address show up in there?

 

With kind regards,

Michel

[johnnyt]

yes. the address is both in the devices and in the ISY Links table. I did compares while I was checking the deive and just checked the ISY links table again now for a few of them.

[Michel Kohanim]

Hi johnnyt,

 

This is extremely odd. Would you be kind enough to print your topology (Tools | Topology) and see if those responders belong to any other scenes at all? If so, to what other scenes?

 

As you have noted, the problem is the responder links ... they should have been removed but they have not been. Can you also tell me your firmware version please?

 

With kind regards,

Michel

[Michel Kohanim]

Hi johnnyt,

 

This is extremely odd. Would you be kind enough to print your topology (Tools | Topology) and see if those responders belong to any other scenes at all? If so, to what other scenes?

 

As you have noted, the problem is the responder links ... they should have been removed but they have not been. Can you also tell me your firmware version please?

 

With kind regards,

Michel

[johnnyt]

am running firmware 3.1.3

 

I think I know what you're asking but I'm not sure.

 

I generated the topology and the first thing I did was look for the "bad" IO linc. Not found. I then picked a couple of the IO Lincs that respond to the "bad" one and looked at each one of the scenes it said they belong to. None of the scene include either the sensor or the relay from the "bad" IO Linc in them.

 

Would you like me to provide you screenshots of the scenes that include some the responding IO Lincs to validate this?

[johnnyt]

am running firmware 3.1.3

I should mention this likely occurred a number of firmware versions ago. I created the scene that probably created the now rogue link record several months ago and have upgrade a few times since then.

[johnnyt]

None of the scene include either the sensor or the relay from the "bad" IO Linc in them.

sorry, that's not accurate. None of the scenes include the sensor input from the "bad" IO Linc but some do include the relay in case that makes a difference.

[LeeG]

If the action of the “bad†I/O Linc relay controls a circuit that leads to the Input Sensor changing state then seeing the “bad†I/O Linc Show Device Links Table output along with the Show Device Links Table output from two other I/O Lincs that are responding will show any linkage between the devices.

 

If this information is posted identify the Insteon address of the “bad†I/O Linc, the other I/O Lincs displayed as well as the ISY PLM.

 

Just read the last series of posts. Suggest posting each of the I/O Linc Show Device Links Table output.

[johnnyt]

If the action of the “bad†I/O Linc relay controls a circuit that leads to the Input Sensor changing state...

The "bad" IO Linc relay did not lead back to its own sensor, if that's what you mean. The sensor was used to detect an AC call. I'm currently using another IO Linc to do this job and everything is working fine. When the sensor is activated (i.e. Call for AC) I have a scene to turn on some of the relays on other IO Lincs (close basement dampers, etc.) but that scene is controlled by an ISY program, not the sensor input.

 

Have attached a screenshot showing the device and ISY links table of one of the five IO Lincs that responds when I activate the relay on the bad IO Linc. I circled the address of the "bad" IO Linc which has been removed (twice now) from ISY and sits unplugged/unused on my workshop bench.

 

By the way I can just plug the "bad" IO Linc in, not link it to anything and the other IO Lincs respond when I tap the set button. This by itself is strange to me given my understanding that the manual activation of an IO Linc relay did not broadcast it's state. (which was the reason I needed to create a scene to query my IO Lincs in the first place). Am less concerned at this point about the apparent inconsistency in behavior or in my understanding as I am about deleting the rogue record.

[LeeG]

The link record circled in red is a Responder link record. I/O Linc 15.B8.5D relay will respond to commands from device 17.78.CF. This link record does not control another device.

 

To prove this remove all wires (Sensor and Relay) connected to 15.B8.5D. Tap the Set button on 15.B8.5D. No other I/O Linc will be affected by the Set button tap.

 

Only link records which start with E2 control other devices. The only E2 link record in 15.B8.5D is the one pointing back to the ISY PLM 14.83.D8 which allows ISY to be aware of input Sensor state changes.

[johnnyt]

I think my basic request is getting lost. I don't want anything responding to 17.78.CF so I want to delete the record with 17.78.CF in it from the five IO Lincs it currently exists in. How do I do that? (a quick reminder that removing/re-installing/re-moving the device didn't do it.)

[LeeG]

An I/O Linc was deleted from the ISY, added to the ISY as a new device and when the add completed it has a responder link for 17.78.CF? Is that really all that was done.

[LeeG]

I'm going to step aside on this one. There may be a simple solution but with the information posted I am not able to determine even what situation actually exists, let alone what was done to get it that way. I believe it would be a mistake to try and correct this by manually editing the ISY files. It is easy to delete the physical link record in the device but so long as the ISY believes it should be there it will come back.

 

The I/O Lincs automatically notify the ISY of any Sensor state change. Relay state changes should only be made by ISY Programs or Scenes the ISY has created. If done this way the ISY will know the state of the Relay as well (unless using Momentary mode). Eliminating this particular link record does not begin to address the symptoms mentioned (ISY not being aware of state changes, Scenes needed to be aware of I/O Linc state). There are other link record problems or communications problems where the I/O Lincs are installed.

 

Good luck.

[Michel Kohanim]

LeeG, thanks so very much for all your help.

 

johnnyt,

 

I am getting a little confused. I thought the problem is that you have devices that respond on their own to another IOLinc to which they were once linked. I am not sure I understand what the "bad" IOLinc got to do with everything else.

 

In any case, this is what you have to do to get rid of bad IOLinc responder link:

1. Find out in which scene Basement Dampers S is a controller

2. Add the bad IOLinc in that scene as a responder

3. Check the Link records and make sure you still see the bad record

4. Remove the bad IOLinc from the scene

 

If this does not work, then I suspect that we have a corrupted database file on ISY.

 

With kind regards,

Michel

[johnnyt]

Sorry that I've made this confusing.

 

Re-adding the "bad" IO Linc (17.78.CF), creating a scene with it's sensor and all the other IO Lincs then deleting that scene deleted the rogue records and fixed the problem.

 

I've also learned that:

1) putting an IO Linc sensor as a controller in a scene makes the manual tapping of the set button on the IO Linc activate that scene.

 

2) one cannot add an IO Linc sensor as a responder to a scene (e.g. for querying purposes) until it has already been added to a scene once as a controller because ISY assumes one wants/needs it to be a controller the first time around. Perhaps the right assumption most of the time but not always, particularly given the behavior mentioned in 1) above.

 

Thanks.

[Michel Kohanim]

Hi johnnyt,

 

Thanks so very much for the update.

 

You cannot add a sensor as a responder since they DO NOT respond; they are controller's only. You can put the Relay in a scene as a responder.

 

With kind regards,

Michel

[johnnyt]

actually one is able (in fact forced) to add a sensor as a responder when it is already a controller in another scene. I was going to use that as a workaround but I ended up doing things differently.

[LeeG]

Thanks for documenting the situation. This is a glitch in the Scene GUI. It should not have allowed the I/O Linc Sensor node as a Responder.

[Michel Kohanim]

Hi johnnyt,

 

What firmware version were you using. The scene UI does NOT allow a sensor node to be added as a responder.

 

With kind regards,

Michel