LeeG

This has been documented in an older post. The old 99i with the Green LEDs are much dimmer than the newer 99i and 994i with the Blue LEDs. The LEDs were changed to a brighter version because of requests from the field that the Green LEDs could not be seen. It was suggested that a future hardware design change allow the LED brightness to be set. I’ll update this post when I can find the older topic. Here is link to Dec 2011 topic regarding Blue LED brightness. Multiple posts by Michel. viewtopic.php?f=27&t=7725

Take a look at this topic viewtopic.php?f=26&t=10813&hilit=upgrade+994i

All Insteon dimmers chop a portion of the AC Sine wave even at 100% On. An appliance that is not rated for dimming can be damaged including the Insteon device itself. EDIT: I ran a small squirrel cage fireplace blower for somewhere around 3 years before the wired ICON Dimmer quit working. Usage was of course seasonal.

The Relay mode should have had no affect on defining a Scene with the KeypadLinc button as a Controller and the Relay as a Responder. The KeypadLinc button should be in Toggle mode. I am concerned the I/O Linc Relay options are not being set as expected. Need to know what Help | About shows for both Firmware and UI. The Relay could still be in Latching mode so the KeypadLinc Off press is turning the Relay Off. The Relay could be in Momentary A mode so that it is reacting to only one command. Once I know the Firmware and UI levels, the next thing would be to run Tools | Diagnostics | Event Viewer at LEVEL 3. Bring up the I/O Linc Set Options. Click the Latching Mode, when the Event Trace completes the activity, click the Momentary B. When the trace activity completes post the event trace. This may not be necessary depending on the Firmware and UI levels.

What level ISY firmware is being used? Does Help | About show the same level for Firmware and UI?

For the KeypadLinc not controlling the Relay, do a Show Device Links Table for the I/O Linc and for the KeypadLinc. Post the results. For the KeypadLinc to control the I/O Linc Relay with a Scene (KPL button press) the KeypadLinc and the I/O Linc require matching link records. What ISY firmware is being used? There was an issue several images back where the Momentary mode was not being set correctly but that was fixed quite some time ago. When Set Options is used to display the I/O Linc setting, it is necessary to click Query on the Set Options display to get the current device settings. If you have a simple On/Off switch it can be connected to the I/O Linc Sensor GND and confirm the I/O Linc Sensor does not cycle On-Off-On for any switch. This is the only case I have seen reported of using that particular magnetic switch with an I/O Linc. Since I/O Lincs do not cycle with other magnetic switches I assume it is the switch and not the I/O Linc. Using another switch that is on hand would confirm that.

paauto I saw this question on the Smarthome forum. The ON/OFF button LEDs being On or Off cannot be reversed from the function they perform. The key here is the KeypadLinc is physically controlling the load per your post. If the load was controlled by some other device an ISY Program could be triggered by the ON and OFF button press and change which button LEDs are On but that directly affects the load the KeypadLinc is controlling. If another device controls the physical load the OFF button could turn On the ON button LEDS without affecting the actual load. The OFF button would turn the load control device Off so the function would remain correct but the ON button LEDs could be turned On without affect the physical load.

Device 09.FF.2D did not respond to any of the commands. As if the device does not physically exist on the Insteon network. Could be the location of the EZIO2X4 is not receiving any Insteon traffic, the Insteon address could be wrong or the device is defective. Move the EZIO2X4 to the PLM plug point and try again. That will eliminate powerline questions.

Be sure to connect I3 and I4 to GND before attempting to add to the ISY. These inputs float which can flood the Insteon network with unwanted messages if they are not locked to GND

Upgrade to 3.3.10 which is the latest Official release. Use New INSTEON Device, enter Insteon address, Name of choice, Device Type set to default Auto Discover. If that is not successful run Tools | Diagnostics | Event Viewer at LEVEL 3. Repeat the New INSTEON Device process. Post the event trace.

