LeeG

It is due to the KeypadLinc sending additional messages beyond that which triggers the Program. Insteon devices handle that, X10 do not. Sending multiple commands is the same as adding a delay. I know of no other way than delaying the X10 traffic until the Insteon traffic is finished.

The links can be removed by using the Set button to unlink the devices or a Restore Device can be done which will rewrite what the ISY is aware of and delete other links that may exist. Be sure to Restore Device to both devices so broken links are not left behind if you chose to use Restore Device. Since it sounds like no ISY Scenes have been created it may be just as easy to delete the devices from the ISY and add them back with the erase existing links option. That will also insure there are no unexpected links.

"if any of the var are not 0 then run the program but if any of the var are not 0 then do nothing" I can provide a sample but please fix the objective wording. If any are not 0 run Program, if any are not 0 do nothing???

Never do Set button links while using an ISY. The ISY is not aware of them and will over write them. Define an ISY Scene. Add the TriggerLinc to the Scene as a Controller, the light switch as a responder. If the light switch is in a multi-way configuration (more than one switch controlling the same load) all the switches should be added to that one ISY Scene as Controllers. The ISY will cross link them as needed to keep them in sync. There are some exceptions to creating Set button links but they are spelled out in the Wiki and they are for special devices. Most Insteon device should never be Set button linked.

How did you create the link between the TriggerLinc and the light switch?

Check the link between the MorningLinc and the lockset by pressing the Set button on the MorningLinc. The lockset should cycle for each Set button press on the MorningLinc.

Nothing wrong with that so long as the linking was done by defining an ISY Scene and adding the devices to the Scene. That way the ISY is aware of the link records. It is my preference to link devices together directly (using ISY Scenes). Fastest response time and things continue to work should the ISY be down for maintenance.

Vince The way the MorningLinc is added to the ISY is critical. Start Linking must be used and the third linking option to "keep existing links" must be used. Otherwise the MorningLinc will not accept commands from the ISY. If that procedure was not followed when the MonrningLinc was added it must be deleted and added back to the ISY using that method. The UDI Wiki covers the process of adding a MorningLinc to the ISY. Lee

Under Link Management click on New Scene. Assign some meaningful name and click Ok. The Scene names will be listed after the devices in the My Lighting tree. Right click on the nodes in the My Lighting tree and select Add to Scene ... Select the Scene name and select whether the node should be a Controller or Responder to a Scene. Motion Sensors and TriggerLincs can only be Controllers. Light switches such as SwitchLincs can be Controllers or Responders. Once the Scene has been defined and the nodes added the Program Adjust Scene statement can be used to adjust the responder On Level for the light switch. The problem is the motion sensor is going to turn the lights out after 1 minute regardless of the On Level setting. The solution is to set the motion sensor to On Only mode. In this mode the motion sensor sends only On commands (no Off commands). This also means an ISY Program has to be used to turn the lights Off after some interval if automatic Off is desired. This automatic Off Program would be triggered by a motion On message. The Program If could be ANDed with the KeypadLinc button Status On and prevent the Program from issuing the light Off if cleaning day. There is a lot here is just starting out. I suggest reading the ISY User Guide and the ISY Wiki for information on writing ISY Programs before starting.

Hope the Motion Sensor(s) were linked using the ISY. Otherwise the ISY will eventually wipe out those links because it is not aware of their existence. If the Scene was an ISY Scene linking the Motion Sensor to the light switch the light switch Responder On Level can be changed from 50% to 100% with a Program Adjust Scene Action statement. Then restore to 50% when cleaning is done. Something like a particular KeypadLinc button used to signal "cleaning dayâ€. The KeypadLinc button On command would trigger a Program Then clause to set the Scene Responder On Level to 100%. The KeypadLinc button Off command would trigger the same Program Else clause to set the Responder On Level back to 50%. If cleaning is always on a certain day during a particular time range a time/day driven Program could always set the Scene On Level to 100% on a specific day at a specific time and set it back to 50% at the end of the time range. That may only be half the problem. Does the Motion Sensor turn the lights Off after the timeout interval or are they turned Off manually?

