LeeG

Both devices must be Controllers of the same ISY Scene. The ISY will cross link them and the status of both devices will be in sync.

No good ideas. To continue to change a responder state the next Off command from the RemoteLinc2 would have to turn devices On and if that happened the next On from the RemoteLinc2 would have to turn devices Off. The effect of On/Off commands would have to continue to be reversed until the last command from the RemoteLinc2 was an Off and the All Off was issued again. Then the RemoteLinc2 commands would have to be reversed again such that On performed On and Off performed Off. Plus the color of the LED blink on the RemoteLinc2 would be backward. Red normally means Off and Green normally mean On. If command actions were reversed through some Program manipulation making an Off command turn devices On the color of the RemoteLinc2 LED is now out of sync. I do not see a good solution to this. Perhaps someone else has some thoughts.

Using the Program is fine. As an FYI, non-toggle On mode buttons should blink twice and remain On, non-toggle Off mode buttons should blink twice and remain Off. On old KeypadLincs the button LED state actually controlled whether the button operated in non-toggle On or non-toggle Off. Some folks took advantage of this, turning the button LED On or Off to change the non-toggle mode. Later KeypadLincs stopped using the button LED as the control for non-toggle mode. On later KeypadLincs the button LED can be turned On for whatever reason and a button press will still issue the Off command when defined to be in non-toggle Off mode. I mention that only because you have a mixture of old and new KeypadLincs.

I programmed button B of an 8 button v.29 KeypadLinc to non-toggle On mode. When the popup came up (different as you pointed out) I pressed the KeypadLinc button B On and then clicked Ok. Button B did go to non-toggle On mode. Subsequent presses of button B result in a double blink and the KeypadLinc button LED stays On. The event trace shows On commands only coming from the KeypadLinc. I'm running 3.1.16. What ISY firmware is being used? If you run the Event Viewer with Level: Device communications events selected, try setting the KeypadLinc button to non-toggle On mode by turning the KeypadLinc button On after the popup is displayed, I will compare the trace from your system with mine.

I have some v.29 KeypadLincs. Will run the same test here. Be sure to use the instructions for the old KeypadLincs. I'm pretty sure the button press sequence changed to rotate through the three toggle modes. As an FYI if the Event Trace Level is set to Device communications events the actual command being sent can be seen. On command is 11, Off command is 13. The trace entries in the posts are the ISY conclusion which are Off commands. There is no doubt in my mind the KeypadLinc is sending Off commands only in non-toggle mode but the more detailed level of trace entries will show the actual command.

What does the Admin Console show for the KeypadLinc firmware level? It is displayed on the line below the Node Name in the right hand pane. Try having the KeypadLinc button On before clicking on Button Toggle Mode rather than turning it On afterward. I have some old KeypadLincs which I will test against once I know what the Admin Console shows for the firmware level. Could be the older KeypadLincs cannot be programmed that way. Should be able to set to non-toggle Off using the KeypadLinc itself. Could also be the KeypadLinc was added by selecting the specific Device Type rather than using Auto Discover. In this case the ISY will not know the KeypadLinc firmware level (v.00 is displayed) so the old method is being used.

robinasu The RemoteLinc2 cannot be communicated with because it is asleep. Are you looking to change what command the button sends next when in Toggle Mode? Lee

What is the firmware level of the Keypadlinc? What is the firmware level of the ISY? The following is what I see on 3.1.16 with a KeypadLinc at v.36 Likely the button is being set to non-toggle Off mode. The Event Viewer will show what command is coming from the KeypadLinc button press.

Insteon Direct commands do not use links. Custom Commands that are issuing Insteon Direct commands work independent of link records.

Which button is being changed? When the button is in Toggle mode clicking the Toggle On/Off button brings up a popup asking do you want to set the button to non-toggle On or non-toggle Off mode. The non-toggle mode set depends on whether the On or OFf button in the popup is pressed. When the button is in one of the non-toggle modes clicking the Toggle On/Off button restores the button to Toggle mode. The 6 button ON/OFF buttons cannot be assigned the same three modes as other button

marksidell I set up what I think is the desired configuration on a 6 button KeypadLinc. Secondary button A controls device 1 Secondary button B controls device 2 Secondary button C controls device 3 Secondary button D has device1, device2, device3, button A, button B, button C as Responders. When button D is pressed On device1,2,3 and the three Secondary buttons A,B,C turn On. When button D is pressed Off the all the devices and Secondary buttons turn Off. When button D is pressed On and turns all devices and buttons A,B,C On the Secondary buttons will turn Off their respective devices. Lee

Vince Sorry about that, I had read the previous information and forgot to respond to that point. The RemoteLinc sleeps to conserve battery power. While asleep it cannot receive any commands. Put the RemoteLinc into linking mode by pressing and holding Dim/Bright buttons until RemoteLinc LED blinks continuously. Now click on Write Updates to Device and they should go. When the updates are complete either press the All Off button to come out of linking mode or wait a few minutes until the RemoteLinc times out itself. Lee

