LeeG

hbsh01 Although the Controller (Motion Sensor) is RF and will be asleep most of the time, the Adjust Scene would be changing the Responder On Level which resides in the link record located in the device physically powering the desk lamp. The Responder On Level can be changed without the need to communicate with the Controller (Motion Sensor).

A right click on My Programs allows Find/Replace to be selected which will change the Programs. The Save has to be done separately.

All changes to $Zone6 and Program 'stay_mode' trigger the Program. Most of the time the If is going to be evaluated False which results in the Wait and turning the Set Scene 'Foyer' Off. I assume these statements were put in the Else because the Set Scene 'Foyer' Off was not being executed when put in the Then clause. They don't get executed because a Wait allows the If to be reevaluated. The Program trigger condition changes to False during the Wait so the statement(s) after the Wait do not get executed. Rather than put the Wait and Set Scene 'Foyer' Off in the Else, split the logic into two Programs. The first Program triggers as coded now but invokes a second Program from the first Program Then clause which has the Then clause Then Set Scene 'Foyer' On Wait 1 minute Set Scene 'Foyer' Off This way the If in the first Program does not get revaluated because there is no Wait statement.

There is an Adjust Scene statement that supports changing the Scene Responder On Level and/or Responder Ramp Rate. The Adjust Scene statement changes the link record in the device controlling the desk lamp. This statement is something that would be issued once or twice a day say based on time of day. Not something to be used dozens of times a day. The other approach is not have the Motion Sensor the Controller of the Scene. Instead the Motion On triggers a Program which turns the desk lamp on at 100% or xx% based on the If conditions or perhaps does not affect the On Level at all if the desk lamp is already On. This provides the most flexibility but adds a slight delay in turning the desk lamp On as the Motion On has to trigger a Program rather than being a Controller of a device.

Here is the file name of an ISY Backup file taken from 3.2.6. It is 20k in size. These files are ZIP in a ZIP. ISY-Backup.v3.2.6__Sun 2012.10.14 11.53.17 AM.zip Without a valid backup I have no suggestion on how to recover short of starting over.

Yes. A specific time is True only at that specific time. Post the Program. Rather than go through a series of Q&A, looking at the Program will usually answer most of the questions. Right click Program name, select Copy to Clipboard, paste to forum post.

The ISY Restore is pointing at a backup file and not an image file.

What level ISY is running and what level backup?

"File | Delete Modem removes ALL the links to devices from the PLM and vice versa. The only way to get them back would be File | Restore ISY (to restore a backup with the links) and then File | Restore Devices." Michel was describing what happens, not that Delete Modem should be issued. Delete Modem is for contractors who used an ISY to establish Insteon and then the ISY and PLM are being physically removed. A normal user NEVER issues a Delete Modem (PLM). I did not review all the posts this morning but if memory is correct the other electronics were not unplugged when the UPS was unplugged.

I would not assume the backup is bad because Windows and Zip have a problem. They are not involved. Use the backup file as it was intended

Sorry, I don't have any idea about images that old. 3.3.10 is the latest official release (last image that will run on a 99i) with 4.0.5 RC2 the likely next official release (4.0.x requires a 994i). You can open a ticket with UDI tech support (link at the bottom of all of Michel's posts). With the impact of running Delete Modem (PLM) and the only backup 2.8.16 I think the best course of action is to install 3.3.10 and rebuild your system from scratch.

That is an indication that during the process of moving to the new PLM a Delete Modem (PLM) was issued. This removed all references to a PLM both in the devices and the PLM itself. Need to go back to an ISY Backup that was done prior to issuing the Delete Modem (PLM). Then do a Restore Modem (PLM) followed by a Show PLM Links Table and Count to verify the older ISY Backup has the PLM link information. Once the PLM has the correct number of link records a File | Restore Devices must be invoked to put the link records back in all the devices that point back to the PLM. Thanks for the additional information about being able to control the devices. This means the PLM is functional. However, that activity does not use Link Records in either the PLM or the device which is why it works even though local state changes are not registered and Scenes do not work. The state change and Scenes require link records in both the PLM and device which were lost when the Delete Modem (PLM) was done.

Also was the ISY powered down while the new PLM was being connected to the ISY? It is necessary for the ISY to reboot after the new PLM is installed for it to be aware of the new PLM address.

