LeeG

Jcanter As Michel has already indicated that is a Scene (Group) Off for Scene (Group) 0x17 decimal 23. The 00 00 17 is the Scene (Group) number. You can issue the following command in a browser and get a list of the Scenes in the ISY. Look for an entry with a 23. The devices listed below it will be the devices in the Scene. If MS messages are being block during this Scene for 5 seconds it normally indicates one or more of the responders is not responding to the Scene (Group) Off. It takes a few seconds for the Controller to retry the Off command multiple times to a non responding device. A Scene normally completes very quickly. http://192.168.2.2/rest/nodes/scenes Example of a Scene displayed by the above Rest command 16833 SceneKPL3Ramp30 59 K07 - 14 71 3C 1 B 4A AD 4 I issued the following Rest command http://192.168.2.2/rest/nodes/16833/cmd/DOF which turns Off the above Scene SceneKPL3Ramp30. This Scene has a deviceGroup 59 hex 0x3B which produced the following Event entry Wed 01/26/2011 02:14:10 PM : [iNST-ACK ] 02 62 00.00.3B CF 13 00 06 LTOFFRR(00) By knowing the Scene you should be able to determine what is turning the Scene Off. Scene On/Off activity is normal. Just depends on whether that Scene should be turning Off at that point. Lee

If you can run Tools | Diagnostics | Event Viewer and select Device Communications Events. Post the event output after walking past an MS. Perhaps by looking at the commands executed we can tell what is happening.

Jay Do you have small green icons to the left of the motion sensor node entries in the My Lighting tree? It sounds like there are pending updates to the motion sensors which cannot be completed until they are put into linking mode and a Write Updates to Device is performed. Lee

aanthony There was a link record missing in the KeypadLinc. For two Insteon devices to stay in sync with the LEDs and load control, the two devices have to be cross-linked. The KeypadLinc Secondary button is linked as a Controller with the SwitchLinc as a Responder. Also the SwitchLinc is linked as a Controller with the KeypadLinc Secondary button as a Responder. It is this link that was not functional. It is very rare for a link record to get lost or corrupted but it does happen. A power glitch that causes the KeypadLinc to lose power for a very small amount of time. Linking outside of ISY can also create link record problems. Probably never identify why it happened and again it is a very rare occurrence. The solution is exactly what you did, restore the KeypadLinc link database. Lee

The steps you listed are different from the steps UDI published at the beginning of this topic for installing 2.8.11. Have you tried doing an install following the steps UDI published?

With the symptom being location specific, not unique to a physical switch, it suggests the switch is being commanded to turn On. I guess it could be electrical in the sense that the power to the switch is fluctuating causing the switch to turn On but that would not explain the Motion Sensor coincidence. Also because of the coincidence of motion being sensed it is more likely to be commanded rather than noise. It would be a good idea “Save†the link database information just in case.

Sorry, my mistake. The scene name is selected from a scrollable list rather than pulldown. The Ramp Rate cannot be specified on a Direct device command. You cannot issue a Direct command to turn a device off with an 8 second ramp rate and then issue another Direct command to turn the device Off with a 4 minute ramp rate. If different Ramp rates are desired use different Scenes with different Responder Ramp Rates. The alternative is to change the Scene Ramp Rate with an Adjust Scene Action. The Adjust Scene function writes different Ramp Rate or Bright Level values into the Responder device. This takes several powerline commands and should be used with that in mind. EDIT: Ramp Rate applies when turning the device On with a Scene or turning the device Off with a Scene.

For those that do not show 2.8.10 after update, after clearing the Java cache, did you invoke the 2.8.11 Admin Console from the UDI web site to do the actual manual update?

Define an ISY Scene with the SwitchLinc Dimmer as a Responder. Right click on the SwitchLinc node and select "Add to Scene ...". Select the ISY Scene from the pulldown list being sure the SwitchLinc is a Responder. Set the Ramp Rate for the SwitchLinc Responder to the desired value. In the Program Set "scene" On rather than turning the device On. The Ramp Rate cannot be controlled with a device Direct command.

My Load Controller is also stable as far as turning the load On and Off. I have not seen the load cycle like that. The demand load sensing does not work reliably but that is only a state indicator. It has no effect on the actual load being controlled, at least it does not on the one I have.

Define an ISY Scene. Add the SwitchLinc and KeypadLinc load control button (ON or Main) as Controllers of the Scene. When the Scene has been written to both devices they will be cross-linked. Either device will control the load and the LEDs will stay in sync.

There is no known command that a device can send to another device that will turn the device On and then have that device send a message that occurs only when the paddle is pressed. Yes, the PLM contains a link database just like any other Insteon device. The PLM will not pass powerline messages to the application (ISY in this case) unless the PLM has at least a Responder record for the device that sent the message. Appreciate your thoughts. I would really like to know the cause of this symptom.

There is no absolute about this but the message has the from Insteon address of the switch and the switch has turned On. Since the switch turns On it is not a false message generated by the PLM.

There are now three traced events on the Powerhome forum for this situation. In all three cases a motion sensor message sequence precedes the switch sending a message that is was turned On. No known command can cause this result. The motion sensors are not linked to the switchs. Different systems involved. Have not heard of a solution so far.

Refer to this post for motion sensor information. http://forum.universal-devices.com/view ... highlight= The smaller the number the darker it has to be. Also the motion sensor requires at least 3.5 minutes at a particular light level before it has an effect.

