LeeG

That cable was/is packed with the PLM itself. It is inside one of the folds of the white cardboard packing material that holds the PLM in place inside its box.

"So it seems there is a legitimate problem here, in that the PLM should not be passing these dupe messages on to the ISY. That seems like basic mesh networking. The messages bounce around from device to device potentially reaching the PLM at multiple times and at different times. The PLM only needs one of them and should ignore the others." I think so. What is the PLM firmware level? Tools | Diagnostics | PLM Info/Status displayed the PLM firmware level. Could be an issue a later PLM firmware has addressed, or not. SmartLabs does not publish a list of defects and fixes so this would not be something generally known. Also this may not be easily resolved by the PLM as it has been given the next serial command so the duplicate message appears as a valid response from its perspective. "Aside from that, the issue in ISY is that two distinct services (the Relay and the Sensor) have the same identifier, and only differentiate from each other by time, ie query one, get response, query the next, get response. If this delicate balance gets disrupted, the ISY no longer knows what's what." That is accurate. Normally though messages do not come out of sequence. In this case they are not actually out of sequence. The Relay Query response comes as it should, after the device has been asked to provide that status, and the Sensor Query response comes as it should, after the device has been asked to provide that status. This issue here is that an additional message is being received rather than the real responses coming out of sequence. See the EDIT is added to my previous post.

"Seems like ISY could be updated to ignore responses from devices that it has already gotten a response from (at least during the query all function)." That is exactly what the ISY did. What I can see as a duplicate Relay Query response by visual analysis of the entirety of the event trace the ISY took as the Query Sensor response. They look exactly the same. "Shouldn't ISY know the difference between Sensor and Relay node responses? " This is the Query response from the Query of the Sensor Wed 02/27/2013 10:15:39 PM : [iNST-SRX ] 02 50 1F.C4.AE 21.31.26 2B 28 01 SET-MSB(01) This is the Query response from the Query of the Relay Wed 02/27/2013 10:15:39 PM : [iNST-SRX ] 02 50 1F.C4.AE 21.31.26 2B 28 00 SET-MSB(00) Except for one indicating On and the other indicating Off they are exactly the same. The following real Sensor Query response is ignored, as you suggest it should, as from the ISY perspective the Sensor Query response has already been processed. EDIT: it is possible if the ISY stops issuing a query for both the Sensor Node and the Relay node during the Query All the duplicates may not cause a problem. Michel did open bug ID #58 (see earlier post this same topic). This would not eliminate the duplicate responses so what other problems the duplicate messages might cause will still exist.

