LeeG

Yes, the RemoteLinc2 is supported starting with one of the later 3.1.x Betas. If going to the 3.1.x Beta images 3.1.15 is the latest. Use New INSTEON Device and select one of the 3 RemoteLinc2 variants from the Device Type pulldown.

Either the KeypadLinc has gained some additional function or my memory was wrong. Either way I gave you bad information before. To define a set of Mutually Exclusive buttons use the lower section and drag/drop the buttons to one of the Mutually Exclusive Buttons definitions (1,2 on 6 button, 1-4 on 8 button). For example, button B,C,D can be dropped on Mutually Exclusive Buttons 1, button G,H can be dropped on Mutually Exclusive Buttons 2. Buttons B,C,D operate as a Mutually Exclusive Group and G,H operate as another Mutually Exclusive Group. The respective check boxes in the columns above are checked gray reflecting the mutual relationship. Explicitly checking a button box in the columns above causes the checked buttons to be turned Off when the top button in the column is pressed, For example, in the column labeled Button D buttons E,G are explicitly checked. When button D is pressed, On or Off, E,G are turned Off if On. My apologies for the previous wrong info. I have established the above examples and they work as described.

tsasecurity KeypadLinc Button Grouping allows a set of KeypadLinc buttons to be defined as Mutually Exclusive. Press one of the buttons in the Group On turns Off any other button in that Group. This only works for the KeypadLinc where the button is actually pressed. If other KeypadLincs are cross-linked the other KeypadLinc buttons have to be controlled with ISY Programs and Scenes designed to create the appearance of Mutually Exclusive button operation. The Program that triggers on the X10 Motion Sensor will have to add the Status of the KeypadLinc button that turns On Scene B. If that button is On then the Program does not turn On Scene A. Lee

douyon When the SwitchLincs are turned On/Off does the Admin Console device Current State column for the respective devices reflect the correct state of the switches? Suggest posting the Program that does not work and provide any more detail that is available. Under Programs | Summary there are Last Run Time, Status and Activity that may have useful information regarding whether the Program is being triggered and whether the Then clause (Status=True) or Else clause (Status=False) ran and when. The Activity column will indicate if a Save of the Program is necessary. Lee

The Green 1011 Icons and red ! indicate comm problems to those devices. Some may be RF devices which are predictable. Suggest working with one device at a time. The ones with the red ! can generally be cleared with a Query (right click node and select Query) assuming comm is good now. If comm is not so good with this new PLM then that has to be cleared up first. The green 1011 Icons indicate pending updates to that device. Right click on node and select Write Updates to Device. Until all the link records have been changed to the new PLM address devices will not work correctly. What ISY firmware is running? Is the new PLM plug point different from before? Why the switch to a new PLM? I don't use UPB but some folks have said it is more reliable. It is more expensive. Insteon is a good technology but it does require a relatively clean power line environment. Insteon works well but it may also require more work to get it that way. Kind of one of those you get what you pay for.

I cannot explain why comm in one direct is good and not in the other. For sure there is some aspect of this that has not been identified yet. Did you run an Event Trace and confirm that there are three Group Cleanup Direct messages being received when the light turns back On? There is no command or option that I have ever seen that will force the PLM to send an ACK or suppress it. That part of the process is all driven by the PLM firmware.

An Event Trace with Device communications events selected when it fails is needed to determine if the filter resolved the problem of the device not receiving ACKs from the PLM. EDIT: the symptom with the KeypadLinc was the wrong node was being posted with an Off when there is a series of Group Cleanup Direct messages from a device. With a single node device that is sending multiple Group Cleanup Direct messages because the ACKs are not being received, the only node would be posted with an additional Off command. The end symptom is different because of the difference in the number of nodes a particular device has but the underlying problem is likely the same. That lack of ACKs back to the device looks like multiple button presses when the Insteon messages are evaluated programmatically.

State variables trigger Programs when changed. Integer variables do not trigger Programs when changed. I think you want to use an Integer variable unless you want the Program to trigger at those specific times (Sunset-30, etc) in addition to triggering with a button press. The value in the Integer variable will control whether the If is True or False and run the Then or Else accordingly when a button is pressed.

