MarkJames

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

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

Thanks. I'll clear my cache and download the newest UI Much appreciated, mark

Interesting.... That does, indeed, take away the white box. I'm used to seeing the blue ones with the device name in them when I open the admin console and have some unreachable devices. The white one with no device listed is confusing, though. Is that a 'hiccup' of some sort? mark

There will be 2 or 3 devices that say 'failed communicating with' behind the white one. I have a couple of outlets that have no power to them so they're not reachable. Those ones are all blue and have device names attached. Are you saying that this white box is somehow related to the other ones? I do use the admin.jnlp link on my desktop - I have to as I use Chrome. mark

Thanks Michel.... Which device, though? It doesn't tell me.... I've had this message before but it always tells me which device and the message box is blue. This message box is white and lists no device. mark

I've been getting this message for some time now. Any thoughts on how to resolve it? Here's a screen grab.

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

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?

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

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

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!

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

I don't have any add-on boards - just the Elk and Web modules but those are just software. It always ran OK with just 200mA - but I never noticed this UPS problem as the power doesn't fail that often. Always good to have a slightly larger than necessary psu than one that's bordering on not enough, though. mark

Thanks - experience is always the best teacher. I couldn't count the hours I've spent troubleshooting Windows issues having started with Windows on an Apple PC and migrated along with it from 3.1 to 95 to 98 to XP, ME, Vista, 7, 8, and 10 along with being an MCSE and maintaining a 300 user environment running under NT. I usually troubleshoot problems WAY faster than the folks I've worked with - not cuz I'm smarter - just cuz I've probably already wasted 3 days somewhere in my past finding out what they're trying to solve. I'll separate them out on the UPS - I have 4 UPS's in my closet so whatever I plug into it's going to have potential issues with something else unless I get a separate UPS for each device and that's just not within my pocketbook. Thanks again, mark

on a separate power strip? Or on separate outlets on the same UPS? I only ask because it's a bit of a proximity issue. mark

I replaced the power supply and can confirm that it's now working properly. The specs from the ISY said 5-30V but 300mA minimum. My psu at 200mA must have been threshold. All is good now happily Thanks so much for the help! mark

It looks like the original got swapped around sometime over the years. This is a replacement to my original ISY 99ir. The adapter is a 9V 200mA one. I have a 12V 1.5A one I can swap with - is 12V within range of the ISY? I can try that instead. [edit] I looked up the specs and I should be good till 30V Looks like 200mA was too small for the ISY as well - perhaps that was part of the problem I've swapped it to 12VDC 1.5A - and will report back

I'll try that but at the moment I've got a 10.14gig file downloading so I've gotta wait a bit. Could it be that the wall wart I'm using to power the ISY doesn't regulate well at 109 or so volts? mark

As an aside - if I follow minimum voltage as I unplug the UPS the voltage drops as low as 109.1. Perhaps I need a more well regulated power supply for the ISY? mark

Same problem I'm afraid. Within a session it immediately goes to Socket failed open.... - ISY reboots and catchup happens again.

The ISY is plugged into a power bar with those 4 devices (2 routers, ISY and cable modem). The power bar is plugged into the master backed up outlet on the UPS. The meter is plugged into 1 of the adjacent battery backed up outlets

Using my Fluke 87V I get 112.4V while powered and 115.6 under battery backup mark [edit] using min/max - under power I get a min of 111.5 and a max of 115.8

So this is probably not related to my ISY but I'm a bit confused by this so I thought I'd start here. I have a 994 controlling my home. I just bought a new UPS - an APC2500 - to maintain/protect a few devices. It has the 994, my Asus router, a VoIP router, and my cable modem all plugged into it - so all low current devices. The UPS is plugged in and fully charged. For some reason when I unplug the power to the UPS - simulating power loss - it seems to do what it's supposed to do and everything stays powered up - but the ISY restarts. The cable modem and 2 routers don't even flinch but the ISY reboots. I can't 'see' it reboot - the lights remain lit - but any sessions will be dropped and a 'catch-up' occurs. I've checked that things are plugged in properly - in my last trial I plugged everything into a power bar and the power bar into the backed up port on the UPS - but the ISY still reboots. This is likely a UPS problem - but any ideas? mark

That's not what I'm saying. What I'm saying is that it acts as if the program condition is being evaluated despite the folder condition being false. I don't know exactly what's going on but what it looks like is that the program condition gets evaluated and runs because it's true - motion *has* been detected. The thing is that it shouldn't get as far as evaluating the program condition because the folder condition is false. As posted above - I tried both integer and state variables and find that both result in an instant change in folder status. So I don't believe that the type of variable is the issue. What would be interesting to know is if ISY continually evaluates program conditions - even in folders that are false - and then when the program is true decides whether to run them on the basis of whether the folder is true. I would suspect it would be the contrary - that so long as the folder is false it wouldn't look at the program at all.