gamard Most of what you repeated is correct. There is one aspect that was not what Chris related which was not repeated correctly. A little background. Some users thought On meant any condition that was not Off when in fact On meant 100% On. To clarify what On means it was changed to 100%. The If below is testing for 100% On If Status 'SwitchLinc Dimmer' is On This was changed going into 4.0.2 If Status 'SwitchLinc Dimmer' is 100% Both If statements above mean the same thing. At 4.0.2 there is no longer an option to say If Status xxxx is On. It has to be If Status xxxx is 100% For an Action statement in 4.0.2 Set 'SwitchLinc Dimmer' On Set 'SwitchLinc Dimmer' 100% are both valid but mean different things. Set 'SwitchLinc Dimmer' 100% turns the SwitchLinc Dimmer to 100% On Level Set 'SwitchLinc Dimmer' On turns the SwitchLinc Dimmer to the defined Local On Level. This is the value set but the slider labeled On Level (applied locally). If the SwitchLinc Local On Level is set to 80% the Set 'SwitchLinc Dimmer' On turns the SwitchLinc to 80% On Level I traced both of the Set statements described above Set 'SwitchLinc Dimmer' On issues an On command with 80% On Level (the CC) Tue 03/05/2013 05:46:31 PM : [iNST-TX-I1 ] 02 62 16 3F 93 0F 11 CC Set 'SwitchLinc Dimmer' 100% issues an On command with 100% On Level (the FF) Tue 03/05/2013 05:46:31 PM : [iNST-TX-I1 ] 02 62 16 3F 93 0F 11 FF I would click Help | About and make sure the UI line indicates 4.0.2. From the description of 100% changing to On it sounds like the UI may not be at 4.0.2. When I save a Program that indicates 100% either in the If or in a Set it stays 100%

The following is necessary to keep I3 and I4 from cycling because they are floating Connect I3 and I4 to EZIO2X4 GND EZIO2X4 Input1 Connect I1+ to EZIO2X4 +5V Connect I1- to one of the alarm panel relay contacts (where I/O Linc Sense and GND are connected) Connect EZIO2X4 GND - to other alarm panel relay contacts EZIO2X4 Relay1 Connect EZIO2X4 +5v to piezo Connect EZIO2X4 GND to R1_A Connect EZIO2X4 R1_B to piezo

The trace shows the off->on triggered twice as there are two X10 A1 Off messages sent for the single On message. The On->On triggered once because there was no change in Status during this test.

These entries are from the door opening. They show the Sensor reporting On, then Off, then On. 02 50 20.F9.17 00.00.01 CB 11 00 LTONRR (00) – SENSOR ON Tue 03/05/2013 06:55:25 AM : [std-Group ] 20.F9.17-->Group=1, Max Hops=3, Hops Left=2 Tue 03/05/2013 06:55:25 AM : [iNST-SRX ] 02 50 20.F9.17 00.00.01 CB 13 00 LTOFFRR(00) – SENSOR OFF Tue 03/05/2013 06:55:26 AM : [iNST-SRX ] 02 50 20.F9.17 00.00.01 CB 11 00 LTONRR (00) – SENSOR ON These entries are from the door closing. They show the Sensor reporting Off, then On, then Off. Tue 03/05/2013 06:55:56 AM : [iNST-SRX ] 02 50 20.F9.17 00.00.01 CB 13 00 LTOFFRR(00) – SENSOR OFF Tue 03/05/2013 06:55:56 AM : [iNST-SRX ] 02 50 20.F9.17 00.00.01 CB 11 00 LTONRR (00) – SENSOR ON Tue 03/05/2013 06:55:57 AM : [iNST-SRX ] 02 50 20.F9.17 00.00.01 CB 13 00 LTOFFRR(00) – SENSOR OFF The reaction of the KeypadLinc button is the result of the I/O Linc Sensor showing a bounce in the magnetic switch as it is going from Off to On and later from On to Off. Very unusual for a magnetic reed switch. As I mentioned before I assume it is the result of the orientation of the magnet to the reed as the door moves, approaching from the end of the reed switch rather than from the long side. Can the magnet be positioned closer to the switch? From the pictures it looks like they would be normally be close anyway. The I/O Linc has no option to debounce the Sensor input. The multiple emails can be handled by putting a Wait of 1-2 seconds before the Notify. The bounce in the Sensor will occur during the Wait, causing the Program to be retriggered before the Wait completes so only when the switch remains On or Off for more than 1-2 seconds will the Notify send the email. If Status ‘Sensor’ is On Then Wait 2 seconds Notify door open Else Wait 2 seconds Notify door closed Another option would be to change to the type of magnetic switch that was used in the I/O Linc garage kit SECO-LARM SM-226L-3 Magnetic Garage Door Contact Switch. This is a wide gap switch with both NO and NC contacts so the Sensor can be wired to be On or Off when the door is closed.