After the new values have been set pull the air gap switch for 30 seconds. When it powers up the new Local On Level and Local Ramp Rate values should take effect.

The only thing I can suggest is to upgrade to 3.1.15 which is a Beta. I have the exact Device Type and Firmware level where 3.1.15 is using the more advanced I2 configuration commands that do not require a power cycle to take effect.

What ISY firmware is being used? Help | About will indicate firmware in the ISY. The old I1 commands are being used to update the Local On Level and Local Ramp Rate. The device would have to be power cycled for this technique to take effect. I am running 3.1.15 which is using the new I2 Extended commands which take effect without a power cycle. Just need to determine why the I1 commands are being used on your system. The following is what the trace should look like. Thu 12/22/2011 08:54:35 PM : [ 15 B2 6A 1] OL 20 Thu 12/22/2011 08:54:35 PM : [ 15 B2 6A 1] RR 24 Thu 12/22/2011 08:54:35 PM : [All ] Writing 2 bytes to devices Thu 12/22/2011 08:54:35 PM : [15 B2 6A 1 ] Memory : Write dbAddr=0x0032 [14] cmd1=0x2E cmd2=0x00 Thu 12/22/2011 08:54:35 PM : [iNST-ACK ] 02 62 15.B2.6A 1F 2E 00 01 06 14 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 12/22/2011 08:54:35 PM : [iNST-SRX ] 02 50 15.B2.6A 19.70.15 2B 2E 00 (00) Thu 12/22/2011 08:54:35 PM : [standard-Direct Ack][15.B2.6A-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Thu 12/22/2011 08:54:35 PM : [15 B2 6A 1 ] Memory : Write dbAddr=0x0021 [18] cmd1=0x2E cmd2=0x00 Thu 12/22/2011 08:54:35 PM : [iNST-ACK ] 02 62 15.B2.6A 1F 2E 00 01 05 18 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 12/22/2011 08:54:36 PM : [iNST-SRX ] 02 50 15.B2.6A 19.70.15 2B 2E 00 (00) Thu 12/22/2011 08:54:36 PM : [standard-Direct Ack][15.B2.6A-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Thu 12/22/2011 08:54:36 PM : [All ] Writing 0 bytes to devices

I tested my ICON Dimmer at the same firmware level and it worked. Run Tools | Diagnostics | Event Viewer with Level: Device communications events selected from pulldown. Change the On Level and Ramp Rate to other values and Save the Program. Were trace entries generated? If so please post the event log. If not is there any Icon to the left of the ICON Dimmer in the My Lighting tree?

Don't think so for that late version firmware ICON. What does the Programs | Summary show for the Program? Also is the Program Enabled?i

The Program looks correct. What happens? Was the Program triggered as Sunset. The Programs | Summary tab will show the Program information. Last Run Time, Status, Activity

The UDI Wiki is a good source for information and examples. http://www.universal-devices.com/mwiki/ ... =Main_Page

Take a look at this topic. It is directly on point. Changing the Local On Level % at different times of day. Be sure to follow the posts to the end (only a few) as the initial Program's Adjust Scene statements are not coded correctly viewtopic.php?f=26&t=7646

Simply add the buttons of both RemoteLinc2’s as Controllers of the same Scene. Same is true using multiple KeypadLincs, etc. Nothing special about the RemoteLinc2. An ISY Scene can have many Controllers. Oops. Same answer for two RemoteLincs.

The Program is triggered by the IF statement twice. At the From time the Then clause is run, at the To time the Else clause is run. Not limited to the From/To definition, anytime a condition in the IF changes that causes a trigger or reevaluation it is done immediately if in a Wait or Repeat statement. Reevaluation will not interrupt other Action statements while they are executing. For example, if the To time arrived and the Then clause is running a series of Action statements the sequence will continue until a Wait or Repeat is encountered. Turning the light On/Off manually during or after From/To time does not cause any Program action with the If statement being used. Some device Status check would, should that be part of the IF and the device status changes. The UDI Wiki has a good description of this.

The To time occurred during the Wait between the On and Off Actions. This causes the Program to be triggered again at 5:00AM. The If is False at that point running the Else clause so the Off is not executed. Add an Off in the Else clause to insure the light is turned Off at 5:00 AM. EDIT: A Wait of some minutes can be coded in the Else before the Set 'xxxx' Off to insure the light does not turn On in the Then and immediately turn Off in the Else, if that is a concern. Would very much depend on the timing since the Wait times in the Then clause are random.

The original Program is not using the KeypadLinc load button as the first parameter. Did you change the Program and Save. The Programs | Summary will show if a Save is pending. The first parameter in the posted Adjust Scene is not the load button. In Scene 'Master Bed / Master Bath / Master Bath' Set 'Master Bed / Master Bath / Master Bath KL (load)' 25% (On Level) What is the firmware level of the KeypadLinc. Some older devices required a power cycle to have changes to the Local On Level and Local Ramp Rate take effect.

Yes. Use the KeypadLinc Primary button as the first parameter in the Adjust Scene. It should already be a Controller in the Scene definition.

The Button Grouping display shows each of the 5 (for 6 button KPL) or 8 buttons available to be grouped together in vertical columns. The checked box to the left of the top entry indicates that button as part of the Group if other buttons in that vertical group have been checked defining the Group. If Scenes have been defined to manage button LED illumination and then Groups are defined the Button Grouping function could change button LED illumination patterns that are inconsistent with what the Scenes are defined to do. The KPL does not indicate to an application (ISY) it has turned Off a KPL LED as part of the Group operation. This could result in the LED pattern established by the Scene(s) changed without the application being aware. Another issue with Button Grouping it only works where the KPL button is actually being pressed. If multiple KPLs are cross-linked the KPLs that are cross-linked do not stay in sync even if all the KPLs have the same Button Group definitions. Button Grouping only works where buttons are actually being pressed. Hope that helps. Please post additional if other questions remain.

I have no idea what is blocking PLM to KPL communication intermittently. With the Group Broadcast and all three Group Cleanup Direct messages received from the KPL okay, one would think the ACKs from the PLM would get back to the KPL. Once the source of interference is identified it may make more sense. As far as triggering the Program, Michel acknowledged that is a bug which UDI is fixing.

It is not the hop count that causes this. If it was as simple as taking 3 hops to get from KPL to PLM this would not be problem. The Group protocol normally consists of a Group Broadcast message followed by what should have been a single Group Cleanup Direct message even if it took 3 hops for the Group Cleanup Direct to be received by the PLM. There are three Group Cleanup Direct messages from the KPL, received processed and ACKed by the PLM and passed to the application (ISY). The first one with max hops 1 was successfully received by the PLM. The second one with max hops 2 was successfully received by the PLM. The third with max hops 3 was successfully received by the PLM. None of the ACKs sent by the PLM in acknowledgement of those three messages made it back to the KPL. Very unusual situation for traffic to get from KPL to PLM with such success and traffic from the PLM to the KPL fail so totally. The problem is each additional Group Cleanup Direct message looks like another button press and could be another button press based on the message itself. If comm. was poor in the other direction, messages having trouble getting from the KPL to the PLM it is very possible to miss the initial Group Broadcast altogether because it has no ACK and no retry associated with it. That is why Insteon designed the Group protocol with a follow up Group Cleanup Direct to each Responder. Since this message is sent to a specific device it must be ACKed and can be retried by the KPL if an ACK is not received. From the message sequence it could actually be three distinct buttons presses with very poor comm. That is a very unusual sequence which is likely why the ISY analyzed it incorrectly.

Now we wait for the analysis being done by Chris. The last two traces show definitively it works when comm is good, it fails when the comm between the PLM and KPL fail. Of course the comm problem can be resolved and not wait for an ISY change, if the answer is with the ISY. That is still an assumption on my part.