swnewman Thanks for that trace. It provided the answer. The Insteon mesh network is creating multiple response messages from a single Query request. The later duplicates come back with a Hops Left=0 suggesting it took longer for them to arrive at the PLM. Normally the PLM will not pass the duplicates but we have seen cases where it does and this is one of those cases. The extra messages come back from the Query of the Relay so they show Off. However, the first duplicate with Hops Left=0 comes back after the ISY has queried the Sensor. The duplicate Relay Query response looks like it is the response to the Sensor Query so the Sensor is marked Off. Thu 02/28/2013 04:00:10 AM : [iNST-TX-I1 ] 02 62 1F C4 AE 0F 19 01 QUERY SENSOR Thu 02/28/2013 04:00:11 AM : [iNST-ACK ] 02 62 1F.C4.AE 0F 19 01 06 LTSREQ (01) Thu 02/28/2013 04:00:11 AM : [iNST-SRX ] 02 50 1F.C4.AE 21.31.26 2B 28 01 SET-MSB(01) Thu 02/28/2013 04:00:11 AM : [std-Direct Ack] 1F.C4.AE-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 02/28/2013 04:00:11 AM : [iNST-TX-I1 ] 02 62 1F C4 AE 0F 19 00 QUERY RELAY Thu 02/28/2013 04:00:11 AM : [iNST-ACK ] 02 62 1F.C4.AE 0F 19 00 06 LTSREQ (LIGHT) Thu 02/28/2013 04:00:11 AM : [iNST-SRX ] 02 50 1F.C4.AE 21.31.26 2B 28 00 SET-MSB(00) FIRST RELAY QUERY RESPONSE Thu 02/28/2013 04:00:11 AM : [std-Direct Ack] 1F.C4.AE-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 02/28/2013 04:00:11 AM : [iNST-TX-I1 ] 02 62 1F C4 AE 0F 19 01 QUERY SENSOR Thu 02/28/2013 04:00:12 AM : [iNST-ACK ] 02 62 1F.C4.AE 0F 19 01 06 LTSREQ (01) Thu 02/28/2013 04:00:12 AM : [iNST-SRX ] 02 50 1F.C4.AE 21.31.26 23 28 00 SET-MSB(00) DUPLICATE RELAY QUERY RESPONSE AFTER QUERY SENSOR ISSUED Thu 02/28/2013 04:00:12 AM : [std-Direct Ack] 1F.C4.AE-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 The other I/O Linc also has these duplicate responses. In this trace the duplicate Query Relay responses from the other I/O Linc came back after the correct responses had been processed so they caused no harm. Thu 02/28/2013 04:00:10 AM : [iNST-TX-I1 ] 02 62 1F C5 CF 0F 19 00 RELAY QUERY Thu 02/28/2013 04:00:10 AM : [iNST-ACK ] 02 62 1F.C5.CF 0F 19 00 06 LTSREQ (LIGHT) Thu 02/28/2013 04:00:10 AM : [iNST-SRX ] 02 50 1F.C5.CF 21.31.26 2B 08 00 (00) RELAY QUERY FIRST RESPONSE Thu 02/28/2013 04:00:10 AM : [std-Direct Ack] 1F.C5.CF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 02/28/2013 04:00:11 AM : [iNST-SRX ] 02 50 1F.C5.CF 21.31.26 23 08 00 (00) RELAY QUERY DUPLICATE RESPONSE Thu 02/28/2013 04:00:11 AM : [std-Direct Ack] 1F.C5.CF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Thu 02/28/2013 04:00:11 AM : [iNST-SRX ] 02 50 1F.C5.CF 21.31.26 23 08 00 (00) RELAY QUERY DUPLICATE RESPONSE Thu 02/28/2013 04:00:11 AM : [std-Direct Ack] 1F.C5.CF-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Of course the question is how can these duplicates be eliminated. Could try plugging an Access Point at the same location as the I/O Lincs. I do not know if this will help or hurt.

Some folks add a wall wart, some add a small night light. The ApplianceLinc sense circuit bleeds enough current to cause some LEDs to have a small glow when Off or blink.

Go to page 1 of this topic, the first post has the list of URLs for 4.0.1

Joe B There is an upgrade offer for those who want to move to a 994i. viewtopic.php?f=44&t=10771 However, you are correct, the features and fixes in 4.0.1 (which do not include fix for Smoke Bridge), those coming in future 4.0.x, 4.1.x and so on will not be in 3.3.10. The Smoke Bridge is only first of what will likely be a long line of new Smarthome devices that will not be in 3.3.10.

Check the URL being used to invoke the Admin Console. To get a down-level Admin Console (UI) either the Java cache is not actually clearing (perhaps not all browsers are closed, applications using Java have not been shut down) or the URL invoking the Admin Console is not pointing to 4.0.1.

No benefit I can think of. There is no hidden X10 function. Smarthome has I/O Linc based Door Bell sensor kits that provide an Insteon message when the door bell is used. Is that useful in your environment? There is no Insteon based 'alarm' module. Some folks have hooked a piezo type buzzer to an I/O Linc Relay for a remote signal.

hmatos There is a forum category dedicated to the ZWave Alpha viewforum.php?f=93 There is a limited number of devices currently support by the Alpha. Don’t know if the lock mentioned is covered.

Not really. I have seen one or two devices lose a link database over a period of years when there have been unusual power outage sequences. Folks do get in trouble if Set button links are done for testing or diagnostic purposes. If it happens consistently I would suspect a device is beginning to fail.

