LeeG

Insteon devices are either Controllers only which send commands to other devices to control those devices; Responders only which are devices controlled by other Insteon devices; or devices are capable of being both a Controller and a Responder. A RemoteLinc is an example of a Controller only. It can control other devices but there is no function in a RemoteLinc that is controlled by anther device. An ApplicanceLinc is an example of a Responder only. It can be turned On and Off by another device but the ApplicanceLinc itself cannot control any other device. A SwitchLinc is an example of a device which is both a Controller (can turn On/Off other devices) and is a Responder (can be turned On/Off by other devices). A KeypadLinc is both a Controller (the KPL buttons can turn On/Off other devices) and a Responder in that the KPL load can be turned On/Off by other devices. Also the secondary button LEDs can be turned On/Off by other devices. To the specific question, yes a KPL button can turn On and Off other Insteon devices. The primary KPL button (ON/OFF in 6 button mode, Main in 8 button mode) can also turn On/Off a locally attached light (load).

raypanic this may only be a typing error but in your last post you described using a PLC. The ISY does not use a PLC, it requires a PLM. They are very different devices. Check the device type on the printed label. It should be a 2412 or 2413 PLM. It cannot be a 2414 PLC.

The motion sensor sleeps when not in use which means the RF circuitry is off and cannot receive any commands. This has nothing to do with Jumper 5. If Jumper 5 kept the motion sensor from sleeping the battery life would be much reduced. Without Jumper 5 (as Brian mentioned applies only to V2 motion sensors) the small pots are used to control the settable values. With Jumper 5 in place software/firmware controls those values. Either way you must put the motion sensor into Linking mode with the Set button before software/firmware can initiate communication with the motion sensor. This applies to creating links and setting those program settable values.

If you want any software/firmware to be able to set any of the characteristics that are under program control, such as time delay to Off, Jumper 5 must be set. Jumper 5 is not necessary establishing links and getting motion, dusk/dawn, battery messages. If Jumper 5 is not set than the small pots are used to adjust those characteristics.

I am running 2.7.15. If the Controller of the Scene is a KPL the buttons are listed with the Bright level slider. If the Controller of the Scene is something other like a RemoteLinc the KPL buttons with the Bright level slider are not displayed. The buttons do show as responders , just the display of the buttons with the sliders is not when the Controller of the Scene is not a KPL.

Thanks for the information on the Scene. Unfortunately as Michel described in his first response. KeypadLinc hardware does not support turning a Scene ON (using the Insteon ON command) and have a Secondary KeypadLinc button(s) turn OFF. This works for all other devices I have tested. SwitchLincs, ICON switches, even the load control button on KeypadLincs (ON/OFF in 6 button mode, Main in 8 button mode). However, KeypadLinc Secondary buttons do not honor the Bright Level (LD1 value) in the Responder to link record in the responder KeypadLinc. You can display the link records in the responder KeypadLinc and the Bright Level (the first byte of the last three bytes of data in the link record) has in fact been set to 0x00 to represent OFF but the KPL hardware ignores it. The KPL, for Secondary buttons only, uses the Insteon command ONLY to determine if the button LED is to be turned ON or OFF. To accomplish turning OFF Secondary KPL buttons they can be defined in a Scene unique to the Secondary buttons and turn that Scene OFF.

oberkc, you are correct. KPL secondary buttons cannot be turned ON or OFF directly from a Program as there is No Insteon SD Direct command to do that. The Insteon SD Direct commands work on the load buttons but not the secondary buttons. Also correct that a KPL Secondary button can be a responder in a Scene just like any other responder (except bright level percentage cannot be specified). When the Set Scene ON is issued the KPL secondary button will turn On, when the Set Scene OFF is issued the KPL secondary button will turn Off.

Perhaps some clarification would be useful. You have defined a Scene where KPLA Secondary button A is the Controller and KPLB Secondary buttons A.B,C,D are Responders. Is that the configuration? If this is the configuration you cannot specify at the individual responder level an ON or OFF for a Secondary KPL button. When you press KPLA button A ON KPLB buttons A,B,C,D should turn ON and when you press KPLA button A OFF KPLB buttons A,B,C,D should turn OFF. That is pretty basic Insteon stuff which makes me think the actual configuration may not be understood on this end. Thanks

