LeeG

Controlling the I/O Linc Relay from a KeypadLinc button is using a Scene to control the Relay. Now which Momentary Mode A,B,C the I/O Linc is in controls how the Relay will react to the KPL button press. In Momentary A mode the Relay will react to only one command (turn On), either Scene On or Scene Off but not both. I Momentary B mode the Relay will turn On with both a Scene On and a Scene Off. This is probably the Momentary mode you want to use. In Momentary C mode the Relay reaction is related to whether the Sensor is On or Off in combination with Scene On or Scene Off. All the detail regarding how the I/O Linc Relay reacts in each Momentary mode is covered in the I/O Linc User Guide. With the Green LED On all the time regardless of whether the magnet is near the reed switch, either the magnetic switch is bad, there is a short in the wiring or the wiring is not correct. So long as the Green LED goes out when the wires to the GND and Sensor connections are removed the I/O Linc itself is working. The I/O Linc does not send a message back to the ISY/PLM when Momentary mode turns the Relay Off. That is why the Relay can indicate On in the Admin Console much of the time even though the Relay is physically Off. This is normal.

For each Scene a device operates there is an ISY node. An 8 button KeypadLinc operates 8 different Scenes, thus 8 nodes. The 6 button KeypadLinc operates 5 Scenes, thus 5 nodes. With the TriggerLinc jumper in place one Scene is used, with On and Off commands sent for that one Scene. When the jumper is removed two Scenes are used, with On only commands sent for each Scene. Excerpts from the User Guide External Sensor Terminals When using an external sensor, TriggerLinc is in the closed state when either the external sensor terminals or the reed switch are closed. In other words, TriggerLinc opens when both the external sensor terminals and reed switch are open. Connecting an External Sensor to TriggerLinc NOTE: For the basic use of TriggerLinc’s external sensor terminals, it is not recommended to also use TriggerLinc’s internal reed switch to help ensure the desired behavior. Using the Internal Reed Switch and External Sensors When the TriggerLinc external sensors input is used in conjunction with its internal reed switch, TriggerLinc behaves much like several sensors connected in parallel (above), meaning: TriggerLinc will be open when both the internal reed switch and external reed switch sensor terminals show open TriggerLinc will be closed when either the internal reed switch or external sensor terminals show closed It is not possible to use the internal reed switch in combination with an external switch to achieve the combination you are looking for. It can be done using external only switches.

The Open/Close Sensor has two operational modes. Refer to the Open/Close Sensor User Guide for the details. There is a single jumper on the Open/Close Sensor PC board that controls the mode. The Closed node is used only when the other operational mode is used which requires removing the jumper from the PC board. The external switches can be wired in series or parallel. If NC switches are wired in series either switch being open will operate the TriggerLinc. With NO switches wired in parallel either switch will operate the TriggerLinc. Using the appropriate combination of NO or NC switches wired in series or parallel will provide whatever combination is needed.

A RemoteLinc and RemoteLinc2 are Controller ONLY devices. They have no actual On/Off Status and have NO Responder capability. The ISY simply sets Current State to the last command received from the respective button. Unlike a KeypadLinc that is both a Controller and Responder where a KPL button LED can be turned On/Off by another Controller, neither the RemoteLinc nor RemoteLinc2 have on board state indicators (what makes them Controller Only devices). Plus as oberkc mentioned, the RemoteLinc2 is a battery device which sleeps making it impossible to change what the RemoteLinc2 button will do next. It is not possible to achieve what you are looking for with the devices themselves.

rick.curl No. I emailed tech support with a reference to this forum topic.

rick.curl Thanks for that trace. Messages are reaching the ISY/PLM but they have an unusual data content. The Insteon architecture calls for the byte containing the 80 to be a Group number which for a Smoke Alarm would normally be expected to be a 01. I suspect that is why the ISY is not reacting to the Smoke Alarm message because it is not the expected Group 1 On Group Broadcast message. Will have to wait for UDI to confirm that. Sat 02/23/2013 08:24:42 PM : [iNST-SRX ] 02 50 23.4E.6B 00.00.01 C7 11 80 LTONRR (80) Sat 02/23/2013 08:24:42 PM : [std-Group ] 23.4E.6B-->Group=1, Max Hops=3, Hops Left=1 This is what the Leak Sensor sends for a Group 1 On message. Note the expected 01 in the message below where the 80 is in the Smoke Bridge message. Sat 02/23/2013 09:36:38 PM : [iNST-SRX ] 02 50 21.7A.CC 00.00.01 CB 11 01 LTONRR (01) Sat 02/23/2013 09:36:38 PM : [std-Group ] 21.7A.CC-->Group=1, Max Hops=3, Hops Left=2