When a button/paddle press does not register in the event viewer at LEVEL 3 either there is a comm problem between the device location and the PLM or there are link records missing/corrupted. A Show Device Links Table for the device followed by a Compare after Show display completes will provide a picture of the device link database and whether there are device link record problems. A Restore Device should resolve device link database problems. There can be PLM link records missing/corrupted that have the same effect. If the PLM link database has become full it cannot accept new Scene link records. The PLM link database can accumulate duplicate and no longer needed link records contributing to the total number of link records in the PLM. A Restore Modem (PLM) will remove duplicates and rebuild the PLM link database. If restoring device and PLM link records does not resolve (assuming the total PLM link records does exceed its capacity) then comm problems would be next thing to look at.

An ISY Program can issue X10 commands without adding X10 device definitions. The optional X10/A10 Module is required to add X10 devices to the My Lighting tree. All the X10 commands the PLM supports can be issued by an ISY Program without the optional X10/A10 Module. The optional X10/A10 Module allows reference to an X10 device by name. Insteon does not support X10 devices in Scenes.

The 4.0.1 Beta has support for the Heartbeat node.

matapan I can confirm my EZX10RF works on 3.3.10. It has firmware v.1C I just added it from scratch and defined an X10 code. However, that does not insure a new EZX10RF will work. Smartenit started shipping I2CS based EZFlora and EZIOxx devices which do work with the ISY as well as older EZFlora and EZIOxx devices. Reacting to I2CS concerns by other products (not UDI) Smartenit started shipping devices with new PLMs that had been reflashed with older PLM firmware. Some of these hybrid reflashed devices do not work with the ISY. The PLMs no longer indicate I2CS but they no longer work with Peek/Poke. I do not know what new EZX10RF and EZSnsRF devices are being shipped with. Therefore do not know if newly shipped devices will work.

kaybee335 With KeypadLincs, each button uses a unique Scene number. In the case of a 6 button KeypadLinc the ON and OFF buttons use the same Scene number. From an application perspective the ON and OFF buttons appear as a single button because they share the same Scene number.

Heartbeat is Group 4. The Group 4 Heartbeat message contains an On command when the Leak Sensor is Dry and an Off command when the Leak Sensor is Wet. The Heartbeat message is separate from the Leak Sensor Dry Group 1 On message or Leak Sensor Wet Group 2 On message. The Heartbeat message could occur many hours after the last Leak Sensor Dry or Leak Sensor Wet message. I do have a Leak Sensor. Firmware v.3E I do have a HeartBeat Program which is what I posted. I removed the functional statements after the Wait that perform Actions I want executed if the Heartbeat fails to arrive. Below is the event trace messages from a single Leak Sensor Set button tap. The test Heartbeat is generated approx 15 seconds after that last Set button tap. Leak Sensor is physically Dry Sun 02/24/2013 11:54:17 PM : [iNST-SRX ] 02 50 21.7A.CC 00.00.01 CB 11 01 LTONRR (01) Sun 02/24/2013 11:54:17 PM : [std-Group ] 21.7A.CC-->Group=1, Max Hops=3, Hops Left=2 Sun 02/24/2013 11:54:17 PM : [ 21 7A CC 1] DON 1 Sun 02/24/2013 11:54:18 PM : [iNST-SRX ] 02 50 21.7A.CC 00.00.01 CB 11 01 LTONRR (01) Sun 02/24/2013 11:54:18 PM : [std-Group ] 21.7A.CC-->Group=1, Max Hops=3, Hops Left=2 Sun 02/24/2013 11:54:18 PM : [iNST-DUP ] Previous message ignored. Sun 02/24/2013 11:54:20 PM : [iNST-SRX ] 02 50 21.7A.CC 11.01.01 CB 06 00 (00) Sun 02/24/2013 11:54:20 PM : [std-Group ] 21.7A.CC-->11.01.01, Max Hops=3, Hops Left=2 Sun 02/24/2013 11:54:21 PM : [iNST-SRX ] 02 50 21.7A.CC 11.01.01 CB 06 00 (00) Sun 02/24/2013 11:54:21 PM : [std-Group ] 21.7A.CC-->11.01.01, Max Hops=3, Hops Left=2 Sun 02/24/2013 11:54:21 PM : [iNST-DUP ] Previous message ignored. Sun 02/24/2013 11:54:34 PM : [iNST-SRX ] 02 50 21.7A.CC 00.00.04 CB 11 04 LTONRR (04) Sun 02/24/2013 11:54:34 PM : [std-Group ] 21.7A.CC-->Group=4, Max Hops=3, Hops Left=2 Sun 02/24/2013 11:54:34 PM : [ 21 7A CC 4] DON 4 Sun 02/24/2013 11:54:34 PM : [ X10] A5 Sun 02/24/2013 11:54:34 PM : [X10-RSP ] 02 63 61 00 06 Sun 02/24/2013 11:54:34 PM : [ X10] A5/On (3) Sun 02/24/2013 11:54:35 PM : [X10-RSP ] 02 63 62 80 06 Sun 02/24/2013 11:54:36 PM : [X10-RX ] 02 52 AA 00 Sun 02/24/2013 11:54:36 PM : [ X10] D4 Sun 02/24/2013 11:54:37 PM : [iNST-SRX ] 02 50 21.7A.CC 11.01.04 CB 06 00 (00) Sun 02/24/2013 11:54:37 PM : [std-Group ] 21.7A.CC-->11.01.04, Max Hops=3, Hops Left=2 Sun 02/24/2013 11:54:37 PM : [X10-RX ] 02 52 A3 80 Sun 02/24/2013 11:54:37 PM : [ X10] D4/Off (11) Sun 02/24/2013 11:54:38 PM : [iNST-SRX ] 02 50 21.7A.CC 11.01.04 CB 06 00 (00) Sun 02/24/2013 11:54:38 PM : [std-Group ] 21.7A.CC-->11.01.04, Max Hops=3, Hops Left=2 Sun 02/24/2013 11:54:38 PM : [iNST-DUP ] Previous message ignored.