Do a Show PLM Links Table followed by Count. Do the Show followed by Count 4 times to insure the same Count is received. If the PLM link count is not correct do the Restore Modem (PLM) again.

The Insteon Direct command does not have a placeholder for Ramp Rate. Use an Adjust Scene where both the In Scene and Set parameters specify the device. The device must be a Controller in a Scene for it to appear as a selection in the In Scene parameter. After the Adjust Scene statement is executed the issue the Insteon Direct command. Note that some older devices require a power cycle for a change to the Local Ramp Rate (or Local On Level) to take affect. This solution also affects what happens when the local paddle is pressed. If the Program action should not have an effect on the local paddle press, define an ISY Scene with the device as a Responder with the Responder On Level and Responder Ramp Rate as desired. Then have the Program turn the ISY Scene On. No device power cycle is needed for this solution.

Looks like the Delete Modem (PLM) function was issued which effectively removes all references to the PLM both in the devices and the PLM itself. Need to go back to an earlier ISY backup, do another Restore Modem (PLM) followed by a Show PLM Links Table and Count to verify the earlier backup was taken before the Delete Modem (PLM). Once the PLM has been restored then a File | Restore Devices is needed to put back the references to the PLM in all the devices.

The PLM has no link records for that Scene. Note the 15 on the end. This indicates the PLM has no record of that Scene. Fri 05/24/2013 04:54:41 PM : [GRP-RX ] 02 61 16 13 00 15 The normal solution is to issue a Restore Modem (PLM). After doing the Restore Modem issue a Show PLM Links Table followed by Count. Do this 4 times to insure the Count is the same each time. How many link records does the Count indicate.

Run Tools | Diagnostics | Event Viewer at LEVEL 3. Run a Scene Test on a small Scene. Post the event trace. It sounds like the link records in the PLM have been lost. If this is true the Insteon command issued to control the Scene will end with a 15 which indicates no link records exist for the Scene in the PLM.

NEVER Delete Modem (PLM). That removes the references to the PLM in the ISY configuration and device link databases. Effectively prevents the ISY from doing what it needs to do. Go back to an ISY Backup taken before the Delete Modem (PLM) was issued. Then Restore Modem (PLM).

Smarthome carries the filler I mentioned before. See this link http://www.smarthome.com/865160W/Levito ... ite/p.aspx

The home improvement stores around here carry a blank filler. It screws in place like any other switch but is thin, just fills in the empty slot.