Try Rand’s suggestion of pulling the battery for several minutes. Be sure to wait several minutes after attaching battery before attempting any programming or motion tests. Is there any chance the motion sensor that does not send an Off command had timed out of linking mode and did not get the time interval or On Only options set as desired. Might also check Jumper 5 to be sure the jumper is on both jumper 5 pins. Coordinating the InLineLinc and Motion Sensor Off situation will probably require an ISY Program to achieve what you want. You can set the RF motion sensor to 5 minutes and it will send an Off command to the InLineLinc at the 5 minute mark. The problem with absolutes like this is what happens if the InLineLinc MS has turned the InLineLinc On 2 minutes after RF Motion Sensor signals motion. In this case the RF Motion Sensor with send an Off what amounts to 3 minutes after the InLineLinc motion sensor signaled On. Just depends on what you want to live with. You may want a Program to monitor both the RF Motion Sensor and the InLineLinc so that the Program can generate an Off 5 minutes later than either On condition rather than a hard 5 minute Off from either the RF Motion Sensor or the InLineLinc motion sensor.

(Occupancy) Sensing mode, when checked, causes the motion sensor to send an On command any time motion is detected regardless of the timeout interval. When (Occupancy) Sensing mode is unchecked, the motion sensor sends the next On command when motion is detected, only after the timeout interval has expired. Normally this option is not checked. Not needed for normal motion detection and reduces battery drain by reducing the number of On commands sent from the motion sensor. If your application wants to know when the area is “occupied†then On commands on any motion is appropriate (Occupancy Sensing mode checked).

Under “Current Release, Betas, and Bug Reports†the first topic covers 2.8.10. Be sure to follow the steps detailed in this topic. There are a few steps for 2.8.10 that have not been in earlier releases. Many folks are on 2.8.10. I cannot stress this point too strongly. Failure to follow all the steps in the order given has resulted in some odd failures, all associated with an install that did not work correctly. Once you get to 2.8.10 the Set Options button will show the 6 options that are software controllable. The On Only mode is one of them. This option has to be checked for the motion sensor to send On and Off commands. Otherwise only On commands are sent. The effect of each option is explained alongside the option in the Set Options popup display. EDIT: you can always go back to full hardware control (remove Jumper 5) if you want to stay on 2.7.15. The two pots on the V2 motion sensors adjust the timeout delay to Off command as well as the Dusk/Dawn level. Not as easy as software control but possible. There is an "Occupancy" mode that can only be established with software control.

When Jumper 5 is installed the only jumper that has an effect is Jumper 1 for sensitivity. What ISY firmware level are you running? The Set Options button should be displaying 6 functions that are software controllable. The On Only mode is one of these 6 options. If not on a later 2.8.x image, where full motion sensor option support was added, you'll need to move to 2.8.10 or remove Jumper 5 and use all hardware control of the motion sensor.

What is the On Only mode set to?

You indicated no jumpers in place. Without Jumper 5 there is no software control of the motion sensor features. The small pot to the right of the jumpers controls the timeout. Sounds like the timeout interval set by the pot is long.

jp5150 That is good news about the KPL button actually being configured despite the error messages and display that shows non-toggle Off. I ran a test on my system earlier and realized that your setting a value 82 versus my setting a value of 02 was because I was setting only button B and from the 82 it would indicate both button B and button H are in non-toggle On mode. The following trace on my system now shows the same 82 because I also put button H into non-toggle ON mode. Fri 01/21/2011 07:36:15 PM : [b 4A AD 1 ] Memory : Write dbAddr=0x0249 [82] Fri 01/21/2011 07:36:15 PM : [iNST-ACK ] 02 62 0B.4A.AD 1F 2E 00 01 08 82 00 00 00 00 00 00 00 00 00 00 00 06 (00) Fri 01/21/2011 07:36:16 PM : [iNST-SRX ] 02 50 0B.4A.AD 12.9F.E4 2B 2E 00 (00) Fri 01/21/2011 07:36:16 PM : [standard-Direct Ack][0B.4A.AD-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 With all the Insteon traffic being the same and the KPL actually being set correctly, I'm wondering about the Java level. I am running 1.6.0_22-b04 on a Windows XP system. Lee

jp5150 Have you been clearing the Java Cache before invoking the Admin Console from the UDI server? Also use Help | About and confirm it shows 2.8.10. EDIT; have you tried the actual KPL button. It takes at least one button press to get the button into non-toggle mode specified. The display is clearly wrong but perhaps it actuall did place the button in non-toggle On mode. Lee

I have found that adding a device with New INSTEON Device and selecting a specific Device Type pulldown entry results in a v00. Looks like that path does not attempt to retrieve the device firmware level. I have not had any issues because of this. If there is some firmware level specific function in the ISY it could be. Try using the Auto Discover option. I get firmware levels when adding a device this way. The Motion Sensor must be added through the New INSTEON Device method selecting the Motion Sensor device type so there is no alternative for a MS. EDIT: 2.8.10 is a better place to be

I ran this test on an 8 button B v33 but I would have thought they would be the same. As you can see from the Memory : Write entry an 02 is being written here where you have an 82. Since your trace shows an ACK it appears the device accepted the command. Are you sure you are running on the 2.8.10 Admin Console. Try invoking the Admin Console directly from the UDI web site. Thu 01/20/2011 11:17:05 AM : [All ] Writing 1 bytes to devices Thu 01/20/2011 11:17:05 AM : [b 4A AD 1 ] Memory : Write dbAddr=0x0249 [02] Thu 01/20/2011 11:17:05 AM : [iNST-ACK ] 02 62 0B.4A.AD 1F 2E 00 01 08 02 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 01/20/2011 11:17:06 AM : [iNST-SRX ] 02 50 0B.4A.AD 12.9F.E4 2B 2E 00 (00) Thu 01/20/2011 11:17:06 AM : [standard-Direct Ack][0B.4A.AD-->ISY/PLM Group=0] Max Hops=3, Hops Left=2