Was XS entered to terminate the telnet session?

The Program is triggered each time a Heartbeat On (Leak Sensor Dry) or Heartbeat Off (Leak Sensor Wet) is received which should be every 24 hours. This will cause the Program to terminate the ‘Wait 25 Hours’ before it completes and executes the statements after the Wait. So long as the Leak Sensor continues to send Heartbeat messages every 24 hours the Program effectively does nothing but Wait. Should a heartbeat message fail to be received in 25 hours the Program Wait completes and does whatever it needs to do to signal a lack of heartbeat.

Multiple ISY Scenes are needed. The first Scene has the KPL ON/OFF buttons as Controller with the three individual switches as Responders. The KPL ON/OFF buttons will turn On/Off together the three switches. Scene 1 KPL 1 ON/OFF buttons as Controller – only ON button assigned to Scene Switch 1 is Responder Switch 2 is Responder Switch 3 is Responder Three more Scenes are needed for each of the Secondary KPL buttons to control their respective Switch and show if that Switch has been operated manually to control its load. Scene 2 – cross links KPL button A and Switch 1 KPL 1 button A as Controller Switch 1 as Controller Scene 3 - cross links KPL button B and Switch 2 KPL 1 button B as Controller Switch 2 as Controller Scene 4 – cross links KPL button C and Switch 3 KPL 1 button C as Controller Switch 3 as Controller These Scenes have only one KPL in the picture. If there are multiple KPLs in the picture add the same buttons from each KPL into each Scene Scene 1 KPL 1 ON/OFF buttons as Controller – only ON button assigned to Scene KPL 2 ON/OFF buttons as Controller - only ON button assigned to Scene Switch 1 is Responder Switch 2 is Responder Switch 3 is Responder Scene 2 – cross links KPL button A and Switch 1 KPL 1 button A as Controller KPL 2 button A as Controller Switch 1 as Controller Scene 3 - cross links KPL button B and Switch 2 KPL 1 button B as Controller KPL 2 button B as Controller Switch 2 as Controller Scene 4 – cross links KPL button C and Switch 3 KPL 1 button C as Controller KPL 2 button C as Controller Switch 3 as Controller

