LeeG

douyon First you need to make the I/O Linc relay a Responder in a Scene and turn that Scene On and Off to control the I/O Linc relay. All the I/O Linc documentation describes the I/O Linc operation using another Insteon device as a Controller. All Insteon Controllers (not counting HA applications using a PLM) use Group/Scene commands. That is why it is necessary to use a Scene when controlling the I/O Linc relay. Using Insteon Direct commands such as those used by the Admin Console when commanding the Relay Node directly produces different results. When using a Scene it then depends on which Momentary mode the I/O Linc relay has been configured to use. In Momentary A mode only the Scene Off command energizes the relay. If doing manual Set button links I think the I/O Linc relay can be set to react only to On commands or only to Off commands but I have not found a means for making the relay react to anything but only Scene Off commands using links established by the ISY. Reacting to only one command in Momentary A mode is consistent with the I/O Linc documentation. In Momentary B mode both a Scene On and Scene Off command energize the I/O Linc relay. This is consistent with the I/O Linc documentation. In Momentary C mode it depends on the state of the I/O Linc Sensor in combination with the Scene On and Scene Off commands. When the I/O Linc Sensor is Off (Green status LED Off) only the Scene On command energizes the I/O Linc relay. When the I/O Linc Sensor is On (Green status LED On) only the Scene Off command energizes the I/O Linc relay. This is also consistent with I/O Linc documentation. These are the observed results using my I/O Linc. Hope this helps. Lee

backinthelab The I/O Linc Sensor should be showing a reliable On/Off status under the Admin Console I/O Linc Sensor node. Querying the relay in any Momentary mode is difficult because the timeout value is going to turn Off the relay in a few seconds. Let’s get the basic I/O Linc working which should make Programming much easier and no band-aid required. Does the I/O Linc Sensor node reliably show sensor status? If not does the I/O Linc Green status LED correctly show the status reliably? If not then the magnetic switch location/installation is where to look. If that is the same magnetic switch that comes with the garage kit it is a wide gap switch which normally works even under the most adverse conditions. If the I/O Linc Green LED is always correct but the Admin Console Sensor node is not accurate the normal powerline analysis is appropriate. Perhaps the circuit the I/O Linc is powered from is noisy or too far from other Insteon devices to reliably reach other Insteon devices to be repeated. If the Admin Console never shows Sensor status change then device or PLM link records are in question. The I/O Linc Sensor uses Insteon Group On/Off commands (Scene commands) which require correct link records on both ends for the Group messages to be seen by the ISY PLM. Only when the I/O Linc Green LED is correct all the time and the Admin Console Sensor node is correct all the time is it useful to look at the Programming side. I'm sure you know but just in case if the Trigger Reverse is an issue then simply use the other wire (red/black?) which reverses the Senor state without the need for the Trigger Reverse option. Lee

JCBond My EZIO8SA is reporting Input 7 (1-wire) as ON and OFF to both the SHN Utility Inputs Settings and Monitor tab as well as the ISY Admin Console for the EZIO8SA node F. I am running 2.8.5 but I'm sure this was tested on earlier 2.8.x images. With the Event Viewer at Change level 3 - Device Communications Events, do you see any event activity as you turn Input 7 On and Off. The ISY does not support Input 7 in 1-wire mode. There is no mechanism to set the 1-wire trip points or the Enable 1-wire Configuration Register option. It should be working as the default digital mode Input and show basic On and Off status for node F. Let me know what the Event Viewer shows as Input 7 is cycled On and OFf. Lee

How long does the light flicker after turning the fan Off? Motors can generate a pulse when tuned Off but I have never heard of that affecting an Insteon dimmer that was already Off. Are the fan and light switch on the same breaker? Is it a SwitchLinc dimmer or ICON dimmer? If no wiring problems are found I would discuss it with Smarthome support.

What type of load are the "lights"? Are they on a dimmer and not at 100% bright. Is it a significant flicker suggesting a lose wire at the switch location or smaller flicker such as can happen with Insteon dimmers when not on an incandescent load?

Chris, Thank you very much for taking the time for your last post. That is what I got from the Wiki but so many different opinions were being posted that did not agree I was beginning to think I had interpreted the Wiki wrong. Really appreciate an explanation from the experts. Lee

Sounds like a communication problem to the EZIO8SA location. Why are you doing a Restore in the first place. Do you have Inputs 5&6 locked to GND. If not those inputs are floating. A built in pullup resister is not possible because those inputs can be used in Digital or Analog mode. If not connected to GND these inputs could be generating powerline traffic interfering with the Restore.

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

backinthelab Did you get the I/O Linc working with the garage setup? Happy to try and help if that is an open question. Lee

Ingeborgdot I came to the same conclusion. The WIKI says the AND has precedence over the OR which means the Motion sensor 1 is ANDed with the Sunset to Sunrise and the Motion sensor 2 is ORed so anything from Motion sensor 2 will trigger outside of the Sunset to Sunrise condition. belias suggestion for the use of the parenthesis will AND the Sunset to Sunrise to both the Motion Sensor 1 OR Motion Sensor 2 events. Lee

