LeeG

Welcome to the ISY forum. Smarthome changed the garage door kit magnetic sensor some months ago. I recommend changing the magnetic sensor. The I/O Linc has a 'Trigger Reverse' option which reverses the commands sent by the I/O Linc Sensor. When Sensor turns On the I/O Linc sends an Off, when the Sensor turns Off the I/O Linc sends an On. That will fix the KPL LED problem. However, the I/O Linc Query response is not reversed by the Trigger Reverse option. The 3AM QueryAll Program issues a Query to all devices to get things in sync in case a status change was missed during the day. It means the Sensor status changes at 3 AM because the Query is returning the actual Sensor state, not the command reversed state. Note that if running 3.2.6 Official release there is a problem with the I/O Linc Set Options function when the I/O Linc is one of the new I2CS devices which yours is being new. That may explain a Momentary mode problem. Also note that the ISY does not write an update if it thinks those same options have already been set. I suggest installing 3.3.4 (RC1) which has the fix for the I/O Linc Set Options. Although 3.3.4 is a beta it is a candidate for the next Official release (RC1).

Really need to see the Program. When at the ISY check for basic stuff like it is Enabled, there are no Saves pending for the Program. With a False status it suggests the Program did trigger but the If condition was evaluated as False which would cause the Else clause to run. Perhaps the previous iteration is generating a False If even thought the current (not saved) version should not be false.

Need to select Level 3 when running the Event Viewer. The default Level 1 does not show command execution or response. Be sure Leak Sensor is near a dual band device and the LED on the Leak Sensor is blinking before clicking Ok on New INSTEON Device.

golfleep Check Help | About, verify both Firmware and UI show 3.3.4. The Leak Sensor is listed in the Device Type pulldown on 3.3.4. The UI (Admin Console) may not be at 3.3.4 Could also be out of RF range. If Help | About shows 3.3.4 for UI, run Tools | Diagnostics | Event Viewer with Level 3 selected. Use New INSTEON Device, enter Insteon Address, Name of choice and leave Device Type set to default Auto Discover. Be sure Leak Sensor is in linking mode (awake) before clicking OK. Post trace.

The KeypadLinc has to be Deleted and added back in the new button configuration. Then the new nodes are added to the Scenes. When a 6 button KPL is changed to an 8 button KPL, the 6 button A,B,C,D nodes become C,D,E,F nodes. When going the other way 3 nodes are lost completely. Although this is all internal configuration information not normally of any concern to the ISY user, 6 button KPL hardware/firmware uses button A = Group 3 button B = Group 4 button C = Group 5 button D = Group 6 When converted to 8 button configuration the KPL hardware/firmware uses button A = Group 1 button B = Group 2 button C = Group 3 button D = Group 4 button E = Group 5 button F = Group 6 Not to worry about how Insteon uses the Group number. The point being that how button A is recognized in a 6 button KPL is different in how button A in an 8 button KPL is recognized. I am not saying that enough rules could not be developed to try and make the conversion automatic but it is very complex at best and does not work going from 8 to 6 because 3 Groups are lost altogether.

Status reflects the last If section evaluation. A Program with True status means the last time the Program was triggered the If section evaluated to True causing the Then clause to execute. A Program with False status means the last time the Program was triggered the If section evaluated to False causing the Else clause to execute.

Do you know what the values were before setting to Pacific. There are locations in India that are x.5 off of GMT.

It is a wonder the TriggerLinc works at all after applying 24v AC to terminals that are expecting a dry contact switch. A small 24v AC relay can be connected in parallel with the door bell. When the door bell button is pressed the relay turns On. The relay dry contacts are connected to the TriggerLinc external connections.

SmartLabs does not release information as to function at the various firmware levels. I don't think anyone has gotten the clock update to work on anything except the 2441ZTH (which I can confirm works) and maybe the 2441TH (which I have not tried yet). If the clock is set the firmware supports it. That is how you know. No has reported successfully setting the clock programmatically on any of the Venstar thermostats.

After a Factory reset which clears the device link database, right click the primary node and select Restore Device.

