LeeG

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.

Swnewman That is actually good news that both I/O Lincs show the same out of sync Sensor state. That tends to eliminate a wiring problem to the magnetic switches since each is wired independently. Also that a Query of each I/O Linc did fix both Sensor states. At least when the manual Query was issued both I/O Lincs reported accurate Sensor state information. Although not providing the answer to the cause itself both I/O Linc Sensors being out of sync tends to eliminate wiring and an individual I/O Linc failure. Can you post the ISY Log that covers the time from before the automatic Query was issued to the time where the KPL button LED was found On. Indicate the Insteon addresses of the I/O Linc.

Were the variable values set by the Program reflected in the Variables tab display of the State variables?

Are those Integer or State Variables? Were the values changed by the Program but did not trigger other Programs? If that is the case it sounds like the Variables are Integer Variables when they should be State Variables.