Whether you add the switches as responders only or controllers (which also makes them responders) depends on whether you want a paddle press on one switch to control the other switch. If a paddle press on one switch should turn on both switches then they should be controllers of the scene.

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.

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.

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.

Are you perhaps testing through the Admin Console to send On and Off commands to the I/O Linc Relay node. I have found the Insteon Direct commands the Admin Console uses for all devices when working with a specific device do not react the same as Inteon Group commands used for Scenes. Controlling a Scene, either through the Admin Console or KeypadLinc button, with On and Off commands does trigger the I/O Linc relay in Momentary B mode on my I/O Linc. The Admin Console using the I/O Linc relay node does not turn On the relay with the Off command. The I/O Linc Momentary mode appears to apply only to Scenes (Group commands) and NOT Insteon Direct command Off commands.

apostolakisl What is the "Music" Scene definition, Controllers and Responders? What is the If condition in the Program that is not being triggered. Lee

The only way the ISY knows that a Controller changed the Responder state (other than doing a Query of the Responder) is for the ISY PLM to be a responder to the same Scene that is changing the KeypadLinc button. Normally the ISY includes the ISY PLM in Scenes it defines so that the ISY knows of changes. In this case since the ELK is initiating the Scene (don't know how the ELK as a non-Insteon device does that) it appears the ISY PLM is not part of the Scene the ELK is initiating. There is nothing in the Insteon architecture that would make the ISY aware of a responder state change by a Controller unless the ISY PLM is also a responder to the Scene.

From the online I/O Linc user Guide. Momentary A Either an ON or an OFF can be programmed to trigger the I/O Linc relay. The other command will be ignored. Momentary B Send either an ON or an OFF to trigger the I/O Linc relay. The I/O Linc relay will respond to both It would seem Momentary B is what is needed for the I/O Linc relay to respond to both On and Off commands. Keep in mind that the relay is simply closing its circuit to make the door move. The relay does not do something special to make the door open versus make the door close. If the door is closed and the relay energized the door will open. If the door is open and the relay is energized the door will close.

Try posting the question on the Smarthome Channel or the Smarthome forum itself. If it does the sales page for the adaptor has not been updated to reflect that support.

The link database requires a null record at the end of the active link list. This is sometimes referred to as the high water mark in some of the Insteon docs. What operation are you trying to perform, add device to a Scene, remove device from a Scene, etc.? Are you able to control the in-line linc manually through the Admin Console and does the switch respond to changes to the Sense line? Suggest turning on the Event Viewer with Change level 3 to see the actual failure to confirm high water mark problem. It sounds like a powerline communication problem. Whether it is a problem with the device in general or something specific to the link database should be determined by the ability to control the device manually through the Admin Console.

They could not have a found a better location if they trying to hid it on purpose.

That is good information. A PLM does not accept a message from a device that does not have an active link record in the PLM link database. The next step would be a File | Restore Modem (PLM) function to get the ISY to rewrite the PLM link records.

Okay, thanks. You are on the right track. The EZIO8I Input states should show up in real time under the Admin Console and those state changes can be used to trigger an ISY Program. Once the necessary link records appear in both the EZIO6I and the ISY PLM I would expect to see the Admin Console display to change for the EZIO6I Inputs just like any other Insteon device. I have various EZIOxx devices installed and they all show real time Input changes. I have been running 2.8.4 for about as long as it has been available.

The EZIO6I Input state changes should be real time in the ISY. You should see each Input turn On/Off using the Admin Console. The ISY needs to be at one of the 2.8.x images and the EZIO6I added to the ISY using one of the 2.8.x images. If the EZIO6I was added to the ISY using an image before 2.8.x and/or your ISY is not on one of the 2.8.x images Input state changes will not be processed correctly making the need for the Query. When you indicate "I'm trying to use ISY to send me a message", what is the me? Is this an ISY Program? The all zeros link record marks the end of the active link record list. The EZIO6I must appear in the PLM Links table. Insteon hardware requires these link records in the ISY PLM to receive Group messages from any Insteon device which includes the EZIO6I. Since you do not have any Scenes defined for the EZIO6I I would suggest Removing the EZIO6I and adding it back using the latest 2.8.4 ISY image.

I'm beginning to think I do not understand how you are using the ISY in your environment. Link records are basically static once established. They do not change as the EZIO6I Inputs change state. The link records in the EZIO6I provide the Insteon address of the ISY PLM so the EZIO6I knows where to send the Group On/Off messages representing Input state changes. The link records in the ISY PLM allow the PLM to receive these Group On/Off messages which support the use of things like "If Control EZIO6I Input 1 On" in an ISY Program. That is not the actual ISY Program syntax but represents the nature of the logic statements in an ISY Program. Are you trying to write your own program independent of the ISY that would handle Insteon message traffic? Seems like all the great ISY capability to detect device messages and trigger ISY Programs is not being considered in your solution. Please expand on what direction you are taking. My responses have assumed you would be using ISY Programs which do not deal with link records directly as that is all done automatically under the covers by the ISY. If you are implementing outside the ISY environment then you have a completely different set of requirements.