LeeG

Yes, 4.1.1 supports the Dual Band KPL as well as other new devices.

No way I know of short of not using the devices that have come out since 3.3.10 was released.

PIR motion sensors detect the movement of heat across the view of the motion sensor. If the heat source does not move as with an individual sitting or standing motion free, a PIR does not trip. Folks have discussed using a pressure sensor in the seat where someone would be sitting. Insteon does not make those but a pressure switch could be connected to an I/O Linc Sensor.

The Dual Band KPL along with other new Insteon devices are not supported by 3.3.10. These devices were released after 3.3.10 was released. There is an upgrade program to move to the newest 994i. Look at the UDI Web site for information.

"This takes about a minute to complete." A minute could be okay. Depends on how many devices are defined, how many Scenes are defined, etc. The PLM activity is happening over the Serial interface so things run pretty quick. If things are not working after the Restore Modem (PLM), run File | Restore Devices.

Do not check the I/O Linc Relay status. It is a Responder Only node so when it is told to turn On to move the door and it turns itself Off, the ISY does not know about that. Looking at the Relay state would not indicate if the door was open or closed anyway. A Program that is checking the I/O Linc Sensor being On or Off indicates if the door is open or closed. Things in the ISY are event driven so the Program only triggers when a event happens. Something like If Status 'iolincsensor' is On (or Off depending on which magnetic switch is used) indicates when the door is open. If Status 'iolincsensor' is On Then turn something On Else

The Restore Modem (PLM) has to be issued after the PLM and the ISY have been cycled. Physically changing the PLM does not alert the ISY to the change. The new PLM does not tell the ISY it is new. Try running the Restore Modem (PLM) again and if that does not resolve things run File | Restore Devices.

The ISY needs to be power cycled after changing the PLM so the ISY knows the PLM has been changed. Changing the PLM requires many link records in ALL the devices (including the PLM) be changed so the devices are sending the state change messages to the correct device and the PLM will received the messages.

Not sure what a Program node code would be. Go to Programs | Summary display, right most column for Program ID.

When the statements after a Wait are not executed it means the If condition changes while in the Wait. The ISY terminates the Wait, reevaluates the If and executes the Else clause because the If is now False. The statements after the Wait never get executed. There is also a problem with the If clause independent of the above. It needs some parens. If From Sunset To Sunrise (next day) And ( $sAlarmZ14_GarageDoorPaco is 1 Or $sAlarmZ13_GarageDoorHoney is 1 ) Then Enable Program 'Garage Scene HallWay' Wait 5 minutes Disable Program 'Garage Scene HallWay' Else - No Actions - (To add one, press 'Action') A simple solution is to put the above into two programs. The Then section invokes Program 2 which has the Enable/Wait/Disable. There are other approaches as well.

Keep in mind the answers applied to the questions asked. Change the question a little and the answer changes. For example ..... If Control 'KPL Floor Dimmer 6 / KPL Floor Dimmer 6 - B' is switched On And Time is 2:38:00PM Then Send X10 'D1/All Lights Off (1)' Else Send X10 'D1/Off (11)' will execute the Else clause.

Things in the ISY are event driven. At the From time the Then clause is invoked. At the To time the Else clause is invoked. A Program that has a single specific time, only the Then clause is invoked at the specific Time

"with zero being off" I said I would not do this but THIS IS WRONG. Run the event trace in HL and watch the commands with their associated values. A value of 00 is not used on HL. You grew up with HL and like it. That is fine but, to say the ISY is not doing something right because HL chose not to offer the option and ISY does is out of place.

I'm going to stand aside from this part of the discussion. The ISY implements what the SmartLabs spec indicates. In this case the discussion of using a 00 value is unique to the ISY. HL does not use that value. There are various combinations the ISY allows and the device supports that HL does not support. The ISY presents it because the SmartLabs specs indicate it is a valid value. The discussion as to what the device does with that value is not something the ISY should change (IMO).

