LeeG

When temp > 50 and pump Off turn pump On

TJF1960 I would have to trace a Scene command sequence where the ISY is the Controller but I would doubt the Group Broadcast is the only message sent. Scenes could/would be very unreliable if only the Group Broadcast message was sent. Positive command acknowledgment and command retry is a hallmark of Insteon protocol and a major reason Insteon enjoys the reliability it has. All Insteon devices being a repeater and the mess RF/powerline network is also a major factor. There is a specific PLM serial command that initiates a Group/Scene. The PLM does all the heavy lifting to send the Group Broadcast message and follow up Group Cleanup Direct messages to each responder, including retrying any Group Cleanup Direct that is not ACKed. The PLM sends back a message to the application (ISY) if any responder fails to ACK the Group Cleanup Direct after all retries have been attempted. It would not be normal protocol for an application to reissue the PLM serial command to initiate the Scene again for an individual responder failure. The responder has already failed multiple attempts by the PLM to initiate the Scene command. No reason to think the next set of retries would be any more successful. All Insteon devices when functioning as a controller issue both Group Broadcast and Group Cleanup Direct messages. There are some exceptions for Dim and Bright Group command sequences. These are very time dependent sequences. It would be impossible to issue a Start Manual Change followed by a Stop Manual Change to every responder in sequence when a paddle/button is pressed and held. For normal On/Fast On/Off/Fast Off Group commands Insteon controllers always send both Group message types. Lee

TJF1960 Only the initial Group Broadcast message issued for a Scene is not ACKed by any individual Responder because it is not sent to any specific responder device. Following the Group Broadcast message the controller sends Group Cleanup Direct messages to every Scene responder in sequence and this message must be ACKed or it is retried. A Scene responder failure is known. Lee

douyon The missing piece in my first post was how to get Momentary A mode to react to an On command only. In my first post Momentary A mode responded to Off commands only. When I defined the Scene with the I/O Linc Relay as a responder the Scene was defined with the Relay On level as 0%. Moving the slider to 100% On for the Relay reverses the command the I/O Linc relay responds to in Momentary A mode. Momentary A mode 0% On Level - Off command only 100% On Level - On command only Also changing the Relay On level to 100% reverses how Momentary C mode responds Momentary C mode with 0% On level Sensor Off - On command energizes relay Sensor On - Off command energizes relay Momentary C mode with 100% On level Sensor Off - Off command energizes relay Sensor On - On command energizes relay With the various combinations of Sensor On/Off and Relay Responder ON Level 0%/100% the I/O Linc Relay will respond with whatever On command/Off command result you want. If you set up a test Scene with a KeypadLinc button as a Controller of the Scene and the I/O Linc Relay as a Responder, keep in mind that there is a Relay On level for the KeypadLinc button as Controller and a separate Relay On level for the ISY as Controller. Setting the I/O Linc Relay to Momentary C mode and the appropriate Relay Responder On level to 0% or 100% you can achieve whatever KeypadLinc button press (On versus Off command) reaction of the I/O Linc Relay you want. Lee

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.