apostolakisl

Is there a single organized write-up on all the jargon contained in these event logs? I would really prefer to be able to interpret this stuff myself and all I can ever find are tidbits of info about how to interpret the language, never a comprehensive write-up.

Lee, So we have established that the PLM/ISY has received the "off" signal, and sent an acknowledgement, but the switch didn't receive it so it sent a second "off" signal thinking the first didn't get through. So we know that at least some of the time, 1 hop isn't enough to get from PLM to Switch. How about the opposite, do we know how many hops it is taking from Switch to PLM? It obviously tries at least twice if it doesn't get an ack. Would it try more than twice? Would the "1" after "DOF" indicate that this is try number 2 and if there were a third try it would put a "2" there? I am trying to figure out if one hop is always enough to go from switch to PLM. If so, why isn't one hop enough to get back? This morning I had a heck of time with it. It took many tries to get it to stay off. Fri 9/30/2011 6:53:15 AM : [iNST-SRX ] 02 50 16.43.BC 00.00.01 C7 13 00 LTO FFRR(00) Fri 9/30/2011 6:53:15 AM : [standard-Group][16.43.BC-->Group=1] Max Hops=3, Hops Left=1 Fri 9/30/2011 6:53:15 AM : [ 16 43 BC 1] DOF 0 Fri 9/30/2011 6:53:15 AM : [ 16 43 BC 1] ST 0 Fri 9/30/2011 6:53:15 AM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 41 13 01 LTO FFRR(01) Fri 9/30/2011 6:53:15 AM : [standard-Cleanup][16.43.BC-->ISY/PLM Group=1] Max Hop s=1, Hops Left=0 Fri 9/30/2011 6:53:16 AM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 42 13 01 LTO FFRR(01) Fri 9/30/2011 6:53:16 AM : [standard-Cleanup][16.43.BC-->ISY/PLM Group=1] Max Hop s=2, Hops Left=0 Fri 9/30/2011 6:53:16 AM : [ 16 43 BC 1] DOF 1 Fri 9/30/2011 6:53:16 AM : [iNST-ACK ] 02 62 16.43.BC 0F 11 3F 06 LTO NRR (3F) Fri 9/30/2011 6:53:17 AM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 27 11 3F LTO NRR (3F) Fri 9/30/2011 6:53:17 AM : [standard-Direct Ack][16.43.BC-->ISY/PLM Group=0] Max Hops=3, Hops Left=1 Fri 9/30/2011 6:53:17 AM : [ 16 43 BC 1] ST 63 Fri 9/30/2011 6:53:20 AM : [iNST-SRX ] 02 50 16.43.BC 00.00.01 C7 13 00 LTO FFRR(00) Fri 9/30/2011 6:53:20 AM : [standard-Group][16.43.BC-->Group=1] Max Hops=3, Hops Left=1 Fri 9/30/2011 6:53:20 AM : [ 16 43 BC 1] DOF 0 Fri 9/30/2011 6:53:20 AM : [ 16 43 BC 1] ST 0 Fri 9/30/2011 6:53:21 AM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 41 13 01 LTO FFRR(01) Fri 9/30/2011 6:53:21 AM : [standard-Cleanup][16.43.BC-->ISY/PLM Group=1] Max Hop s=1, Hops Left=0 Fri 9/30/2011 6:53:21 AM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 42 13 01 LTO FFRR(01) Fri 9/30/2011 6:53:21 AM : [standard-Cleanup][16.43.BC-->ISY/PLM Group=1] Max Hop s=2, Hops Left=0 Fri 9/30/2011 6:53:21 AM : [ 16 43 BC 1] DOF 1 Fri 9/30/2011 6:53:21 AM : [iNST-ACK ] 02 62 16.43.BC 0F 11 3F 06 LTO NRR (3F) Fri 9/30/2011 6:53:22 AM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 27 11 3F LTO NRR (3F) Fri 9/30/2011 6:53:22 AM : [standard-Direct Ack][16.43.BC-->ISY/PLM Group=0] Max Hops=3, Hops Left=1 Fri 9/30/2011 6:53:22 AM : [ 16 43 BC 1] ST 63 Fri 9/30/2011 6:53:22 AM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 20 EE FE (FE) Fri 9/30/2011 6:53:22 AM : [standard-Direct Ack][16.43.BC-->ISY/PLM Group=0] Max Hops=0, Hops Left=0 Fri 9/30/2011 6:53:25 AM : [iNST-SRX ] 02 50 16.43.BC 00.00.01 C3 13 00 LTO FFRR(00) Fri 9/30/2011 6:53:25 AM : [standard-Group][16.43.BC-->Group=1] Max Hops=3, Hops Left=0 Fri 9/30/2011 6:53:25 AM : [ 16 43 BC 1] DOF 0 Fri 9/30/2011 6:53:25 AM : [ 16 43 BC 1] ST 0 Fri 9/30/2011 6:53:25 AM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 41 13 01 LTO FFRR(01) Fri 9/30/2011 6:53:25 AM : [standard-Cleanup][16.43.BC-->ISY/PLM Group=1] Max Hop s=1, Hops Left=0 Fri 9/30/2011 6:53:25 AM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 42 13 01 LTO FFRR(01) Fri 9/30/2011 6:53:25 AM : [standard-Cleanup][16.43.BC-->ISY/PLM Group=1] Max Hop s=2, Hops Left=0 Fri 9/30/2011 6:53:25 AM : [ 16 43 BC 1] DOF 1 Fri 9/30/2011 6:53:26 AM : [iNST-ACK ] 02 62 16.43.BC 0F 11 3F 06 LTO NRR (3F) Fri 9/30/2011 6:53:26 AM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 27 11 3F LTO NRR (3F) Fri 9/30/2011 6:53:26 AM : [standard-Direct Ack][16.43.BC-->ISY/PLM Group=0] Max Hops=3, Hops Left=1 Fri 9/30/2011 6:53:26 AM : [ 16 43 BC 1] ST 63 Fri 9/30/2011 6:53:30 AM : [iNST-SRX ] 02 50 16.43.BC 00.00.01 C3 13 00 LTO FFRR(00) Fri 9/30/2011 6:53:30 AM : [standard-Group][16.43.BC-->Group=1] Max Hops=3, Hops Left=0 Fri 9/30/2011 6:53:30 AM : [ 16 43 BC 1] DOF 0 Fri 9/30/2011 6:53:30 AM : [ 16 43 BC 1] ST 0 Fri 9/30/2011 6:53:30 AM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 41 13 01 LTO FFRR(01) Fri 9/30/2011 6:53:30 AM : [standard-Cleanup][16.43.BC-->ISY/PLM Group=1] Max Hop s=1, Hops Left=0 Fri 9/30/2011 6:53:30 AM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 42 13 01 LTO FFRR(01) Fri 9/30/2011 6:53:30 AM : [standard-Cleanup][16.43.BC-->ISY/PLM Group=1] Max Hop s=2, Hops Left=0 Fri 9/30/2011 6:53:30 AM : [ 16 43 BC 1] DOF 1 Fri 9/30/2011 6:53:30 AM : [iNST-ACK ] 02 62 16.43.BC 0F 11 3F 06 LTO NRR (3F) Fri 9/30/2011 6:53:31 AM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 27 11 3F LTO NRR (3F) Fri 9/30/2011 6:53:31 AM : [standard-Direct Ack][16.43.BC-->ISY/PLM Group=0] Max Hops=3, Hops Left=1 Fri 9/30/2011 6:53:31 AM : [ 16 43 BC 1] ST 63 Fri 9/30/2011 6:53:35 AM : [iNST-SRX ] 02 50 16.43.BC 00.00.01 C7 13 00 LTO FFRR(00) Fri 9/30/2011 6:53:35 AM : [standard-Group][16.43.BC-->Group=1] Max Hops=3, Hops Left=1 Fri 9/30/2011 6:53:35 AM : [ 16 43 BC 1] DOF 0 Fri 9/30/2011 6:53:35 AM : [ 16 43 BC 1] ST 0 Fri 9/30/2011 6:53:35 AM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 41 13 01 LTO FFRR(01) Fri 9/30/2011 6:53:35 AM : [standard-Cleanup][16.43.BC-->ISY/PLM Group=1] Max Hop s=1, Hops Left=0

