LeeG

matapan To question 1, yes it is an option. Don't know how much work that would require to implement. The device firmware level is returned with the command that is used to obtain the device type (cat/subcat) information when Auto Discover is used. When the device type is specifically selected it is not necessary to ask the device what type it is so the firmware level is not known. To question 2, what was the situation with the old KeypadLinc? Error message, hang, it would be useful to know that to answer the question. If you are able to delete and add the KeypadLinc back with the Event Viewer running with Level: Device communication events selected (most important) I can analyze the trace. Lee

SteveSBE I renamed a Scene on 3.1.16 with 2 Responders. All the On Level and Ramp Rate values were unaffected by the rename. Did the rename several times. I suggest moving to 3.1.16 and see if it happens there. Lee

SteveSBE I don't think that is normal. What ISY firmware level is being used? Lee

jwagner010 The "Succeeded" in front of each Scene responder indicates the responders reacted to the Scene Test command. This means all the link records in the PLM and each Responder device exist and are correct. If a Responder fails to react to a Program Set Scene On for the same scene there are communications issues. The Set Scene uses a slightly different command sequence which does not have the redundancy of Scene Test. You are looking for some form of interference, noise or signal sucker, that is interfering with communication between the ISY PLM and the device(s) that are not responding to the Set Scene. Lee

jwagner010 Run a Scene Test for the Scene(s) that are not working reliably. Does the Scene Test work correctly? SteveSBE Can you clarify the situation a little. Is it the new devices that are not responding? For a device that fails a Scene Test try deleting the device from the Scene and adding it back. Sounds like something may have happened during the Insteon address update process such that not all the link records were updated with the new device address, Lee

Click Link Management | Start Linking. Press Set button on I/O Linc for 3-5 seconds. Click Finish button on popup. When device has been added the Insteon address will be displayed as the new node name. A meaningful node name can be assigned by renaming the new entry in the My Lighting tree.

That sounds like the results of the manual changes made to the device names in Programs and the changes were not Saved after the find/replace.

It is not the ISY time that is "off". It is the time the Admin Console is keeping separate from the ISY. Refer to the link I posted earlier with Michel explanation..

That was added at 2.8.7 so it will not be available in 2.7.15.

Move to 3.1.16. That symptom cannot be evaluated on that old a code base.

Could have been a small power glitch, could be a device on the way out. Just have to wait and see. I have found that very small power drops have more adverse affects than a full outage that lasts for minutes or hours. Also make sure the device is not being overloaded. Excess heat can be a factor. Do not change Programs or Scenes. The Replace xxx With does all that. The Program device name should not change. It references the old name and continues to reference the old name but the old name will have the new device address after the Replace with finishes. Add new KPL. Right click old KPL and select Replace xxxx With .... selecting new device. Lots of processing changing all link records affected (Scenes) and Program references. Again the Program device name reference should not change as the old device name remains in the My Lighting tree. Just all the references will have the new device address rather than the old device address.

Regarding the load being On, a Factory Reset might clear the condition if it is not a KPL hardware failure.

The Program and Scene changes should not have been done before the Replace. The Replace does all that. Since the Replace no longer finds the old address in Programs or Scene it cannot change the old references to the new address.

Michel posted on this subject before. I'll update with the link when I find it. Syncing the clock relates to syncing the ISY not the Admin Console. Exit the Admin Console and reinvoke to bring the times together. From memory I think Michel indicated the Admin Console can be up to 8 minutes out of sync with the ISY itself if the Admin Console remains running for a long period of time. EDIT: sorry it is 5 minutes. See this link.. viewtopic.php?f=27&t=6915&hilit=sync+time

You are very welcome. The addition of the UI line (Admin Console level) was added one or two beta images ago to provide a positive indication of the Admin Console level.

Take a look at the ISY User Guide Page 46 Section 3.6 Notifications. That should get you started.

Go to Help | About and be sure the Firmware line and the UI line both indicate 3.1.16. If both lines are not at 3.1.16 or there is no UI line at all clear the Java cache and be sure the URL invoking the Admin Console is for 3.1.16. It sounds like the Admin Console being run is not at 3.1.16 (indicated by the UI line just below the Firmware line). That would explain both the Unsupported device message and the link records not being correct. If the Help | About shows 3.1.16 for both run a Show Device Links Table for the InLineLinc and check the values in the last byte for a 01 of the link records that start with A2.

The link records in the InLineLinc have to be recreated under 3.1.16. Remove it from any Scene and add it back so the link records will be rewritten. Just to be sure the same issue is being discussed, what symptom is being experienced. EDIT: I checked my InLineLinc on 3.1.16. A Scene defined under 3.1.16 with the InLineLinc as a Responder has the corrected link record. The number in red should be a 1. If a 0 the link record has to be rewritten. A sample link record from my InLineLinc follows… A2 15 19.70.06 FF 1F 01

If you have to turn the Relay Off manually before issuing another On that works the Relay is not in Momentary mode. Set the Relay to one of the three Momentary modes and set the timeout interval for 2-3 seconds. The I/O Linc will automatically turn the Relay Off (will not be shown as Off in the Admin Console but it will be Off). The next On will turn the Relay On again moving the door again. If Status 'garage sensor' is On is the form of If needed. When the door closes the Status will change to Off and the Wait will be canceled. The Else clause will run. Since nothing is in the Else the email is effectively cancelled

That specific device type was added to one of the later 3.1.x betas. The latest beta is 3.1.16.

The Wait should be put after the existing statements. Otherwise the first message will come at 10:05 rather than 10:00 If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 288 times existing statements Wait 5 minutes Else - No Actions - (To add one, press 'Action')

Add a Repeat and Wait before statements in the Then Clause. A Repeat of 288 covers 24 hours. Probable not need that long. Adjust for as many 5 minute periods to repeat message. If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 288 times Wait 5 minutes Existing statements Else - No Actions - (To add one, press 'Action') When the Status of the heater goes to Off the Repeat loop ends.

I think you can mark them Disabled which will stop the ISY accessing them when they are unplugged. A potential problem would be if the Scenes they are in, if any, are updated. A year seems like a long time to have device definitions around that cannot be accessed. They can always be deleted later if problems arise. Will be interesting to see what others are doing in similar situations.

Motion Sensor - Dusk/Dawn

No. Put something in front or turn the ISY toward the wall.