LeeG

bfish Run Event Viewer with 3-Device communications events selected. The alarm may be sending multiple X10 messages for reliability. Lee

oberkc Thanks for the additional example. I was thinking of using a variable but your approach works without that additional definition. Yes, regarding Disabling my second Program. Did not think Disable would prevent reevaluation but testing this morning does show if Disabled reevaluation does not happen. That is what I like about the ISY, learn something new every day. Plau Either use oberkc approach of using 3 Programs or my second example using 2 Programs and mark the second Program Disabled. When a Program is using "If Status" and the Program changes the status of the device being checked in the If and the Program contains a Wait or Repeat, the Program If is reevaluated. This causes a loop in my second Program if it is not marked Disabled. The first Program will still Run the second Program even though it is marked Disabled. Lee

Another user posted a possible alternative. Define a Scene that would create the erroneous link. Then Delete the Scene.

The second Program will not work as coded because it is changing the Status of light in the If. I'll post something else later.

The first program no longer has the Repeat loop. It invokes a second Program that checks the Status of the light to flash. If the light is currently On it will flash Off/On 5 times leaving the light On. If the light is currently Off then the Else does what the original program did, flash On/Off 5 times leaving the light Off. If Status 'TriggerLinc1-Opened' is On Then Wait 15 minutes Send Notification to 'ALL' content 'Custom with date' Run Program 'XXXX' (If) Else - No Actions - (To add one, press 'Action') Program XXXX If Status 'ICON Dimmer 1' is On Then Repeat 5 times Set 'ICON Dimmer 1' Fast Off Wait 1 second Set 'ICON Dimmer 1' Fast On Wait 1 second Else Repeat 5 times Set 'ICON Dimmer 1' Fast On Wait 1 second Set 'ICON Dimmer 1' Fast Off Wait 1 second

From the Mighty Mule product manual it does not appear to have an external connection built into the receiver. I too have been using a Dakota Alert driveway monitor for many years. I chose the magnetic variant that is buried alongside the driveway. Has worked flawlessly. The receiver monitors up to 4 devices and does have relay connections for each of the 4 devices (channels). I have my Dakota Alert receiver connected to an EZIO6I (first 4 opto-isolated inputs). This has also worked well. Actually have a magnetic sensor buried at the mail box and one along the drive. The other two channels monitor other activity. Most of the EZIOxx devices have some number of opto-isolated inputs. If the Mighty Mule has a digital quality signal that can be connect to an EZIOxx or I/O Linc Sensor (single input) it should work. The problem being it requires going into the internals of the Mighty Mule to find out which will likely invalidate the warranty.

Maybe something like this. When the TriggerLinc turns On (when door opens) the Program Waits for 15 minutes. If the door closes before the 15 minutes completes the TriggerLinc will turn Off and the Program will run the Else so no Notify is done. After the Notify the light is flashed On/Off at 1 second intervals for 5 times. The Else insures the light is turned Off in case the door closes and the TriggerLinc turns Off during the Repeat loop. If Status 'TriggerLinc1-Opened' is On Then Wait 15 minutes Send Notification to 'ALL' content 'Custom with date' Repeat 5 times Set 'ICON Dimmer 1' Fast On Wait 1 second Set 'ICON Dimmer 1' Fast Off Wait 1 second Else Set 'ICON Dimmer 1' Fast Off

Do not use the "Relay follows Input" option. That will turn the Relay On when the Sensor turns On. Can stop the door movement prematurely. It is like pressing the manual button after the door starts to move. Most openers will stop door movement at the point as a safety feature.

boser I am not at all sure the tact switch is the problem. I would delete the ISY Scene, define a new Scene and add the three devices as Controllers. Basically starting from scratch as far as the Scene definition is concerned. It still sounds like a link record problem. Lee

beachfront71 If it ain't broke don't fix it. Momentary A,B,C have meaning as far as what commands do what ONLY when the I/O Linc Relay is a Responder to a Scene and the Scene is being turned On and Off. Sounds like you are controlling the Relay with direct commands so which Momentary mode is in effect makes no difference. The I/O Linc Relay does not report back that the I/O Linc has turned Off the Relay after the Momentary mode timeout which works regardless of which Momentary mode is selected. That is why the Relay shows On because that is the last command sent to the Relay. Lee

I don't know what that error message is but from an Insteon perspective X10 devices cannot be part of an Insteon Scene. The Insteon link records have no accommodation for X10 addresses.

Smarthome was replacing them based on an extended warranty period. If you have the original receipt that shows when they were purchased I would contact Smarthome and see if they will replace them. It has been so long ago not sure they are still replacing them anymore.

The paddle results indicate there is a link record problem. Pressing and holding the paddle generates a different Insteon message sequence than a simple single tap. The single paddle tap is dependent on the link records being correct in both devices. Are these new devices. There were issues with the paddle tact switches years ago but that does not exist today. Of course someone could have dumped a bunch of defective devices on ebay just to get rid of them.

Yes. Any time the ISY image is upgraded the Java cache should be cleared. Normally when upgrading from Beta to Beta a new URL is needed to use the level of Admin Console that goes with that Beta level. Waiting for the next official release avoids the need to change the URL for Admin Console access (Java cache still needs to be cleared after the upgrade as the cached image will be 2.8.16 Admin Console).

The Java cache needs to be cleared and the URL for accessing the 3.1.17 Admin Console must be used. The 2.8.16 Admin Console is being used with the ISY 3.1.17 firmware. Not a good combination to continue with. When running the 3.1.17 Admin Console there will be an additional line in the Help | About which is UI:. This line identifies the Admin Console level which did not exist at 2.8.16.