Not that I know of. The Show Device Links Tables by the previous user will/would show any differences between the link records created by the ISY and those created by the Smoke Bridge itself. The Leak Sensor creates a link record with information that is not currently described in the Developer information. It could result in the PLM not seeing messages from the Smoke Bridge if it also generates these undocumented link records and the comm. between the Smoke Bridge and the PLM plug points is marginal. There is a possibility the Smoke Bridge plug point is not able to communicate with the PLM location. One test would be to move the Smoke Bridge to the PLM plug point. Run Tools | Diagnostics | Event Viewer at LEVEL 3. Trip the smoke detector with smoke and see if the event viewer traces any messages from the Smoke Bridge when plugged into the PLM location.

The KeypadLinc button and the device it is controlling must be Controllers of the same ISY Scene. The ISY will automatically cross-link the devices so they are in sync with each other.

If problems remain please provide the following along with a description of the problem(s). Thanks Does the Green LED at I/O Linc connections turn On and Off as door is opened and closed? If so is the Green LED On when the door is closed? What is being used to control the I/O Linc Relay? Admin Console turning Relay On/Off directly, using an ISY Scene, KPL button? Does the I/O Linc White LED turn On bright when the Relay turns On and goes dim when the Relay turns Off?

The door opener not functioning when the I/O Linc Relay N/O Com is connected is the result of not putting the I/O Linc Relay into one of the Momentary modes. When the I/O Linc Relay was turned On the effect was the same as pushing in and holding the manual button. Click the I/O Linc Relay node, click the Set Options button, set the Momentary hold time to 1-2 seconds and set Momentary A mode to start. Which Momentary mode will ultimately be used depends on other factors. The above should not have affected the operation of the I/O Linc Sensor. Factory resetting the I/O Linc erased the link database such that the I/O Linc can no longer send Sensor state change messages. Right click the I/O Linc Sensor node, select Restore Device to rebuild the I/O Linc link database. Watch the Green LED at the I/O Linc wire connector. It should turn On and Off as the garage door is closed and opened. If the Green LED does not cycle On and Off the wires connecting the magnetic switch were disturbed when working with the Relay connections.

jjp076 Do a Show Device Links Table for the Smoke Bridge and the device that was Set button linked with the Smoke Bridge. Post the Show images if you have the means of hosting an image. I don't think the forum is accepting .jpg files yet. If unable to post the Show images, Save the Show display results which will be an .XML file and post the XML file as text meaning the xml tags need to be included in the post text. Need to see what the links look like that the ISY established versus what the Smoke Bridge established with Set button linking.

First, an individual KeypadLinc button backlight level cannot be controlled. Setting the backlight level affects all buttons on the KeypadLinc and there is only Off/On level or % On level (depends on the KPL firmware). Cannot set a button backlight level to 50% of On level and later to 100% of On level. The KeypadLinc does not support that level of backlight control. Next, Secondary KeypadLinc buttons cannot be turned On/Off with Insteon Direct commands. It is necessary to assign the KeypadLinc button to an ISY Scene as a Responder and turn the Scene On and Off. All the intelligence needed to do different things with first button press versus second button press, whether a Secondary button is On with Main A from one KPL or Main A from another KPL has to be done with ISY Programs. The Secondary button D can be assigned as an additional Controller in an ISY Scene with one of the Main A buttons but control would be absolute. No logic to say turn On if either Main A is On. That type of logic can be implemented in ISY Programs taking into account the first two items in this post.

swnewman It is odd that it showed after the upgrade. Has a pretty obvious visual so it would seem hard to miss if it existed before. Without many reporting the same result it is not systemic. Have not found a way to recreate. I've restored SwitchLincs, deleted and readded SwitchLincs, cannot find anything that issues a command used to set the equivalent I/O Linc option. Of course moving to 4.0.1 here did not have that result on my SwitchLincs. The cat/subcat (device type) for the SwitchLinc and I/O Linc are very different so it does not seem likely the ISY would have confused a SwitchLinc with an I/O Linc. The cost to implement is the additional Admin Console code to manage all the various SwitchLinc, KeypadLinc, etc variants that now have these features. Plus the cost to regression test which is likely more than the cost to do the initial implementation. Button/paddle beep Blink LED on traffic Resume Bright and some others that do not come to mind are all candidates for future UI management.

