bclarke01

I'm having basically the same problem. Everything mysteriously stopped working with ISY unable to control anything and errors reported when ISY tries to query Insteon devices. Everything has worked fine for a couple of years so can't think of any recent changes that might result in this behavior. Power cycled both PLM and ISY and finally got things I thought working about 12:15 last night. At 2:00am, a very old program runs that shuts the house down and runs a query against the whole ISY network. All the queries returned errors and now the ISY is back to not being able to control anything. It can see changes instigated from keypads and switches, but is unable to make any changes on its own. It feels like there is a communication or synching problem to the PLM, but getting things working OK for awhile and then having them go awry again seems very strange. Yes, a ticket is opened with UDI support. I'll update this thread when I hear back. But for now, add me to the list of users experiencing this same problem.

Isn't that what "ISY" is? Many places in this forum and in some documents contain references to "scene ISY query". If I trace the activity during the ISY query function, it appears that ISY is walking the device list getting status from known devices. Am I really off-base thinking that "scene ISY on" would turn all the lights on? Not saying you're wrong; I certainly have a mix of devices going back many generations so your explanation makes sense but not in the direction I was hoping. My last house had over 125 devices; manually creating a single scene holding all of them would be a mess to manage.

In the Administrative Console (v 4.6.2), the homescreen displays an item "ISY" and shows three buttons: "Query", "All On" and "All Off". When I select "All Off", about half of my devices controlled by the ISY go off. The device screens show that all devices are On or Off, but in reality, they don't change state. If I select one of the devices that is still On after an "All Off" signal and ask for it to be Query'ed, the ISY does determine and reflect that the device is actually On. What might be the explanation? Any idea what might be causing this behavior?

Any chance it could be considered for the future to allow additional information to be collected in the logfiles such as variable state changes, program name invocations, etc? Perhaps even add a new programmable action "LOG" that would insert a text string along with the timestamp into the logfile? Just a thought.

I have a project with a geography too large for the standard Insteon mesh to reach from one end to the other (no path exists to propagate signal in the max of 3 hops). There is CAT5 run through the site so the use of multiple ISY is possible. But is there an easy way for a Program running on ISY-A to easily manipulate/query a device within range of ISY-B using the facilities of the optional Network module? I've added the Network module to the first ISY currently onsite. Looking for reassurance that this is feasible and relatively easy before investing in the second ISY. Thanks! Bruce Clarke

Installed 3.1.17 without issue last night. Then had to do some troubleshooting and noticed what I think is a change. Was I not able to see Insteon commands sent out from a keypad in the Diagnostics->Event Viewer before? I am now seeing only ISY-initiated commands being sent. And as reported earlier in the thread, changes made external to the ISY are no longer being reflected in the status screens unless the particular device is manually queried. So it feels like some non-ISY event tracking has been lost. Bruce Clarke

That was exactly it. I had never noticed that there was a scene "My Lighting" that had appeared without my actually creating it. Now that I have tried it, have observed an interesting effect; about 2/3 of my Insteon devices respond to it on the first try and the remainder on the second try. Anyone have an explanation for why this would be the case?

On the Network screen, there is a button All On / Off (or something like that). How do I access this from a ISY program? I would like to tell everything to turn off in the morning when I leave and then turn back on just a few things. Thanks!

I believe I got here by having used some of the Smarthome software to get started programming some scenes. I then made the mistake of bringing these into ISY without allowing it to clear the links. I went through a third of the switches and devices this morning first deleting all scenes defined for them, then removing them from ISY. I then did a factory reset on every single device. Next went through and allowed ISY to discover each of the products and went back through and created all the scenes just in ISY this time. I now have a solid implementation that seems to be complete and reliable. Had an interesting problem I'll pass on. Some devices, after being discovered by ISY, didn't want to accept programming. An error was returned during the programming and then then the diagnostic Show Device Links Table showed that it couldn't reach the device. Cure was to interrupt the power to these devices for a moment and return it. I'm guessing that they locked up for some reason and this was a form of soft reset. Whatever, it seemd to work. I have also found that subsequent corrective action pretty much must include deleting scenes and removing the device from ISY and then allowing it to learn it from scratch and clean the links table. Then scenes can be added or defined and will be clean and reliable. Apparently Insteon implementations are not quite standard and compatible at this point. I'm guessing that if I ask HCA or HouseLinc would probably not be very useful at this point (but frankly don't care to try). Thanks!