This is what I get when I tap the Set button on the Smoke Bridge with v.43 firmware. Five groups/nodes receive messages. Thu 05/23/2013 02:07:59 AM : [iNST-SRX ] 02 50 23.50.FD 00.00.01 CB 11 80 LTONRR (80) Thu 05/23/2013 02:07:59 AM : [std-Group ] 23.50.FD-->Group=1, Max Hops=3, Hops Left=2 Thu 05/23/2013 02:07:59 AM : [ 23 50 FD 1] DON 128 Thu 05/23/2013 02:07:59 AM : [ 23 50 FD 1] ST 255 Thu 05/23/2013 02:07:59 AM : [iNST-SRX ] 02 50 23.50.FD 11.00.01 CB 06 00 (00) Thu 05/23/2013 02:07:59 AM : [std-Group ] 23.50.FD-->11.00.01, Max Hops=3, Hops Left=2 Thu 05/23/2013 02:07:59 AM : [iNST-INFO ] Previous message ignored. Thu 05/23/2013 02:08:01 AM : [iNST-SRX ] 02 50 23.50.FD 00.00.02 CB 11 40 LTONRR (40) Thu 05/23/2013 02:08:01 AM : [std-Group ] 23.50.FD-->Group=2, Max Hops=3, Hops Left=2 Thu 05/23/2013 02:08:01 AM : [ 23 50 FD 2] DON 64 Thu 05/23/2013 02:08:01 AM : [ 23 50 FD 2] ST 255 Thu 05/23/2013 02:08:01 AM : [iNST-SRX ] 02 50 23.50.FD 11.00.02 CB 06 00 (00) Thu 05/23/2013 02:08:01 AM : [std-Group ] 23.50.FD-->11.00.02, Max Hops=3, Hops Left=2 Thu 05/23/2013 02:08:01 AM : [iNST-INFO ] Previous message ignored. Thu 05/23/2013 02:08:06 AM : [iNST-SRX ] 02 50 23.50.FD 00.00.06 CB 11 10 LTONRR (10) Thu 05/23/2013 02:08:06 AM : [std-Group ] 23.50.FD-->Group=6, Max Hops=3, Hops Left=2 Thu 05/23/2013 02:08:06 AM : [ 23 50 FD 6] DON 16 Thu 05/23/2013 02:08:06 AM : [iNST-SRX ] 02 50 23.50.FD 11.00.06 CB 06 00 (00) Thu 05/23/2013 02:08:06 AM : [std-Group ] 23.50.FD-->11.00.06, Max Hops=3, Hops Left=2 Thu 05/23/2013 02:08:06 AM : [iNST-INFO ] Previous message ignored. Thu 05/23/2013 02:08:11 AM : [iNST-SRX ] 02 50 23.50.FD 00.00.07 CB 11 08 LTONRR (08) Thu 05/23/2013 02:08:11 AM : [std-Group ] 23.50.FD-->Group=7, Max Hops=3, Hops Left=2 Thu 05/23/2013 02:08:11 AM : [ 23 50 FD 7] DON 8 Thu 05/23/2013 02:08:11 AM : [iNST-SRX ] 02 50 23.50.FD 11.00.07 CB 06 00 (00) Thu 05/23/2013 02:08:11 AM : [std-Group ] 23.50.FD-->11.00.07, Max Hops=3, Hops Left=2 Thu 05/23/2013 02:08:11 AM : [iNST-INFO ] Previous message ignored. Thu 05/23/2013 02:08:16 AM : [iNST-SRX ] 02 50 23.50.FD 00.00.05 CB 11 00 LTONRR (00) Thu 05/23/2013 02:08:16 AM : [std-Group ] 23.50.FD-->Group=5, Max Hops=3, Hops Left=2 Thu 05/23/2013 02:08:16 AM : [ 23 50 FD 5] DON 0 Thu 05/23/2013 02:08:16 AM : [ 23 50 FD 1] ST 0 Thu 05/23/2013 02:08:16 AM : [ 23 50 FD 2] ST 0 Thu 05/23/2013 02:08:16 AM : [iNST-SRX ] 02 50 23.50.FD 11.00.05 CB 06 00 (00) Thu 05/23/2013 02:08:16 AM : [std-Group ] 23.50.FD-->11.00.05, Max Hops=3, Hops Left=2 Thu 05/23/2013 02:08:16 AM : [iNST-INFO ] Previous message ignored. Unfortunately my sensor order is back ordered for more than a week so I cannot test with multiple sensors linked to the Smoke Bridge. I don't think you link multiple sensors to the Smoke Bridge as they are all linked between themselves so the one linked to the Smoke Bridge will provide the needed alarm messages. Note that the various sensors are not "linked" to the smoke bridge using Insteon link database so when the device is added to the ISY the remove existing links (referring to Insteon links, not sensor links) should be selected.

The FanLinc should be connected to unswitched 120v AC. The SwitchLinc is getting in the way of correct FanLinc operation.

Garage Door Opener Program cannot be triggered by a change in the Variable value because it is an Integer variable. Integer variables cannot trigger Programs. The example provided is run using a Run Then from MobiLinc, not from the variable value changing. “This is my Open Close program (Run then from Mobilinc)†There is a complete forum Category for variables. The very first post describes how variables work which explains that the only difference between an Integer and State variable is that Integer variables never trigger Programs.

Do a Show Device Links Table for 0D.73.B1 and Compare. It is looking more and more like a Delete PLM was issued which along with removing device references from the PLM would remove PLM references from devices. With an earlier ISY backup now in use I think the Compare after reading the Device Links Table will show the device missing the link records that point back to the PLM. A Restore Device followed by another Scene Test. Eventually we may run into the bug where the Scene Test displayed failure when the Scene Test was successful but that will be clear from the event trace. First the PLM did not have the necessary link records. Now that the PLM has been corrected the device NAKed the Scene Test command because the device is missing the Responder link record pointing back to the PLM. If the Restore Device corrects the problem so the Scene Test shows successful or it falsely shows failure due to the bug even though the actual Scene Test was successful, a File | Restore Devices will be needed to put the PLM link records back in all the devices. This is the NAK response from the device. It means the device did not have the required Responder Link record Wed 05/22/2013 08:01:08 AM : [iNST-SRX ] 02 50 0D.73.B1 1F.25.10 E1 13 FF LTOFFRR(FF)