johnnyt Posted January 30, 2014 Share Posted January 30, 2014 Am intermittently seeing EZIO8SA devices being ON (or at least reporting ON) when they should be OFF. I first emailed Smartenit support and, in a fit of laziness, simply copied most of it and their reply here as the body of my post. (I left the comment he made to me about the EZX10RF as an FYI.) Note that I happen to know he has only just upgraded ISY to the current 4.1.2 version today - and replied to him my concern that he hadn't really had much of a chance to test this... From: Justin Samuel [mailto] Sent: Thursday, January 30, 2014 1:56 PM I have tested functionality of the EZIO8SA with the latest version of the ISY and have not found any issues as of yet. What you mentioned is odd, but I don’t have any clues as to what would cause the EZIO8SA to turn on the relays unless they’ve been linked to something or programmed to respond to X10. The only thing I can suggest if you believe the EZIO8SA is originating this odd behavior is to factory reset the PLM of the EZIO8SA and re-add it to the ISY. I’ve also tested the EZX10RF, which works great so far… ----------------------------------- Hi, I’m using a new EZIO8SA with and ISY 994i running the latest available firmware (4.1.2) and am noticing strange behavior where relays are either sometimes mysteriously being turned on or the query is returning the wrong state. As a reliability check I had in place before I got the EZIO8SA – I bought your product to replace some IO Lincs – I have an ISY program run a query to check that the state of my HVAC relays is what ISY thinks they are. This is mostly because some IOLinc sensors I have don’t always report when they change states. Occasionally now, though, the query reports back that some of the relays on the EZIO8SA are ON when ISY thinks they are OFF (as they should be). This is intermittent and not something I programmed the EZIO8SA to do. In the log entries below you can see the query, which – as indicated by the second last column – is initiated by a program and returns in this case that relays 2, 3, 5,7 and 8 are on. (Of course I renamed them to something more meaningful.) Normally when a query returns what ISY expected, no entry is logged other than the query event itself. I know it is not another program that changes the state as evidenced by the 2nd last column showing this is a “System†event. I can also confirm that no events showing a change to those relays occurred just prior to the query so it’s not some sort of timing or insteon command collision issue. Those relays should all have been OFF at the time of that query. 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Sun 2014/01/26 07:39:00 AM Program Log 1-MISC (Non Lighting) / HVAC / Furnace Rm Damper Status 100% Sun 2014/01/26 07:39:01 AM System Log 1-MISC (Non Lighting) / HVAC / Office Damper Status 100% Sun 2014/01/26 07:39:01 AM System Log 1-MISC (Non Lighting) / HRV / HRV Low Status 100% Sun 2014/01/26 07:39:01 AM System Log 1-MISC (Non Lighting) / HVAC / Humidifier Status 100% Sun 2014/01/26 07:39:01 AM System Log Z-Unused Relay Sensors / 28.AD.BD.8 Status 100% Sun 2014/01/26 07:39:01 AM System Log I only use relays 1-7 and it’s not always the same relays that act up. I don’t use relay 8 and don’t use any of the inputs. Also, yes, I do have inputs 5&6 connected to Gnd. Finally, I did validate that the EZIO8SA PLM link table is identical to what ISY has in its PLM table for it. Do you know what might be going on? Any info would be appreciated. Link to comment
LeeG Posted January 30, 2014 Share Posted January 30, 2014 Next time this happens an Event Trace at LEVEL 3 with the Query response would be useful. Note the System Log entries are the results of the Query EZIO8SA Status Query Thu 2014/01/30 06:48:34 PM Web Log EZIO8SA Status 0% Thu 2014/01/30 06:48:35 PM System Log EZIO8SA / EZIO8SA - 2 Status 100% Thu 2014/01/30 06:48:35 PM System Log EZIO8SA / EZIO8SA - 6 Status 100% Thu 2014/01/30 06:48:35 PM System Log Link to comment
LeeG Posted January 31, 2014 Share Posted January 31, 2014 I suspect the issue will be the same thing we see with the I/O Linc. The Query of both the I/O Linc and the EZIO8SA requires two commands. The Insteon network returns duplicate messages for one of the query responses that due to the time when the duplicate comes back makes it look like a response to the other query. The event trace at LEVEL 3 will confirm that. Link to comment
johnnyt Posted January 31, 2014 Author Share Posted January 31, 2014 The event trace at LEVEL 3 will confirm that.but it's intermittent - in practice this would mean I need to run at level 3 for as much as a day (it usually happens at least once a day) and hope it happens sooner rather than later. Long ago I was told not to leave the event viewer at level 3 as the disk (and ISY performance?) gets hammered with data logging. The Insteon network returns duplicate messages...is it overly simplistic to suggest ISY simply ignore duplicate message to a single query command? - By duplicate message I assume you don't mean the second distinct message that comes in (one for the outputs, one for the inputs), e.g. RINPUT (00) and RINPUT (30) in this sample query I just ran: Thu 01/30/2014 07:48:21 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 4F 02 Thu 01/30/2014 07:48:21 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 4F 02 06 IOCTL (QUERY) Thu 01/30/2014 07:48:21 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 4F 4A IOCTL (4A) Thu 01/30/2014 07:48:21 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 01/30/2014 07:48:22 PM : [ 28 AD BD 1] ST 0 Thu 01/30/2014 07:48:22 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Thu 01/30/2014 07:48:22 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 49 00 06 RINPUT (00) Thu 01/30/2014 07:48:22 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 49 30 RINPUT (30) Thu 01/30/2014 07:48:22 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Link to comment
LeeG Posted January 31, 2014 Share Posted January 31, 2014 With the I/O Linc the duplicate message came in after the next command was issued and before that Query response was received. Made the duplicate look like it belonged to the Query last issued when it was a duplicate from the previous Query. I believe the ISY did ignore the duplicate but the duplicate from the ISY view was the response from the second Query. The EZIO8SA firmware has not changed for years so it is not likely a new issue is just surfacing. Not impossible but not very likely. If you know the relay states have been reported incorrectly a second Query call would show if the relays are actually On or not. What if you added a second Query in the test Program. Then if the second Query call produced a different set of relay values it would suggest the relays really are not On. Link to comment
johnnyt Posted February 7, 2014 Author Share Posted February 7, 2014 I got lucky today and was able to catch a blast of the problem I see intermittently with the event viewer at level 3. First let me set up what I have in place. I have up to two rounds of device querying to catch/notify me when any of my EZIO relays report a status that ISY did not have in its records. At least that's what I think I'm doing. Below are the programs involved. This first one is called by another program that gets triggered every 15 mins or when an IOLinc sensor that monitors stat call changes (today a heat call, in the summer an AC call), or when an X10 command from an IO Linc is received. The X10 command was put in as a backup. If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $iRunQueryTestAgain = 0 $sHVAC.Query.Count = 0 Run Program 'QT-Basement Damper- Set Variable' (If) Run Program 'QT-Fan ON - Set Variable' (If) Run Program 'QT-Furnace Damper- Set Variable' (If) Run Program 'QT-Office Damper- Set Variable' (If) Run Program 'QT-HRV Low - Set Variable' (If) Run Program 'QT-HRV High - Set Variable' (If) Run Program 'QT-Humidifier - Set Variable' (If) Send Notification to 'me' content 'Generic Program Log' Wait 3 seconds Set '1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1' Query Wait 10 seconds Run Program '1-Run Query Test Again' (If) Else - No Actions - (To add one, press 'Action') There are then seven times each of the three following programs; one for each EZIO relay I use. All variables in the three programs below are integer variables. Program 'QT-Basement Damper- Set Variable' If Status '1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1' is 100% Then $a.StateOfBasementDamper = 1 Wait 1 second Enable Program 'QT-Basement Damper- Notify Change ON' Enable Program 'QT-Basement Damper- Notify Change OFF' Wait 8 seconds Disable Program 'QT-Basement Damper- Notify Change ON' Disable Program 'QT-Basement Damper- Notify Change OFF' Else $a.StateOfBasementDamper = 0 Wait 1 second Enable Program 'QT-Basement Damper- Notify Change ON' Enable Program 'QT-Basement Damper- Notify Change OFF' Wait 8 seconds Disable Program 'QT-Basement Damper- Notify Change ON' Disable Program 'QT-Basement Damper- Notify Change OFF' Program 'QT-Basement Damper- Notify Change ON' If Status '1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1' is 100% And $a.StateOfBasementDamper is 0 Then Send Notification to 'me' content 'Device Changed ON After Query' $iRunQueryTestAgain = 1 Else - No Actions - (To add one, press 'Action') Program 'QT-Basement Damper- Notify Change OFF' If Status '1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1' is Off And $a.StateOfBasementDamper is 1 Then Send Notification to 'Jean' content 'Device Changed OFF After Query' $iRunQueryTestAgain = 1 Else - No Actions - (To add one, press 'Action') Should one of the latter two above run, it set $iRunQueryTestAgain = 1 for the following second round of testing If $iRunQueryTestAgain > 0 Then $sHVAC.Query.Count = 0 Run Program 'QT-Basement Damper- Set Variable' (If) Run Program 'QT-Fan ON - Set Variable' (If) Run Program 'QT-Furnace Damper- Set Variable' (If) Run Program 'QT-Office Damper- Set Variable' (If) Run Program 'QT-HRV Low - Set Variable' (If) Run Program 'QT-HRV High - Set Variable' (If) Run Program 'QT-Humidifier - Set Variable' (If) Send Notification to 'Jean' content 'Generic Program Log' Wait 3 seconds Set '1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1' Query $iRunQueryTestAgain = 0 Else - No Actions - (To add one, press 'Action') This afternoon I got a flood of notifications showing an unexpected device status from the 1st query test followed by the reverse status from the second query test. See attached screenshot at the bottom. Below are the related log events. The first chunk shows the events from one heat call change / query test prior to the (second) one that resulted in the notifications getting sent. X10 K8 Fri 2014/02/07 02:17:14 PM System Log X10 K8 Fri 2014/02/07 02:17:15 PM System Log X10 K8 Off (11) Fri 2014/02/07 02:17:15 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Fri 2014/02/07 02:17:23 PM Program Log Scene:1-MISC (Non Lighting) / HVAC / HVAC Sensors Status Query Fri 2014/02/07 02:17:30 PM Program Log 1-MISC (Non Lighting) / HVAC / Sensor - Heat Off - Office Da Status 0% Fri 2014/02/07 02:17:31 PM System Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) On 255 Fri 2014/02/07 02:17:41 PM Program Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Status 100% Fri 2014/02/07 02:17:41 PM System Log Scene:1-MISC (Non Lighting) / HVAC / Office Damper for Prgs On Fri 2014/02/07 02:17:44 PM Program Log 1-MISC (Non Lighting) / HVAC / Old Office Damper (for LED) Status 100% Fri 2014/02/07 02:17:44 PM System Log 1-MISC (Non Lighting) / HVAC / Office Damper-EZIO.4 Status 100% Fri 2014/02/07 02:17:44 PM System Log Scene:1-MISC (Non Lighting) / HRV / HRV High for Prgs On Fri 2014/02/07 02:17:49 PM Program Log 1-MISC (Non Lighting) / HRV / Back KPL.G - HRV High (XLink) Status 100% Fri 2014/02/07 02:17:49 PM System Log 1-MISC (Non Lighting) / HRV / Back KPL.H - HRV High (XLink) Status 100% Fri 2014/02/07 02:17:49 PM System Log 1-MISC (Non Lighting) / HRV / HRV High-EZIO.6 Status 100% Fri 2014/02/07 02:17:49 PM System Log Scene:1-MISC (Non Lighting) / HRV / HRV Low for Prgs Off 0 Fri 2014/02/07 02:18:00 PM Program Log 1-MISC (Non Lighting) / HRV / Back KPL.F - HRV Low Status 0% Fri 2014/02/07 02:18:00 PM System Log 1-MISC (Non Lighting) / HRV / HRV Low-EZIO.5 Status 0% Fri 2014/02/07 02:18:00 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Off 0 Fri 2014/02/07 02:18:14 PM Program Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Fri 2014/02/07 02:18:14 PM System Log And here is the set of log entries related to the notifications. X10 K8 Fri 2014/02/07 02:24:06 PM System Log X10 K8 Fri 2014/02/07 02:24:06 PM System Log X10 K8 On (3) Fri 2014/02/07 02:24:06 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Fri 2014/02/07 02:24:15 PM Program Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 100% Fri 2014/02/07 02:24:16 PM System Log 1-MISC (Non Lighting) / HVAC / Fan On-EZIO.2 Status 100% Fri 2014/02/07 02:24:16 PM System Log 1-MISC (Non Lighting) / HVAC / Furnace Rm Damper-EZIO.3 Status 100% Fri 2014/02/07 02:24:16 PM System Log 1-MISC (Non Lighting) / HRV / HRV High-EZIO.6 Status 0% Fri 2014/02/07 02:24:16 PM System Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Status 0% Fri 2014/02/07 02:24:16 PM System Log Scene:1-MISC (Non Lighting) / HRV / HRV High for Prgs On Fri 2014/02/07 02:24:22 PM Program Log Scene:1-MISC (Non Lighting) / HVAC / HVAC Sensors Status Query Fri 2014/02/07 02:24:22 PM Program Log 1-MISC (Non Lighting) / HRV / HRV High-EZIO.6 Status 100% Fri 2014/02/07 02:24:22 PM System Log 1-MISC (Non Lighting) / HVAC / Sensor - Heat Off - Office Da Status 100% Fri 2014/02/07 02:24:23 PM System Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) On 255 Fri 2014/02/07 02:24:26 PM Program Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Fri 2014/02/07 02:24:26 PM System Log 1-MISC (Non Lighting) / HVAC / Fan On-EZIO.2 Status 0% Fri 2014/02/07 02:24:26 PM System Log 1-MISC (Non Lighting) / HVAC / Furnace Rm Damper-EZIO.3 Status 0% Fri 2014/02/07 02:24:26 PM System Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Status 100% Fri 2014/02/07 02:24:26 PM System Log Now the related level 3 event viewer entries, the first block being what ISY would end up with in its records when the second block of commands is sent/received. Fri 02/07/2014 02:17:13 PM : [ X10] K8 Fri 02/07/2014 02:17:13 PM : [X10-RX ] 02 52 3D 00 Fri 02/07/2014 02:17:13 PM : [ X10] K8 Fri 02/07/2014 02:17:13 PM : [X10-RX ] 02 52 33 80 Fri 02/07/2014 02:17:13 PM : [ X10] K8/Off (11) Fri 02/07/2014 02:17:20 PM : [ Time] 14:17:20 1(0) Fri 02/07/2014 02:17:21 PM : [VAR 2 68 ] 0 Fri 02/07/2014 02:17:21 PM : [ Time] 14:17:21 1(0) Fri 02/07/2014 02:17:21 PM : [VAR 2 78 ] 0 Fri 02/07/2014 02:17:21 PM : [VAR 2 79 ] 0 Fri 02/07/2014 02:17:21 PM : [VAR 2 77 ] 1 Fri 02/07/2014 02:17:21 PM : [VAR 2 76 ] 0 Fri 02/07/2014 02:17:21 PM : [VAR 2 73 ] 1 Fri 02/07/2014 02:17:21 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 4F 02 Fri 02/07/2014 02:17:21 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 4F 02 06 IOCTL (QUERY) Fri 02/07/2014 02:17:22 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 4F 11 IOCTL (11) Fri 02/07/2014 02:17:22 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:17:22 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Fri 02/07/2014 02:17:22 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 49 00 06 RINPUT (00) Fri 02/07/2014 02:17:23 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 49 30 RINPUT (30) Fri 02/07/2014 02:17:23 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:17:23 PM : [ Time] 14:17:24 1(0) Fri 02/07/2014 02:17:23 PM : [ Time] 14:17:25 1(0) Fri 02/07/2014 02:17:29 PM : [iNST-TX-I1 ] 02 62 15 BB 45 0F 19 01 Fri 02/07/2014 02:17:29 PM : [iNST-ACK ] 02 62 15.BB.45 0F 19 01 06 LTSREQ (01) Fri 02/07/2014 02:17:29 PM : [iNST-SRX ] 02 50 15.BB.45 24.1B.FE 2B 0D 00 (00) Fri 02/07/2014 02:17:29 PM : [std-Direct Ack] 15.BB.45-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:17:29 PM : [iNST-TX-I1 ] 02 62 15 BB 45 0F 19 00 Fri 02/07/2014 02:17:29 PM : [iNST-ACK ] 02 62 15.BB.45 0F 19 00 06 LTSREQ (LIGHT) Fri 02/07/2014 02:17:29 PM : [iNST-SRX ] 02 50 15.BB.45 24.1B.FE 2B 0D 00 (00) Fri 02/07/2014 02:17:30 PM : [std-Direct Ack] 15.BB.45-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:17:30 PM : [iNST-TX-I1 ] 02 62 15 BB 62 0F 19 01 Fri 02/07/2014 02:17:30 PM : [iNST-ACK ] 02 62 15.BB.62 0F 19 01 06 LTSREQ (01) Fri 02/07/2014 02:17:30 PM : [iNST-SRX ] 02 50 15.BB.62 24.1B.FE 2B 08 00 (00) Fri 02/07/2014 02:17:30 PM : [std-Direct Ack] 15.BB.62-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:17:30 PM : [iNST-TX-I1 ] 02 62 15 BB 62 0F 19 00 Fri 02/07/2014 02:17:30 PM : [iNST-ACK ] 02 62 15.BB.62 0F 19 00 06 LTSREQ (LIGHT) Fri 02/07/2014 02:17:30 PM : [iNST-SRX ] 02 50 15.BB.62 24.1B.FE 2B 08 00 (00) Fri 02/07/2014 02:17:31 PM : [std-Direct Ack] 15.BB.62-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:17:31 PM : [iNST-TX-I1 ] 02 62 17 71 EA 0F 19 01 Fri 02/07/2014 02:17:31 PM : [iNST-ACK ] 02 62 17.71.EA 0F 19 01 06 LTSREQ (01) Fri 02/07/2014 02:17:31 PM : [iNST-SRX ] 02 50 17.71.EA 24.1B.FE 2B 00 01 (01) Fri 02/07/2014 02:17:31 PM : [std-Direct Ack] 17.71.EA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:17:31 PM : [iNST-TX-I1 ] 02 62 17 71 EA 0F 19 00 Fri 02/07/2014 02:17:31 PM : [iNST-ACK ] 02 62 17.71.EA 0F 19 00 06 LTSREQ (LIGHT) Fri 02/07/2014 02:17:31 PM : [iNST-SRX ] 02 50 17.71.EA 24.1B.FE 2B 00 FF (FF) Fri 02/07/2014 02:17:32 PM : [std-Direct Ack] 17.71.EA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:17:32 PM : [ Time] 14:17:33 1(0) Fri 02/07/2014 02:17:32 PM : [ Time] 14:17:33 1(0) Fri 02/07/2014 02:17:33 PM : [ 15 BB 45 1] ST 0 Fri 02/07/2014 02:17:33 PM : [VAR 2 52 ] -670 Fri 02/07/2014 02:17:33 PM : [VAR 2 12 ] -1 Fri 02/07/2014 02:17:35 PM : [VAR 2 58 ] 1756 Fri 02/07/2014 02:17:35 PM : [VAR 2 70 ] 1912 Fri 02/07/2014 02:17:37 PM : [VAR 2 59 ] 1962 Fri 02/07/2014 02:17:37 PM : [VAR 2 70 ] 1910 Fri 02/07/2014 02:17:39 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 45 07 Fri 02/07/2014 02:17:39 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 45 07 06 IOON (07) Fri 02/07/2014 02:17:40 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 45 91 IOON (91) Fri 02/07/2014 02:17:40 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:17:40 PM : [ 28 AD BD 8] ST 255 Fri 02/07/2014 02:17:41 PM : [VAR 2 50 ] 2106 Fri 02/07/2014 02:17:43 PM : [iNST-TX-I1 ] 02 62 00 00 16 CF 11 00 Fri 02/07/2014 02:17:43 PM : [ Time] 14:17:44 1(0) Fri 02/07/2014 02:17:43 PM : [iNST-ACK ] 02 62 00.00.16 CF 11 00 06 LTONRR (00) Fri 02/07/2014 02:17:43 PM : [ 15 BB 45 2] ST 255 Fri 02/07/2014 02:17:43 PM : [ 28 AD BD 4] ST 255 Fri 02/07/2014 02:17:43 PM : [VAR 2 62 ] 481 Fri 02/07/2014 02:17:45 PM : [VAR 2 60 ] 2006 Fri 02/07/2014 02:17:45 PM : [VAR 2 70 ] 1908 Fri 02/07/2014 02:17:49 PM : [ Time] 14:17:48 1(0) Fri 02/07/2014 02:17:49 PM : [iNST-TX-I1 ] 02 62 00 00 20 CF 11 00 Fri 02/07/2014 02:17:49 PM : [iNST-ACK ] 02 62 00.00.20 CF 11 00 06 LTONRR (00) Fri 02/07/2014 02:17:49 PM : [VAR 2 42 ] 1 Fri 02/07/2014 02:17:49 PM : [ 20 43 49 7] ST 255 Fri 02/07/2014 02:17:49 PM : [ 20 43 49 8] ST 255 Fri 02/07/2014 02:17:49 PM : [ 28 AD BD 6] ST 255 Fri 02/07/2014 02:17:49 PM : [ Time] 14:17:50 1(0) Fri 02/07/2014 02:17:49 PM : [VAR 2 68 ] 1 Fri 02/07/2014 02:17:50 PM : [VAR 2 33 ] 152 Fri 02/07/2014 02:17:53 PM : [VAR 2 32 ] 56 Fri 02/07/2014 02:17:59 PM : [iNST-TX-I1 ] 02 62 00 00 1F CF 13 00 Fri 02/07/2014 02:17:59 PM : [VAR 2 38 ] 0 Fri 02/07/2014 02:17:59 PM : [iNST-ACK ] 02 62 00.00.1F CF 13 00 06 LTOFFRR(00) Fri 02/07/2014 02:17:59 PM : [ 20 43 49 6] ST 0 Fri 02/07/2014 02:17:59 PM : [ 28 AD BD 5] ST 0 Fri 02/07/2014 02:18:02 PM : [VAR 2 12 ] 1 Fri 02/07/2014 02:18:12 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 46 00 Fri 02/07/2014 02:18:12 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 46 00 06 IOOFF (00) Fri 02/07/2014 02:18:13 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 46 A8 IOOFF (A8) Fri 02/07/2014 02:18:13 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:18:13 PM : [ 28 AD BD 1] ST 0 Fri 02/07/2014 02:24:03 PM : [ X10] K8 Fri 02/07/2014 02:24:04 PM : [X10-RX ] 02 52 3D 00 Fri 02/07/2014 02:24:04 PM : [ X10] K8 Fri 02/07/2014 02:24:04 PM : [X10-RX ] 02 52 32 80 Fri 02/07/2014 02:24:04 PM : [ X10] K8/On (3) Fri 02/07/2014 02:24:13 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 4F 02 Fri 02/07/2014 02:24:13 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 4F 02 06 IOCTL (QUERY) Fri 02/07/2014 02:24:13 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 4F A8 IOCTL (A8) Fri 02/07/2014 02:24:13 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:13 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Fri 02/07/2014 02:24:13 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 49 00 06 RINPUT (00) Fri 02/07/2014 02:24:13 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 49 30 RINPUT (30) Fri 02/07/2014 02:24:13 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:15 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 21 89 0F (0F) Fri 02/07/2014 02:24:15 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 1] ST 255 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 2] ST 255 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 3] ST 255 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 6] ST 0 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 8] ST 0 Fri 02/07/2014 02:24:20 PM : [iNST-TX-I1 ] 02 62 00 00 20 CF 11 00 Fri 02/07/2014 02:24:20 PM : [iNST-ACK ] 02 62 00.00.20 CF 11 00 06 LTONRR (00) Fri 02/07/2014 02:24:20 PM : [iNST-TX-I1 ] 02 62 15 BB 45 0F 19 01 Fri 02/07/2014 02:24:20 PM : [iNST-ACK ] 02 62 15.BB.45 0F 19 01 06 LTSREQ (01) Fri 02/07/2014 02:24:20 PM : [iNST-SRX ] 02 50 15.BB.45 24.1B.FE 2B 0D 01 (01) Fri 02/07/2014 02:24:20 PM : [std-Direct Ack] 15.BB.45-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:20 PM : [iNST-TX-I1 ] 02 62 15 BB 45 0F 19 00 Fri 02/07/2014 02:24:20 PM : [iNST-ACK ] 02 62 15.BB.45 0F 19 00 06 LTSREQ (LIGHT) Fri 02/07/2014 02:24:21 PM : [iNST-SRX ] 02 50 15.BB.45 24.1B.FE 2B 0D FF (FF) Fri 02/07/2014 02:24:21 PM : [std-Direct Ack] 15.BB.45-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:21 PM : [iNST-TX-I1 ] 02 62 15 BB 62 0F 19 01 Fri 02/07/2014 02:24:21 PM : [iNST-ACK ] 02 62 15.BB.62 0F 19 01 06 LTSREQ (01) Fri 02/07/2014 02:24:21 PM : [iNST-SRX ] 02 50 15.BB.62 24.1B.FE 2B 08 00 (00) Fri 02/07/2014 02:24:21 PM : [std-Direct Ack] 15.BB.62-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:21 PM : [iNST-TX-I1 ] 02 62 15 BB 62 0F 19 00 Fri 02/07/2014 02:24:21 PM : [iNST-ACK ] 02 62 15.BB.62 0F 19 00 06 LTSREQ (LIGHT) Fri 02/07/2014 02:24:22 PM : [iNST-SRX ] 02 50 15.BB.62 24.1B.FE 2B 08 00 (00) Fri 02/07/2014 02:24:22 PM : [std-Direct Ack] 15.BB.62-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:22 PM : [iNST-TX-I1 ] 02 62 17 71 EA 0F 19 01 Fri 02/07/2014 02:24:22 PM : [iNST-ACK ] 02 62 17.71.EA 0F 19 01 06 LTSREQ (01) Fri 02/07/2014 02:24:22 PM : [iNST-SRX ] 02 50 17.71.EA 24.1B.FE 2B 00 01 (01) Fri 02/07/2014 02:24:22 PM : [std-Direct Ack] 17.71.EA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:22 PM : [iNST-TX-I1 ] 02 62 17 71 EA 0F 19 00 Fri 02/07/2014 02:24:22 PM : [iNST-ACK ] 02 62 17.71.EA 0F 19 00 06 LTSREQ (LIGHT) Fri 02/07/2014 02:24:23 PM : [iNST-SRX ] 02 50 17.71.EA 24.1B.FE 2B 00 FF (FF) Fri 02/07/2014 02:24:23 PM : [std-Direct Ack] 17.71.EA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:23 PM : [ Time] 14:24:25 1(0) Fri 02/07/2014 02:24:23 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 45 07 Fri 02/07/2014 02:24:23 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 45 07 06 IOON (07) Fri 02/07/2014 02:24:24 PM : [ Time] 14:24:26 1(0) Fri 02/07/2014 02:24:24 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 45 A8 IOON (A8) Fri 02/07/2014 02:24:24 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:24 PM : [ 28 AD BD 6] ST 255 Fri 02/07/2014 02:24:25 PM : [ 15 BB 45 1] ST 255 Fri 02/07/2014 02:24:26 PM : [ 28 AD BD 1] ST 0 Fri 02/07/2014 02:24:26 PM : [ 28 AD BD 2] ST 0 Fri 02/07/2014 02:24:27 PM : [ 28 AD BD 3] ST 0 Fri 02/07/2014 02:24:27 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 4F 02 Fri 02/07/2014 02:24:27 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 4F 02 06 IOCTL (QUERY) Fri 02/07/2014 02:24:27 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 4F A8 IOCTL (A8) Fri 02/07/2014 02:24:27 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:27 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Fri 02/07/2014 02:24:27 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 49 00 06 RINPUT (00) Fri 02/07/2014 02:24:27 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 49 30 RINPUT (30) Fri 02/07/2014 02:24:27 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:29 PM : [ 28 AD BD 8] ST 255 Any insight into what's happening would be appreciated. Hopefully I've provided everything that's available but if not, please let me know. Link to comment
LeeG Posted February 8, 2014 Share Posted February 8, 2014 I found a bad sequence that explains why the relays have the wrong status but not sure what to do about it. There is an extra message with the EZIO8SA address after the Input Query response that the ISY analyzes and marks several relays with the wrong status. Something similar to what we see with an I/O Linc but different enough that it requires more analysis. Fri 02/07/2014 02:24:13 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 4F 02 Fri 02/07/2014 02:24:13 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 4F 02 06 IOCTL (QUERY) Fri 02/07/2014 02:24:13 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 4F A8 IOCTL (A8) – 4 & 6 & 8 On - Ok Fri 02/07/2014 02:24:13 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:13 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Fri 02/07/2014 02:24:13 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 49 00 06 RINPUT (00) Fri 02/07/2014 02:24:13 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 49 30 RINPUT (30) Fri 02/07/2014 02:24:13 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:15 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 21 89 0F (0F) Fri 02/07/2014 02:24:15 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 1] ST 255 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 2] ST 255 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 3] ST 255 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 6] ST 0 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 8] ST 0 Link to comment
LeeG Posted February 8, 2014 Share Posted February 8, 2014 I’m not sure how to explain the extra message. It has the EZIO8SA address but the Max Hops count, command code and the cmd2 value being evaluated as relay status do not match either of the last two Query calls. In the I/O Linc case the extra message matches an earlier Query except for a smaller Hops Left count, making the message look like a duplicate. There is so much information in this message that does not match the real EZIO8SA condition it raises the question as to whether it is actually from the EZIO8SA. I think another level 3 trace is needed to see if the extra message has any similarities between cases. Link to comment
johnnyt Posted February 8, 2014 Author Share Posted February 8, 2014 Here's an example of a query that surprised ISY with 6 incorrect statuses, followed by the related level 3 events. It looks like there are a couple of extra queries and other messages along the way before the answer arrives, a full 10 seconds after the query and 8-9 seconds after the log entries are posted. 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Sat 2014/02/08 12:16:16 PM Program LogZ-Unused Relay Sensors / EZIO.7 (reversedwith8) Status 100% Sat 2014/02/08 12:16:16 PM System Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Status 100% Sat 2014/02/08 12:16:16 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Sat 2014/02/08 12:16:17 PM System Log 1-MISC (Non Lighting) / HVAC / Furnace Rm Damper-EZIO.3 Status 0% Sat 2014/02/08 12:16:17 PM System Log Z-Unused Relay Sensors / EZIO.7 (reversedwith8) Status 0% Sat 2014/02/08 12:16:17 PM System Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Status 0% Sat 2014/02/08 12:16:17 PM System Log Sat 02/08/2014 12:16:15 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 4F 02 Sat 02/08/2014 12:16:15 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 4F 02 06 IOCTL (QUERY) Sat 02/08/2014 12:16:15 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 4F 07 IOCTL (07) Sat 02/08/2014 12:16:15 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 02/08/2014 12:16:15 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Sat 02/08/2014 12:16:15 PM : [iNST-ACK ] 02 62 28.AD.BD 00 4F 02 06 IOCTL (QUERY) Sat 02/08/2014 12:16:16 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 20 B0 C7 (C7) Sat 02/08/2014 12:16:16 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=0, Hops Left=0 Sat 02/08/2014 12:16:16 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 20 B0 C7 (C7) Sat 02/08/2014 12:16:16 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=0, Hops Left=0 Sat 02/08/2014 12:16:16 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 20 4F 02 IOCTL (QUERY) Sat 02/08/2014 12:16:16 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=0, Hops Left=0 Sat 02/08/2014 12:16:25 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Sat 02/08/2014 12:16:25 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 49 00 06 RINPUT (00) Sat 02/08/2014 12:16:25 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 49 30 RINPUT (30) Sat 02/08/2014 12:16:25 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 For comparison, here's what an event trace looks like when there are no surprises. Sat 02/08/2014 12:30:51 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 4F 02 Sat 02/08/2014 12:30:51 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 4F 02 06 IOCTL (QUERY) Sat 02/08/2014 12:30:52 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 4F 13 IOCTL (13) Sat 02/08/2014 12:30:52 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 02/08/2014 12:30:52 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Sat 02/08/2014 12:30:52 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 49 00 06 RINPUT (00) Sat 02/08/2014 12:30:52 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 49 30 RINPUT (30) Sat 02/08/2014 12:30:52 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Link to comment
LeeG Posted February 8, 2014 Share Posted February 8, 2014 Thanks for the additional trace data. There are some differences in this event but add to the overall picture. The entries marked in red are additional messages that should not be there. The command code (0xB0) does match either Query sequence and of course the cmd2 data (0xC7) is completely unrelated to the state of the EZIO8SA relays. Sat 02/08/2014 12:16:15 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 4F 02 Sat 02/08/2014 12:16:15 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 4F 02 06 IOCTL (QUERY) Sat 02/08/2014 12:16:15 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 4F 07 IOCTL (07) Sat 02/08/2014 12:16:15 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 02/08/2014 12:16:15 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Sat 02/08/2014 12:16:15 PM : [iNST-ACK ] 02 62 28.AD.BD 00 4F 02 06 IOCTL (QUERY) Sat 02/08/2014 12:16:16 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 20 B0 C7 (C7) Sat 02/08/2014 12:16:16 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=0, Hops Left=0 Sat 02/08/2014 12:16:16 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 20 B0 C7 (C7) Sat 02/08/2014 12:16:16 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=0, Hops Left=0 Sat 02/08/2014 12:16:16 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 20 4F 02 IOCTL (QUERY) Sat 02/08/2014 12:16:16 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=0, Hops Left=0 Sat 02/08/2014 12:16:25 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Sat 02/08/2014 12:16:25 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 49 00 06 RINPUT (00) Sat 02/08/2014 12:16:25 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 49 30 RINPUT (30) Sat 02/08/2014 12:16:25 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 This is looking more like an EZIO8SA issue than something happening due to Insteon network issues. Link to comment
38link Posted February 15, 2014 Share Posted February 15, 2014 The following is a shorter (very low patience) version of a reply attempted a few minutes ago. In checking the model name on one of the Smartenit devices too much time elapsed and the system logged me off. Forum here doesn't appear to have an autosave function so the earlier post was lost. We have been having similar problems here for 2 years now. The 8SA does not report the correct relay status. PLMs were changed from v 98 to v 9B on the 8SA and later the 8SAs were changed to the V2 model. There was no effective difference after the dance steps. No 8SA relays have changed state when not commanded by programs only the status is wrong. Lately on a separate bare bones 994i system, with only an EZIO4O connected, a programmed Notification is being sent out every day when the Query program runs. In this case relays have been changing state when not commanded and it's clear it's coming from execution of the query program. Packaging for the DIN rail mount version of the Insteon I/O module will make a mess of some of the control boards here when compared to the existing 8SAs but we are calling it quits on all of the Smartenit devices regardless of whether the bug is at their end or not. Link to comment
johnnyt Posted February 19, 2014 Author Share Posted February 19, 2014 38link, thanks for posting despite the trouble you ran into. After another week and a half of testing (mostly automated) I thought I would provide an update and mention what Smartenit has said about the issue. Below are examples of how ISY is being surprised on a daily basis by the EZIO8SA status following a query. While it doesn’t happen every time the device is queried - and never, so far, when I manually do it - it isn’t a rare occurrence as it happens to varying degrees every day. Just to recap, the programs outlined in my previous post do the following: 1) before a query, the status ISY has is recorded in a variable for all my EZIO8SA relays and programs that look for an unexpected state are enabled 2) the EZIO8SA is queried and for any device that isn't as expected, ISY sends an email 3) After sending the email a second round of query testing is run for that device after a short delay to see if it changes again following the subsequent query. I guesstimate that 10% - 20% of the time there is an unexpected state, the first email is followed by a second email indicating the was now the opposite state. In addition to sending an email, ISY also writes the notification to a custom log file, which augments notifications sent by another program when the relay controlling a humidifier is turned [on /off], as well as when the query test is initiated. Here are 2 sets of custom log entries aligned with the emails shown in my 1st screenshot below. I've highlighted the messages from the Query Test (prefixed by QT). 2014/02/14, 15:36:28, Notification of Humidifier OFF ran True 2014/02/14, 15:43:51, Query HVAC Devices on Sensor ran True 2014/02/14, 15:44:01, QT-Humidifier - Notify Change ON ran because device was showing OFF when it was ON 2014/02/14, 15:44:01, Notification of Humidifier ON ran True 2014/02/14, 15:44:15, QT-Humidifier - Notify Change OFF ran because device was showing ON when it was OFF 2014/02/14, 15:44:15, Notification of Humidifier OFF ran True The above shows: 1) The last recorded activity for the humidifier prior to the query (OFF) 2) ISY is surprised to learn the humidifier is ON 3) The notification that the humidifier is now recorded as ON 4) The query test is run again (although not logged) and again ISY is surprised to learn the humidifier is now OFF 5) The notification that the humidifier is now recorded as OFF Similarly, about an hour later the following was recorded: 2014/02/14, 16:46:51, Notifiication of Humidifier ON ran True 2014/02/14, 16:52:19, Query HVAC Devices on Sensor ran True 2014/02/14, 16:52:30, QT-Basement Damper- Notify Change ON ran because device was showing OFF when it was ON 2014/02/14, 16:52:31, QT-Humidifier - Notify Change OFF ran because device was showing ON when it was OFF 2014/02/14, 16:52:31, Notifiication of Humidifier OFF ran False 2014/02/14, 16:52:45, QT-Basement Damper- Notify Change OFF ran because device was showing ON when it was OFF 2014/02/14, 16:52:46, QT-Humidifier - Notify Change ON ran because device was showing OFF when it was ON 2014/02/14, 16:52:46, Notifiication of Humidifier ON ran True 2014/02/14, 16:52:47, QT-Humidifier - Notify Change ON ran because device was showing OFF when it was ON 2014/02/14, 16:52:47, QT-Basement Damper- Notify Change OFF ran because device was showing ON when it was OFF 2014/02/14, 16:58:06, Notifiication of Humidifier OFF ran True The 1st screenshot below shows a sampling of how frequently these unexpected statuses followed by the reversal can happen. The 2nd screenshot shows a sampling of the occurrences when ISY is surprised by the status and the second query does not see the reverse. A day can could go by without me seeing the first scenario but no day has gone by since I put these test programs in a few week ago where I haven’t had a message from ISY about an unexpected EZIO8SA status. If every time an entry changed it would change back, or if every time I queried the EZIO8SA ALL relay statuses were unexpected, I would think it's only a problem with querying (unexplained messages shown by LeeG) but because that's not the case, I'm thinking something is changing the EZIO8SA relays without ISY knowing. The problem now is that - unless I'm missing something - catching this would require having to sit there for probably hours at a time and watch devices controlled by the EZIO8SA (since there are no LED's on the EZIO) alongside an ISY console session running the event viewer at level 3 hoping I actually catch it happen during the query test window and before ISY takes action that might change the device back to what ISY thinks it's supposed to be. That's about as appealing to me as the idea of watching paint dry. Smartenit can't replicate the problem and has suggested an older model PLM (pre-dual band) would fix the problem. Have asked them to send me one to try that but am concerned that these older PLMs aren't or won't be supported for much longer. While they have some inventory today, are older PLM's still being made/licensed by smartlabs? What is the longer term fix? How will an older PLM hold up with i2CS and future changes? Asking UDI to ignore the extra messages occasionally sent by the newer PLMs would presumably fix the query problem, but what about the mysterious state changes that may not be about these extra messages? Also, I didn't see anything come out to fix the duplicate messages that sometimes come from an IO Linc. How different would ignoring extra messages from an EZIO8SA be from the perspective of UDI putting something in? I'm kind of stuck because there are problems with both IO Lincs and the EZIO8SA. Are there other options available today or on the horizon, e.g. zwave? Link to comment
Michel Kohanim Posted February 20, 2014 Share Posted February 20, 2014 Hi johnnyt, I got an email from Justin at SmartenIt ... I told him that the issue is that we are receiving duplicate messages. Getting duplicate messages is OK because RF devices send 2 (or sometimes 3). This said, EZIO never used to do that. So, questions: 1. How old is your EZIO? 2. Do you know whether or not it's a dual band device? With kind regards, Michel Link to comment
johnnyt Posted February 20, 2014 Author Share Posted February 20, 2014 It's about 2 months old. Yes, it's dual band. Sent from my iPad using Tapatalk Link to comment
Michel Kohanim Posted February 20, 2014 Share Posted February 20, 2014 Hi johnnyt, Thank you. I will follow up with SmartenIt. With kind regards, Michel Link to comment
johnnyt Posted February 20, 2014 Author Share Posted February 20, 2014 Hi Michel, Was just looking back and and it seems there's something more than simply a duplicate message going on. I found a bad sequence that explains why the relays have the wrong status but not sure what to do about it. There is an extra message with the EZIO8SA address after the Input Query response that the ISY analyzes and marks several relays with the wrong status. Something similar to what we see with an I/O Linc but different enough that it requires more analysis. Fri 02/07/2014 02:24:13 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 4F 02 Fri 02/07/2014 02:24:13 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 4F 02 06 IOCTL (QUERY) Fri 02/07/2014 02:24:13 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 4F A8 IOCTL (A8) – 4 & 6 & 8 On - Ok Fri 02/07/2014 02:24:13 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:13 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Fri 02/07/2014 02:24:13 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 49 00 06 RINPUT (00) Fri 02/07/2014 02:24:13 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 49 30 RINPUT (30) Fri 02/07/2014 02:24:13 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:15 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 21 89 0F (0F) Fri 02/07/2014 02:24:15 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 1] ST 255 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 2] ST 255 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 3] ST 255 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 6] ST 0 Fri 02/07/2014 02:24:15 PM : [ 28 AD BD 8] ST 0 Link to comment
Michel Kohanim Posted February 20, 2014 Share Posted February 20, 2014 Hi johnnyt, Yes, thankfully, LeeG provided more details; The problem is we are getting two responses for the same command one of which is not valid. Justin mentioned that he's going to send you another unit to try. Please keep us posted. With kind regards, Michel Link to comment
johnnyt Posted March 10, 2014 Author Share Posted March 10, 2014 Okay, so Smartenit sent me a new EZIO8SA/PLM Combo but this time with a single band PLM hoping it would solve the problems I'm seeing but it didn't. As the issue is intermittent and Smartenit can't reproduce it, I'm coming back here for advice on what I'm seeing and/or missing in troubleshooting this. I'll recap then build on what I've provided so far using up to date data generated by the single band PLM instead of the dual band one that came with the EZIO8SA initially. I won't repeat a desciption of the programs that I posted earlier to automate the testing in my attempts to catch this intermittent problem. Here's a typical winter time set of HVAC related events I control with three IO Lincs and the EZIO8SA. First the log entries below show a call for heat detected by an IOLinc (15.BB.45) that triggers a query scene made up of the three IOLinc sensors monitoring HVAC calls, one for heat, one for AC and one for Furnace Fan. (Someday I might separate the three but for now a change in any of the them triggers a query of all three). X10 K8 Sat 2014/03/08 09:12:48 PM System Log X10 K8 Off (11) Sat 2014/03/08 09:12:48 PM System Log Scene:1-MISC (Non Lighting) / HVAC / HVAC Sensors Status Query Sat 2014/03/08 09:12:54 PM Program Log 1-MISC (Non Lighting) / HVAC / Sensor - Heat Off - Office Da Status 0% Sat 2014/03/08 09:12:54 PM System Log 1-MISC (Non Lighting) / HVAC / Old Office Damper (for LED) Status 0% Sat 2014/03/08 09:12:55 PM System Log Notes: 1. The IO Lincs are configured to send X10 commands. This and the sensor query are safeguards for reliability, which are needed because ISY does not always see / act on an IO Linc sensor change. 2. Because the IOLinc sensor is ON when the stat call is OFF, the device name above shows that "Heat Off" has turned OFF, meaning heat is ON. 3. "Heat Off" device is the IO Linc sensor and the "Old Office Damper (for LED)" is the relay of the same IOLinc. As I learned not that long ago, an IOLinc query of either the sensor or the relay returns the value of both. I use the relay state only for its matching LED state to provide a visual indicator of the Office Damper (in a scene with the EZIO8SA relay that controls the damper). Noteworthy here, and what seems like a bug, is that there isn't a log entry for the sensor change. The event can be seen in the event viewer (see below) and does cause the query program to run (6 seconds later, as designed) so it seems that a log entry is simply not posted. This is consistent behavior. Here are the L3 event viewer entries from the IO Linc Sensor: Sat 03/08/2014 09:12:36 PM : [ Time] 21:12:42 1(0) Sat 03/08/2014 09:12:41 PM : [iNST-SRX ] 02 50 15.BB.45 00.00.01 CB 11 00 LTONRR (00) Sat 03/08/2014 09:12:41 PM : [std-Group ] 15.BB.45-->Group=1, Max Hops=3, Hops Left=2 Sat 03/08/2014 09:12:41 PM : [ 15 BB 45 1] DON 0 Sat 03/08/2014 09:12:41 PM : [iNST-SRX ] 02 50 15.BB.45 24.1B.FE 41 11 01 LTONRR (01) Sat 03/08/2014 09:12:41 PM : [std-Cleanup ] 15.BB.45-->ISY/PLM Group=1, Max Hops=1, Hops Left=0 Sat 03/08/2014 09:12:41 PM : [iNST-DUP ] Previous message ignored. And below are the event viewer entries aligned to the log entries above. The other two IO Lincs in the scene that is queried are 15.BB.62 and 17.71.EA. What seems a little weird to me is that the status response of those other sensors does NOT end up in the log. When I manually run a query, log entries are posted whether or not the status is a change but when queried here by a program, the only entry logged is for the heat call IO Linc (see above). Side question: 1) what does the INST-ERX message at 09:12:50 represent? Sat 03/08/2014 09:12:42 PM : [X10-RX ] 02 52 3D 00 Sat 03/08/2014 09:12:42 PM : [ X10] K8 Sat 03/08/2014 09:12:42 PM : [X10-RX ] 02 52 33 80 Sat 03/08/2014 09:12:42 PM : [ X10] K8/Off (11) Sat 03/08/2014 09:12:48 PM : [ Time] 21:12:53 1(0) Sat 03/08/2014 09:12:48 PM : [iNST-TX-I1 ] 02 62 15 BB 45 0F 19 01 Sat 03/08/2014 09:12:48 PM : [iNST-ACK ] 02 62 15.BB.45 0F 19 01 06 LTSREQ (01) Sat 03/08/2014 09:12:48 PM : [iNST-SRX ] 02 50 15.BB.45 24.1B.FE 2B 0D 00 (00) Sat 03/08/2014 09:12:48 PM : [std-Direct Ack] 15.BB.45-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 03/08/2014 09:12:48 PM : [iNST-TX-I1 ] 02 62 15 BB 45 0F 19 00 Sat 03/08/2014 09:12:48 PM : [iNST-ACK ] 02 62 15.BB.45 0F 19 00 06 LTSREQ (LIGHT) Sat 03/08/2014 09:12:48 PM : [iNST-SRX ] 02 50 15.BB.45 24.1B.FE 2B 0D 00 (00) Sat 03/08/2014 09:12:48 PM : [std-Direct Ack] 15.BB.45-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 03/08/2014 09:12:48 PM : [iNST-TX-I1 ] 02 62 15 BB 62 0F 19 01 Sat 03/08/2014 09:12:49 PM : [iNST-ACK ] 02 62 15.BB.62 0F 19 01 06 LTSREQ (01) Sat 03/08/2014 09:12:49 PM : [iNST-SRX ] 02 50 15.BB.62 24.1B.FE 2B 08 00 (00) Sat 03/08/2014 09:12:49 PM : [std-Direct Ack] 15.BB.62-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 03/08/2014 09:12:49 PM : [iNST-TX-I1 ] 02 62 15 BB 62 0F 19 00 Sat 03/08/2014 09:12:49 PM : [iNST-ACK ] 02 62 15.BB.62 0F 19 00 06 LTSREQ (LIGHT) Sat 03/08/2014 09:12:49 PM : [iNST-SRX ] 02 50 15.BB.62 24.1B.FE 2B 08 00 (00) Sat 03/08/2014 09:12:49 PM : [std-Direct Ack] 15.BB.62-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 03/08/2014 09:12:49 PM : [iNST-TX-I1 ] 02 62 17 71 EA 0F 19 01 Sat 03/08/2014 09:12:50 PM : [iNST-ACK ] 02 62 17.71.EA 0F 19 01 06 LTSREQ (01) Sat 03/08/2014 09:12:50 PM : [iNST-ERX ] 02 51 15 BB 62 24 1B FE 10 F7 C0 66 DF C0 03 EE FE 81 44 01 0A 0D 3A AA 7D Sat 03/08/2014 09:12:50 PM : [Ext-Direct ] 15.BB.62-->ISY/PLM Group=0, Max Hops=0, Hops Left=0 Sat 03/08/2014 09:12:50 PM : [iNST-SRX ] 02 50 15.BB.62 24.1B.FE 2B 08 00 (00) Sat 03/08/2014 09:12:50 PM : [std-Direct Ack] 15.BB.62-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 03/08/2014 09:12:50 PM : [iNST-SRX ] 02 50 15.BB.62 24.1B.FE 23 08 00 (00) Sat 03/08/2014 09:12:50 PM : [std-Direct Ack] 15.BB.62-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sat 03/08/2014 09:12:51 PM : [iNST-SRX ] 02 50 17.71.EA 24.1B.FE 2B 00 01 (01) Sat 03/08/2014 09:12:51 PM : [std-Direct Ack] 17.71.EA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 03/08/2014 09:12:51 PM : [iNST-TX-I1 ] 02 62 17 71 EA 0F 19 00 Sat 03/08/2014 09:12:51 PM : [iNST-ACK ] 02 62 17.71.EA 0F 19 00 06 LTSREQ (LIGHT) Sat 03/08/2014 09:12:52 PM : [iNST-SRX ] 02 50 17.71.EA 24.1B.FE 2B 00 FF (FF) Sat 03/08/2014 09:12:52 PM : [std-Direct Ack] 17.71.EA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 03/08/2014 09:12:52 PM : [ 15 BB 45 1] ST 0 Sat 03/08/2014 09:12:52 PM : [ 15 BB 45 2] ST 0 Moving to the EZIO8SA side of things. The above action resulted in my Humidifier going on as desired, however, setting the humidifer ON also reported the status of two other EZIO relays that surprised ISY. Relays 1 and 2 were found to be the opposite of what ISY thought. 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) On 255 Sat 2014/03/08 09:13:05 PM Program Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 0% Sat 2014/03/08 09:13:06 PM System Log 1-MISC (Non Lighting) / HVAC / Fan On-EZIO.2 Status 100% Sat 2014/03/08 09:13:06 PM System Log 1-MISC (Non Lighting) / HVAC / Humidifier-EZIO.8(really7) Status 100% Sat 2014/03/08 09:13:06 PM System Log Here is the event viewer L3 trace that aligns to the above log entries: Sat 03/08/2014 09:13:01 PM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 45 07 Sat 03/08/2014 09:13:01 PM : [ Time] 21:13:05 1(0) Sat 03/08/2014 09:13:01 PM : [iNST-ACK ] 02 62 23.8D.7C 0F 45 07 06 IOON (07) Sat 03/08/2014 09:13:01 PM : [ Time] 21:13:06 1(0) Sat 03/08/2014 09:13:01 PM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 45 82 IOON (82) Sat 03/08/2014 09:13:01 PM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 03/08/2014 09:13:01 PM : [ 23 8D 7C 1] ST 0 Sat 03/08/2014 09:13:01 PM : [ 23 8D 7C 2] ST 255 Sat 03/08/2014 09:13:01 PM : [ 23 8D 7C 8] ST 255 A little over a min later ISY initiates my query testing (the set of programs explained in an earlier post), which does a query of the EZIO8SA and confirms (or updates) the device status reported a minute earlier: 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Sat 2014/03/08 09:14:06 PM Program Log Overnight all worked well as the furnace cycled on and off, repeating the above pattern but without any surprises, and "Fan On-EZIO.2" remained ON throughout. At 7:30 AM the next day, however, the EZIO8SA query surprised ISY again. (A search of the log for "Fan On-EZIO.2" confirms there are no entries between 9:13:06 PM and 7:33:45 AM.) 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Sun 2014/03/09 07:33:25 AM Program Log 1-MISC (Non Lighting) / HVAC / Fan On-EZIO.2 Status 0% Sun 2014/03/09 07:33:45 AM System Log 1-MISC (Non Lighting) / HVAC / Office Damper-EZIO.4 Status 0% Sun 2014/03/09 07:33:45 AM System Log 1-MISC (Non Lighting) / HRV / HRV Low-EZIO.5 Status 100% Sun 2014/03/09 07:33:45 AM System Log 1-MISC (Non Lighting) / HRV / HRV High-EZIO.6 Status 100% Sun 2014/03/09 07:33:45 AM System Log Below are the related event viewer entries. What surprises me are the three queries, each within 10 secs of the previous one. Only one query is sent in my program logic unless the response surprises ISY, in which case a second round of testing is initiated about 13 secs later in the hope it might provide a clue as to what's going on. The second instance relies on the response to the first but there is no response here until the third query about 20 secs after the query is initiated and logged. There is also what appears to be a duplicate query message at 07:33:28 with Max Hops=3, Hops Left=0 in an environment that's otherwise pretty reliable comms-wise. Sun 03/09/2014 07:33:12 AM : [ Time] 07:33:23 0(0) Sun 03/09/2014 07:33:14 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:33:14 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:18 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:18 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:23 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:33:23 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:32 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:32 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Sun 03/09/2014 07:33:33 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Sun 03/09/2014 07:33:33 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:34 AM : [ Time] 07:33:45 0(0) Sun 03/09/2014 07:33:34 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 49 30 RINPUT (30) Sun 03/09/2014 07:33:34 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 03/09/2014 07:33:37 AM : [ 23 8D 7C 2] ST 0 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 4] ST 0 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 5] ST 255 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 6] ST 255 Just to confirm it wasn't a program that runs/queries twice, I create a custom notification/log when it runs. Here are those entries including the one before and two after the related one at 7:23:22. This also shows the two rounds of automated testing that occured at 7:40 seen further below. 2014/03/09, 07:22:38, 1-Initiate Query Test ran True 2014/03/09, 07:33:22, 1-Initiate Query Test ran True 2014/03/09, 07:40:03, 1-Initiate Query Test ran True 2014/03/09, 07:40:15, 1-Run Query Test Again ran True About 6 mins later, when the heat call ends, ISY is again surprised for two of the EZIO8SA devices : X10 K8 Sun 2014/03/09 07:38:47 AM System Log X10 K8 Sun 2014/03/09 07:38:47 AM System Log X10 K8 On (3) Sun 2014/03/09 07:38:48 AM System Log Scene:1-MISC (Non Lighting) / HVAC / HVAC Sensors Status Query Sun 2014/03/09 07:38:52 AM Program Log 1-MISC (Non Lighting) / HVAC / Sensor - Heat Off - Office Da Status 100% Sun 2014/03/09 07:38:52 AM System Log Bedrooms / Boys Bedroom Table Lamp Status Query Sun 2014/03/09 07:40:00 AM Program Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Sun 2014/03/09 07:40:05 AM Program Log 1-MISC (Non Lighting) / HVAC / Fan On-EZIO.2 Status 100% Sun 2014/03/09 07:40:05 AM System Log 1-MISC (Non Lighting) / HRV / HRV High-EZIO.6 Status 0% Sun 2014/03/09 07:40:05 AM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Sun 2014/03/09 07:40:18 AM Program Log Here are the related event viewer L3 entries: Sun 03/09/2014 07:39:53 AM : [ Time] 07:40:05 0(0) Sun 03/09/2014 07:39:53 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:39:53 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:39:53 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:39:53 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:39:53 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Sun 03/09/2014 07:39:53 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Sun 03/09/2014 07:39:53 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Sun 03/09/2014 07:39:53 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:39:54 AM : [ 23 8D 7C 2] ST 255 Sun 03/09/2014 07:39:54 AM : [ 23 8D 7C 6] ST 0 Sun 03/09/2014 07:40:05 AM : [ Time] 07:40:17 0(0) Sun 03/09/2014 07:40:06 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:40:06 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:40:06 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:40:06 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:40:06 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Sun 03/09/2014 07:40:06 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Sun 03/09/2014 07:40:07 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Sun 03/09/2014 07:40:07 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 While it would be nice to see log entries for IO Linc sensor changes (and that certainly would have helped me in the past), the only thing that concerns me at this point are the three queries in a row being sent out without responses. I'm also hoping without the dual band PLM in play, it's easy to pinpoint the problem for me to tell Smartnenit. Any suggestions? Link to comment
LeeG Posted March 10, 2014 Share Posted March 10, 2014 INST-SRX = Standard Response – 02 50 15.BB.62 24.1B.FE 2B 08 00 INST-ERX = Extended Response – 02 51 15 BB 62 24 1B FE 10 F7 C0 66 DF C0 03 EE FE 81 44 01 0A 0D 3A AA 7D The new PLM seems to have eliminated the odd messages with invalid command codes. Only snippets are posted but none of the posted trace has similar invalid commands as seen in the old posts Fri 02/07/2014 02:24:13 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Fri 02/07/2014 02:24:13 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 49 00 06 RINPUT (00) Fri 02/07/2014 02:24:13 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 49 30 RINPUT (30) Fri 02/07/2014 02:24:13 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 02/07/2014 02:24:15 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 21 89 0F (0F) Fri 02/07/2014 02:24:15 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 The relay status changes from older traces showed invalid commands. The new trace entries have the expected commands and what I would assume is valid relay status. Perhaps this was a finger check. I do not see a trace entry for “the related one at 7:23:22†“three queries in a row being sent out without responses.†What are the time stamps. I do not see a query without a response. Link to comment
johnnyt Posted March 10, 2014 Author Share Posted March 10, 2014 Perhaps this was a finger check. I do not see a trace entry for “the related one at 7:23:22†“three queries in a row being sent out without responses.†What are the time stamps. I do not see a query without a response. Thanks for looking through this stuff, LeeG. Here's what I thought were three queries without a response. I guess I meant three queries with only ONE response. I could certainly be misinterpreting what this is but I saw the word "query" three times and what I interpret to be a single response "RINPUT", although is the third instance of "RINPUT" a duplicate? Sun 03/09/2014 07:33:12 AM : [ Time] 07:33:23 0(0) Sun 03/09/2014 07:33:14 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:33:14 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:18 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:18 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:23 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:33:23 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:32 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:32 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Sun 03/09/2014 07:33:33 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Sun 03/09/2014 07:33:33 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:34 AM : [ Time] 07:33:45 0(0) Sun 03/09/2014 07:33:34 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 49 30 RINPUT (30) Sun 03/09/2014 07:33:34 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 03/09/2014 07:33:37 AM : [ 23 8D 7C 2] ST 0 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 4] ST 0 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 5] ST 255 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 6] ST 255 The above events were the result of the query test program sequence that ran at 7:33:22, i.e. “the related one at 7:23:22†2014/03/09, 07:33:22, 1-Initiate Query Test ran True If needed, I can upload the complete log file and event viewer trace if you think I might have missed something. Thanks again. Link to comment
LeeG Posted March 10, 2014 Share Posted March 10, 2014 There are three Queries each of which have the same response. The second Query has a duplicate response record with a Hops Left=0. This is same situation seen with I/O Lincs and the duplicate message has the correct command code and same indication regarding which relays are On. Query 1 of Relays – relay 2 & 4 On Sun 03/09/2014 07:33:12 AM : [ Time] 07:33:23 0(0) Sun 03/09/2014 07:33:14 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:33:14 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:18 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:18 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Query 2 of Relays – relay 2 & 4 On Sun 03/09/2014 07:33:23 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:33:23 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Query 3 of Relays – relay 2 & 4 On Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:32 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:32 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Query of Inputs Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Sun 03/09/2014 07:33:33 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Sun 03/09/2014 07:33:33 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:34 AM : [ Time] 07:33:45 0(0) Sun 03/09/2014 07:33:34 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 49 30 RINPUT (30) Sun 03/09/2014 07:33:34 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 03/09/2014 07:33:37 AM : [ 23 8D 7C 2] ST 0 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 4] ST 0 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 5] ST 255 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 6] ST 255 The Query of Inputs has a duplicate Hops Left=0 response but the command code is correct and both responses show the same Input pattern. If the event trace is not too large posting that would be a good idea. I’d like to see if any of the duplicate messages exist with bad command codes. Link to comment
johnnyt Posted March 10, 2014 Author Share Posted March 10, 2014 There are three Queries each of which have the same response. The second Query has a duplicate response record with a Hops Left=0. This is same situation seen with I/O Lincs and the duplicate message has the correct command code and same indication regarding which relays are On. The Query of Inputs has a duplicate Hops Left=0 response but the command code is correct and both responses show the same Input pattern. If the event trace is not too large posting that would be a good idea. I’d like to see if any of the duplicate messages exist with bad command codes. Thanks for clarifying the querying. Still, why three queries of the relays and such a long wait to query the input? And why does the following summary update of the relays only occur after the input is queried and over 20 secs after the first query? Sun 03/09/2014 07:33:37 AM : [ 23 8D 7C 2] ST 0 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 4] ST 0 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 5] ST 255 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 6] ST 255 I've attached the log from 1PM 03/08 to 3:35PM 03/09 and the event viewer L3 log from 9PM 03/08 to ~8AM 03/09. Also, the attached screenshot shows how often a problem is caught by my automated testing. The arrow shows the device I chose to track for my post. Logs20140308-20140309.zip Link to comment
LeeG Posted March 11, 2014 Share Posted March 11, 2014 The full event trace shows the problem. The additional Queries of the Relays was caused by a 4 second delay in getting the response from the device. It is a those something is keeping the EZIO8SA from sending a response. On the third Relay Query the response was immediate and the ISY went on to Query the Inputs. This Query Input received two responses. There is a Variable update (marked in Red) and then the ISY adjusts the Relay Status using the Query Input response. Of course the Query Input response does not reflect the actual Relay Status so the Relays are marked with the wrong information. Do not know if this is caused by the extra Query Input response, the Variable being updated, or something else. The next Query Relay returns the actual Relay status which brings the Relay Status back to normal. Sun 03/09/2014 07:33:14 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 - Query Relays Sun 03/09/2014 07:33:14 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:18 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) - Relay 2 & 4 On after 4 second delay Sun 03/09/2014 07:33:18 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:23 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 - Query Relays Sun 03/09/2014 07:33:23 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) - Relay 2 & 4 On after 4 second delay Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 - Query Relays Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:32 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) - Relay 2 & 4 On with no delay Sun 03/09/2014 07:33:32 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 - Query Inputs Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Sun 03/09/2014 07:33:33 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Sun 03/09/2014 07:33:33 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:34 AM : [ Time] 07:33:45 0(0) Sun 03/09/2014 07:33:34 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 49 30 RINPUT (30) Sun 03/09/2014 07:33:34 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 03/09/2014 07:33:35 AM : [VAR 2 58 ] 1887 Sun 03/09/2014 07:33:37 AM : [ 23 8D 7C 2] ST 0 - Relay status changed based on the Query Input response Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 4] ST 0 - marks Relay 2 & 4 Off even though Relays 2 & 4 On Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 5] ST 255 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 6] ST 255 Link to comment
ELA Posted March 11, 2014 Share Posted March 11, 2014 There is also what appears to be a duplicate query message at 07:33:28 with Max Hops=3, Hops Left=0 in an environment that's otherwise pretty reliable comms-wise. I'm also hoping without the dual band PLM in play, it's easy to pinpoint the problem for me to tell Smartnenit. Any suggestions? Hello johnnyt, I tried to sift through all the data you have posted. One thing stood out to me. The comment about an "otherwise pretty reliable comms-wise". The following is based on a quick review. If I miss read, or you feel it does not pertain then please ignore. It seems in several posts that you are getting very long delays in the response message. You cannot only look at the Max hops and hops remaining, you also need to look at the time delay. Such a long delay often indicates that retries are occurring at the Insteon device level. I have often observed strange occurrences when the communications gets marginal and retries are occurring. You often see several missed attempts and then you finally get a response on the max =3 ,remaining =2, on the last retry, thus the time delay. I would recommend that you ignore status for a bit and concentrate on something simple like a "get engine" request. Log as much data as possible and observe if you get excessive delays in the responses. If so then focus on how to get a more reliable communications to that device location. Link to comment
johnnyt Posted March 11, 2014 Author Share Posted March 11, 2014 ELA, Thanks for trying to sift through my troubles and for the suggestion. I just ran about 4 query insteon engine commands against node 1 of the EZIO8SA. On the last one I first initiated my query testing "suite" with a 10 second delay before it queries the EZIO8SA. The thinking was that I would create a collision. The results were all similar and I was surprised to find no trace of the device query from my program within the query engine trace. I'm guessing the regular query command was trumped by the query insteon engine command. FWIW, I've attached the result of the last one here. I'll try again at other times of the day and look for other ways to hammer the insteon network when I do it. I presume there's no way to call for a "query insteon engine" from within a program. Otherwise I would add that into the mix. Would a scene test work? I would mention that the only things on the circuit are 3 IO Lincs and the EZIO8SA on a 14 AWG power bar that doesn't have any built in filtering. In the past I had an HRV, chest freezer and 24VAC power supply that were found to cause problems despite being on a 15A ACT filter but they were moved to another circuit. Sun 03/09/2014 07:33:14 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 - Query Relays Sun 03/09/2014 07:33:14 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:18 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) - Relay 2 & 4 On after 4 second delay Sun 03/09/2014 07:33:18 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:23 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 - Query Relays Sun 03/09/2014 07:33:23 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) - Relay 2 & 4 On after 4 second delay Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:28 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 4F 0A IOCTL (0A) Sun 03/09/2014 07:33:28 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 4F 02 - Query Relays Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 4F 02 06 IOCTL (QUERY) Sun 03/09/2014 07:33:32 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 4F 0A IOCTL (0A) - Relay 2 & 4 On with no delay Sun 03/09/2014 07:33:32 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:32 AM : [iNST-TX-I1 ] 02 62 23 8D 7C 0F 49 00 - Query Inputs Sun 03/09/2014 07:33:32 AM : [iNST-ACK ] 02 62 23.8D.7C 0F 49 00 06 RINPUT (00) Sun 03/09/2014 07:33:33 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 2B 49 30 RINPUT (30) Sun 03/09/2014 07:33:33 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 03/09/2014 07:33:34 AM : [ Time] 07:33:45 0(0) Sun 03/09/2014 07:33:34 AM : [iNST-SRX ] 02 50 23.8D.7C 24.1B.FE 23 49 30 RINPUT (30) Sun 03/09/2014 07:33:34 AM : [std-Direct Ack] 23.8D.7C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 03/09/2014 07:33:35 AM : [VAR 2 58 ] 1887 Sun 03/09/2014 07:33:37 AM : [ 23 8D 7C 2] ST 0 - Relay status changed based on the Query Input Response Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 4] ST 0 - marks Relay 2 & 4 Off even though Relays 2 & 4 On Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 5] ST 255 Sun 03/09/2014 07:33:38 AM : [ 23 8D 7C 6] ST 255 I'm sure I must be missing something so I'd like to tell you what I see when I look at the event viewer entries hoping you can help. I see that ISY sends out a query for the relays, gets a response 4 secs later, considers that too long so waits 5 secs and sends another query for relays. Rinse. Repeat. Until it gets a response quickly enough and then it queries the input. In this case, the response comes twice - perhaps a remnant from a previous query because of comm problems that don't show up in the max hops / remain hops - and ISY confuses it (or the variable that got updated while this is happening) as being a change in status for 4 of the 8 relays with relays 2 & 4 the wrong status. Were relays 5 & 6 ON all along or is that also a reverse status? I also noticed that an output status response came twice too (that one with an indication of a comms issue) but it was handled okay. I see this flow as problematic but figure I must be misinterpreting what's happening. Thanks again for your help. Link to comment
Recommended Posts