Unfortunately the suggested thread does not describe what interpretation to make for the output of the Compare command. That would be really helpful. Yes, some of the devices had links already in place when ISY "learned" them. But since then, all have been factory reset and restored by ISY. So if anything is now amiss in the device tables, ISY put it there. Bruce Clarke

I haven't had a chance to read the suggested link; will get there in a moment. Did just get the following display on the telnet session when I attempted to restore a KPL. http://192.168.0.9> LOGGER: -2 : n=[10 5 36 1] c=[ ] a=[ ] H_ERROR:-5012 : H_ERROR:-5012 : H_ERROR:-5012 : H_ERROR:-5011 : uuid:00:21:b9:00:d1:49,1 H_ERROR:-5011 : uuid:00:21:b9:00:d1:49,1 H_ERROR:-5011 : uuid:00:21:b9:00:d1:49,1 H_ERROR:-5011 : uuid:00:21:b9:00:d1:49,1 H_ERROR:-5011 : uuid:00:21:b9:00:d1:49,1 H_ERROR:-5011 : uuid:00:21:b9:00:d1:49,1 H_ERROR:-5011 : uuid:00:21:b9:00:d1:49,1 H_ERROR:-5011 : uuid:00:21:b9:00:d1:49,1 H_ERROR:-5011 : uuid:00:21:b9:00:d1:49,1 H_ERROR:-5011 : uuid:00:21:b9:00:d1:49,1 LOGGER:-5012 : n=[null] c=[null] a=[null] LOGGER:-5012 : n=[null] c=[null] a=[null] LOGGER:-5012 : n=[null] c=[null] a=[null] LOGGER:-5011 : n=[null] c=[uuid] a=[null] LOGGER:-5011 : n=[null] c=[uuid] a=[null] LOGGER:-5011 : n=[null] c=[uuid] a=[null] LOGGER:-5011 : n=[null] c=[uuid] a=[null] LOGGER:-5011 : n=[null] c=[uuid] a=[null] LOGGER:-5011 : n=[null] c=[uuid] a=[null] LOGGER:-5011 : n=[null] c=[uuid] a=[null] LOGGER:-5011 : n=[null] c=[uuid] a=[null] LOGGER:-5011 : n=[null] c=[uuid] a=[null] LOGGER:-5011 : n=[null] c=[uuid] a=[null] Does any of this suggest anything to you? Bruce Clarke

I have absolutely no idea. I do know that after I factory reset all controllers and devices and then run "ISY Restore" on all devices, I then run "Show Device Links table" on an 8 switch KPL and ask it to compare to the PLM, I get LOTS of "Extra Record" items. Specifically, "Show" reports the KPL having a count of 63 items in the memory. "Compare" reports that the first 25 are "Identical", the next 35 are "Extra Record" and the last three are "Ignore" (but are not zeros). So there is pretty consistently one or two keys out of the 8 that are misdirected. ISY detected this KPL as a 2486S/WH6 keypadLinc relay v.33 if that helps any. Is there a thread on the Wiki that describes how to read the output of the various diagnostics? Bruce Clarke

My setup presently is around 97 devices controlled by 30 KPLs and a handful of SwitchLincs. Periodically I like to reload the devices to ensure that they and ISY have the same idea of what is real. For some reason, I frequently get stray devices picked up into scenes unexpectedly. To restore devices it appears one can either request all devices or do them one at a time. With this many devices, the 'all' restore runs all night and is still not done in the morning. And this is usually overkill; there are usually only a handful of misbehaving controllers and devices Is there a way to only get the controllers and devices involved in a particular scene to be restored? Lacking that, is there a way to specify a handful of devices get restored rather than the entire system? Finally, it would be really nice if there was a separate log kept during the "all" restore of only those devices / controllers which failed to accept their programming. Scanning the log containing thousands and thousands of Insteon transactions is difficult when one is not sure what one is looking for. Bruce Clarke Los Altos, CA