Vince Beginning to think the world is picking on you? The Dual Band OutletLinc Dimmer is supported in the latest 3.1.16 Beta. There are a number of Insteon devices that were announced and released after the last offical release 2.8.16 became available. Nature of the beast. Not much the ISY can do until the devices becomes available and any differences or new features handled. Support for the new devices appear in the incremental betas. In a way it is a good thing that SmartLabs/SmartHome are continuing to add new devices and improve the ones currently available. The down side is trying to keep up with the new devices implies using Beta code for awhile. The beta images have been pretty good overall and UDI does a good job of resolving whatever surfaces and that is what the Beta process is for. UDI has announced it is targeting the next official release soon, perhaps by the end of the month. That is a target, not a hard date. Depends on how testing of the next image proceeds. I have found 3.1.16 stable for the main line Insteon functions if you are considering moving to 3.1.16 for OutletLinc support. The MorningLinc is an unknown at this point. A few folks have seen the issue but since UDI cannot recreate it is not a solid universal failure. The analysis is a work in progress. Lee

Vince A safer alternative to manual linking would be to trigger a Program with the RemoteLinc button and issue an On or Off command to the MorningLinc node itself. This way there are no link records that the ISY is unaware of. If Control 'RemoteLinc-2 - 2' is switched On Then Set 'MorningLinc-On' Lock Door Else - No Actions - (To add one, press 'Action') If Control 'RemoteLinc-2 - 2' is switched Off Then Set 'MorningLinc-On' Unlock Door Else - No Actions - (To add one, press 'Action') EDIT: I have confirmed this works assuming the MorningLinc has been added back and no Scenes created

Vince The rev1.0 is the hardware level of the MorningLinc. The Admin Console displays the firmware level on the 2nd line of the device screen just below the Node name in the right pane. What ISY firmware level is being used? OutletLinc device type was added in one of the 3.1.x Betas. In the Unsupported message there is a number x.yy. What is that number? I will check to be sure that device cat/subcat value is listed in the latest 3.1.16 beta. The only way to use the MorningLinc in a Scene at present is to manually link it. However, the ISY will not know about those link records and will overlay them if changes are made to the RemoteLinc subsequent to the manual links. Lee

What Operating System is being used? Is that a 64 bit machine? If so was the 64 bit Java installed? In other cases once the slider has been moved and that movement recognized the next movement may be okay without the intermediate stop. Seeing a Progress Bar is key. When that comes up the Admin Console has been notified of the movement.

There is a forum Category dedicated to Variables. viewforum.php?f=68 The first Summary topic covers the basics.

If a Progress Bar does not appear Java has not indicated a slider movement to the application. There have been cases reported where Java was not handling slider movements correctly. Be sure Java is current. Also try moving the slider to an intermediate position, release the mouse button, then move the slider to 0. Until a Progress Bar appears the Admin Console is not aware of the slider movement and not updating the responder link record. I ran a test on 3.1.16 with an ApplianceLinc. A 0% On Level does turn the ApplianceLinc Off when the Admin Console is aware of the slider movement. What ISY firmware is being used?

Do not turn Off updates. Change the slider for the ApplianceLinc Responder On Level to 0%. Does a Progress Bar appear after the mouse button is released? Is there more than one Controller (ISY PLM is always a Controller) for the Scene?

What ISY firmware is being used?

There is no functional equivalent in Variables to an Insteon If Control. An If Control triggers the Program when a specific Insteon command is received. State variables trigger on all changes. Integers never trigger. There is nothing in Variables to trigger only on a specific value (like If Control). The If State value determines whether the Then or Else clause runs but the Program is triggered on all changes.

Not all devices can be turned Off that way. What are the device types that do not remain at 0%?

State variables trigger Programs when the variable value is changed (like If Status). Integer variables DO NOT trigger Programs.

Vince UDI is working at recreating this. As of Sunday evening they had not been able to recreate using their MorningLincs. Both of my v3A MorningLincs have the problem. What is the firmware of your MorningLinc? Until a Scene is created the MorningLinc nodes will cycle the lockset by issuing On or Off commands to the node itself. Only after a Scene (sometimes more than one before the problem arises) is defined is communication lost. For now only the nodes themselves can be used until the cause is identified and resolved. Lee

I doubt HL fails to stop when reading a 00 flag byte. Otherwise it would be reading 417 link records. There are multiple conflicts trying to use ISY and HL together. If the device was known to HL before being added to the ISY with the "remove existing links" all the link records HL wrote when the device was added to HL will be erased and the ISY links written which HL does not know about. Now HL sees link records written by the ISY which do not match what HL has and the link records which HL wrote are missing making the link records in the HL PLM broken. If the add is done in the opposite order. ISY first, HL second, the ISY will eventually wipe out some or all of the HL links because they are not known to the ISY. I have run both products using some of my test bed devices and have seen just about every conflict that can arise and that was with a relatively small number of devices. The HL is a little better at handling what it sees as Set button links (actually written by the ISY) but there are issues that always surface no matter how careful one tries to be. Add to ISY, establish all ISY Scenes that will ever be used, then add to HL and never touch the configuration again. That is just not realistic. Use HL for communications testing but anything beyond that as far as changing configuration will lead to failures.