The ISY does not change the Heartbeat to Off on its own. This Program will monitor the Heartbeat node. If Control 'Leak Sensor-Heartbeat' is switched On Or Control 'Leak Sensor-Heartbeat' is switched Off Then Wait 25 hours do something - turn On KPL button, send Notify, etc Else - No Actions - (To add one, press 'Action') It was a user suggestion to change On to 100%. Some users were interpreting On to mean any device state that was not Off when On really means 100% On. The change from On to 100% is a general change in the Admin Console, not specific to the Leak Sensor

Triggering with Fast On/Off should have no affect on Scene reliability. What might be happening is the double tap is generating two On sequences rather than one Fast On sequence. The speed of the double tap is critical in generating a Fast On. One way to watch this is run Tools | Diagnostics | Event Viewer in LEVEL 3. Do a double tap and see if the event trace shows a Fast On or On command. This is an On command Sun 02/24/2013 08:13:00 PM : [iNST-SRX ] 02 50 1D.38.00 00.00.01 CB 11 00 LTONRR (00) This is a Fast On Sun 02/24/2013 08:14:04 PM : [iNST-SRX ] 02 50 1D.38.00 19.70.06 41 12 01 LTON-F (01)

Controlling the I/O Linc Relay from a KeypadLinc button is using a Scene to control the Relay. Now which Momentary Mode A,B,C the I/O Linc is in controls how the Relay will react to the KPL button press. In Momentary A mode the Relay will react to only one command (turn On), either Scene On or Scene Off but not both. I Momentary B mode the Relay will turn On with both a Scene On and a Scene Off. This is probably the Momentary mode you want to use. In Momentary C mode the Relay reaction is related to whether the Sensor is On or Off in combination with Scene On or Scene Off. All the detail regarding how the I/O Linc Relay reacts in each Momentary mode is covered in the I/O Linc User Guide. With the Green LED On all the time regardless of whether the magnet is near the reed switch, either the magnetic switch is bad, there is a short in the wiring or the wiring is not correct. So long as the Green LED goes out when the wires to the GND and Sensor connections are removed the I/O Linc itself is working. The I/O Linc does not send a message back to the ISY/PLM when Momentary mode turns the Relay Off. That is why the Relay can indicate On in the Admin Console much of the time even though the Relay is physically Off. This is normal.

For each Scene a device operates there is an ISY node. An 8 button KeypadLinc operates 8 different Scenes, thus 8 nodes. The 6 button KeypadLinc operates 5 Scenes, thus 5 nodes. With the TriggerLinc jumper in place one Scene is used, with On and Off commands sent for that one Scene. When the jumper is removed two Scenes are used, with On only commands sent for each Scene. Excerpts from the User Guide External Sensor Terminals When using an external sensor, TriggerLinc is in the closed state when either the external sensor terminals or the reed switch are closed. In other words, TriggerLinc opens when both the external sensor terminals and reed switch are open. Connecting an External Sensor to TriggerLinc NOTE: For the basic use of TriggerLinc’s external sensor terminals, it is not recommended to also use TriggerLinc’s internal reed switch to help ensure the desired behavior. Using the Internal Reed Switch and External Sensors When the TriggerLinc external sensors input is used in conjunction with its internal reed switch, TriggerLinc behaves much like several sensors connected in parallel (above), meaning: TriggerLinc will be open when both the internal reed switch and external reed switch sensor terminals show open TriggerLinc will be closed when either the internal reed switch or external sensor terminals show closed It is not possible to use the internal reed switch in combination with an external switch to achieve the combination you are looking for. It can be done using external only switches.

The Open/Close Sensor has two operational modes. Refer to the Open/Close Sensor User Guide for the details. There is a single jumper on the Open/Close Sensor PC board that controls the mode. The Closed node is used only when the other operational mode is used which requires removing the jumper from the PC board. The external switches can be wired in series or parallel. If NC switches are wired in series either switch being open will operate the TriggerLinc. With NO switches wired in parallel either switch will operate the TriggerLinc. Using the appropriate combination of NO or NC switches wired in series or parallel will provide whatever combination is needed.