No, sorry that is not what I am saying. You indicated that Motion Off triggers the Program. Assuming that statement is correct, the Program is going to trigger with Motion Off regardless of the value of the variable. The value of the variable will determine whether the If evaluates to True and the Then Clause runs, or the If evaluates to False and the Else Clause runs but the Program will run because of the Motion Off trigger. The True/False evaluation of the If does not determine whether it triggers or not. The True/False evaluation only determines which clause, Then or Else, runs. Changing to a State variable does not change the True/False evaluation. Using a State variable would cause the Program to be triggered whenever the State variable value is changed. Does not sound like what you want. Making the If False does not stop the Program from being triggered. Making the If False results in the Else clause running when the Program is triggered by whatever conditions are in the IF that trigger Programs. When looking at an If statement separate out those definitions that cause a Program to be triggered from those that control the evaluation of True/False.

The Program will trigger, the Else clause will run. Setting an Integer variable does not control whether a Program is triggered. It does control whether the Then clause or Else clause runs when the Program is triggered by some other activity.

Integer variables DO NOT trigger a program. Changing an Integer variable to something that makes the IF False does not make the last program execution false because the Program was not triggered. Something else in the IF must trigger the Program to run and then the IF will be false because of the 1 in whole-house.

Don't worry about the wiring. Whether using red/black or green/black is a matter of personal choice. Should the I/O Linc Sensor be On when the door is closed or should the Sensor be On when the door is open. Either works, just have to have some of the other options set to be consistent with the Sensor. The Scene Responder On Level for the Relay determines whether an ON command turns the Relay On or an OFF command turns the Relay On, in combination with whether the Sensor is On or Off (assuming Momentary C). Just have to set the On Level consistent with the Sensor state which is controlled by using green/black or red/black. Neither implementation is right or wrong, simply your choice as to whether the Sensor is On when the door is closed or On when the door is open and what restrictions do you want to put on what command will do what action. Same with the Momentary mode. Momentary C is neither right nor wrong. Simply another choice. In Momentary C the Insteon Scene On/Off commands much match the Sensor state. In Momentary B either command will turn the Relay On regardless of the Sensor state. Again, personal choice. Just a matter of how you want it to work. Neither choice is right or wrong. I made an assumption about the Sensor state versus door open/closed. It would have been a better answer to tell you to reverse the On Level rather than set a specific value. As an FYI it is not how many times the button is pressed that makes the difference. It is whether an On or Off command is sent. It may be necessary to cycle through a button press to get to the correct command but it is not the number of presses that makes the difference. It is that the correct command is being sent.

jjpoje Can I assume the ISY is not on one of the latest Beta images. Reversing 0%-100% or 100%-0% On Level setting reverses what the On and Off commands do. Glad it is doing what you want. Lee

"Then I used the black and red wires and now the sensor reads correct (off for closed, on for open)." The red/black combination uses the magnetic switch that is electrically open (not making connection) when the door is closed and electrically closed (making contact) when the door is open. This means Green LED Sensor will be On when the door is open, Off when the door is closed. What the Sensor node in the ISY shows depends on whether Trigger Reverse is used or not. Stopping the door half open looks the same to the Sensor as being completely open. The only way to achieve the KPL response you are looking for is to install a second magnetic sensor that is activated when the door is fully open. That way the combination of sensors indicate closed, part open, fully open. With that knowledge the ISY Programs can be written to show the door still open even thought the command to close the door was given which actually used the emergency stop capability and stopped motion half way through the cycle. Without the additional sensor it is not possible to differentiate the partial open from the full open.

