Unexpected Query All results - plus a nasty surprise...

[johnnyt]

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]

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]

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]

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]

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]

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]

 

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]

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]

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]

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]

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]

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]

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]

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