That may make perfect sense in a logical world but we work with what SmartLabs engineers produce. The ISY did not chose how the device reacts to 00. It is an interesting discussion but the SmartLabs folks are who you need to have a discussion with.

shannong The 00 Backlight level is not Off. It looks like the equivalent of the default On level. The Off Backlight level uses a different command to shut Off the KPL button LEDs.

The Adjust Scene statement changes what happens when the Scene is invoked either by a Program or a device paddle/button press (or both with enough Adjust Scene statements). The Adjust Scene statement itself does not affect the physical On Level or Ramp Rate. With multiple devices involved multiple Adjust Scene statements are necessary. ------------------------------------- The Local On Level for the KPL which is physically controlling the load has to change so the pressing of the KPL button will have the new On Level. The KPL is the Controller. The SwitchLinc is a Responder so it needs an Adjust Scene statement so that the Status LEDs of the SwitchLinc stay in sync when the KPL button is pressed. ------------------------------------- The reverse is also true. The Local On Level of the SwitchLinc needs to be changed so when the SwitchLinc paddle is pressed the SwitchLinc Status LEDs will be correct. The SwitchLinc is the Controller. The KPL Responder On Level has to be changed so when the SwitchLinc turns the KPL load On the KPL turns On to the correct Responder On Level. -------------------------------------- If the Scene Name will be used in a Program two more Adjust Scene statements are needed. In this case the PLM is the Controller so the KPL Responder On Level and SwitchLinc Responder On Level also have to be changed. -------------------------------------- Six Adjust Scene statements are needed to change all the possible On Level values involved. ---------------------------------------------------------------- Again, the Adjust Scene statements change what will happen when the KPL button is pressed, what will happen when the SwitchLinc paddle is pressed and what happens when the Scene Name is used. The Adjust Scene statements themselves do not change the displayed On Level.

If it catches a failure that should provide good information. It is likely something before the Sunrise activity that is causing this with all the KPLs marked as comm failures.

What would be helpful is to have Tools | Diagnostics | Event Viewer at LEVEL 3 running a few minutes before the backlight change at 10 PM. The event trace at that time will show what happens with the backlight changes if they fail.

Are all the KPLs involved with the backlight change marked with a Red ! or Green Icon? If all the devices are marked there would something common. Could be general comm issue or PLM. If only selected KPLs are marked then comm would be more likely, maybe an Access Point not coupling as it should. Thanks for the PLM info. The 2413 PLMs have a faster processor than the older 2412. With both being a 2413 that would not be factor.

Was the previous PLM a 2412?

Thanks for the trace data. No obvious issues seen. It takes 1 extra hop to get to 15.9C.2F but that is consistent across the tests. Another user suggested putting a Wait 1 second between the calls to allow for any retry activity. I think that is a good idea. Also are other Insteon things being initiated at the same time these backlight changes are being run. Something else at Sunrise for example.

Suggest posting the Program with Copy to Clipboard. It sounds like a comm problem is developing which is slowing down the backlight processing or something is interfering with the Program trigger that is changing the backlight level. Look at Programs | Summary the next time this happens and see if the Program was actually triggered and what the Status column (True/False) indicates. To look at how well comm is working in general handling the backlight change run Tools | Diagnostics | Event Viewer at LEVEL 3. Right click the backlight Program and select Run Then (or Run Else). Look at the various Hops Left=x counts going to the various KPLs. Hops Left=2 is best, Hops Left=0 is poor.

The ISY Finder window is normal. The second number being described is the UUID of the ISY. Google UUID for a description. If you had multiple ISY devices installed the ISY Finder would normally show all of them, allowing you to pick which ISY the Admin Console should connect to. I don't think this is related to the missing option. Going directly to the ISY IP address bypasses the ISY Finder. Without specifying the IP address, the Admin Console goes to the router asking for UUID of the ISY(s).

Sorry about the time reference. For Java a few months is a long time. The browsers were closed and the Java cache cleared after installing the latest Java?