LeeG

I always manually update because I want to have positive control of image installs. There is no physical difference as far as the ISY is concerned. Only Official releases are done automatically. I never allow such a spread between what is installed and what is available. I don't want to see an issue that has already been resolved in a later image. Some folks will sit on an older image until some issue surfaces or newer device support is needed. There are folks running 3.3.10 on a 99i, even some have a 994i sitting in a box just in case. If you have no problems, staying with an old image avoids spending the few minutes to install each new beta image. I guess it comes down to personal choice what you want to spend time doing. I'm sure there will be strong views on both sides of the question. Is Ford or Chevy better?

There is no dimmerlinc. Is that a SwitchLinc Dimmer, KeypadLinc Dimmer, ToggleLinc Dimmer, LampLinc (which always has dimmer capability), etc

My trace was invoking a test Program. The Program issued the X10 traffic. Motion1x - [iD 0067][Parent 0001] If Control 'MotionSensor2-Sensor' is switched On And Status 'SwitchLinc Dimmer' is Off And From 3:00:00PM To 10:00:00PM (same day) Then Set 'SwitchLinc Dimmer' On Wait 10 minutes Set 'SwitchLinc Dimmer' Off Else Send X10 'A1/All Lights Off (1)'

This is a trace of the MS sensor with those options set. Fri 01/23/2015 02:32:45 PM : [iNST-SRX ] 02 50 13.F2.57 00.00.01 CB 11 01 LTONRR (01) Fri 01/23/2015 02:32:45 PM : [std-Group ] 13.F2.57-->Group=1, Max Hops=3, Hops Left=2 Fri 01/23/2015 02:32:45 PM : [D2D EVENT ] Event [13 F2 57 1] [DON] [1] uom=0 prec=-1 Fri 01/23/2015 02:32:45 PM : [ 13 F2 57 1] DON 1 Fri 01/23/2015 02:32:45 PM : [D2D-CMP 006D] CTL [13 F2 57 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Fri 01/23/2015 02:32:45 PM : [D2D-CMP 0067] CTL [13 F2 57 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Fri 01/23/2015 02:32:45 PM : [ X10] A1 Fri 01/23/2015 02:32:45 PM : [X10-RSP ] 02 63 66 00 06 Fri 01/23/2015 02:32:45 PM : [ X10] A1/All Lights Off (1) Fri 01/23/2015 02:32:46 PM : [iNST-SRX ] 02 50 13.F2.57 22.80.0B 46 11 01 LTONRR (01) Fri 01/23/2015 02:32:46 PM : [std-Cleanup ] 13.F2.57-->ISY/PLM Group=1, Max Hops=2, Hops Left=1 Fri 01/23/2015 02:32:46 PM : [iNST-DUP ] Previous message ignored. Fri 01/23/2015 02:32:46 PM : [X10-RSP ] 02 63 66 80 06 Fri 01/23/2015 02:32:47 PM : [X10-RX ] 02 52 66 00 Fri 01/23/2015 02:32:47 PM : [ X10] A1 Fri 01/23/2015 02:32:55 PM : [iNST-SRX ] 02 50 13.F2.57 00.00.01 CB 11 01 LTONRR (01) Fri 01/23/2015 02:32:55 PM : [std-Group ] 13.F2.57-->Group=1, Max Hops=3, Hops Left=2 Fri 01/23/2015 02:32:55 PM : [D2D EVENT ] Event [13 F2 57 1] [DON] [1] uom=0 prec=-1 Fri 01/23/2015 02:32:55 PM : [ 13 F2 57 1] DON 1 Fri 01/23/2015 02:32:55 PM : [D2D-CMP 006D] CTL [13 F2 57 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Fri 01/23/2015 02:32:55 PM : [D2D-CMP 0067] CTL [13 F2 57 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Fri 01/23/2015 02:32:55 PM : [ X10] A1 Fri 01/23/2015 02:32:55 PM : [X10-RSP ] 02 63 66 00 06 Fri 01/23/2015 02:32:55 PM : [ X10] A1/All Lights Off (1) Fri 01/23/2015 02:32:56 PM : [iNST-SRX ] 02 50 13.F2.57 22.80.0B 46 11 01 LTONRR (01) Fri 01/23/2015 02:32:56 PM : [std-Cleanup ] 13.F2.57-->ISY/PLM Group=1, Max Hops=2, Hops Left=1 Fri 01/23/2015 02:32:56 PM : [iNST-DUP ] Previous message ignored. Fri 01/23/2015 02:32:56 PM : [X10-RSP ] 02 63 66 80 06 Fri 01/23/2015 02:32:57 PM : [X10-RX ] 02 52 66 00 Fri 01/23/2015 02:32:57 PM : [ X10] A1 Fri 01/23/2015 02:33:06 PM : [iNST-SRX ] 02 50 13.F2.57 00.00.01 CB 11 01 LTONRR (01) Fri 01/23/2015 02:33:06 PM : [std-Group ] 13.F2.57-->Group=1, Max Hops=3, Hops Left=2 Fri 01/23/2015 02:33:06 PM : [D2D EVENT ] Event [13 F2 57 1] [DON] [1] uom=0 prec=-1 Fri 01/23/2015 02:33:06 PM : [ 13 F2 57 1] DON 1 Fri 01/23/2015 02:33:06 PM : [D2D-CMP 006D] CTL [13 F2 57 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Fri 01/23/2015 02:33:06 PM : [D2D-CMP 0067] CTL [13 F2 57 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Fri 01/23/2015 02:33:06 PM : [ X10] A1 Fri 01/23/2015 02:33:06 PM : [X10-RSP ] 02 63 66 00 06 Fri 01/23/2015 02:33:06 PM : [ X10] A1/All Lights Off (1) Fri 01/23/2015 02:33:07 PM : [iNST-SRX ] 02 50 13.F2.57 22.80.0B 46 11 01 LTONRR (01) Fri 01/23/2015 02:33:07 PM : [std-Cleanup ] 13.F2.57-->ISY/PLM Group=1, Max Hops=2, Hops Left=1 Fri 01/23/2015 02:33:07 PM : [iNST-DUP ] Previous message ignored. Fri 01/23/2015 02:33:07 PM : [X10-RSP ] 02 63 66 80 06 Fri 01/23/2015 02:33:16 PM : [iNST-SRX ] 02 50 13.F2.57 00.00.01 CB 11 01 LTONRR (01) Fri 01/23/2015 02:33:16 PM : [std-Group ] 13.F2.57-->Group=1, Max Hops=3, Hops Left=2 Fri 01/23/2015 02:33:16 PM : [D2D EVENT ] Event [13 F2 57 1] [DON] [1] uom=0 prec=-1 Fri 01/23/2015 02:33:16 PM : [ 13 F2 57 1] DON 1 Fri 01/23/2015 02:33:16 PM : [D2D-CMP 006D] CTL [13 F2 57 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Fri 01/23/2015 02:33:16 PM : [D2D-CMP 0067] CTL [13 F2 57 1] DON op=1 Event(val=1 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> true Fri 01/23/2015 02:33:16 PM : [ X10] A1 Fri 01/23/2015 02:33:16 PM : [X10-RSP ] 02 63 66 00 06 Fri 01/23/2015 02:33:16 PM : [ X10] A1/All Lights Off (1) Fri 01/23/2015 02:33:17 PM : [iNST-SRX ] 02 50 13.F2.57 22.80.0B 46 11 01 LTONRR (01) Fri 01/23/2015 02:33:17 PM : [std-Cleanup ] 13.F2.57-->ISY/PLM Group=1, Max Hops=2, Hops Left=1 Fri 01/23/2015 02:33:17 PM : [iNST-DUP ] Previous message ignored. Fri 01/23/2015 02:33:17 PM : [X10-RSP ] 02 63 66 80 06 Fri 01/23/2015 02:33:18 PM : [X10-RX ] 02 52 66 00 Fri 01/23/2015 02:33:18 PM : [ X10] A1

I had to go back to 4.2.18 to get the Options display that matches yours. The Motion Sensor is not using those options as it would not use the timeout if Sensing mode was checked in the motion sensor. Uncheck Sensing Mode; and click Ok. After the MS updates have been written, click Options, check Sensing Mode and click Ok. This should stop the Motion Sensor from using the timeout value.

This is Motion Sensor Options display from 4.2.18 with the required options checked.

GaryK4 The 4.2.22 image did not change the way Motion Sensors work. The Motion Sensors Options popup did change how the MS options are presented but the underlying MS functions remain the same. It will take some minutes but I will post the Options popup from 4.2.18. The Motion Sensor was not updated for some reason since it is waiting the .5 second timeout. If the Sensing mode: was checked it did not get written back to the Motion Sensor. With the Motion Sensor in linking mode, uncheck Sensing Mode and write that back to the Motion Sensor. Bring up the Options popup again, check the Sensing mode: and write it back to the Motion Sensor. The ISY does not write changes back to the Motion Sensor unless they are different from what the ISY thinks are already set. The "Previous message ignored" message is displayed for the several Insteon messages that are generated for each Motion On message. They serve no function in terms of triggering a Program and are ignored by the ISY.

You must be running something other than 4.2.22 so my post in the other topic does not match your motion sensor Options display. Check the Sensing Mode: option. With this option checked along with sending On Only commands the motion sensor does not wait for the timeout value to expire before sending the next motion On message.

Jumper 5 should be the only jumper in use. Put the Motion Sensor into linking mode and set these Options EDIT: note that MS Options display is from 4.2.22. The MS Options display looks different on 4.2.18 but the options work the same. UDI changed the format of the display, not the underlying MS Options themselves.

bambamf16 Sorry the example from post #11 was not clear In Scene "hiddendoorsensor" Set "responder" xx% Happy larryllix was able to clear it up

Sounds like a PLM problem. Unplug the PLM for a few minutes. After plugging it back in do a Factory Reset of PLM followed by a File | Restore Modem (PLM) to rebuild PLM. Is the PLM a 2412 or 2413 and how old?

"The above programs change the on level of the dimmer in the scene but not in the Door sensor" For the Program to affect what the Scene name does the Scene name had to be specified in the In Scene parameter. That statement remains as is. To that add another Adjust Scene statement with the Hidden Door Sensor in the In Scene parameter. I have assumed the Hidden Door Sensor is also a Controller in the Scene definition. If that is not correct post the Scene definition and the current Program(s).

"What is the disadvantage of variables?" Compared to what? Variables are great when a variable is needed/useful. What would you use instead?

The Adjust Scene needs to specify the name of the Controller in the "In Scene" parameter. In Scene "hiddendoorsensor" Set "responder" xx%

The PLM has 5 Controller link records with that Scene number, each pointing to one of the 5 devices. Each of the 5 Responders has a Responder link record with the PLM address and Scene number. The PLM issues a single Scene On that all devices receive. Those devices that have a matching Responder link record react to that single Scene On. Suggest going to insteon.com and read the insteondetails.pdf doc

shannong If 472 is consistently received on multiple Show PLM commands it as as Stusviews indicated, old no longer used links have been eliminated. Need to see that number on multiple Show PLM commands to know it is accurate. I am concerned that number is accurate as the 780 number was the number from multiple PLM restores and Show PLM Links Table commands.

Using Direct commands each device turns On, one after the other. Five Insteon commands are issued and 5 ACKs are received. Using a Scene a single command issued and all the devices turn On at the same time.

Scenes are a normal way of doing things in Insteon. It would be unusual to do all things with individual devices and Programs. Too slow and too much Insteon traffic to do things one device at a time..

Grizzy It is a waste of time keeping multiple PLMs updated while the environment is changing. Also, if you have reliable Insteon network changing PLMs is nothing more than time. All your devices will be I2CS so each device PLM link update is done with one command. If your Insteon network is unreliable you will have issues replacing a PLM.

Keep an eye on the count of PLM link records. If near the maximum it does not take too much repeated updates (as adding devices from scratch) to over flow the PLM link database. It may be necessary to run Show PLM Links Table multiple times to get a repeatable count as device messages received during the Show PLM will produce a false high or low link count.

The process is dependent on the reliability of the Insteon network. There are large numbers of commands issued to update all the device link records that contain the PLM address. An 8 button KPL has 9 link records (minimum) with the PLM address not counting ISY Scenes the device participates in. If any are I2 (or old I1) devices the updates are done 1 byte at a time which is 2 or three commands per byte changed. Areas that have marginal Insteon comm usually have issues do to the high volume of Insteon traffic. Often folks are not interested in spending the time to resolve the comm issues because they don't fail much in day to day operation. Just keep issuing Write Updates to Device until each marginal device has all the updates written.

The Event Viewer at LEVEL 3 will show the activity. So will watching the Icons to the left of the device nodes. Devices that are not I2CS update link records 1 byte at a time. As Teken has indicated updating all the link records in all the devices that have the old PLM address can take hours. When the powered devices are complete each battery powered device has to be put into linking mode, one device at a time, to update those devices.

If the Door Open node is not being used it could be a Controller of an ISY Scene that has the LampLinc as a Responder with a 0% On Level. That Scene will turn Off the LampLinc when the door is opened because of the 0% Responder On Level.

The Hidden Door Sensor does not send an Off message even though the ISY marks the node Off. A Program triggered by a Status of Off to turn the LampLinc Off is required.

The KPL has retry so changing to a Program issued Direct command would not have benefit. A program could be triggered by the KPL button press and check the Status of the device that should have been controlled by the KPL. Some sort of Direct command retry to failing device until it reacts as wanted (or some maximum retry count).