swnewman Thanks for the information. I confirmed that my v.40 SwitchLinc has that feature so it would be expected on the v.41. Not sure how that option could have been set since the ISY has no function to manage these new options. Also confirmed the v.40 SwitchLinc has the ‘beep on button/paddle press' feature. A new KeypadLinc came up with the 'beep on button press' enabled after a very short (1/2 to 1 second) power outage. Have not wanted to do a factory reset to see if that would turn Off as that KPL is one I have a hard time communicating with using extended commands. None of my SwitchLincs in the test bed came up with 'blink LED on Insteon traffic' enabled from the short power outage so don't know if they are susceptible to the same type of very short power outage as the new KPL is.

swnewman What is the firmware level of the two SwitchLincs? Some devices have a feature that blinks the LED when it detects Insteon traffic. The ISY has no logic to control such a feature. Will do some research once I know the firmware level. Factory reset may eliminate but not sure about that.

Sounds like the Factory Reset was not successful. Perform the Factory Reset again. Before doing a Restore Device verify that button B does not control Main A in any way. If button B continues to affect Main A do the Factory Reset again. Must get the KeypadLinc to the point where button B has no affect on Main A before going past the Factory Reset. Once button B is independent of Main A, do a Restore Device to rebuild the KPL link database. If button B once again controls Main A in any way after the Restore Device, Delete the KPL from the ISY, Factory Reset the KPL until B no longer affects Main A, add the KPL back to the ISY.

Secondary KPL buttons cannot be controlled with Direct commands. Assign button C as a Responder in an ISY Scene. Turn the Scene Off.

Michel I thought I had seen a post from a user on 3.3.10 that I confirmed with my 2441TH. I may have already been on 4.0.x when I verified or the user must have been on 4.0.1. I thought the user reported the symptom before 4.0.1 was released. I'll go back to 3.3.10 and see if I can recreate. EDIT: I checked the dates and I had to be on 4.0.1 when I did my test. My apologies, I was wrong about it occurring on 3.3.10.

I think you contact sales@universal-devices.com to arrange to have the Pro option enabled. It allows more devices and Programs. There is a chart on the UDI web site that compares the various ISY models. Before thinking about upgrading the 99i to Pro, release 3.3.10 has been identified as the last firmware update for the 99i. This is due to the size of future images being too large for the 99i on board memory. See the following link for information on upgrading to a 994i. I think upgrading to a 994i first or part of moving to a 994i Pro is the more logical approach. UDI sales@.... can provide all the information. viewtopic.php?f=44&t=10771

As an FYI, not updating the Admin display also occurs at 3.3.10.

I traced the 3AM Query on my system this morning. Had one I/O Linc Sensor On and the other I/O Linc Sensor Off just to see what the trace of Query produced. No unexpected state results. The only thing I noticed is the Query is done twice, once for each I/O Linc node. Since a Query of either I/O Linc node produces a physical query command to both Sensor and Relay nodes the effect is the I/O Linc Sensor node along with the Relay node are queried twice. Nothing wrong with that as both queries produced the same state information. I note it because it is the only thing I saw in the trace that was not expected. There is some law in nature that when the event is watched it will not fail. Let’s hope yours will fail sooner than later. I'll run my trace again tonight but I don't see the change in Sensor state so I don't expect the 3AM trace here to show anything new.

The next step is to have the Event Viewer running at LEVEL 3 covering from when the doors were last closed even if opened/closed to generate Sensor messages when Event Viewer started through the 4AM Query so the actual I/O Linc Query and response can be seen. The ISY Log certainly indicates the both I/O Linc Sensors reported Off during that Query and the KPL button turned On..

The Smoke Bridge can be moved as none of the linking is related to its physical location. Moving the Smoke Bridge to the PLM plug point eliminated the powerline communication question. However, it did not communicate with the PLM at its old plug point. That is not going to change without fixing the powerline problem.

The trace shows the extended commands that are asking for the link database start address get no response from device. Plug the Smoke Bridge into the same plug point as the PLM and try again.

swnewman The ISY Log is a function separate from the event viewer. Under Tools | Log select Log. A popup will prompt for displaying in a spread sheet. Select No. Another popup will solicit the location to store the ISY Log file as .txt Each line is time stamped. Select some lines starting before the automatic Query through the time when the KPL button was found On. Paste those lines to a forum post.