LeeG

Assuming a Secondary KeypadLinc button the only way to turn On/Off that Secondary KeypadLinc button is assign the button as a Responder in an ISY Scene and turn the Scene On/Off. Secondary KeypadLinc buttons cannot be turned On/Off with Direct Insteon commands. The Direct command structure has no means of identifying which Secondary KeypadLinc button.

Since both doors opened within seconds of HER door closing I would look at the Remote in HER car to see if there is some way it is sending the Opens.

Both doors opened 2 and 3 seconds after HER door closed. Note the time stamp on the LOG messages. HER door opened at 4:16:56 HER door closed at 4:18:08 HER door opened at 4:18:10 - door opened 2 seconds after HER door closed HIS door opened at 4:18:11 - door opened 3 seconds after HER door closed As there are no RELAY actions logged between 4:18:08 and 4:18:10/4:18:11, the doors opened in response to a Remote command or some other RF signal.

The Mini Remote does not have the capability to change individual button status. There is nothing available with Mini Remote that allows a button "next command issued" to be changed. An ISY Program can be written to trigger based on either command (or both) and turn a device/Scene On/Off but the Mini Remote LED will be out of sync with the action performed by the ISY Program. Having multiple Mini Remote buttons affect the same device will always result in either pressing a button multiple times or the Mini Remote LED being out of sync with the action performed by an ISY Program. The Mini Remote is just too limited in function to have the kind of button control possible with a KeypadLinc.

It is not a bug as that is how the Wait and Repeat functions are designed to work. The Wiki section that covers Wait and Repeat explains this interaction. I think adding an option to Wait and Repeat to prevent the If reevaluation has been asked for but has a low priority as using two Programs is the alternative. The If reevaluation works well when used with actions that repeat such as Motion Sensors where the actions after the Wait/Repeat are desired only after all motion stops. If Control 'motion - sensor' is switched On Then turn lights On Wait 10 minutes turn lights Off Else The lights stay On as long a motion detection continues.

The Program is in the 30 minute Wait at 7:30. The Program is triggered at 7:30 because of the Time parameter. Being ANDed with †'is9Minyan' is True†the evaluation is False so the Else clause executes. Knowing the Program started at 7:00 rather than 7:30 as was originally indicated changes how the scenario occurs but the result is the same. Starting at 7:00 means the 7:30 Time triggers the Program. If it had started at 7:30 one of the other conditions would have had to change to cause the Program to trigger again as the Time parameters had already passed.

To contact UDI tech support click the Submit a Ticket link in Michel post above. The static or DHCP IP is the internal LAN IP address. If not able to reach the ISY externally look at the external IP address. They are different IP addresses.

Run Tools | Diagnostics | Show PLM Links Table followed by Count when display is complete. It sounds like the PLM lost the link record table. Devices operate individually without links but the ISY is not aware of device changes and Scenes from the ISY/PLM do not work. If the PLM Links Table is small or empty the File | Restore Modem (PLM) function rebuilds the PLM link database.

A check of LOG file shows the following .... HER door opened at 4:16:56 HER door closed at 4:18:08 HER door opened at 4:18:10 HIS door opened at 4:18:11 HIS door closed at 4:39:42 HER door closed at 4:39:43 No RELAY action for either door at these events. That suggests the doors were commanded by the remote or some other non-Insteon mechanism. Can you identify when the doors were found open.

Watch the Green LED next to the wire connections. Does the Green LED turn On with door closed and turn Off when door opens. If the Green LED does not change state the issue is with the magnetic switch. Assuming the Green LED cycles as door opens/closes then the I/O Linc is not communicating with the PLM. This could be caused by ... a general comm issue the I/O Linc link database lost its link records the PLM lost its link records. I would do a Restore Device on the I/O Linc first. If that does not resolve the issue then do a File | Restore Modem (PLM). If that does not resolve the issue something has happened with comm between the I/O Linc and the PLM.

Both the Subject and Body require content.