jpoje In the Scene where the KPL button is the Controller and the I/O Linc Relay is the Responder, check the On Level for the I/O Linc Relay when the KPL button node below the Scene name is clicked. For the ON command to open the door the On Level should be 100%. The ISY is setting the I/O Linc Relay Responder On Level to 0% as the initial value when the Scene is created. This would cause the OFF command to open the garage door which is what is happening. The first KPL button press turns the KPL button ON but does not move the door because the Relay does not turn On. The next press turns the button Off sending an OFF command which now moves the door because the Relay is responding to an OFF command when the door is closed. This happens when the Relay Responder On Level is 0% rather than 100%. Lee

Run the Event Viewer using one of the 8 button KPLs. Is a different Secondary button being used when in 8 button mode? Sounds like a Scene or Program did not get updated. For example, button D on a 6 button is totally different from button D on an 8 button.

It should not make any difference between a 6 or 8 button KPL. When the KPL button has to be pressed twice can I assume that the KPL button LED is turning On and Off with each press but the I/O Linc Relay is only reacting to either an ON press or an OFF press but not both? It should not make any difference between a 6 or 8 button KPL. When the KPL button has to be pressed twice can I assume that the KPL button LED is turning On and Off with each press but the I/O Linc Relay is only reacting to either an ON press or an OFF press but not both? Suggest running Tools | Diagnostics | Event Viewer with Device communications selected. From identical situations, both doors closed, both KPL (6 & buttons Off. Press the button on the 6 button and let the door open. Then press the button on the 8 button. Does the door open or no and does the KPL LED turn On or no.

Thanks Rich. Sorry for not being clear, I was asking what ISY firmware level has been running for that 1.5 to 2 years.

ahwman What type of device is controlling the front porch light (dimmer or relay) and what type of load (CFL, LED, incandescent)? Lee

How is the light being turned ON, with a Program or Scene? If a Scene was the Scene created under the ISY or was the TriggerLinc linked to the light with the Set button. If the later the ISY would not know about it. If an ISY Scene was used to establish the link between the TriggerLinc and the light there is a communications problem between the TriggerLinc and the ISY PLM or there is a link record problem between the TriggerLinc and the ISY PLM such that the PLM does not see the TriggerLinc turning on the light. If using an ISY Scene run Tools | Diagnostics | Event Viewer with Device communications events selected and see if the TriggerLinc state change message is reaching the PLM. The TriggerLinc that is showing Closed ON means the TriggerLinc sent an ON when the TriggerLinc closed and the jumper on the TriggerLinc PC board is not connected. If the Opened node changes from On to Off to On then the jumper is now working and take it as a one time TriggerLinc failure. If the Opened node does not cycle On to Off to On the jumper is not working and the TriggerLinc is working in the alternate two node mode.

stillen_i30 The I/O Linc Relay is set for Momentary C mode. The ON command issued when the KPL button is pressed On works only when the door is closed and I/O Linc Sensor is Off. Stopping mid movement the I/O Linc Sensor is still On as though the door is fully Open. Try Momentary B which will cause the Relay to turn On regardless of the Sensor state. I do not use that Wiki example so I cannot say if there are other implications using Momentary B with your configuration. The other approach is to ignore the situation. How often do you use the emergency stop capability of the door opener? May not be worth scrambling an otherwise working solution. Lee

In all cases that have been reported where the Variables tab was missing, a version of the Admin Console was being used that was before Variables were introduced. The situation was likely resolved when the URL to access the Admin Console was updated to 3.1.16. Check Help | About to be sure both the Firmware line and the UI line (just below the Firmware line) indicate 3.1.16.

The link record for KPL button D is missing. With the ISY compare not showing a missing link record the ISY has lost track of the link record for button D. Does the Help | About show 3.1.15 for both Firmware and UI (UI line is immediately below Firmware line)? What firmware level has been running since the KeypadLinc was replaced? EDIT: the link records are not in the order they would normally be. Was a Restore Device issued for the KeypadLinc and if so why?