Lee, thanks for the insight. I don't really know where to go from here. The ISY has a basically instant response to button presses of these devices as I watch the console or if I do querries. I don't know why the com would be so quick and error free from device to PLM to ISY but not from PLM to device. The problem barely existed prior to upgrading my firmware, so I don't know what to make of that. The PLM is 2 years old. The problem exists on every device that I have the program running on. I assume that means it actually exists on every device, it just doesn't cause a problem unless it has this program. And why does it list max hops as 1, 2, or 3 at different times? Does the max hop count mean that it quits repeating after 1, 2, or 3 hops? Why would it limit itself to 1 hop max ever?

OK, here they are with all the extra detail. You can see the "DOF 1" in there a little over half way down which is the erroneous "off" signal that put the light to 25% unexpectedly. Thu 9/29/2011 4:51:29 PM : [ 16 43 BC 1] DON 0 Thu 9/29/2011 4:51:29 PM : [ 16 43 BC 1] ST 137 Thu 9/29/2011 4:51:30 PM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 42 11 01 LTONRR (01) Thu 9/29/2011 4:51:30 PM : [standard-Cleanup][16.43.BC-->ISY/PLM Group=1] Max Hops=2, Hops Left=0 Thu 9/29/2011 4:51:31 PM : [iNST-SRX ] 02 50 16.43.BC 00.00.01 C7 13 00 LTOFFRR(00) Thu 9/29/2011 4:51:31 PM : [standard-Group][16.43.BC-->Group=1] Max Hops=3, Hops Left=1 Thu 9/29/2011 4:51:31 PM : [ 16 43 BC 1] DOF 0 Thu 9/29/2011 4:51:31 PM : [ 16 43 BC 1] ST 0 Thu 9/29/2011 4:51:31 PM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 41 13 01 LTOFFRR(01) Thu 9/29/2011 4:51:31 PM : [standard-Cleanup][16.43.BC-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Thu 9/29/2011 4:51:31 PM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 47 13 01 LTOFFRR(01) Thu 9/29/2011 4:51:31 PM : [standard-Cleanup][16.43.BC-->ISY/PLM Group=1] Max Hops=3, Hops Left=1 Thu 9/29/2011 4:51:31 PM : [ 16 43 BC 1] DOF 1 Thu 9/29/2011 4:51:32 PM : [iNST-ACK ] 02 62 16.43.BC 0F 11 3F 06 LTONRR (3F) Thu 9/29/2011 4:51:32 PM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 27 11 3F LTONRR (3F) Thu 9/29/2011 4:51:32 PM : [standard-Direct Ack][16.43.BC-->ISY/PLM Group=0] Max Hops=3, Hops Left=1 Thu 9/29/2011 4:51:32 PM : [ 16 43 BC 1] ST 63 Thu 9/29/2011 4:51:37 PM : [iNST-SRX ] 02 50 16.43.BC 00.00.01 C7 13 00 LTOFFRR(00) Thu 9/29/2011 4:51:37 PM : [standard-Group][16.43.BC-->Group=1] Max Hops=3, Hops Left=1 Thu 9/29/2011 4:51:37 PM : [ 16 43 BC 1] DOF 0 Thu 9/29/2011 4:51:37 PM : [ 16 43 BC 1] ST 0 Thu 9/29/2011 4:51:37 PM : [iNST-SRX ] 02 50 16.43.BC 0F.D5.71 41 13 01 LTOFFRR(01) Thu 9/29/2011 4:51:37 PM : [standard-Cleanup][16.43.BC-->ISY/PLM Group=1] Max Hops=1, Hops Left=0

I will set the event viewer to pick up all the details and post them. But just looking at what I have right now there appears to be a dof signal being sent out that is boggus. The question is where did it come from and how to get rid of it.

Here is another example. This is my other daughter's bedroom and it looks like it did the same thing. I was not the one pushing the buttons. At 7:05:30 you see the second bogus dof (again with the 1 after it) which triggers the program and the light back onto 25%. Thu 9/29/2011 6:29:38 AM : [ 1 6 4 6 1 E 1 ] ST 255 Thu 9/29/2011 6:46:31 AM : [ 1 6 4 2 8 E 1 ] ST 255 Thu 9/29/2011 6:51:26 AM : [ 1 6 4 2 8 E 1 ] ST 0 Thu 9/29/2011 6:51:42 AM : [ 1 6 4 2 8 E 1 ] ST 255 Thu 9/29/2011 6:56:37 AM : [ 1 6 4 2 8 E 1 ] ST 0 Thu 9/29/2011 7:00:03 AM : [ 1 6 4 6 1 E 1 ] ST 0 Thu 9/29/2011 7:00:06 AM : [ 1 6 4 6 1 E 1 ] DON 0 Thu 9/29/2011 7:00:06 AM : [ 1 6 4 6 1 E 1 ] ST 155 Thu 9/29/2011 7:05:29 AM : [ 1 6 4 6 1 E 1 ] DOF 0 Thu 9/29/2011 7:05:29 AM : [ 1 6 4 6 1 E 1 ] ST 0 Thu 9/29/2011 7:05:30 AM : [ 1 6 4 6 1 E 1 ] DOF 1 Thu 9/29/2011 7:05:31 AM : [ 1 6 4 6 1 E 1 ] ST 63 Thu 9/29/2011 7:11:33 AM : [ 1 6 4 2 8 E 1 ] ST 255 Thu 9/29/2011 7:22:05 AM : [ 1 6 4 2 8 E 1 ] ST 0 Thu 9/29/2011 7:37:08 AM : [ 1 6 4 6 1 E 1 ] ST 0 Thu 9/29/2011 6:46:18 AM : [ 1 6 1 B D F 1 ] ST 255 Thu 9/29/2011 6:52:35 AM : [ 1 6 4 6 5 F 1 ] DOF 0 Thu 9/29/2011 6:52:40 AM : [ 1 6 4 6 5 F 1 ] DON 0 Thu 9/29/2011 6:52:40 AM : [ 1 6 4 6 5 F 1 ] ST 255 Thu 9/29/2011 6:52:48 AM : [ 1 6 4 6 5 F 1 ] DOF 0 Thu 9/29/2011 6:52:48 AM : [ 1 6 4 6 5 F 1 ] ST 0 Thu 9/29/2011 7:00:45 AM : [ 1 6 1 B D F 1 ] ST 0 Thu 9/29/2011 7:06:05 AM : [ 1 6 1 B D F 1 ] ST 255 Thu 9/29/2011 8:03:32 AM : [ 1 6 1 B D F 1 ] ST 0

Thanks Lee. I will start running sessions for logging. In the mean time. Thu 9/29/2011 6:29:36 AM : [ 1 6 4 3 B C 1 ] ST 255 Thu 9/29/2011 6:46:31 AM : [ 16 43 C 1 ] ST 255 Thu 9/29/2011 6:51:26 AM : [ 16 43 C 1 ] ST 0 Thu 9/29/2011 6:51:42 AM : [ 16 43 C 1 ] ST 255 Thu 9/29/2011 6:51:44 AM : [ 1 6 4 3 B C 1 ] DOF 0 Thu 9/29/2011 6:51:44 AM : [ 1 6 4 3 B C 1 ] ST 0 Thu 9/29/2011 6:51:44 AM : [ 1 6 4 3 B C 1 ] DOF 1 Thu 9/29/2011 6:51:45 AM : [ 1 6 4 3 B C 1 ] ST 63 Thu 9/29/2011 6:51:49 AM : [ 1 6 4 3 B C 1 ] DOF 0 Thu 9/29/2011 6:51:49 AM : [ 1 6 4 3 B C 1 ] ST 0 Thu 9/29/2011 6:51:57 AM : [ 1 6 4 3 B C 1 ] BMAN 1 Thu 9/29/2011 6:51:59 AM : [ 1 6 4 3 B C 1 ] SMAN 0 Thu 9/29/2011 6:51:59 AM : [ 1 6 4 3 B C 1 ] ST 83 Thu 9/29/2011 6:53:30 AM : [ 1 6 4 3 B C 1 ] DON 0 Thu 9/29/2011 6:53:30 AM : [ 1 6 4 3 B C 1 ] ST 137 Thu 9/29/2011 6:53:31 AM : [ 1 6 4 3 B C 1 ] DOF 0 Thu 9/29/2011 6:53:31 AM : [ 1 6 4 3 B C 1 ] ST 0 Thu 9/29/2011 6:56:37 AM : [ 16 43 C 1 ] ST 0 Thu 9/29/2011 7:11:33 AM : [ 16 43 C 1 ] ST 255 Thu 9/29/2011 7:22:05 AM : [ 16 43 C 1 ] ST 0 I sorted by the device and here is just this device's info for the entire morning. I am wondering if my daughter didn't actually push the button when I was in with my other daughter. But sometime in the 6:50'ish times I shut the light off, it bounced, and I shut it off again. But I am a bit confused. At 7:11 my daughters were both in the kitchen eating breakfast so how it is listed as 255 is a mystery to me. EDIT: Just noticed that perhaps that some of those are perhaps not the same device. I don't understand what device those codes are that are similar but different. I have no device 16:43:c1. For whatever reason ISY adds a 1 to the end of everything. The actual device in question is 16:43:bc MORE EDIT: It looks like 6:51:44 is when things went wrong. You can see that there is a device off, state 0, device off again (same time stamp), state 63, device off (third time), state 0. So it looks like there were device off commands received at 6:51:44 with the second one turning the light back on to 63 (25%). So, something caused a second signal. This might be what Indy Mike was talking about. Thu 9/29/2011 6:51:44 AM : [ 1 6 4 3 B C 1 ] DOF 0 (me pushing button) Thu 9/29/2011 6:51:44 AM : [ 1 6 4 3 B C 1 ] ST 0 (lihgt turned off) Thu 9/29/2011 6:51:44 AM : [ 1 6 4 3 B C 1 ] DOF 1 (bogus off command, ???what does the 1 mean after the dof, and for that matter what does the 0 mean the other times???) Thu 9/29/2011 6:51:45 AM : [ 1 6 4 3 B C 1 ] ST 63 (program ran and set to 25%) Thu 9/29/2011 6:51:49 AM : [ 1 6 4 3 B C 1 ] DOF 0 (me pushing button again) Thu 9/29/2011 6:51:49 AM : [ 1 6 4 3 B C 1 ] ST 0

I don't think that is what actually happened. I know I did not do that, but my 6 year old daughter might have acted on the switch. I do know that when I got up to her room the light was on brightly as is exptected from the 6:30 program that turns it on as an alarm. I do know that around 6:50'ish I tapped the off and the light went from brightly on to off, then bounced up to 25% ish, then I immediately tapped off again and it shut off and stayed off. As far as event viewer. I need to start a session of the admin console, set the event viewer to level "device communication events" and then let it start collecting data. As I understand, it is not possible to change the viewer level after the fact and get that info, correct?

Here is the event viewer. Curiously, the times don't line up with the log. 1643bc is the light in question and the timing of events is not the same as in the log. Thu 9/29/2011 6:51:51 AM : [ 1 5 8 5 2 8 1 ] DON 0 Thu 9/29/2011 6:51:51 AM : [ 1 5 8 5 2 8 1 ] ST 255 Thu 9/29/2011 6:51:57 AM : [ 1 6 4 3 B C 1 ] BMAN 1 Thu 9/29/2011 6:51:59 AM : [ 1 6 4 3 B C 1 ] SMAN 0 Thu 9/29/2011 6:51:59 AM : [ 1 6 4 3 B C 1 ] ST 83 Thu 9/29/2011 6:52:27 AM : [MOD 2 2 1 5] 1000 Weather - Temperature Rate = 0.1 ï½° F/h Thu 9/29/2011 6:52:27 AM : [MOD 2 2 1 12] 20000 Weather - Wind Average Speed = 2 mph Thu 9/29/2011 6:52:27 AM : [MOD 2 2 1 22] 2235 Weather - Evapotranspiration = 0.2 235 inches/day Thu 9/29/2011 6:52:35 AM : [ 1 6 4 6 5 F 1 ] DOF 0 Thu 9/29/2011 6:52:40 AM : [ 1 6 4 6 5 F 1 ] DON 0 Thu 9/29/2011 6:52:40 AM : [ 1 6 4 6 5 F 1 ] ST 255 Thu 9/29/2011 6:52:48 AM : [ 1 6 4 6 5 F 1 ] DOF 0 Thu 9/29/2011 6:52:48 AM : [ 1 6 4 6 5 F 1 ] ST 0 Thu 9/29/2011 6:53:26 AM : [MOD 2 2 1 5] 2000 Weather - Temperature Rate = 0.2 ï½° F/h Thu 9/29/2011 6:53:26 AM : [MOD 2 2 1 13] 130000 Weather - Wind Direction = W Thu 9/29/2011 6:53:30 AM : [ 1 6 4 3 B C 1 ] DON 0 Thu 9/29/2011 6:53:30 AM : [ 1 6 4 3 B C 1 ] ST 137 Thu 9/29/2011 6:53:31 AM : [ 1 6 4 3 B C 1 ] DOF 0 Thu 9/29/2011 6:53:31 AM : [ 1 6 4 3 B C 1 ] ST 0

Below is a log of the status of a light that behaved wrong this morning. I don't know what the third line means where it says "on 63". Other than that, you can see that at 6:30 the light was turned on by the wakeup program. The next action on the light was to turn it off by me manually at 6:52:35. Then there is a program log with the 63 which I don't know what means, then the light turns on to 25% which it should not have done. Then I turned it off again and it stayed off. Alexis Room / Alexis BR/Overhead L Status 100% Thu 2011/09/29 06:30:00 AM System Log Alexis Room / Alexis BR/Overhead L Status 0% Thu 2011/09/29 06:52:35 AM System Log Alexis Room / Alexis BR/Overhead L On 63 Thu 2011/09/29 06:52:36 AM Program Log Alexis Room / Alexis BR/Overhead L Status 25% Thu 2011/09/29 06:52:37 AM System Log Alexis Room / Alexis BR/Overhead L Status 0% Thu 2011/09/29 06:52:42 AM System Log

Hmmm. That's something to think about. I do have maybe 4 rf doohickies plugged in around the house. I have had those all along however. It would be no big deal to unplug them and see what happens. I do have 3 breaker boxes in the house and don't wan't to lose signal through the different panels and their phases.

You would be very limited with those. They typically are capable of multiple tones but the user needs to select one of them at the base station. You could use an Insteon relay device and "hot wire" it to the doorbell button allowing ISY to "ring the bell", but that would be just one tone. If you bought 8 of them and selected different tones for each one, it might work, but you would probably find that they all shared the same frequency and thus all would go off every time one of them was triggered. Maybe you can find a hardwired version and thus be able to keep them separate. My doughter has one like that she put on her bedroom door, but it just does a little chime, no voices or anything.

I have a 2412s modem that I bought 7/09. I have both icon dimmers and switchlinc dimmers running the program and all of them are the newer models with the beeper in them (less than 2 years old). The problem is happening with both the icons and the switchlincs. I really didn't have this issue prior to firmware 3.1.7. The programs all say "off" and "switched off", not "less than 5%" and "switched off"

Now that I have been using the lights "real world" for about a week, I am sad to say that it is behaving improperly a lot more than when I just stood there hitting on/off/on/off etc. It is probably running the program when I turn the light off from a "not off" status 25% of the time. This is probably too much to keep the programs running. I think I am going to have to disable them.

That is what I was thinking with the "is you computer always on" question. But it still also needs an intercom unless you have a small house and can crank up the volume on your computer speaker.

Talk to io_guy. He has written a couple applications that run in the background on a pc and set ISY variables. I have his app syncing my cai webcontrol unit with isy variables. If you can use http commands to poll your Davis weather station then I am sure it would work pretty much the same.

Do you have an intercom system in your house with a line-in? Do you have an Elk m1G? Do you have a computer that runs all the time?

You might try updating to the latest firmware. "bounce" would be a good adjective for how it behaves when it isn't doing what it should. But with the current firmware, this is a pretty rare event. It is a little odd to me that it happens like this. It would seem more likely to me that it would happen every time or none of the time. 5% is kind of odd. Especially considering that at the time I was testing it, the ISY had no other active programs. I can only assume that it has something to do with Insteon communciation fluctuations since I would thin ISY was in a steady state at the time.

I played with it some more last night. I think saying it functions properly 95% of the time is pretty accurate. I was able to get 2 more misfires of the program out of roughly 40 tries. I am sure you guys will get it 100% soon enough. It is not that big of a deal at a 5% error rate in this context. However, there might be a time when someone wants to use that program technique in a less forgiving application where 5% failure would be bad.

I know this isn't exactly the answer you were looking for, but there are fairly inexpensive ways to reboot the ISY if it is locked up (remotely). 1) If you have an Elk, put a relay board on it and run the power to the ISY through one of the relays. 2) Buy a cai webcontrol and a relay board. You need relays that activate from ttl outputs which can be found on ebay by searching "pic relay". For about $60 total you can have 8 IP controlled relays which you can use to cycle power to up to 8 devices. If you don't need 8 relays, you can save about $15 and just get a single relay. ISY can also directly control the CAI unit using the network module which might be useful. Also, you can sync all of the cai's functions with ISY using io_guy's little application. This is actually the cheapest way to get multiple temperatures into ISY. Still doesn't help you, however, if your modem or router lockup. Although you probably can control the Elk from the phone. I've never looked into it.

With the new firmware update (3.1. the problem is nearly elliminated. I turned several of the switches with this program on/off dozens of times. The problem did occurr a few times. I did have my laptop with me to confirm that isy registered all actions on the switches and that it wasn't a com failure. There were zero com failures in the 30 or 40 on/off cycles. I didn't take exact counts, but the program now is mis-behaving maybe 5% of the time versus maybe 75% of the time with 3.1.7.

The two programs below will do it. But you can't have the kitchen table linked to the in line device. Let ISY turn it on and off. Blink If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Set 'Kitchen table' On Wait 5 seconds Run Program 'blink' (Else Path) Else Set 'Kitchen table' Off Wait 5 seconds Run Program 'blink' (Then Path) Run Blink If Status 'in line linc' is not Off Then Run Program 'blink' (Then Path) Else Stop program 'blink'

It happened so rarely before that I couldn't repeat the event while investigating. There is a very good chance that it was a failure to comunicate when the light was turned on, resulting in a proper execution of the program (from the perspective of ISY which thought the light was off). The programs were presented to be used exactly as I am using them. This is a "night light" program and was presented as such. I quickly perused the wiki and didn't see this program. But I found this set of programs which is the exact same thing except for if status is on, and it is switched on (instead of off). But it is functionally the same thing. http://www.universal-devices.com/mwiki/ ... tion_Order

I have taken tjf1960's idea and slightly altered it. For now, I am using the "fast off" to turn the light off when I actually want it off. The sinlge off will still get me the 25%. It is almost comical. Turn the light off, 1 second later it comes on to 25%. Click off again, it goes off, then boom, 25% again. It isn't the same for every switch. Some do it darn near every time, some not so often. I don't know what the creators of ISY intended when writing the first code for it, but they definitely pointed out this feature. As I mentioned, I did not brain storm it up myself, it was from an official UD publication that I got the idea. Before this firmware, this happened every once in a while, but now, it happens most of the time. EDIT: I do believe that ISY is responding very quickly to status changes of devices and communicating better than ever with this firmware. I do like it. So, a simple workaround to get this particular program functioning again would be great.

What you say is true. The point is that it used to work and now it doesn't. The ISY has changed either how fast it processes or the order of processing. I liked the way it used to work and would like it to still work that way. And tjf1960 makes a fine suggestion, it is just that at 3am you are swatting blindly at a light switch, trying to get a double click may be out of the quesiton.