stillwater

I can see from the ISY Event Log that when the Query All program ran 4 buttons (E,F,G,H) on a particular KPL changed their Status to ON in ISY. (However the lights in those buttons never turned on). Two of these buttons have zero role in my ISY programs or scenes. One (G) is a responder to a scene and also is tested in a program to open a window when the button is ON. I have seen other forum entries suggesting that a failing KPL or PLM or communication issues may be to blame. My insteon network is usually very reliable -- many nearby dual band devices, a phase bridge, noise generators/signal suckers isolated behind filters, etc. We did have recent power failures during which my UPS that powers the ISY ran out of battery, as well as lightning storms though my house is protected by various devices. I can turn off the program that opens the window during the time the Query All is active and reset the button to OFF in ISY based on the corresponding scene before reactivating the program, so I have already acted to avoid having the window open in the future. I have factory reset the KPL and restored from ISY. Will watch to see what happens in future nights. (Will set Event Log to level 3) My immediate question is: If I had tested in the program on the CONTROL is Switched ON rather than Status is ON would the change in Status in ISY based on Query ALL have triggered the program? I am running an ISY994i Pro with 5.0.16C RC1 though I doubt the software version is material here. Insteon devices through PLM and a home-brewed raspberry PI node server and various network resources and rest interconnections but no ZWAVE. I checked that nothing in the network interconnections was changing the state of the KPL or scenes. Thanks for any illumination on this.

Now it appears to be working normally (with an error log with only a couple of handfuls of lines)

Yes using the 16B console and firmware. Rebooting did not change anything. I clicked to clear the error log while the cursor was still rotating and the file menu appeared to save the log, and indeed the log was saved properly (with content back to October). The log was not cleared despite having said yes to clearing it. After the log was saved to a file then perhaps I was able to clear the log (when I tried to access the log after clearing it I get an error message (first could not access some portal file and then "request failed", which is the error it gives now. So I'll follow up later after it generates some content for the log (?). I see the last time I tried to generate an error log was on 5.0.15A on October 11 so I don't know when this behavior started

5.0.16B is working great for me ... with one possible exception... I have no reason to believe this is a problem specific to 5.0.16b but also no way to know it is more general. I tried to view the error log from the Tools menu in Admin Console and the cursor turns into a circular "working" icon but other than that nothing happens-- for over 9 hours... Admin console functionality is fully available with the funny cursor. I vaguely remember that some months back I increased the size of the error log so maybe the problem is related to that. I am open to any suggestions that would help diagnosis. I don't really have a serious need to look at the error log, so I could try to clear it and then see what happens. Happy New Year!

Upgraded from 5.0.15A to 5.0.16 on two ISYs without any issues. Thanks!

Oh. Of course. I was being completely stupid. The ISY is ending the message to itself via the internet to the portal and back. I will do this!

Thanks @bmercier That's very helpful but it introduces a separate point of failure (the external computer that needs to talk to the ISY over the internet every 5 minutes). I was hoping for something built in to the ISY portal itself that would not require active intervention from an outside computer. What I was thinking of was that the ISY would periodically ping or otherwise communicate with the portal server (assuming there is such a thing) and if it didn't get a response then it could take an action (in my case run a program that would turn power off to the router and modem and turn it back on). This presumes that the portal server is up with high reliability. Of course it doesn't have to be the ISY portal that is the outside server performing this function. For example The ISY already set up to periodically get time information from a NTP server or pool. If there were a system variable to indicate whether this update had succeeded, that could be used as the trigger for a program -- that would be all that I would need, thought it would be best if it could retry and only provide the "failure" signal after a couple of retries.

I am wondering whether the ISY994i connected to the ISY Portal can trigger a program (or, the equivalently, set a state variable) when internet connectivity is lost -- enabling ISY to reboot a router or modem (via insteon outlet or relay) to attempt to restore internet.

Thanks to both of you. The Insteon Command Table was something I hadn't seen before.

I think somewhere on the UDI site there is documentation of the format and content of insteon messages (as accessed via a web socket) but I can't remember where and couldn't find it with searches I thought to try.... I'd be grateful for a steer in the right direction (or better, a link), and I apologize in advance because I'm probably missing something obvious Thanks