The RemoteLinc firmware does not matter. The KeypadLinc is too old to support turning a Secondary KeypadLinc button Off with an On command from another Controller (RemoteLinc in this case) The Set Scene in the Program should issue a Set Scene 'xxxxx' Off to turn Off Secondary KeypadLinc buttons. The RemoteLinc button should remain a Controller in the Existing Scene. Adding a RemoteLinc button as a Controller to the existing ISY Scene is the correct thing to do. Making a separate Scene with the RemoteLinc button as Controller and Secondary KeypadLinc button(s) as Responders will not work any better. A V.36 KeypadLinc does not have the function for an On command to turn Off a Secondary KeypadLinc button. That function was introduced with v.40 firmware. If you do pick up a new KeypadLinc to replace the one in use now, remember to check the Responder On Levels for 0% On when the RemoteLinc button node below the ISY Scene name is selected. The KeypadLinc button as Controller has the correct On Levels for the KPL buttons to have one On only. The RemoteLinc button as Controller has its own set of On levels which also must be set to 0% On just as was done for the KeypadLinc button as Controller.

The device should be Deleted from the ISY and added back. The ISY generates the required link(s) in the device and the PLM during device add. Would be a good idea to factory reset the device before adding it back. Theoretically the PLM can be connected to a Serial port on a PC and write an application that creates the PLM link record. Requires knowledge of the PLM Serial command set, serial command interface protocol with the PLM in additional to the ISY requirements for link records in the PLM. I think Deleting the device and adding it back is best approach.

Assuming the Responder On Levels are set to 0% for the Secondary KeypadLinc buttons and assuming the KeypadLinc firmware does not support an On command from another controller turning Off a Secondary KeypadLinc button, the standard solution is to use ISY Programs and additional Scenes. An ISY Program is triggered by a button B On press. The Program issues a Set Scene Off for a Scene that has Secondary buttons A,C,D as Responders. This turns Off the other Secondary buttons. Need a Program and Scene for each of the Secondary buttons. This is the solution that has been used for years until SmartLabs added support for turning a Secondary button Off with an On command from another Controller. An easy alternative is to replace the KeypadLinc with a new one, moving the old KeypadLinc to a location where the Secondary buttons do not have to operate in one On only mode.

Each Scene Controller has unique Responder values. Click on a RemoteLinc button node name below the Scene name and verify the other Secondary KeypadLinc buttons have the correct 0% On Level. What is the KeypadLinc firmware level? It is displayed on the second line in the right pane when a KeypadLinc button is selected in the My Lighting tree. Only relatively new KeypadLincs have the function to turn a Secondary button Off with an On command from another Controller. What ISY firmware is being used? (Help | About shows Firmware and UI levels)

1) Is the process of "Restore PLM" as delicate as "Show PLM Links Table"? (i.e. will insteon traffic screw up the restore process?) I don’t think so because the add process is searching for an existing link with the same information. It is not just dumping the next add at a preset next point. That is what I think rather than what I know from explicit tests. 2) How does the "Restore PLM" prioritize what it restores to the PLM? (i.e. are the latest added scenes left out when it fills the PLM) The last Restore Modem (PLM) restored by Insteon address in ascending order. However, there were two different blocks of addresses. Not sure why there were two different blocks of Insteon addresses. Both blocks were in ascending order. 3) Is there a way to add a PLM record to the PLM without using "Restore PLM"? Adding a new ISY Scene will do that. 4) Is there any better way to count and compare links? Looking through hundreds of links for a certain insteon address is cumbersome. The Show PLM Links Table display can be saved to a file. I used WordPad to view that file. The problem is the data is stored in decimal, not hex so values have to be converted. For example, the Insteon address would have to be converted to decimal with the decimal value used in the Find. 5) Are there plans to make a PLM that holds more data? kind of ridiculous that it only holds 992 (or so?) links. (If no, then can we hereby put in a request?) This forum will not have that answer. Even if SmartLabs had plans for that they would not make it public. The Smarthome forum has a category for making Insteon product requests. The 2412 PLM physically held 2000+ links. There were reports that the PLM could not search the entire link database for a matching inbound record before the next inbound record arrived. Some reports links over 800/900 links could be a problem. I have no hard evidence of that. The 2413 PLM has a faster processor and supports a much smaller link database. Only speculation that was done to solve the 2412 link search problem.