"What remains a mystery is why this second example appeared to trigger two evaluations and the first program never did this." The first Program was triggered twice during the off->on test. When the On command is received the Program is initially triggered due to the If Control On. The If evaluation is False because at first trigger time the current Status is Off and the Program is checking If Status On. That accounts for the first X10 A1 Off in the trace. When the current Status changes from Off to On the Program is triggered again. The If evaluates to False because at second trigger time the If Control On part of the If is False. At the Status change trigger the On command is not being processed. The second trigger resulting from the Off->On test is False so a second X10 A1 Off is issued and traced. Mon 03/04/2013 10:02:07 PM : [iNST-SRX ] 02 50 12.C9.76 00.00.01 CB 11 00 LTONRR (00) ON COMMAND RECEIVED Mon 03/04/2013 10:02:07 PM : [std-Group ] 12.C9.76-->Group=1, Max Hops=3, Hops Left=2 Mon 03/04/2013 10:02:07 PM : [ 12 C9 76 1] DON 0 Mon 03/04/2013 10:02:07 PM : [iNST-SRX ] 02 50 12.C9.76 0D.FE.30 41 11 01 LTONRR (01) Mon 03/04/2013 10:02:07 PM : [std-Cleanup ] 12.C9.76-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Mon 03/04/2013 10:02:07 PM : [iNST-DUP ] Previous message ignored. Mon 03/04/2013 10:02:07 PM : [X10-RSP ] 02 63 66 00 06 Mon 03/04/2013 10:02:07 PM : [ E EF 55 1] ST 255 Mon 03/04/2013 10:02:07 PM : [ 12 C9 76 1] ST 255 Mon 03/04/2013 10:02:08 PM : [ 17 89 51 1] ST 255 Mon 03/04/2013 10:02:08 PM : [ X10] A1 - FIRST TRIGGER FROM IF CONTROL ON is FALSE Mon 03/04/2013 10:02:08 PM : [ X10] A1/Off (11) Mon 03/04/2013 10:02:08 PM : [ FF 01 01 1] DOF 0 Mon 03/04/2013 10:02:08 PM : [ FF 01 01 2] DOF 0 Mon 03/04/2013 10:02:08 PM : [ X10] A1 – SECOND TRIGGER FROM CHANGE IN STATUS is FALSE Mon 03/04/2013 10:02:08 PM : [ X10] A1/Off (11) EDIT: the On->On part of the first test triggered once because there was no change in Status (On to On) to cause a second trigger.

oberkc I have not seen timing issues or variations with this example. Would be great to have additional testing done. EDIT: if you do find something unexpected see if it can be reproduced with the event trace running and post the event trace. thanks

If the KeypadLinc button will/is configured to send only On commands or only Off commands Momentary A mode can be used with the right Relay Responder On Level setting. The Responder On Level setting determines whether the Relay reacts to On commands only or Off commands only when in Momentary A mode. It is much simpler to use Momentary B mode which allows the Relay to turn On from either a Scene On or Scene Off command. Set Momentary B mode and leave it there. If the Relay does not work as needed the situation can be diagnosed from an environment that should work rather than an environment that works only with one command. The switch is advertised as a wide gap. With the magnetic sliding in from the end of the reed I think any slight variation in distance at the very beginning may allow the reed to bounce (close, open, close). Other magnetic switches I've used the magnet approaches parallel to the long side of the reed. It is very unusual for a reed switch to bounce when the magnet approaches parallel to the reed switch. The event trace will confirm how that switch is reacting.