The second line displayed should look like this if I did the conversion correctly.. FF0 E2 1 129FFA FF1F01 129FFA should be the ISY/PLM Insteon address. The Sensor state change should be reported to the ISY/PLM. Run Tools/Diagnostics/Event Viewer with Change Level to level 3. Then change the Sensor state by moving the magnet to and away from the magnetic switch, not with relay control. You can move the door position with the existing door opener manual switch. Post the Event Log results. If nothing appears in the Event Log when the Sensor changes state move the IOLinc to the plug point of the ISY/PLM and use a simple wire jumper between Sensor and GND to change the Sensor state and see if the Event Log shows activity.

The ON command is turning the output relay On for a short period of time which causes the door opener to move, either Open or Close. It sounds like the IOLinc is operating in Momentary A mode. Take a look at the EDIT: I added to my previous post. It explains why the Show Device Links Table is needed.

There are a couple of symptoms, first the Sensor is not reporting status as it changes and the momentary mode does not seem to be what was selected. Suggest running Tools/Diagnostics/Show Device Links Table for the IOLinc. The Sensor not reporting status is normally a link problem as the IOLinc has to be told what device it should report status to. The Link information will show what device the IOLinc should report status to, if any. Are the symptoms with the new IOLinc the same as you reported in your first post. EDIT: the idea here is determine if the IOLinc has the necessary link record for communication with the ISY/PLM. If the Link record is there then the Event Log level 3 trace will show whether the IOLinc Group message is making to the ISY/PLM. If the Link record is not there then tracing the Insteon device add process will be necessary to see why the link record did not get written. Either situation could be the result of a communication problem between the IOLinc and the ISY/PLM. May be necessary to move the IOLinc to the same plug point as the ISY/PLM but that is down the road.

You are correct in the conclusion that the ISY issued the right command to turn the LampLinc on to 30%. Also the ACK that the LampLinc sent back indicates the LampLinc turned on to 30%. Smartlabs updated LampLincs quite some time ago to send a Group 1 On message if/when it detects that the LampLinc has been turned on manually. That is the Group 1 ON trace entry that follows the Program issued 30% ON. The first message is a Group Broadcast and the second is the follow up Group Cleanup Direct issued by the LampLinc itself. Sun 07/18/2010 11:12:52 PM : [iNST-SRX ] 02 50 14.4B.11 00.00.01 CB 11 00 LTONRR (00) Sun 07/18/2010 11:12:52 PM : [iNST-SRX ] 02 50 14.4B.11 0F.2B.3E 41 11 01 LTONRR (01) I would look at the load the LampLinc is controlling. A lose bulb, or maybe a bulb that is near the end of its life cycle and the filament is intermittent when initially turned ON by the program. We have seen this happen when someone walks by a bulb that is loose in the socket or near the end of its life cycle. Try a different light fixture plugged into the LampLinc or a new bulb for starters.

The ISY User Guide indicates a blinking MEM and ERROR LEDs indicate an Ethernet connection problem. There are two RJ45 jacks on the ISY. Port A for the PLM connection and Network for the Ethernet connection. Might check to be sure these are not swapped. By default I think the ISY is looking for a DHCP server to acquire the IP address.

When I renamed KPL buttons they still appeared in button order even though that was not the collating sequence by button name. Regardless of that click on Rename and look at the second line in the Rename popup labeled Address. It retains the button number as the last digit on mine. Just cancel the Rename popup.

You can control a Secondary button as a responder in a Scene. You can turn the Scene On and the secondary button will turn On and of course you can turn the Scene Off and the secondary button will turn Off. What you cannot do is turn the Scene On (which uses an Insteon ON command) and have that Insteon ON command turn the Secondary KPL button Off. EDIT: I agree with the approach that the devices should work as much as possible independent of any automation. I want my basic house to function whether the PC or ISY is up or down.