"is no way to know what the firmware version is unless the switch is on the power line and recognized by the UD controller?" Adding a device is the best way. No need to use it if you do not like the firmware level. There are usually various methods of getting information on firmware level but why have to learn some other method. They are all dependent on accessing the device. Use an appliance cord to power the device and add it to the ISY. No need to install in a box. "V1.2" is the hardware revision. The device hardware level is established when the device is manufactured. SmartLabs will use the latest firmware so the firmware level could well evolve over the life of a particular hardware revision. Hardware revision has not been used to identify an issue with a device. Since SmartLabs publishes nothing about issues with any level of hardware/firmware there could be an issue with a particular hardware revison but likely that would not be known. The latest devices are usually faster to manage because they use Extended commands for link management and configuration. Also the latest devices usually have features that older devices do not have.

The v.2A and v.2C are firmware levels, not hardware revisions.

There are two things that stop a Program in a Wait, either the Conditions in the If change causing the If to be reevaluated or the Program was Stopped/Disabled.

If nothing executed after the 30 minute Wait either 'IsShabbatOrYomtov' or 'is9Minyan' changed Status before the Wait completed. That change in Status terminated the Wait and executed the Else. Note: it is a good idea to identify the names of Programs that are posted.

"Missing Application-Name manifest attribute for: https://192.168.1.77:41443/web/insteon.jar" Java was updated to a level that is looking for a manifest file. This requirement did not exist when 3.3.10 was released. Go to Java | Security and add the ISY URL to the Exception Site List. Should upgrade to a 994i as several of the newer Insteon devices cannot be added under 3.3.10 including the latest KeypadLinc.

Uninterruptible Power Supply (UPS). A battery backup device that runs equipment when power goes down.

Sounds like the external IP address has changed.

The answer is posted after your question on the Smsrthome forum. No search required. Same answer is now posted here. oberkc is very good and provided the solution. There are many ways to configure an I/O Linc in a garage application. None of the specifics are provided in either original post so oberkc provided the solution that requires you to fill in the variables that apply to your installation. The major point is to use "If Status" rather than the "If Control". That takes care of the situation where the door is closed before the Wait completes. How the Program closes the door depends on how you configured the I/O Linc, which Momentary mode did you chose to use for example.

The same question has been answered. Do you not agree with the previous answer from oberkc?

If both electrical boxes are powered from the same meter the house has two 120v legs. I have no way to know if you have a UPS device. You do not know if a UPS is being used? If the PLM is put into test mode with its Set button, do all the other wired devices blink Green or Red?

It does sound like the problems go beyond the I/O Linc. I would start with the basics, are the two 120v legs correctly coupled with a pair of Access Points that have passed the Set button test which verifies being on opposite 120v legs. Are devices such as UPS, modem, router powered from from the same circuit as the PLM and not on a FilterLinc?

If the 3 AM Query is changing the Status there is likely a comm issue between the I/O Linc and the PLM. The Query is setting the current Status which did not reach the PLM when the change happened.

If before Sunset, trigger the motion sensor and see if the Program is triggered. It should trigger as long as Enabled and before Sunset. If all the conditions are correct and it does not trigger run Tools | Diagnostics | Event Viewer at LEVEL 3. Does the event viewer show motion sensor activity when walking past motion sensor? If so post the event viewer trace. EDIT: Running the If section will not be True because of the If Control 'motion' is switched On. A motion On is needed for the If to run True.

"Where do I look to see if the Program is a folder with a false state?" Click Programs | Summary tab. The display shows the Path (is a Program in a Folder), when Last Run Time, Status when it did run. "How do I copy the program as text to paste into this forum reply? (Ctl+A and Ctl+C doesn't do it)." Right click on Program name and select Copy to Clipboard. Paste into forum The False Status indicates the If was evaluated as False which would run the Else clause. Why was If False? Paste the Program. What was the Last Run Time? Does it match Sunrise or Sunset?