Sorry for the long post. Did not want to edit the event traces. A Program triggered by If Control has the If evaluated ‘before’ the Status changes from the same On command. I used this test Program with a Dual Band SwitchLinc. Starting with the SwitchLinc Off, a tap of the On paddle triggers the Program with a True If. Status is Off when On command received. The If Control On triggers the Program with the If evaluated before any changes the On command may have to Status. Note the event trace shows the X10 A1 On issued when the Program initially triggers True because Status was Off when the On command is received. The Program is triggered a second time when Status changes to On, driving the Else clause and issuing the X10 A1 Off. A second tap of the On paddle is done. The Program is triggered again by the If Control On but this time Status is On from the first On paddle tap so the If is False driving the Else clause issuing the X10 A1 Off only. If Status 'SwitchLinc DB Dimmer v40' is Off And Control 'SwitchLinc DB Dimmer v40' is switched On Then Send X10 'A1/On (3)' Else Send X10 'A1/Off (11)' Event trace of first On paddle press. Mon 03/04/2013 11:42:28 AM : [iNST-SRX ] 02 50 1D.38.00 00.00.01 CB 11 00 LTONRR (00) Mon 03/04/2013 11:42:28 AM : [std-Group ] 1D.38.00-->Group=1, Max Hops=3, Hops Left=2 Mon 03/04/2013 11:42:28 AM : [ 1D 38 0 1] DON 0 Mon 03/04/2013 11:42:28 AM : [ 1D 38 0 1] ST 255 Mon 03/04/2013 11:42:28 AM : [ X10] A1 Mon 03/04/2013 11:42:28 AM : [ X10] A1/On (3) Mon 03/04/2013 11:42:28 AM : [ X10] A1 Mon 03/04/2013 11:42:28 AM : [ X10] A1/Off (11) Mon 03/04/2013 11:42:28 AM : [iNST-SRX ] 02 50 1D.38.00 19.70.06 41 11 01 LTONRR (01) Mon 03/04/2013 11:42:28 AM : [std-Cleanup ] 1D.38.00-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Mon 03/04/2013 11:42:28 AM : [iNST-DUP ] Previous message ignored. Mon 03/04/2013 11:42:28 AM : [X10-RSP ] 02 63 66 00 06 Mon 03/04/2013 11:42:29 AM : [X10-RSP ] 02 63 62 80 06 Mon 03/04/2013 11:42:30 AM : [X10-RSP ] 02 63 66 00 06 Mon 03/04/2013 11:42:31 AM : [X10-RSP ] 02 63 63 80 06 Event trace of second On paddle press. Mon 03/04/2013 11:42:34 AM : [iNST-SRX ] 02 50 1D.38.00 00.00.01 CB 11 00 LTONRR (00) Mon 03/04/2013 11:42:34 AM : [std-Group ] 1D.38.00-->Group=1, Max Hops=3, Hops Left=2 Mon 03/04/2013 11:42:34 AM : [ 1D 38 0 1] DON 0 Mon 03/04/2013 11:42:34 AM : [ X10] A1 Mon 03/04/2013 11:42:34 AM : [ X10] A1/Off (11) Mon 03/04/2013 11:42:34 AM : [iNST-SRX ] 02 50 1D.38.00 19.70.06 41 11 01 LTONRR (01) Mon 03/04/2013 11:42:34 AM : [std-Cleanup ] 1D.38.00-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Mon 03/04/2013 11:42:34 AM : [iNST-DUP ] Previous message ignored. Mon 03/04/2013 11:42:34 AM : [X10-RSP ] 02 63 66 00 06 Mon 03/04/2013 11:42:35 AM : [X10-RSP ] 02 63 63 80 06 Mon 03/04/2013 11:43:58 AM : [All ] Writing 0 bytes to devices This is the same test run with a SwitchLinc that is not Dual Band. Same results. If Control On triggers the Program with the If evaluated before any Status changes resulting from the On command. If Status 'SwitchLinc Dimmer' is Off And Control 'SwitchLinc Dimmer' is switched On Then Send X10 'A2/On (3)' Else Send X10 'A2/Off (11)' Event trace of first On paddle press from a SwitchLinc Off Status Mon 03/04/2013 12:04:08 PM : [iNST-SRX ] 02 50 16.3F.93 00.00.01 CB 11 00 LTONRR (00) Mon 03/04/2013 12:04:08 PM : [std-Group ] 16.3F.93-->Group=1, Max Hops=3, Hops Left=2 Mon 03/04/2013 12:04:08 PM : [ 16 3F 93 1] DON 0 Mon 03/04/2013 12:04:08 PM : [ 16 3F 93 1] ST 255 Mon 03/04/2013 12:04:08 PM : [X10-RSP ] 02 63 6E 00 06 Mon 03/04/2013 12:04:08 PM : [ 1D 23 6B 1] ST 255 Mon 03/04/2013 12:04:08 PM : [ X10] A2 Mon 03/04/2013 12:04:08 PM : [ X10] A2/On (3) Mon 03/04/2013 12:04:08 PM : [ X10] A2 Mon 03/04/2013 12:04:08 PM : [ X10] A2/Off (11) Mon 03/04/2013 12:04:09 PM : [iNST-SRX ] 02 50 16.3F.93 19.70.06 4B 11 01 LTONRR (01) Mon 03/04/2013 12:04:09 PM : [std-Cleanup ] 16.3F.93-->ISY/PLM Group=1, Max Hops=3, Hops Left=2 Mon 03/04/2013 12:04:09 PM : [iNST-DUP ] Previous message ignored. Mon 03/04/2013 12:04:09 PM : [X10-RSP ] 02 63 62 80 06 Mon 03/04/2013 12:04:10 PM : [X10-RSP ] 02 63 6E 00 06 Mon 03/04/2013 12:04:11 PM : [X10-RSP ] 02 63 63 80 06 Second On paddle press Mon 03/04/2013 12:04:24 PM : [iNST-SRX ] 02 50 16.3F.93 00.00.01 CB 11 00 LTONRR (00) Mon 03/04/2013 12:04:24 PM : [std-Group ] 16.3F.93-->Group=1, Max Hops=3, Hops Left=2 Mon 03/04/2013 12:04:24 PM : [ 16 3F 93 1] DON 0 Mon 03/04/2013 12:04:24 PM : [ X10] A2 Mon 03/04/2013 12:04:24 PM : [X10-RSP ] 02 63 6E 00 06 Mon 03/04/2013 12:04:24 PM : [ X10] A2/Off (11) Mon 03/04/2013 12:04:24 PM : [iNST-SRX ] 02 50 16.3F.93 19.70.06 4B 11 01 LTONRR (01) Mon 03/04/2013 12:04:24 PM : [std-Cleanup ] 16.3F.93-->ISY/PLM Group=1, Max Hops=3, Hops Left=2 Mon 03/04/2013 12:04:24 PM : [iNST-DUP ] Previous message ignored. Mon 03/04/2013 12:04:25 PM : [X10-RSP ] 02 63 63 80 06

