MarkJames Posted May 18, 2016 Posted May 18, 2016 I had a 2413S fail last week. These seem to be a weak point in the general scheme of ISY - I've had a number of them fail over the years so I always keep a spare handy. I replaced it with a new one and restored the database to it. All went reasonably well - there's always a few links that don't seem to write properly but given enough time I manage to sort them out. The second night after replacing it I had my burglar alarm go off at around 3am and every single light in the house turn on. Turns out my garage door had opened and set off the alarm. I'm not sure why all the lights were on but I closed the door, turned off all the lights and went back to bed. This afternoon at around 1:55pm the exact same thing happened. I've figured out why it is that the door is opening - there's an ioLinc relay attached to it and when it gets an ON signal it triggers the door opener. So the garage door opening is part of the overall issue of everything in the house turning on. This is a bit of a problem as I have somewhere around 200 ISY devices in my network - pretty much everything in the house. The ioLinc on the garage door is not controlled by anything BUT the PLM so it seems that the problem must lie there. This is a pretty well established system - it's been in place and operating trouble free for 10 or more years. I've checked the program run logs and nothing has run at that time. I'm not sure what to do next.... restore the PLM? Thanks for any input. mark
Teken Posted May 18, 2016 Posted May 18, 2016 Hello Mark, There are at least two lengthy threads about what to do for this condition which you can find in the UDI Wiki. Also, do you believe you can make this happen again?
MarkJames Posted May 19, 2016 Author Posted May 19, 2016 (edited) Thanks for that. I read the wiki entry - but nothing lengthy. Perhaps you're referring to another article that might be of interest to me? The wiki refers to scenes/control conflicts. If I didn't have those before the PLM change I don't see why I should have them now. The other reference in the wiki entry is to the wireless motion detectors sending multiple signals when their batteries get low. I'll check on that as I do have a few of those kicking around and I've not touched their batteries in some time. The curious thing is that it only started when the PLM was changed. I've made no other program/device changes whatsoever. As for making it happen again? I've been scratching my head trying to duplicate it but there's nothing very unusual in the log around the time it happened. I think I'll start saving the logs and comparing what's going on at the time it happens. That might give me a clue if I have some kind of program conflict overloading the PLM. Thanks, mark [edit] Actually I do see something weird in the log. There's a whole whack of 2 lights turning on in rapid succession about the time the ALL ON happened. This bears investigation. Thanks again! Edited May 19, 2016 by MarkJames
Teken Posted May 19, 2016 Posted May 19, 2016 Thanks for that. I read the wiki entry - but nothing lengthy. Perhaps you're referring to another article that might be of interest to me? The wiki refers to scenes/control conflicts. If I didn't have those before the PLM change I don't see why I should have them now. The other reference in the wiki entry is to the wireless motion detectors sending multiple signals when their batteries get low. I'll check on that as I do have a few of those kicking around and I've not touched their batteries in some time. The curious thing is that it only started when the PLM was changed. I've made no other program/device changes whatsoever. As for making it happen again? I've been scratching my head trying to duplicate it but there's nothing very unusual in the log around the time it happened. I think I'll start saving the logs and comparing what's going on at the time it happens. That might give me a clue if I have some kind of program conflict overloading the PLM. Thanks, mark Hello Mark, The Wiki entry doesn't have a huge amount of information about the ALL ON / ALL OFF situation. But does offer some insight to conditions that may contribute to the problem. If you are able to scratch off all of the listed *possible* issues from the WiKi. The next steps require more investment in time or finances. You will need to decide if your time is more valuable then the short term investment of money. Meaning some users have replaced the Insteon GDO kit with Z-Wave products. While some have gone through the entire programming logic and added wait times to any programs in hopes of eliminating said problem. When you find the two massive ALL ON / ALL OFF thread you will note my views on the issue at hand.
stusviews Posted May 19, 2016 Posted May 19, 2016 http://forum.universal-devices.com/topic/13815-another-all-on-event/ http://forum.universal-devices.com/topic/10516-random-all-on-event/
nadler Posted May 19, 2016 Posted May 19, 2016 Mark I recently had the same issue. New PLM, 3 am garage light (and some others) go on and stay on all night, garage iolinc indicates the garage is open when it isn't and not much info in the log. Apparently I had a very old KPL. I used one of the back light buttons to indicate whether the garage door was opened or closed. That seems to be one of the themes running through the solutions Stu mentions above. I replaced the KPL with a new one and everything is fine. I believe the older KPL were known for sending itinerant commands. At 3 am ISY sends a query to all devices. I think, at least in my case, this was the key. The KPL responded to the query in a strange way which lead to all the bad things that happened.
MarkJames Posted May 19, 2016 Author Posted May 19, 2016 Thanks for the links, Stu, and for your input as well, Nadler. I have one other thing that I'm going to look into before dealing with any possible PLM firmware issues. My PLM is at 9B so it may well be the problem. I'm not sure what rev my last one was but it was at least as old as the 9B one. I am interfaced with an Elk M1G. I only have a handful of devices that were exported to the Elk for control but since the PLM change none of those devices work under Elk control. It's been so long since I set the Elk up to control any of the Insteon devices that I don't remember if I was controlling scenes or devices. I'm guessing (correct me if I'm wrong) that I would have to re-export any scenes I want to control and re-import them into the Elk otherwise I'll be dealing with incorrect/broken links. I've disabled all Elk automation of Insteon/ISY and will see if that makes a difference. It may take a few days to find out, though. Thanks all for your input. mark
MarkJames Posted May 21, 2016 Author Posted May 21, 2016 Well it just happened yet again. I checked my log immediately and found nothing weird other than the last line in the log is an 'Elk - Get Topology' call which I'm not sure exactly what means. I noticed in another thread that UDI is able to upgrade some PLM's to different firmware... does anyone know if that's still an option and if so who to contact? Thanks, mark
stusviews Posted May 21, 2016 Posted May 21, 2016 The log doesn't show devices being set to 100% at about the time the All On occurred? Of concern is what occurred within a minute prior the the first full on device. No new PLM is currently available from UDI
MarkJames Posted May 21, 2016 Author Posted May 21, 2016 (edited) Back yard / LIGHT - Nanny House Patio Fast Off Fri 2016/05/20 08:20:04 PM Program Log Back yard / KPL - PH2 - Pool House Off 0 Fri 2016/05/20 08:20:04 PM Program Log Master Bedroom / Towel Warmer On Fri 2016/05/20 08:20:05 PM Program Log Hot Water Tank - Kitchen On Fri 2016/05/20 08:20:05 PM Program Log Hot Water Tank - Master Bedro On Fri 2016/05/20 08:20:06 PM Program Log Scene:Laundry / Laundry KPLs for sync On Fri 2016/05/20 08:20:06 PM Program Log Scene:Back yard / Guest House Patio Status Query Fri 2016/05/20 08:25:03 PM Program Log Garage/Shop / LIGHT - G2 - Outside Fast Off Fri 2016/05/20 08:25:04 PM Program Log Garage/Shop / LIGHT - G2 Inside Fast Off Fri 2016/05/20 08:25:04 PM Program Log Back yard / LIGHT - Nanny House Patio Fast Off Fri 2016/05/20 08:25:04 PM Program Log Back yard / KPL - PH2 - Pool House Off 0 Fri 2016/05/20 08:25:04 PM Program Log Master Bedroom / Towel Warmer On Fri 2016/05/20 08:25:06 PM Program Log Hot Water Tank - Kitchen On Fri 2016/05/20 08:25:06 PM Program Log Hot Water Tank - Master Bedro On Fri 2016/05/20 08:25:06 PM Program Log Scene:Laundry / Laundry KPLs for sync On Fri 2016/05/20 08:25:07 PM Program Log Get Topology ELK-TX Fri 2016/05/20 08:26:49 PM System Log Here's the log in the minute or two leading up to the all-on event. Do you see anything in it? Is there a way to upgrade a PLM? Edited May 21, 2016 by MarkJames
stusviews Posted May 21, 2016 Posted May 21, 2016 Was the activity prior to the Status Query expected? Was the activity after the Status Query expected? What caused the Status Query? Nothing you mentioned indicated 8PM.
MarkJames Posted May 21, 2016 Author Posted May 21, 2016 (edited) The activity before the status query was part of a routine that recurs every 5 minutes. The routine shuts off any unnecessary lights and makes sure that hot water tanks etc. that are supposed to be on or off are, indeed, the way they're supposed to be. I have a series of flags for which things in the house should be on and when and the routine just goes through making sure that nobody has changed anything. So... you can see that the same routine happened at 8:20 and then again at 8:25. The status query is actually part of that routine but I cut the first one off in the log when I cut/pasted. I can't remember why I had that in there - I wrote this routine several years ago. I think it was to ensure that the info ISY had about some devices was current but I can't remember. I've removed that line from the routine now as I don't think I need it. I'm not sure what you mean by 'nothing you mentioned indicated 8pm'. mark Edited May 21, 2016 by MarkJames
MarkJames Posted May 25, 2016 Author Posted May 25, 2016 Well, it's been a few days now with no repeat of the all on problem so I'm feeling like it may be solved. For any who may search the issue and find this thread I'll offer up what I believe was the cause in hope that it helps you. I believe I had a couple of issues. First was that my motion sensor programs were hammering my PLM. I don't use Insteon motion sensors because of the 9v battery. Rather, I use ISY programs that monitor my alarm sensors via my Elk M1 panel. Every time the sensor would violate it would trigger the program and send an ON to the scene involved. Checking the log this would sometimes result in dozens of hits in a second or two. To eliminate the problem I added a 'flood control' routine where before sending the on I check the status of a variable. The variable goes true when the sensor detects motion and then resets to false after 5 seconds. It's just a way of avoiding re-triggering within a few seconds and it seems to work. I think it's wiser to let the Elk control the lights through its own automation/lighting rules as Elk has a built in retrigger delay - so if you're planning on doing something similar you may want to go that route as it's considerably less complicated and the Elk triggers the lights noticeably faster than an ISY program does. The other issue I had was when I changed out my PLM I didn't re-export the devices to Elk that I allow it to manage. I'm not certain this was a problem as ISY allows you to export devices but not scenes and the devices were stil the same but I re-exported them all the same. Anyways - I'll update the thread if the problem recurs but so far things seem pretty good. Thanks to all for the help and input, mark
apostolakisl Posted May 25, 2016 Posted May 25, 2016 Well, it's been a few days now with no repeat of the all on problem so I'm feeling like it may be solved. For any who may search the issue and find this thread I'll offer up what I believe was the cause in hope that it helps you. I believe I had a couple of issues. First was that my motion sensor programs were hammering my PLM. I don't use Insteon motion sensors because of the 9v battery. Rather, I use ISY programs that monitor my alarm sensors via my Elk M1 panel. Every time the sensor would violate it would trigger the program and send an ON to the scene involved. Checking the log this would sometimes result in dozens of hits in a second or two. To eliminate the problem I added a 'flood control' routine where before sending the on I check the status of a variable. The variable goes true when the sensor detects motion and then resets to false after 5 seconds. It's just a way of avoiding re-triggering within a few seconds and it seems to work. I think it's wiser to let the Elk control the lights through its own automation/lighting rules as Elk has a built in retrigger delay - so if you're planning on doing something similar you may want to go that route as it's considerably less complicated and the Elk triggers the lights noticeably faster than an ISY program does. The other issue I had was when I changed out my PLM I didn't re-export the devices to Elk that I allow it to manage. I'm not certain this was a problem as ISY allows you to export devices but not scenes and the devices were stil the same but I re-exported them all the same. Anyways - I'll update the thread if the problem recurs but so far things seem pretty good. Thanks to all for the help and input, mark If I were you I would get rid of the Insteon control of your GDO. Since you have Elk, use that, it is too important to trust your GDO to Insteon. I neglected to pull wires from my Elk to the GDO when the house was under construction, but there is a simple work around provided your Elk is within radio range of the GDO. I simply took one of my standard push button radio control GDO with 3 buttons on it and soldered leads to the 3 micro switches and then ran those to 3 relays on the elk. If you care to have ISY control your GDO and have the Elk module, this is now just a simple process of adding a program that turns the relay on for a second. ISY is not the problem, it is Insteon, and this takes Insteon out of the loop and replaces it with the far more reliable Elk.
MarkJames Posted May 25, 2016 Author Posted May 25, 2016 If I were you I would get rid of the Insteon control of your GDO. Since you have Elk, use that, it is too important to trust your GDO to Insteon. I neglected to pull wires from my Elk to the GDO when the house was under construction, but there is a simple work around provided your Elk is within radio range of the GDO. I simply took one of my standard push button radio control GDO with 3 buttons on it and soldered leads to the 3 micro switches and then ran those to 3 relays on the elk. If you care to have ISY control your GDO and have the Elk module, this is now just a simple process of adding a program that turns the relay on for a second. ISY is not the problem, it is Insteon, and this takes Insteon out of the loop and replaces it with the far more reliable Elk. Thanks, I'll put some thought into that. I actually have quite a number of unused wires running out to my detached garage at the moment. I had 4 cctv cameras out there which I've since replaced with IP cams. The IP cams simply connect to the PoE network switch that's out there so I have the 8 spare power supply wires and the 4 coax cables sitting out there doing nothing but looking for the next project. Honestly the Insteon control of my GDO hasn't been problematic for me at all. The ALL ON PLM problem is really the first issue I've had. I run HomeSeer in parallel with my ISY system so I have voice announcements of the door opening and closing as well as warnings at night if any of the doors have been left open. The Elk is definitely very robust. The only issues I've had with it have been with the battery powered wireless sensors that can get a bit flaky when the batteries get weak. Since I retired a few years ago I travel more and can't have them going off while I'm away so I replace all the batteries annually even though they really get more like 2 or 3 years. I wish I'd had the foresight to hardwire the sensors but then I had no idea my HA system was going to grow the way it has. The technology has really advanced so quickly. My cat 5e that's everywhere now makes me sad with 6e available lol Mark
apostolakisl Posted May 25, 2016 Posted May 25, 2016 Thanks, I'll put some thought into that. I actually have quite a number of unused wires running out to my detached garage at the moment. I had 4 cctv cameras out there which I've since replaced with IP cams. The IP cams simply connect to the PoE network switch that's out there so I have the 8 spare power supply wires and the 4 coax cables sitting out there doing nothing but looking for the next project. Honestly the Insteon control of my GDO hasn't been problematic for me at all. The ALL ON PLM problem is really the first issue I've had. I run HomeSeer in parallel with my ISY system so I have voice announcements of the door opening and closing as well as warnings at night if any of the doors have been left open. The Elk is definitely very robust. The only issues I've had with it have been with the battery powered wireless sensors that can get a bit flaky when the batteries get weak. Since I retired a few years ago I travel more and can't have them going off while I'm away so I replace all the batteries annually even though they really get more like 2 or 3 years. I wish I'd had the foresight to hardwire the sensors but then I had no idea my HA system was going to grow the way it has. The technology has really advanced so quickly. My cat 5e that's everywhere now makes me sad with 6e available lol Mark The trouble with the all on is that I don't really think anyone actually knows for sure why it happens. It may be that there are multiple things that can do it. Which means you may think you fixed it, but there is no way to test that. I have had exactly one all on event in my system in 7 years. Nothing changed for a long time before it happened and I have changed nothing since. So how do you trouble shoot this and how do you know when you fixed it. I just don't trust Insteon to anything significant, I use Elk for all that stuff.
apostolakisl Posted May 25, 2016 Posted May 25, 2016 Just an FYI. I am on my 3rd PLM. The first was the older model which I replaced about 4.5 years ago because. . . I don't remember why, the old PLM worked fine but it seems to me there was some issue with using the 2412 unit, maybe since it wasn't dual band. Anyway, the new 2413s that i bought 4.5 years ago lasted 2 years and 3 months. . . as you would expect from Smarthome. I replaced it with a new one and recapped the old one as a spare. Well the new one died at 2 years and 2 months just last week. In short, I have had 3 plms over the years and only one all on event. This was using my third plm, the one I bought 2 years and 2 months ago and while it still had its original caps. This happened about 2 years into its life (or in other words about 2 months ago). Could not quite dead yet caps be part of the problem? I restored that 4.5 year old plm with the new caps last week and it is working fine. I'll be recapping my just died plm as soon as they arrive from Mousser and keep it as a backup.
MarkJames Posted May 25, 2016 Author Posted May 25, 2016 The trouble with the all on is that I don't really think anyone actually knows for sure why it happens. It may be that there are multiple things that can do it. Which means you may think you fixed it, but there is no way to test that. I have had exactly one all on event in my system in 7 years. Nothing changed for a long time before it happened and I have changed nothing since. So how do you trouble shoot this and how do you know when you fixed it. I just don't trust Insteon to anything significant, I use Elk for all that stuff. Fair enough - it's an easy enough change as the sensors etc. are all wired to the Elk already anyways. The peace of mind will be worth the hour or two of sorting out and testing.
MarkJames Posted May 25, 2016 Author Posted May 25, 2016 Just an FYI. I am on my 3rd PLM. The first was the older model which I replaced about 4.5 years ago because. . . I don't remember why, the old PLM worked fine but it seems to me there was some issue with using the 2412 unit, maybe since it wasn't dual band. Anyway, the new 2413s that i bought 4.5 years ago lasted 2 years and 3 months. . . as you would expect from Smarthome. I replaced it with a new one and recapped the old one as a spare. Well the new one died at 2 years and 2 months just last week. In short, I have had 3 plms over the years and only one all on event. This was using my third plm, the one I bought 2 years and 2 months ago and while it still had its original caps. This happened about 2 years into its life (or in other words about 2 months ago). Could not quite dead yet caps be part of the problem? I restored that 4.5 year old plm with the new caps last week and it is working fine. I'll be recapping my just died plm as soon as they arrive from Mousser and keep it as a backup. I've lost count of PLMs - probably 5 or so by now - but not all were because of failures, some were for functionality/headroom. Funny you mention the PLM fix. I found that thread on the weekend and thought I'd give it a go. Sadly when I went to remove the board from the box I pushed on the ethernet connector and it stripped all the connections off the board. That pretty much stopped me right there. The 'new' PLM I have is actually a few years old as I bought it for a spare. So far it's running nice and cool so I hope it has a long, happy life. mark
MarkJames Posted May 28, 2016 Author Posted May 28, 2016 (edited) apostolakisl, I was sitting down to plan out the GDO run by the Elk today. I figured I'd use the Elk to control the fireplace as well. The thing is that all methods I have to trigger the Elk to open/close the garage door/fireplace are going to be via Insteon buttons unless I use Elk keypads or keyfobs. I suppose that the ALL-ON problem is a responder event as I see no device ON commands in the event viewer so the Elk should be unaffected. Are you just using a program something like if control KPL-Fireplace is ON Elk Output GDO ON Off Timer 1 second Seems like that's all it should take... To ensure even greater security I could require a fast-on or fast-off event.... just thinking out loud Edited May 28, 2016 by MarkJames
apostolakisl Posted May 31, 2016 Posted May 31, 2016 (edited) apostolakisl, I was sitting down to plan out the GDO run by the Elk today. I figured I'd use the Elk to control the fireplace as well. The thing is that all methods I have to trigger the Elk to open/close the garage door/fireplace are going to be via Insteon buttons unless I use Elk keypads or keyfobs. I suppose that the ALL-ON problem is a responder event as I see no device ON commands in the event viewer so the Elk should be unaffected. Are you just using a program something like if control KPL-Fireplace is ON Elk Output GDO ON Off Timer 1 second Seems like that's all it should take... To ensure even greater security I could require a fast-on or fast-off event.... just thinking out loud This is a good question. I have only had one all on event, so perhaps I am not most qualified to characterize it. However, if you use if control . . . terminology, an all on event should not be an issue. I can tell you that I have the following program If control kpl button is switched on Then arm elk night mode and my all on event did not trigger that. I also have several other if control programs that do things like turn on the house music and what not and none of those ran either. I would be more careful with "is status" programs since I suppose that could trigger. I do not recall if ISY registered the change in status of all the devices or not during the all on event. I want to say yes, but I will not swear to it. Edited May 31, 2016 by apostolakisl
MarkJames Posted June 10, 2016 Author Posted June 10, 2016 Sigh.... So my ALL ON events continue. I'm back to one a day or so now despite having switched to a build 1617 v9E PLM This is the event viewer log of the minute or so leading up to the all-on. If you have a chance, Lee, could you see if anything looks 'suspect' to you? Sorry there's a bit here - I cut/pasted the last 15 seconds or so. At 8:09:25 a series of programs that turn off unneeded lights started - that's what sets all the traffic in motion. I can see that in the log file. I've highlighted an odd one with device 0C.80.93. It's a switchlinc Relay v.2C Thanks, mark Fri 06/10/2016 08:09:16 AM : [VAR 2 9 ] 1 Fri 06/10/2016 08:09:16 AM : [iNST-TX-I1 ] 02 62 10 A8 E0 0F 14 00 Fri 06/10/2016 08:09:16 AM : [iNST-TX-I1 ] 02 62 0C 80 93 0F 14 00 Fri 06/10/2016 08:09:16 AM : [ Time] 08:09:25 11(0) Fri 06/10/2016 08:09:16 AM : [iNST-ACK ] 02 62 10.A8.E0 0F 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:16 AM : [iNST-SRX ] 02 50 10.A8.E0 40.D1.EC 2B 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:16 AM : [std-Direct Ack] 10.A8.E0-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 06/10/2016 08:09:16 AM : [iNST-ACK ] 02 62 0C.80.93 0F 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:17 AM : [iNST-SRX ] 02 50 0C.80.93 40.D1.EC 27 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:17 AM : [std-Direct Ack] 0C.80.93-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Fri 06/10/2016 08:09:17 AM : [iNST-SRX ] 02 50 0C.80.93 40.D1.EC 23 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:17 AM : [std-Direct Ack] 0C.80.93-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Fri 06/10/2016 08:09:17 AM : [iNST-TX-I1 ] 02 62 00 00 57 CF 14 00 Fri 06/10/2016 08:09:17 AM : [iNST-TX-I1 ] 02 62 00 00 36 CF 14 00 Fri 06/10/2016 08:09:17 AM : [iNST-TX-I1 ] 02 62 10 A8 E0 0F 14 00 Fri 06/10/2016 08:09:17 AM : [iNST-ACK ] 02 62 00.00.57 CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:17 AM : [iNST-TX-I1 ] 02 62 0C 80 93 0F 14 00 Fri 06/10/2016 08:09:18 AM : [iNST-ACK ] 02 62 00.00.36 CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:18 AM : [iNST-ACK ] 02 62 10.A8.E0 0F 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:19 AM : [iNST-SRX ] 02 50 10.A8.E0 40.D1.EC 2B 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:19 AM : [std-Direct Ack] 10.A8.E0-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 06/10/2016 08:09:19 AM : [iNST-ACK ] 02 62 0C.80.93 0F 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:19 AM : [iNST-TX-I1 ] 02 62 00 00 58 CF 14 00 Fri 06/10/2016 08:09:19 AM : [iNST-TX-I1 ] 02 62 00 00 18 CF 14 00 Fri 06/10/2016 08:09:19 AM : [iNST-ACK ] 02 62 00.00.58 CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:20 AM : [iNST-SRX ] 02 50 0C.80.93 40.D1.EC 2B 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:20 AM : [std-Direct Ack] 0C.80.93-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 06/10/2016 08:09:20 AM : [iNST-TX-I1 ] 02 62 3D 2A 20 0F 11 FF Fri 06/10/2016 08:09:20 AM : [iNST-TX-I1 ] 02 62 00 00 4C CF 14 00 Fri 06/10/2016 08:09:20 AM : [iNST-ACK ] 02 62 3D.2A.20 0F 11 FF 06 LTONRR (FF) Fri 06/10/2016 08:09:20 AM : [iNST-TX-I1 ] 02 62 08 66 4B 0F 14 00 Fri 06/10/2016 08:09:21 AM : [iNST-SRX ] 02 50 3D.2A.20 40.D1.EC 2B 11 FF LTONRR (FF) Fri 06/10/2016 08:09:21 AM : [std-Direct Ack] 3D.2A.20-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 06/10/2016 08:09:21 AM : [iNST-SRX ] 02 50 3D.2A.20 40.D1.EC 23 11 FF LTONRR (FF) Fri 06/10/2016 08:09:21 AM : [std-Direct Ack] 3D.2A.20-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Fri 06/10/2016 08:09:21 AM : [iNST-ACK ] 02 62 00.00.4C CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:21 AM : [iNST-TX-I1 ] 02 62 23 7D A0 0F 11 FF Fri 06/10/2016 08:09:21 AM : [iNST-TX-I1 ] 02 62 00 00 16 CF 14 00 Fri 06/10/2016 08:09:21 AM : [iNST-TX-I1 ] 02 62 00 00 5A CF 14 00 Fri 06/10/2016 08:09:21 AM : [iNST-ACK ] 02 62 08.66.4B 0F 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:22 AM : [iNST-SRX ] 02 50 08.66.4B 40.D1.EC 23 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:22 AM : [std-Direct Ack] 08.66.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Fri 06/10/2016 08:09:22 AM : [iNST-ACK ] 02 62 23.7D.A0 0F 11 FF 06 LTONRR (FF) Fri 06/10/2016 08:09:22 AM : [iNST-TX-I1 ] 02 62 00 00 30 CF 14 00 Fri 06/10/2016 08:09:22 AM : [iNST-TX-I1 ] 02 62 00 00 21 CF 14 00 Fri 06/10/2016 08:09:22 AM : [iNST-TX-I1 ] 02 62 23 7E 01 0F 11 FF Fri 06/10/2016 08:09:22 AM : [iNST-ACK ] 02 62 00.00.16 CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:23 AM : [iNST-SRX ] 02 50 23.7D.A0 40.D1.EC 2B 11 FF LTONRR (FF) Fri 06/10/2016 08:09:23 AM : [std-Direct Ack] 23.7D.A0-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 06/10/2016 08:09:23 AM : [iNST-TX-I1 ] 02 62 10 A8 E0 0F 14 00 Fri 06/10/2016 08:09:23 AM : [iNST-TX-I1 ] 02 62 0C 80 93 0F 14 00 Fri 06/10/2016 08:09:23 AM : [iNST-TX-I1 ] 02 62 00 00 2C CF 13 00 Fri 06/10/2016 08:09:23 AM : [iNST-ACK ] 02 62 00.00.30 CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:23 AM : [ Time] 08:09:32 11(0) Fri 06/10/2016 08:09:24 AM : [iNST-TX-I1 ] 02 62 00 00 57 CF 14 00 Fri 06/10/2016 08:09:24 AM : [iNST-TX-I1 ] 02 62 00 00 36 CF 14 00 Fri 06/10/2016 08:09:24 AM : [iNST-TX-I1 ] 02 62 10 A8 E0 0F 14 00 Fri 06/10/2016 08:09:24 AM : [iNST-ACK ] 02 62 00.00.21 CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:24 AM : [iNST-TX-I1 ] 02 62 0C 80 93 0F 14 00 Fri 06/10/2016 08:09:24 AM : [iNST-TX-I1 ] 02 62 00 00 58 CF 14 00 Fri 06/10/2016 08:09:24 AM : [iNST-TX-I1 ] 02 62 00 00 18 CF 14 00 Fri 06/10/2016 08:09:24 AM : [iNST-ACK ] 02 62 23.7E.01 0F 11 FF 06 LTONRR (FF) Fri 06/10/2016 08:09:25 AM : [iNST-SRX ] 02 50 23.7E.01 40.D1.EC 2F 11 FF LTONRR (FF) Fri 06/10/2016 08:09:25 AM : [std-Direct Ack] 23.7E.01-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Fri 06/10/2016 08:09:25 AM : [iNST-ACK ] 02 62 10.A8.E0 0F 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:25 AM : [iNST-SRX ] 02 50 10.A8.E0 40.D1.EC 23 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:25 AM : [std-Direct Ack] 10.A8.E0-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Fri 06/10/2016 08:09:25 AM : [iNST-ACK ] 02 62 0C.80.93 0F 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:26 AM : [iNST-TX-I1 ] 02 62 3D 2A 20 0F 11 FF Fri 06/10/2016 08:09:26 AM : [iNST-TX-I1 ] 02 62 00 00 4C CF 14 00 Fri 06/10/2016 08:09:26 AM : [iNST-ACK ] 02 62 00.00.2C CF 13 00 06 LTOFFRR(00) Fri 06/10/2016 08:09:26 AM : [iNST-TX-I1 ] 02 62 08 66 4B 0F 14 00 Fri 06/10/2016 08:09:26 AM : [iNST-SRX ] 02 50 0C.80.93 40.D1.EC 2B 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:26 AM : [std-Direct Ack] 0C.80.93-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 06/10/2016 08:09:27 AM : [iNST-TX-I1 ] 02 62 23 7D A0 0F 11 FF Fri 06/10/2016 08:09:27 AM : [iNST-TX-I1 ] 02 62 00 00 16 CF 14 00 Fri 06/10/2016 08:09:27 AM : [iNST-ACK ] 02 62 00.00.36 CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:27 AM : [iNST-TX-I1 ] 02 62 00 00 5A CF 14 00 Fri 06/10/2016 08:09:27 AM : [iNST-ACK ] 02 62 10.A8.E0 0F 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:28 AM : [iNST-TX-I1 ] 02 62 00 00 30 CF 14 00 Fri 06/10/2016 08:09:28 AM : [iNST-TX-I1 ] 02 62 00 00 21 CF 14 00 Fri 06/10/2016 08:09:28 AM : [iNST-ACK ] 02 62 0C.80.93 0F 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:28 AM : [iNST-ACK ] 02 62 0C.80.93 0F 14 00 06 LTOFF-F(00): Duplicate or ACK for a different device Fri 06/10/2016 08:09:28 AM : [iNST-TX-I1 ] 02 62 23 7E 01 0F 11 FF Fri 06/10/2016 08:09:28 AM : [iNST-SRX ] 02 50 10.A8.E0 40.D1.EC 2B 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:28 AM : [std-Direct Ack] 10.A8.E0-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 06/10/2016 08:09:28 AM : [iNST-ACK ] 02 62 00.00.58 CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:28 AM : [iNST-SRX ] 02 50 10.A8.E0 40.D1.EC 23 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:28 AM : [std-Direct Ack] 10.A8.E0-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Fri 06/10/2016 08:09:29 AM : [iNST-ACK ] 02 62 00.00.18 CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:29 AM : [iNST-ACK ] 02 62 3D.2A.20 0F 11 FF 06 LTONRR (FF) Fri 06/10/2016 08:09:30 AM : [iNST-SRX ] 02 50 3D.2A.20 40.D1.EC 2B 11 FF LTONRR (FF) Fri 06/10/2016 08:09:30 AM : [std-Direct Ack] 3D.2A.20-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 06/10/2016 08:09:30 AM : [iNST-ACK ] 02 62 00.00.00 CF 11 FF 06 LTONRR (FF) Fri 06/10/2016 08:09:30 AM : [iNST-SRX ] 02 50 3D.2A.20 40.D1.EC 23 11 FF LTONRR (FF) Fri 06/10/2016 08:09:30 AM : [std-Direct Ack] 3D.2A.20-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Fri 06/10/2016 08:09:30 AM : [iNST-ACK ] 02 62 08.66.4B 0F 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:31 AM : [iNST-SRX ] 02 50 08.66.4B 40.D1.EC 2B 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:31 AM : [std-Direct Ack] 08.66.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 06/10/2016 08:09:31 AM : [iNST-SRX ] 02 50 08.66.4B 40.D1.EC 23 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:31 AM : [std-Direct Ack] 08.66.4B-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Fri 06/10/2016 08:09:31 AM : [iNST-ACK ] 02 62 23.7D.A0 0F 11 FF 06 LTONRR (FF) Fri 06/10/2016 08:09:31 AM : [iNST-SRX ] 02 50 23.7D.A0 40.D1.EC 2F 11 FF LTONRR (FF) Fri 06/10/2016 08:09:31 AM : [std-Direct Ack] 23.7D.A0-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Fri 06/10/2016 08:09:31 AM : [iNST-ACK ] 02 62 00.00.16 CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:32 AM : [iNST-ACK ] 02 62 00.00.5A CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:32 AM : [iNST-ACK ] 02 62 00.00.30 CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:33 AM : [iNST-ACK ] 02 62 00.00.21 CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:33 AM : [iNST-ACK ] 02 62 23.7E.01 0F 11 FF 06 LTONRR (FF) Fri 06/10/2016 08:09:33 AM : [iNST-SRX ] 02 50 23.7E.01 40.D1.EC 2F 11 FF LTONRR (FF) Fri 06/10/2016 08:09:33 AM : [std-Direct Ack] 23.7E.01-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Fri 06/10/2016 08:09:47 AM : [FileOpen ] Open failed for [/CONF/NET/WOL.CFG] ® Fri 06/10/2016 08:10:15 AM : [VAR 2 9 ] 0
LeeG Posted June 10, 2016 Posted June 10, 2016 I'm concerned about all the overlapping Insteon traffic. There are multiple cases. Fri 06/10/2016 08:09:16 AM : [VAR 2 9 ] 1 Fri 06/10/2016 08:09:16 AM : [iNST-TX-I1 ] 02 62 10 A8 E0 0F 14 00 Fri 06/10/2016 08:09:16 AM : [iNST-TX-I1 ] 02 62 0C 80 93 0F 14 00 Fri 06/10/2016 08:09:16 AM : [ Time] 08:09:25 11(0) Fri 06/10/2016 08:09:16 AM : [iNST-ACK ] 02 62 10.A8.E0 0F 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:16 AM : [iNST-SRX ] 02 50 10.A8.E0 40.D1.EC 2B 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:16 AM : [std-Direct Ack] 10.A8.E0-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 06/10/2016 08:09:16 AM : [iNST-ACK ] 02 62 0C.80.93 0F 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:17 AM : [iNST-SRX ] 02 50 0C.80.93 40.D1.EC 27 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:17 AM : [std-Direct Ack] 0C.80.93-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Fri 06/10/2016 08:09:17 AM : [iNST-SRX ] 02 50 0C.80.93 40.D1.EC 23 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:17 AM : [std-Direct Ack] 0C.80.93-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Fri 06/10/2016 08:09:17 AM : [iNST-TX-I1 ] 02 62 00 00 57 CF 14 00 Fri 06/10/2016 08:09:17 AM : [iNST-TX-I1 ] 02 62 00 00 36 CF 14 00 Fri 06/10/2016 08:09:17 AM : [iNST-TX-I1 ] 02 62 10 A8 E0 0F 14 00 Fri 06/10/2016 08:09:17 AM : [iNST-ACK ] 02 62 00.00.57 CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:17 AM : [iNST-TX-I1 ] 02 62 0C 80 93 0F 14 00 Fri 06/10/2016 08:09:18 AM : [iNST-ACK ] 02 62 00.00.36 CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:18 AM : [iNST-ACK ] 02 62 10.A8.E0 0F 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:19 AM : [iNST-SRX ] 02 50 10.A8.E0 40.D1.EC 2B 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:19 AM : [std-Direct Ack] 10.A8.E0-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 06/10/2016 08:09:19 AM : [iNST-ACK ] 02 62 0C.80.93 0F 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:19 AM : [iNST-TX-I1 ] 02 62 00 00 58 CF 14 00 Fri 06/10/2016 08:09:19 AM : [iNST-TX-I1 ] 02 62 00 00 18 CF 14 00 Fri 06/10/2016 08:09:19 AM : [iNST-ACK ] 02 62 00.00.58 CF 14 00 06 LTOFF-F(00) Fri 06/10/2016 08:09:20 AM : [iNST-SRX ] 02 50 0C.80.93 40.D1.EC 2B 14 00 LTOFF-F(00) Fri 06/10/2016 08:09:20 AM : [std-Direct Ack] 0C.80.93-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 I'm not concerned about the message you noted. The PLM sent a duplicate message but I see no bad effect and I've seen PLMs do that before.
MarkJames Posted June 10, 2016 Author Posted June 10, 2016 I've modified my energy saver programs by adding a 2 second wait between each scene that it turns off. Does that seem like a reasonable first step? mark
LeeG Posted June 10, 2016 Posted June 10, 2016 The Scene Fast Off does not get a response (normal) so not sure they are the issue. No harm in trying that though. The commands that I noted are Direct Fast Off to specific devices that are overlapping.
Recommended Posts