johnnyt Posted February 1, 2014 Posted February 1, 2014 I'm finding the 3 AM "query all" regularly returns unexpected statuses that are either likely false or confirmed false. In researching this, I also uncovered a nasty little surprise. More on that in a minute. First, looking back over the past two nights, starting with last night / this morning, the following events were recorded at 3AM: Scene:My Lighting Status Query Fri 2014/01/31 03:00:03 AM Program Log Main Floor / Front Inside Light Status 0% Fri 2014/01/31 03:00:37 AM System Log Bedrooms / Master Bedroom Ceiling Light Status 100% Fri 2014/01/31 03:00:46 AM System Log This had a downstream effect because I have a program that calls a night lighting scene (a bedroom floor lamp to about 20%) after the bedroom ceiling light has been on for 1 hour. So shortly after 4AM the last 2 nights, our bedroom floor lamp has gone ON to 20%. The Front Inside Light being at 0% should not have been a surprise to ISY as that light had been turned off several hours earlier. Similarly, the Master Ceilling Light had been turned OFF long before, and I can confirm that it was OFF all night or it would have woken me up / kept me from sleeping. The OFF events of earlier in the night are shown as having been picked up by ISY in these log entries: Bedrooms / Master Bedroom Ceiling Light Status 0% Thu 2014/01/30 08:34:32 PM System Log Main Floor / Front Inside Light Fade Start 0 Thu 2014/01/30 08:36:36 PM Program Log Here's an excerpt from the error log around 3AM. Fri 2014/01/31 03:00:49 AM System -170001 [uDSockets] HTTP:20 error:6 Fri 2014/01/31 03:00:52 AM System -10 n/a Fri 2014/01/31 03:00:54 AM System -170001 [uDSockets] HTTP:20 error:6 Fri 2014/01/31 03:00:59 AM System -170001 [uDSockets] HTTP:20 error:6 Fri 2014/01/31 03:01:04 AM System -170001 [uDSockets] HTTP:20 error:6 Fri 2014/01/31 03:01:09 AM System -170001 [uDSockets] HTTP:20 error:6 Fri 2014/01/31 03:01:14 AM System -170001 [uDSockets] HTTP:20 error:6 Fri 2014/01/31 03:01:19 AM System -170001 [uDSockets] HTTP:20 error:6 I was not able to find error -170001 on the wiki but found that error -10 means "UNEXPECTED DEVICE RESPONSE ". Of course in response to the 3AM query that could have been about any of many devices. Similarly, this happened last night and I can confirm that neither of the lights reported as ON were ON. Scene:My Lighting Status Query Sat 2014/02/01 03:00:03 AM Program Log Bedrooms / Master Bedroom Ceiling Light Status 100% Sat 2014/02/01 03:00:45 AM System Log Bedrooms / Boys Bedrm Ceiling Light Status 26% Sat 2014/02/01 03:00:52 AM System Log Bedrooms / Master Bedroom Ceiling Light Status 0% Fri 2014/01/31 07:50:34 PM System Log Bedrooms / Boys Bedrm Ceiling Light Status 0% Fri 2014/01/31 07:50:50 PM System Log Error Log around 3AM: Sat 2014/02/01 03:00:10 AM System -10 n/a Below are more 3AM query all log entries. 1D.5B.9E is a v41 IOLinc, which very frequently responds to being queried (causing programs to run when they shouldn't or don't need to) - I believe this to be a flaw in this particular IO Linc. I have 2 v41 IOLincs and 9 v36 IO Lincs and only this one behaves this way. Front Inside Light is a frequent repeat offender Scene:My Lighting Status Query Fri 2014/01/17 03:00:00 AM Program Log 1D.5B.9E-Sensor Status 0% Fri 2014/01/17 03:00:24 AM System Log 1D.5B.9E-Relay Status 0% Fri 2014/01/17 03:00:25 AM System Log 1D.5B.9E-Sensor Status 100% Fri 2014/01/17 03:00:25 AM System Log Main Floor / Front Inside Light Status 0% Fri 2014/01/17 03:00:27 AM System Log Scene:My Lighting Status Query Sat 2014/01/18 03:00:00 AM Program Log 1D.5B.9E-Sensor Status 0% Sat 2014/01/18 03:00:25 AM System Log 1D.5B.9E-Relay Status 0% Sat 2014/01/18 03:00:25 AM System Log 1D.5B.9E-Sensor Status 100% Sat 2014/01/18 03:00:26 AM System Log Main Floor / Front Inside Light Status 0% Sat 2014/01/18 03:00:28 AM System Log Scene:My Lighting Status Query Sun 2014/01/19 03:00:01 AM Program Log 1D.5B.9E-Sensor Status 0% Sun 2014/01/19 03:00:25 AM System Log 1D.5B.9E-Sensor Status 100% Sun 2014/01/19 03:00:26 AM System Log I'll stop there but these kinds of unexpected (to me) responses are a daily occurrence in the life of this log file. Now to the nasty surprise I uncovered. Looking back at all my "query all's" I noticed this little gem that was not initiated by me: 0 null Sun 2014/01/19 04:41:45 PM System Start Scene:My Lighting Status Query Sun 2014/01/19 04:42:29 PM System Log this was followed by about 3 mins and 250 status reporting entries in the log (which is more than the ~170 nodes I have), followed by a second "query all" with more responses Scene:My Lighting Status Query Sun 2014/01/19 04:45:13 PM Program Log X10 G9 Status = On ( Sun 2014/01/19 04:45:14 PM System Log X10 Transceiver Module Outlet Status 100% Sun 2014/01/19 04:45:14 PM System Log 15 B9 70 2 Status 0% Sun 2014/01/19 04:45:24 PM System Log 1D.5B.9E-Relay Status 100% Sun 2014/01/19 04:45:49 PM System Log Wouldn't ISY already know this from the query all just before? Unfortunately my error log doesn't go that far back (I have been doing a lot of level 3 event viewing lately so the error log is full) Below is what was happening just before the crash. The "web" entries indicates I was doing some testing of my new EZIO8SA at the time. I suspect this ISY crash only looked like a GUI crash to me, which happens with some regularity. And because at over 700 programs, 200 variables and 172 nodes the GUI takes so long to load for me, I believe I didn't notice / clue in to the fact that ISY had crashed so didn't know until now that's what happened. 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Sun 2014/01/19 04:35:47 PM Program Log Scene:1-MISC (Non Lighting) / HVAC / HVAC Sensors Status Query Sun 2014/01/19 04:35:53 PM Program Log 1-MISC (Non Lighting) / HVAC / Sensor - Heat Off - Office Da Status 100% Sun 2014/01/19 04:35:53 PM System Log 50405 Status Query Sun 2014/01/19 04:36:13 PM Program Log Main Floor / Laundry Room Motion-Sensor Status 100% Sun 2014/01/19 04:36:56 PM System Log Main Floor / Laundry Room Motion-Sensor Status 0% Sun 2014/01/19 04:37:32 PM System Log Z-Unused Relay Sensors / Relay for Fan OFF Sensor Off Sun 2014/01/19 04:38:00 PM Web Log Z-Unused Relay Sensors / Relay for Fan OFF Sensor Status 0% Sun 2014/01/19 04:38:03 PM System Log 1-MISC (Non Lighting) / HVAC / Office Damper-EZIO.4 Off Sun 2014/01/19 04:38:21 PM Web Log 1-MISC (Non Lighting) / HVAC / Office Damper-EZIO.4 Status 0% Sun 2014/01/19 04:38:25 PM System Log Z-Unused Relay Sensors / Relay for Fan OFF Sensor Status Query Sun 2014/01/19 04:38:35 PM Program Log Z-Dusk and Low Bat Sensors / Laundry Room Dusk-Dawn Status 0% Sun 2014/01/19 04:38:38 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 On 255 Sun 2014/01/19 04:38:55 PM Program Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Error 1 Sun 2014/01/19 04:38:59 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Sun 2014/01/19 04:38:59 PM System -2 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Error 0 Sun 2014/01/19 04:39:00 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 100% Sun 2014/01/19 04:39:00 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Sun 2014/01/19 04:39:25 PM Web Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 100% Sun 2014/01/19 04:39:26 PM System Log Bedrooms / Boys Bedroom Table Lamp Status Query Sun 2014/01/19 04:40:00 PM Program Log 0 null Sun 2014/01/19 04:41:45 PM System Start What's going on with the query all responses, and is there any clue in the above as to why ISY crashed?
LeeG Posted February 1, 2014 Posted February 1, 2014 The QueryAll Program exists to correct any inaccurate device status resulting from missed Insteon messages. In general when the QueryAll changes a device status it means there are comm issues where a state change was missed in earlier 24 hour period. The I/O Linc change in status can be the above or it can be duplicate Insteon messages affecting the Query analysis because the I/O Linc requires two commands to determine the relay and sensor status. For an I/O Linc that always changes status at 3AM it could also be it is running with Trigger Reverse set. This option reverses the Sensor state commands as the Sensor changes state but the option does not affect the Query response. It means the Sensor state will change at 3AM when the Trigger Reverse option is used. Already discussed the EZIO8SA. Need to see a LEVEL 3 trace.
johnnyt Posted February 2, 2014 Author Posted February 2, 2014 The QueryAll Program exists to correct any inaccurate device status resulting from missed Insteon messages. In general when the QueryAll changes a device status it means there are comm issues where a state change was missed in earlier 24 hour period. The I/O Linc change in status can be the above or it can be duplicate Insteon messages affecting the Query analysis because the I/O Linc requires two commands to determine the relay and sensor status. For an I/O Linc that always changes status at 3AM it could also be it is running with Trigger Reverse set. This option reverses the Sensor state commands as the Sensor changes state but the option does not affect the Query response. It means the Sensor state will change at 3AM when the Trigger Reverse option is used. Already discussed the EZIO8SA. Need to see a LEVEL 3 trace. Thanks for the reply, LeeG. Am, not worried about the EZIO8SA here unless querying it caused or contributed to ISY crashing. I have another post on the EZIO8SA and will update that post when I have more data from some programs I added yesterday to do a second round of query tests when the status is not as expected. For this problem, I left the event viewer at level 3 overnight last night and the following two unexpected statuses were reported during the 3AM query: Scene:My Lighting Status Query Sun 2014/02/02 03:00:03 AM Program Log Main Floor / Front Inside Light Status 0% Sun 2014/02/02 03:00:29 AM System Log Main Floor / Front Light Companion Sw Status 100% Sun 2014/02/02 03:00:30 AM System Log Below is the event viewer data: Front Inside Light = 16.10.F6 Front Light Companion SW = 0F.D4.91 Sun 02/02/2014 03:00:22 AM : [iNST-TX-I1 ] 02 62 16 10 F6 0F 19 00 Sun 02/02/2014 03:00:22 AM : [iNST-ACK ] 02 62 16.10.F6 0F 19 00 06 LTSREQ (LIGHT) Sun 02/02/2014 03:00:22 AM : [iNST-SRX ] 02 50 16.10.F6 24.1B.FE 27 22 00 (00) Sun 02/02/2014 03:00:22 AM : [std-Direct Ack] 16.10.F6-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Sun 02/02/2014 03:00:23 AM : [iNST-TX-I1 ] 02 62 0F D4 91 0F 19 00 Sun 02/02/2014 03:00:23 AM : [iNST-ACK ] 02 62 0F.D4.91 0F 19 00 06 LTSREQ (LIGHT) Sun 02/02/2014 03:00:23 AM : [iNST-SRX ] 02 50 0F.D4.91 24.1B.FE 2B 0F FF PING (FF) Sun 02/02/2014 03:00:23 AM : [std-Direct Ack] 0F.D4.91-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 02/02/2014 03:00:23 AM : [iNST-TX-I1 ] 02 62 16 D9 56 0F 19 00 Sun 02/02/2014 03:00:23 AM : [iNST-SRX ] 02 50 0F.D4.91 24.1B.FE 23 0F FF PING (FF) Sun 02/02/2014 03:00:23 AM : [std-Direct Ack] 0F.D4.91-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 02/02/2014 03:00:23 AM : [iNST-ACK ] 02 62 16.D9.56 0F 19 00 06 LTSREQ (LIGHT) Sun 02/02/2014 03:00:24 AM : [iNST-SRX ] 02 50 16.D9.56 24.1B.FE 2B 0A FF LNK-OFF(FF) Sun 02/02/2014 03:00:24 AM : [std-Direct Ack] 16.D9.56-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Did the Front Light Companion Sw respond twice? Both devices had been turned off earlier in the evening with the push of a Front KPL Sleep button. Here are the log entries showing that: Main Floor / FrontKPL.H-Sleep Status 100% Sat 2014/02/01 09:46:02 PM System Log Scene:All ON/OFF Downstairs Off 0 Sat 2014/02/01 09:46:03 PM Program Log Main Floor / Front Light Companion Sw Status 0% Sat 2014/02/01 09:46:03 PM System Log Kitchen / EatingKPL.1 Status 0% Sat 2014/02/01 09:46:03 PM System Log Kitchen / EatingKPL.1 Off 0 Sat 2014/02/01 09:46:06 PM Program Log 30 secs after KPL Sleep Button is pushed, Front Inside Light is turned off, per the program I have: Main Floor / Front Inside Light Fade Start 0 Sat 2014/02/01 09:46:33 PM Program Log Below is the corresponding event viewer data: Front Light Companion SW is part of All ON/OFF Downstairs scene, which I presume is the highlighted address below (in ISY the scene number is 51164) 17.A3.7B is FrontKPL address 18.58.D8 is EatingKPL address Sat 02/01/2014 09:46:04 PM : [iNST-SRX ] 02 50 17.A3.7B 00.00.08 C3 11 00 LTONRR (00) Sat 02/01/2014 09:46:04 PM : [std-Group ] 17.A3.7B-->Group=8, Max Hops=3, Hops Left=0 Sat 02/01/2014 09:46:04 PM : [ 17 A3 7B 8] DON 0 Sat 02/01/2014 09:46:04 PM : [iNST-SRX ] 02 50 17.A3.7B 24.1B.FE 41 11 08 LTONRR (08) Sat 02/01/2014 09:46:04 PM : [std-Cleanup ] 17.A3.7B-->ISY/PLM Group=8, Max Hops=1, Hops Left=0 Sat 02/01/2014 09:46:04 PM : [iNST-DUP ] Previous message ignored. Sat 02/01/2014 09:46:04 PM : [ 17 A3 7B 8] ST 255 Sat 02/01/2014 09:46:04 PM : [iNST-TX-I1 ] 02 62 00 00 14 CF 13 00 Sat 02/01/2014 09:46:04 PM : [iNST-ACK ] 02 62 00.00.14 CF 13 00 06 LTOFFRR(00) Sat 02/01/2014 09:46:04 PM : [ F D4 91 1] ST 0 Sat 02/01/2014 09:46:04 PM : [ 18 58 D8 1] ST 0 Sat 02/01/2014 09:46:07 PM : [iNST-TX-I1 ] 02 62 18 58 D8 0F 13 00 Sat 02/01/2014 09:46:07 PM : [iNST-ACK ] 02 62 18.58.D8 0F 13 00 06 LTOFFRR(00) Sat 02/01/2014 09:46:08 PM : [VAR 2 56 ] 34 Sat 02/01/2014 09:46:08 PM : [iNST-SRX ] 02 50 18.58.D8 24.1B.FE 2B 13 00 LTOFFRR(00) Sat 02/01/2014 09:46:08 PM : [std-Direct Ack] 18.58.D8-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 02/01/2014 09:46:08 PM : [ Time] 21:46:07 4(0) and 30 secs later: Sat 02/01/2014 09:46:34 PM : [iNST-TX-I1 ] 02 62 16 10 F6 0F 17 00 Sat 02/01/2014 09:46:34 PM : [iNST-ACK ] 02 62 16.10.F6 0F 17 00 06 LTMCON (DOWN) Sat 02/01/2014 09:46:34 PM : [VAR 2 68 ] 3 Sat 02/01/2014 09:46:34 PM : [iNST-SRX ] 02 50 16.10.F6 24.1B.FE 23 17 00 LTMCON (DOWN) Sat 02/01/2014 09:46:34 PM : [std-Direct Ack] 16.10.F6-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 There are no other entries for those devices in either the log or the event viewer between 9:46 PM and 3 AM, and the Front Light was not on when I got up this morning (and no program would have turned it off if something had turned it on so it would have been on when I got up.)
LeeG Posted February 2, 2014 Posted February 2, 2014 Sun 02/02/2014 03:00:23 AM : [iNST-TX-I1 ] 02 62 0F D4 91 0F 19 00 Sun 02/02/2014 03:00:23 AM : [iNST-ACK ] 02 62 0F.D4.91 0F 19 00 06 LTSREQ (LIGHT) Sun 02/02/2014 03:00:23 AM : [iNST-SRX ] 02 50 0F.D4.91 24.1B.FE 2B 0F FF PING (FF) Sun 02/02/2014 03:00:23 AM : [std-Direct Ack] 0F.D4.91-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 02/02/2014 03:00:23 AM : [iNST-TX-I1 ] 02 62 16 D9 56 0F 19 00 Sun 02/02/2014 03:00:23 AM : [iNST-SRX ] 02 50 0F.D4.91 24.1B.FE 23 0F FF PING (FF) Sun 02/02/2014 03:00:23 AM : [std-Direct Ack] 0F.D4.91-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 02/02/2014 03:00:23 AM : [iNST-ACK ] 02 62 16.D9.56 0F 19 00 06 LTSREQ (LIGHT) Sun 02/02/2014 03:00:24 AM : [iNST-SRX ] 02 50 16.D9.56 24.1B.FE 2B 0A FF LNK-OFF(FF) Sun 02/02/2014 03:00:24 AM : [std-Direct Ack] 16.D9.56-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Did the Front Light Companion Sw respond twice? Yes it did. However both responses indicate the device is On. The Front Inside Light = 16.10.F6 responded only once and it showed the device as Off. There is a problem with the Fade Down of 16.10.F6. Perhaps it was later in the trace but there is no Fade Stop to end the Fade Down. Issuing a Fade Up/Down without issuing a Fade Stop leaves the device in a bad state. That situation should not happen and cannot happen with hardware as there is always a Fade Stop when a paddle/button is released. The device may not react to the next command as expected. Here is a trace of a Fade Down followed by a Fade Stop. Note that the ISY does not mark the Status of the device until the Fade Stop is issued as the timing between the Fade Down and the Fade Stop establish the On Level (approx). Without the Fade Stop the ISY does not know the Status of the device. Sun 02/02/2014 05:50:57 PM : [iNST-ACK ] 02 62 1D.23.6B 0F 17 00 06 LTMCON (DOWN) Sun 02/02/2014 05:50:57 PM : [iNST-SRX ] 02 50 1D.23.6B 22.80.0B 2B 17 00 LTMCON (DOWN) Sun 02/02/2014 05:50:57 PM : [std-Direct Ack] 1D.23.6B-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 02/02/2014 05:50:58 PM : [iNST-TX-I1 ] 02 62 1D 23 6B 0F 18 00 Sun 02/02/2014 05:50:58 PM : [iNST-ACK ] 02 62 1D.23.6B 0F 18 00 06 LTMCOFF(00) Sun 02/02/2014 05:50:58 PM : [iNST-SRX ] 02 50 1D.23.6B 22.80.0B 2B 18 00 LTMCOFF(00) Sun 02/02/2014 05:50:58 PM : [std-Direct Ack] 1D.23.6B-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 02/02/2014 05:50:58 PM : [ 1D 23 6B 1] ST 71 ------------------------------------------------------------------------------------------------- The comm. from 17.A3.7B is also at the limit of function with a Hops Left=0 when button 8 was pressed. It worked this time but it might not work each time. Sat 02/01/2014 09:46:04 PM : [iNST-SRX ] 02 50 17.A3.7B 00.00.08 C3 11 00 LTONRR (00) Sat 02/01/2014 09:46:04 PM : [std-Group ] 17.A3.7B-->Group=8, Max Hops=3, Hops Left=0 Sat 02/01/2014 09:46:04 PM : [ 17 A3 7B 8] DON 0
Big517 Posted February 2, 2014 Posted February 2, 2014 I have roughly 100 zwave devices and spend a good 15 seconds clicking off all the errors for each device only to find that the isy has error free communication on regular use so the errors are false. Maybe the timeout is at to soon? There is no heal option yet either so routing is a mystery to me also.
johnnyt Posted February 3, 2014 Author Posted February 3, 2014 There is a problem with the Fade Down of 16.10.F6. Perhaps it was later in the trace but there is no Fade Stop to end the Fade Down. Issuing a Fade Up/Down without issuing a Fade Stop leaves the device in a bad state. That situation should not happen and cannot happen with hardware as there is always a Fade Stop when a paddle/button is released. The device may not react to the next command as expected.Thanks. That would explain why this one happens daily without fail. I changed the program to send an OFF. I don't actually remember setting it to do a Fade Down but that's what was there. Probably did it to get a nice slow off since the local ramp rate is not that slow, but maybe I'll just create a scene to do it. The comm. from 17.A3.7B is also at the limit of function with a Hops Left=0 when button 8 was pressed. It worked this time but it might not work each time. I'm not going to notice / look for a companion switch being off when it should be on given that no load is attached to it so for this device I'm not too worried about it. For other things though, like my bedroom ceiling light (original post), this issue is of greater concern. I'll have to watch more closely and, I guess, run more overnight level 3 event viewer and sift through the data as I now think this may explain other misbehavior that I just ignored. For example I've occasionally gotten up in the middle of the night to find lights on downstairs and just turned them off without looking into it.
Xathros Posted February 3, 2014 Posted February 3, 2014 Now to the nasty surprise I uncovered. Looking back at all my "query all's" I noticed this little gem that was not initiated by me: 0 null Sun 2014/01/19 04:41:45 PM System Start Scene:My Lighting Status Query Sun 2014/01/19 04:42:29 PM System Log this was followed by about 3 mins and 250 status reporting entries in the log (which is more than the ~170 nodes I have), followed by a second "query all" with more responses This directly follows a system startup. Have you looked for "Query at restart" under the system config: -Xathros
johnnyt Posted February 4, 2014 Author Posted February 4, 2014 Xathros, thanks for the screenshot. Although I was confused about the two query all's when I expected only one, it dawned on me from your screenshot why that happened. I have "Catch up schedules at Restart". See screenshot below. I guess if I wanted to prevent the query all from running a second time after a restart, I would have to either schedule it for 11:59:59 PM since the catch up is from 00:00:00 the day of the restart. That or turn off "Query at restart" and schedule the query all for shortly after midnight so a restart before 3AM - although unlikely - won't miss running it. The second thing that confused me was the fact that a second query all 3 minutes after the first returned some different statuses. While I know the 1D.5B.9E-Relay is my problematic v41 IO Linc that always responds (and is neither trigger reversed, nor in momentary mode), the status of the other devices should have been the same for the two queries. Scene:My Lighting Status Query Sun 2014/01/19 04:45:13 PM Program Log X10 G9 Status = On ( Sun 2014/01/19 04:45:14 PM System Log X10 Transceiver Module Outlet Status 100% Sun 2014/01/19 04:45:14 PM System Log 15 B9 70 2 Status 0% Sun 2014/01/19 04:45:24 PM System Log 1D.5B.9E-Relay Status 100% Sun 2014/01/19 04:45:49 PM System Log
Xathros Posted February 4, 2014 Posted February 4, 2014 jonnynt- Have you seen what LeeG has found Re IOLinc queries and duplicate responses? The IOLinc is queried twice - once for the relay and once for the sensor. In some cases, the ISY reads a duplicate response from the first query as a reply to the second. It's a timing issue and may be related to insteon messages taking multiple routes back to the PLM (Powerline and RF via dualband devices). Yes, I know the IOLinc is not dualband but it is possible for messages that originate on the power line to be retransmitted and received via access points and other dual band devices. Not sure that this is any help - just a possible explanation for your issue. -Xathros
johnnyt Posted February 4, 2014 Author Posted February 4, 2014 Have you seen what LeeG has found Re IOLinc queries and duplicate responses? Yes, I did, and it explains (or likely explains) the situation when the response is related to IO Lincs. I also have an explanation for the Front Inside Light That leaves the following unexplained: From my original post: Scene:My Lighting Status Query Sun 2014/02/02 03:00:03 AM Program Log Main Floor / Front Light Companion Sw Status 100% Sun 2014/02/02 03:00:30 AM System Log From my more recent post: Scene:My Lighting Status Query Sun 2014/01/19 04:45:13 PM Program Log X10 G9 Status = On ( Sun 2014/01/19 04:45:14 PM System Log X10 Transceiver Module Outlet Status 100% Sun 2014/01/19 04:45:14 PM System Log Now let me add to that what happened for the query all the night before last: Scene:My Lighting Status Query Mon 2014/02/03 03:00:03 AM Program Log Kitchen / Family Rm Wall Light Status 0% Mon 2014/02/03 03:00:24 AM System Log Kitchen / Kitchen Sink Area Light Status 0% Mon 2014/02/03 03:00:24 AM System Log Main Floor / Front Light Companion Sw Status 0% Mon 2014/02/03 03:00:31 AM System Log Kitchen / Bookcase Lights Status 0% Mon 2014/02/03 03:00:45 AM System Log X10 G9 Mon 2014/02/03 03:00:47 AM Program Log X10 G9 Status Request (10) Mon 2014/02/03 03:00:47 AM Program Log All the above, except for the X10 devices, were turned off by the All ON/OFF Downstairs scene earlier that evening. Here's the log showing that event Main Floor / FrontKPL.H-Sleep Status 100% Mon 2014/02/03 10:50:49 PM System Log Scene:All ON/OFF Downstairs Off 0 Mon 2014/02/03 10:50:50 PM Program Log Main Floor / Front Light Companion Sw Status 0% Mon 2014/02/03 10:50:50 PM System Log If I read this right, the only device that was turned off was Front Light Companion Sw and all the other devices in the scene were already OFF and therefore not logged. (The scene has 10 devices in it.) Other than for X10 devices, a common thread so far for the unexpected/unexplained statuses seems to be devices that are turned off by the scene All ON/OFF Downstairs. I suppose the other thing left unexplained is why ISY rebooted itself but I guess that really should be a separate thread (that I'm going to pass on at this point since I didn't catch it when it happened and there's little to go on other than what I've provided in my original post.)
johnnyt Posted February 4, 2014 Author Posted February 4, 2014 a common thread so far for the unexpected/unexplained statuses seems to be devices that are turned off by the scene All ON/OFF Downstairs. wait, I take that back. The device that made me look into this (master bedroom ceiling light) and the boys bedroom ceiling light are not part of that scene.
LeeG Posted February 4, 2014 Posted February 4, 2014 The devices in an ISY Scene On/Off are marked according to how they should react, not how they actually reacted. There are no ACKs associated with an ISY Scene being turned On or Off. Suggest running a Scene Test with the All On/Off Scene with the event viewer running at LEVEL 3. That will give some indication of the general reliability of the devices associated with that Scene. From one of the earlier traces one of the KeypadLincs has poor communication with the PLM with a Hops Left=0 from a button press. There may be other areas the Scene Test will show.
johnnyt Posted February 5, 2014 Author Posted February 5, 2014 The devices in an ISY Scene On/Off are marked according to how they should react, not how they actually reacted. There are no ACKs associated with an ISY Scene being turned On or Off. Why then does the event log have a status entry for Front Light Companion Sw, one of the devices in the scene, right after calling that scene? Scene:All ON/OFF Downstairs Off 0 Mon 2014/02/03 10:50:50 PM Program Log Main Floor / Front Light Companion Sw Status 0% Mon 2014/02/03 10:50:50 PM System Log
LeeG Posted February 5, 2014 Posted February 5, 2014 That entry means the ISY thinks the device was On and the Scene turned it Off. All device changes marked after a Scene On or Off are what the ISY believes should happen based on the Scene definition. Of course a Scene Off will mark any device as Off the ISY currently believes is not Off when the Scene Off is issued. The Scene Test uses a different PLM command so there are actual device responses for a Scene Test
Recommended Posts