It would make a difference. If the 3AM message sequence is the same as the other user, a duplicate Relay Query status message looks like the Sensor Query response. Since the Relay is Off in a garage door situation, the Sensor is marked Off. If the Sensor was normally Off at 3AM the status would not be changed by the odd message sequence.

belias Thanks for that trace data. If that happened at the 3AM Query it could have affected what state the Sensor was marked as. This looks so much like the other user I am wondering if this is an I/O Linc query anomaly rather than a network issue. What is the I/O Linc firmware level? Although in the manual query trace the hops left count is moving around, 1 then 2 then 0 so there may be something interfering with the I/O Linc location.

You need Momentary B mode to have the KPL button press move the garage door assuming the KPL button is in toggle mode. In Momentary B mode the I/O Linc Relay turns On in response to both Scene On and Scene Off commands generated by a KPL button in toggle mode. Momentary A mode reacts to only Scene On or only Scene Off depending on other factors. Run Tools | Diagnostics | Event Viewer at LEVEL 3 and trace the door opening and closing. I've not used that style rail mounted switch. It sounds like the switch is bouncing when cycled open or closed. Would like to verify that with an event trace before deciding what to do next.

Both the Leak Sensor and the Smoke Bridge should be deleted and readded under 4.0.2. 4.0.2 has a fix for the Smoke Bridge which requires the device to be deleted and added back. The Heartbeat support in 4.0.1 for the Leak Sensor adds an additional node which also requires a delete and readd. The Heartbeat message every 24 hours carries the current Leak Sensor Dry/Wet status which does seem to be affecting the Program.

That is the way Insteon works. To control both switches together turn the Scene On/Off. When an individual switch is controlled that switch does not control its linked responders. This allows Insteon to control an individual switch without affecting any linked devices.

Two On sequences in a row. Sun 03/03/2013 06:51:47 PM : [iNST-SRX ] 02 50 20.93.9B 00.00.01 C3 11 00 LTONRR (00) Sun 03/03/2013 06:51:47 PM : [std-Group ] 20.93.9B-->Group=1, Max Hops=3, Hops Left=0 Sun 03/03/2013 06:51:47 PM : [iNST-SRX ] 02 50 20.93.9B 00.00.01 C3 11 00 LTONRR (00) Sun 03/03/2013 06:51:47 PM : [std-Group ] 20.93.9B-->Group=1, Max Hops=3, Hops Left=0 Sun 03/03/2013 06:51:47 PM : [iNST-DUP ] Previous message ignored. Sun 03/03/2013 06:51:47 PM : [iNST-SRX ] 02 50 20.93.9B 11.00.01 C3 06 00 (00) Sun 03/03/2013 06:51:47 PM : [std-Group ] 20.93.9B-->11.00.01, Max Hops=3, Hops Left=0 Sun 03/03/2013 06:51:50 PM : [iNST-SRX ] 02 50 20.93.9B 00.00.01 C3 11 00 LTONRR (00) Sun 03/03/2013 06:51:50 PM : [std-Group ] 20.93.9B-->Group=1, Max Hops=3, Hops Left=0 Sun 03/03/2013 06:51:50 PM : [iNST-SRX ] 02 50 20.93.9B 11.00.01 C3 06 00 (00) Sun 03/03/2013 06:51:50 PM : [std-Group ] 20.93.9B-->11.00.01, Max Hops=3, Hops Left=0

That would depend on whether the device in question can have its On Level and Ramp Rate affected. Is the situation where Scenes with devices that had sliders in the past no longer have sliders or a new Scene that does not have sliders and the question is why this particular Scene. Perhaps it would be good to describe the Scene. What devices are in the Scene and are they defined as Controllers or Responders? What does Help | About show for Firmware What does Help | About show for UI