The latest Beta 3.1.17 (RC) is an official release candidate. Depends on how stable it turns out to be. Has been very stable for me. I don't think you would have any problems using 3.1.17. Would expect the decision about whether to label 3.1.17 as the next official release to be made soon (I do not speak for UDI so that is my opinion only).

stefangordon Do not manually change the conf files. What does Help | About show for the Firmware: line and the UI: line immediately below the Firmware line What did you migrate from when going to 3.1.17 Lee

I looked over an I2 trace from a earlier post. The Red FF (255) is the default countdown value. The Blue F2 is the time remaining. Note that in the second 02 51 response the time remaining to Off has gone down by 1 minute (F2 to F1) which generally matches the difference in time stamps between the two trace entries. Fri 01/27/2012 10:28:19 AM : [iNST-ERX ] 02 51 11 DC 42 13 24 E1 11 2E 00 01 01 00 FF 20 00 00 F2 00 00 00 26 B3 00 Fri 01/27/2012 10:29:09 AM : [iNST-ERX ] 02 51 11 DC 42 13 24 E1 11 2E 00 01 01 00 FF 20 00 00 F1 00 00 00 2F FC 00 It would be very interesting to see what command sequence is issued when the Save button is clicked and what the read of the current values are the next time the configuration popup is displayed.

There is no means of retrieving the countdown value from an I1 device, thus the 0 value. The ISY cannot change the countdown interval on I1 devices so I have to conclude this is a device failure (not the 0, the fact that it does not countdown). If that is in question do a Factory Reset of the I1 device. If the device is not defective that will restore the countdown operation. I have not seen a trace of an I2 device having the countdown time changes. I'll be happy to take a look if you want to generate a test trace. With the Event Viewer running with 3-Device communications events selected, set the countdown interval to some value, say 100, click Save and then Close. Bring up the configuration popup again and change the countdown value to 50, click Save and then Close. Bring up configuration again and Close. Post the trace. The reason for closing and restarting the configuration process each time is the ISY retrieves the current settings with an I2 command at the beginning. Starting the configuration process new each time will show what effect the previous change actually had.

From the I1 test results I would conclude the older SwitchLincs do not support changing the countdown interval programmatically. I went through the command reference again, searching for "countdown", "timeout, "interval". Found no reference for setting the countdown interval with I1 commands. All the other options displayed in the popup are described and match the commands issued in the trace. Not unlike the motion sensors. There are things that can be done programmatically with the later motion sensors that cannot be done programmatically with the early ones. Another example is some older devices must be power cycled for certain configuration changes to take effect. The I1 method for setting some values does not provide a method for activating the changes. On newer versions of the same device that support I2 configuration, changes are automatically picked up without a power cycle.

The three devices should be added to one ISY Scene as Controllers. The ISY assumes a Controller is also a Responder. If one device is not working try deleting that device from the Scene and add it back as a Controller. Sounds like it was accidently added as a Responder. Also check that there are no Icons to the left of any of the nodes indicating updates might be pending. Such as a small Green Icon or a Red !.

It is an I1 device. “Retrieved engine version is i1" There is a series of changes issued. LED On during Tx LED Off during Tx Countdown Timer Disabled Countdown Timer Enabled Trigger ALL-Link Disabled Trigger ALL-Link Enabled LED Off LED Enabled 1 minute warning Disabled 1 minute warning Enabled There were no commands issued to set the Timeout Interval. Does not appear to be an I1 command to set the Timeout interval. No I1 command is listed in the command reference for that purpose. If the error popup occurred when attempting to change the Timeout interval it is a logical failure message. In other words, no command actually failed as there is no I1 command to issue. Except for the lack of an I1 command to change the Timeout interval the other commands track the options listed in the posted screen capture.

That part is easy. Define an ISY Scene. Add the I/O Linc Sensor as a Controller and the KeypadLinc button that represents door status (opened/closed) as a Responder. When the I/O Linc Sensor turns On as the door opens the KeypadLinc button will light. When the door closes the Sensor turns Off and the KeypadLinc button will turn Off.

Only to the two older SwitchLincs. The ISY is using I2 Extended Set/Get commands to read/write the configuration data. Very likely the older SwitchLincs do not support I2, thus the 0 timeout value. This can be confirmed with an Event Viewer trace with 3-Device communications events selected. Read the current options for one of the old SwitchLincs. This is from one of your previous posts. The 02 51 Extended response will likely not be traced with the older SwitchLinc. Fri 01/27/2012 10:28:18 AM : [iNST-ACK ] 02 62 11.DC.42 1F 2E 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 06 (00) Fri 01/27/2012 10:28:18 AM : [iNST-SRX ] 02 50 11.DC.42 13.24.E1 2B 2E 00 (00) Fri 01/27/2012 10:28:18 AM : [standard-Direct Ack][11.DC.42-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 01/27/2012 10:28:19 AM : [iNST-ERX ] 02 51 11 DC 42 13 24 E1 11 2E 00 01 01 00 FF 20 00 00 F2 00 00 00 26 B3 00

Unfortunately that is like asking should I buy a Chevy or a Ford. There are several ways to use an I/O Linc, no one way is better than the other. The first choice is yours; do you want the I/O Linc Sensor to be On when the door is open or On when the door is closed? Once that choice is made it dictates which wires to use, red/black or green/black. The next choice is how the open/close status will be displayed versus how the garage door opener will be controlled. Some folks like door open/close status and opener control to be rolled into a single KeypadLinc button. There is an example on the UDI Wiki for that setup. I don't like that approach, several others are very happy with it and I'm sure they can/will help if you want to implement the UDI Wiki garage example. The I/O Linc Relay must be in one of the Momentary modes, A,B,C. Which option is chosen can be dictated by the above choice of how many KeypadLinc buttons will be used for status display and opener control. I suggest looking over the Wiki example as a starting point.