This is a sample Event Viewer trace level 3 of a Set ON followed by a Set 30%. The first ON command has a Bright level of cmd2=0xFF which is full bright. The second ON command has a Bright level of cmd2=0x4C which the ISY generated to bring to 30% Bright. If the device is being told to come on to something close to cmd2=0x4C but is coming on full bright then it is a hardware issue. Sun 07/18/2010 02:26:17 PM : [iNST-ACK ] 02 62 12.B4.E1 0F 11 FF 06 LTONRR (FF) Sun 07/18/2010 02:26:17 PM : [iNST-SRX ] 02 50 12.B4.E1 12.9F.E4 2B 11 FF LTONRR (FF) Sun 07/18/2010 02:26:17 PM : [standard-Direct Ack][12.B4.E1-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sun 07/18/2010 02:26:17 PM : [ 12 B4 E1 1] ST 255 Sun 07/18/2010 02:26:21 PM : [iNST-ACK ] 02 62 12.B4.E1 0F 11 4C 06 LTONRR (4C) Sun 07/18/2010 02:26:21 PM : [iNST-SRX ] 02 50 12.B4.E1 12.9F.E4 2B 11 4C LTONRR (4C) Sun 07/18/2010 02:26:21 PM : [standard-Direct Ack][12.B4.E1-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sun 07/18/2010 02:26:21 PM : [ 12 B4 E1 1] ST 76

This sounds like a hardware issue but you can tell for sure by turning on the ISY Event Viewer Tools/Diagnostics and select Change Level to level 3. The cmd2 value contains the Bright level for On command. Either the cmd2 value will be something much smaller than 0xFF (255) for the 30% Dim that does not work or not. If the cmd2 value is 0xFF then it is an ISY question but I doubt that will be the case. If you have any trouble analyzing the Event Log post the results.

The technique of issuing an ON command to 0% to turn a device Off does not work on KeypadLinc Secondary buttons. This is KPL hardware. It works with the Primary load button (ON in 6 button mode, Main in 8 button mode) but not the Secondary button LEDs. This can be done by defining a Scene with the KPL Secondary button as a Responder and turning the Scene Off. Define a Scene for each Secondary button or combination of Secondary buttons you want to turn Off and then turn the Scene(s) Off. Smartlabs is constantly adding/changing device function so it might work on some KPL but all the KPLs I have tested here will not turn Off a Secondary KPL button LED using an ON to 0%.

kingwr, The All On/Off function on the RemoteLinc (and Controlinc) does not have a unique Scene definition per se. To understand how the All On/Off works it is necessary to understand how a normal Scene/Group is defined and works. A RemoteLinc button will have one or more responders linked to it. In this example RemoteLinc button 3 has three Responders A/B/C. The link records will look something like this for button 3 … Three Link records In the RemoteLinc … Group 3 - Controller of Responder A Group 3 - Controller of Responder B Group 3 - Controller of Responder C One Link record in Responder A … Responder to RemoteLinc Group 3 One Link record in Responder B … Responder to RemoteLinc Group 3 One Link record in Responder C … Responder to RemoteLinc Group 3 When RemoteLinc button 3 is pressed On the following commands are issued by the RemoteLinc Group Broadcast from RemoteLinc Group 3 On Group Cleanup Direct from RemoteLinc Group 3 to Responder A On Group Cleanup Direct from RemoteLinc Group 3 to Responder B On Group Cleanup Direct from RemoteLinc Group 3 to Responder C On The Group Broadcast message will cause the three Responders A/B/C to turn On simultaneously. The Group Cleanup Direct commands follow up just in case a particular Responder did not see the Group Broadcast message. The Group Cleanup Direct commands require an ACK from each Responder and will be retried if an ACK is not received by the RemoteLinc from a given Responder. When the All On button is pressed the RemoteLinc sends ONE command Group Broadcast from RemoteLinc Group 255 Fast On Just as in the case where button 3 (Group 3) is pressed, any device which has a Responder to link record with the RemoteLinc address and a matching Group number reacts to the Group Broadcast message. For the All On a specially architected Group number 255 is used. None of the Responders A/B/C actually have a link record with Group 255. The Responder firmware is coded such that for Group 255 only the RemoteLinc address has to match a Responder to link record in each Responder. Most RemoteLincs have Responders linked to each button. All Responders linked to all of the RemoteLinc buttons will respond to the Group 255 Fast On because the Responder to link record will match the RemoteLinc address and the Group/Button number is ignored when Group 255 is received. The ISY has only one Controller and that is the PLM so all Responder devices which have a Responder to link record with the ISY PLM address will react to a Group 255 command. This generally does not have the granularity needed unless you want every Insteon device on the powerline to turn On or Off. Of course only those Responders with a Responder to link record with the ISY PLM address responds, not litterally every device on the powerline. Also just like any Group Broadcast command it is not ACKed or retried so it may not produce reliable results if the powerline is anything but absolutely perfect. Another reason why All On/Off is not normally attempted by software/firmware. Anticipating someone running an Event Log level 3 trace of a RemoteLinc All On there are actually 2 Group Broadcast messages issued. This is not unique to the All On function. All RF based devices, Motion Sensors, TriggerLincs, RemoteLincs send the Group Broadcast message twice so it is a little more reliable than if only one Group Broadcast message was sent. When this was initially observed years ago when RF devices first appeared it was thought that the two Group Broadcast messages were the result of two Access Points picking up a Group sequence from an RF device. However, folks have removed all but one Access Point and two Group Broadcast messages still occur. I have not seen an explanation from SmartLabs or Smarthome why this is but all the RF devices I have traced send 2 Group Broadcast messages. You will see in the Event Log that the second Group Broadcast message is dropped as a duplicate, I assume so that Programs being triggered by a Group Broadcast message will not be triggered twice (only an assumption).

Rand, is it the Group Broadcast message or the Group Cleanup Direct that is sent specifically to the ISY/PLM (since each Controller paddle/button has the ISY/PLM as a Responder) that the ISY is responding to.

I apologize for this long response but the situation is complex. Knowing the Insteon command sequence will help in understanding the results. When the KPL button is pressed a Group command sequence is initiated. First the KPL sends a Group Broadcast command which contains the KPL Insteon address and the Group number of the KPL button pressed. This command is not addressed to any specific Insteon device. Literally every Insteon device on the powerline receives this Group Broadcast message which causes each device, essentially simultaneously, to search its link database looking for a matching “Responder to†link record. All the devices that have been linked as a Responder to the KPL button will find a match and all devices will react nearly simultaneously to the command issued. This is why/how responders seem to all react at the same time. The Group Broadcast is sent once and none of the responding devices send an ACK so the Controller (KPL) does not know if all or any of the responder devices actually saw the Group Broadcast. The KPL then sends a Group Cleanup Direct message to each linked responder individually. This message is ACKed by each responder in turn and if no ACK is received the KPL will resend the Group Cleanup Direct up to a total of three times. For the scenario going on here that means that a send of the Group Cleanup Direct and ACK response will occur for each responder. This is a total of 6 Insteon messages that flow to complete the KPL button press Group command sequence. It is actually worse than that as the KPL is also sending a Group Cleanup Direct message to the ISY/PLM as it is also a responder to the KPL button press. The Insteon architecture understands that this Group command sequence may take some time and should another Group command sequence be detected by the KPL the KPL will abort the Group command sequence started from the KPL button press. This is standard Insteon Group processing and has been in effect for Insteon command flow forever. The effect of this is that the Scene being initiated by the Program in response to a status change by one of the three lights could abort the KPL button Group command sequence and likely would if the ISY has good reaction time. Even software running on a PC can have this affect, cancelling the current Group processing. That is why “Wait†is needed. If would not be needed if a Direct command was being issued but since the Program is issuing a Scene/Group sequence the “Wait†is necessary. If the powerline is good the Group Broadcast will have been seen by all the responders so visually everything looks right even if the Group command sequence is aborted. The problem is that if the Group command sequence is aborted (which is likely even with a 1 second Wait) the ISY will not see all the expected Group Cleanup Direct Insteon traffic. This is how software/firmware can get out of sync with the actual responder devices. Try increasing the Wait time to 5 seconds. Should not need that much but it should take the Scene control being issued from the Program well away from the KPL Group command processing generated by the KPL button press. If the longer Wait delay provides stability to the results then the time can be reduced until unreliable results are seen. Again, sorry for such a long winded response but Scene/Group command sequences and the fact that a Scene/Group will be aborted is not well understood. Not a problem for pure Insteon hardware but it plays havoc with software/firmware trying to track what the hardware is doing.

Are any of the three lights on a dimmer such that one of the lights might look Off but not be at absolute Off. If any of the three were in that condition the KPL button LED would remain On. Try leaving the Admin Console up for a few nights so that when it happens you can look at the current status ISY thinks exists.

The Button Grouping feature of a KPL (only 1 button in the group On at a time, sometimes referred to as mutex or radio buttons) applies to Scenes where the KPL button is the Controller, Scene initiated by a KPL button press. The Button Grouping relationship does not apply to Scenes where the ISY is the Controller (Scene turned On/Off from Programs) with one of the KPL buttons in the Group as a Responder. The Scene(s) itself is a normal Scene with a KPL button as the Controller and one or more devices as Responders. The KPL simply insures that all buttons in the Group are Off except for the button in the Group that is pressed to turn On. Scene processing for the active KPL button press is the same whether the button is part of a Button Group or not.

HouseLinc2 is using Extended Set/Get (0x2E). Setting a timeout value of 30 seconds sets the timeout value to 00. Setting a timeout value of 2 hours sets the timeout value to 0xEF which evaluates to 119.5 minutes. When adding the +30 seconds from Brian's post the values set track to the timeout values requested. EDIT: note that this test was run using a V2 Motion Sensor. Likely the smaller timeout value was applicable to the V1 Motion Sensor

Michel, from the SH web site for Motion Sensor (no reference to HL2) ... "Automatically turns off after motion stops (adjustable anywhere between 30 seconds and 2 hours)" Looks like the specs have changed for a V2 motion sensor from the API document.