The answer for question 1 is the accumulation of Insteon information over years of using/debugging/playing with Insteon. SmartLabs does not document this information in any meaningful way for the general public. There is an insteondetails.pdf document on the insteon.net web site (I think) that is 'very' old but may describe some information on link records. Luckily the basic format of the 8 byte link record has never changed from day one of Insteon. Would be difficult to change that now without introducing incompatibilities with existing devices and software packages. There are folks who have posted information on Insteon gathered from many sources over the years. Try this link http://www.madreporite.com/insteon/insteon.html He has lots of Insteon information, not sure if there is a specific section on link records. One of the problems with Insteon is that SmartLabs considers all the really good information confidential and proprietary. A Developer Subscription can be purchased for $200 (last time I looked) which gives access to some of the really good info but one has to sign an NDA. This means that folks such as UDI are limited as to what can be published and shared publically because it is confidential. As mentioned before, the good thing about link records is once you have learned some of the basics it applies to every device that has ever been sold. For question 2, when a device is turned Off manually or otherwise and some other device turns On it is not a link record issue. An Insteon Off command cannot turn On another device. An Insteon On command can turn Off a device if the Responder On Level is set to 0% On but Off commands can do only one thing, turn the device and any linked devices Off. Something else is turning On the other device. Try running the Event Viewer at Level 3 to see if there is an On command flowing from a Program. A zebra would be the device turning On has an X10 address assigned to it and some noise on the powerline looks like an X10 message which the device is reacting to. Actually that is not so much a zebra.

If the Admin Code is pulled from the ISY itself on a 99i the UI will indicate 99i. I presume the Admin Console you are using came from the UDI web site which must have been loaded from a 994 build. My 99i with 3.3.4 indicates 99i on the UI line. My 994 with 3.3.4 indicates 994. I pull the Admin Console from the ISY itself. I still believe it is the same code.

Yes, the same Admin Console (UI) code runs on the 99 and 994. It is the ISY image itself that is dependent on which ISY hardware is being used.

The link records in the three posts are fine. The one that says [identical/ignore] is a deleted link (22 in the first byte which is a flag byte marks it as inactive). It matches what the ISY expects [identical] and is an inactive/deleted record [ignore]. The last record labeled [record mismatch] is also fine. The ISY is now showing a dummy End Of List record in the ISY Links Table Display. This is represented by 8 00's. The only meaningful number is the 00 in the first byte which is the flag byte for End of List. The End of List link record in the actual device has the 00 in the first byte. The remaining 7 bytes are the remains of some previous link record that is not longer being used. The last 7 bytes have no function/meaning when the first byte is 00. When the ISY marks the link record following the last link record it knows about as an End of List record it sets only the first byte to 00. That is all the device hardware/firmware is looking at to identify the End of List record. The ISY could zero out the other 7 bytes but that action would require several additional commands for no functional value. Bottom line, the tree posted images are fine.

Without a Set button manual Set button linking is initiated when the bulb is initially screwed in. The Start Linking may work by screwing in the bulb after initiating Start Linking. Have not tried that. The New INSTEON Device should work also and it eliminates any timing question. The LED bulb is listed in the Device Types pulldown on 3.3.4. Very last entry in the [01.xx] list.

tunaman Yes, that is what the values should be for both the ISY itself and the UI Admin Console. It means the Java cache was cleared successfully and the correct URL for the Admin Console is being used.

The leading zero (0) is not used. It is little convoluted but a REST call entered in the command line of a browser displays the information in the format the ISY expects. The following are two examples for displaying node information and scene information. http://192.168.x.x/rest/nodes/ http://192.168.x.x/rest/nodes/scenes

When a TriggerLinc operates in multi-Scene mode (jumper removed) both nodes issue On messages only. Off messages are not sent from the TriggerLinc for either node so both nodes will show On as that is the only messages send by the TriggerLinc. If the problem is the Programs trigger only once when initially going to On state, use If Control rather than If Status to trigger the Programs. If Control triggers on every On message. If Status triggers only when the Status changes which is only once.

Be careful about moving between 3.2.6 and 3.3.x. The 3.3.x images change the configuration file, making it incompatible with 3.2.6. You have to restore a good 3.2.6 backup when going back that far.

What ISY firmware is being used? The ISY does not currently support setting the Beep on button press.