johnnyt

the CL command to change the log size does not work using SSH lowercase either

Not surprised. So how do I increase the log size in eISY? My log file rotates after about a day and a half and getting at and reading the old files for days past is a PIA.

Am trying to increase my log file file size using the CL command outlined here https://wiki.universal-devices.com/ISY-99i/ISY-26_INSTEON:Advanced_Configuration_Guide by telnet'ing into eISY following the instructions here https://wiki.universal-devices.com/ISY-99i/ISY-26_INSTEON:Quick_Start_Guide#Connecting_to_the_ISY_Shell but I get a message "Could not open connection..." Is this an outdated way of doing it? Is there a way to do this using Putty/SSH (which is working fine)?

I make *extensive* use of this capability. I don't know how people troubleshoot anything more than simple problems with just the log and error log. (Full disclosure: I have over 1300 programs) I just wish I didn't have to click every small '+' sign to get to the folder where the files are each time I go to the web server tab. I also wish there was a better folder view with last changed date/time, file size, and files sortable by those various columns. Be aware that the data is NOT backed up as part of the backup function. You need to go pull the files manually and it's a bit of a process because they are in a folder with restricted access.

I removed an airthings device by deleting it using the plug-in config page and after that the following error kept happening every short poll: 2024-09-22 13:24:04.648 Thread-107 (handler_poll) udi_interface ERROR pgSession:response: Not Found: https://ext-api.airthings.com/v1//devices/3220001054/latest-samples: text: {"error":"NOT_FOUND","error_description":"segment for user <myapikey> does not exist"} 2024-09-22 13:24:04.648 Thread-107 (handler_poll) udi_interface ERROR Controller:api_get: failed to parse res={'code': 404, 'data': {'error': 'NOT_FOUND', 'error_description': 'segment for user <myapikey> does not exist'}} Traceback (most recent call last): File "/var/polyglot/pg3/ns/<myeisy>_8/nodes/Controller.py", line 251, in api_get LOGGER.warning(f"Service returned code {code} {res['data']['message']}") ~~~~~~~~~~~^^^^^^^^^^^ This caused the "server status" in IoX to become false and it triggered a program to notify me of that every short poll. I didn't notice until I checked my email later to see an inbox full of notifications. It's like the polling temporarily changes the status to something other than false but then back to false, causing the program to trigger each time. IMO, I should have only received one notification when it went false the first time. The problem stopped after I restarted the plug-in but I'd suggest that, if possible, some cleaning up could be done within the plug-in when one deletes a node so one does not have to restart to avoid this error. Alternatively the plug-in could restart itself (if that's possible) or a message to restart the plug-in could be provided, although these are less elegant solutions. The problem with restarts is that they reset the polling timer to zero, which causes the API limit to be reached. Of course this is not critical. Just something to maybe consider the next time the plug-in is opened up for changes. Thanks for all the good work you've done on this plug-in to make using these devices in my automation possible.

The other error has not re-occurred. Maybe I just needed to reboot/restart PG3. (I did a reboot)

It happened again the night after I installed 1.2.2 so I went in and turned on debug log level (because the reinstall returned log level to warning only) but it hasn't happened since. Maybe I needed to restart PG3, which I think I did later the next day. Anyway, all is good now. Thanks

Hold on publishing that change. I got a ton of these errors last night again, which you suggested was fixed in 1.2.2: Have turned on debug level for logs - hopefully it happens again soon. Could be tonight because it's been happening almost daily since I reported it. It requires a restart, which then causes API limit to be reached not long after the restart. I wish there was a way to stop/start plug-in from IoX so I could heal things programmatically instead of manually.

Well the long poll does matter because if user picks a short poll that's longer than the long poll using the GUI, it won't stick. I'm not sure what the heartbeat is all about for this, anyway. Is the number important for something, i.e. could I set it to 10000 or something ridiculous? Is it something one can use for anything? Thanks.

I did notice today that if I change short poll using the GUI and the long poll is the same or shorter than the number I set, it changes it back (or changes it to long poll - not sure. It was the same in my case). So I had to go into plug-in config to first change long poll to something longer. There was no message about this in the GUI. I just knew the issue from having gotten the message doing that in plug-in config. You may need to add long poll to GUI and have a message pop-up there if the numbers don't work if you want to keep things this way.

ok, i now see the option to set auto short poll in Admin Console. Did not notice that before. A good place for that would be on config page for plug-in right below the poll config info. When I reinstalled plug-in to get 1.2.2, it set the values too low for all three of my instances. Correct me if I'm wrong but I'm now having to choose between always having to change polling every update vs. having the plug-in change it for me to the minimum it calculates and overwriting any change I make the next time it reads data. Could the plug-in not just leave any existing short poll setting alone at restart and during data updates? Or at least during data updates? The latter is the bigger flaw in this. I understand if a timestamp solution is too complicated. Yes, there are more beneficial things to work on if it's not an easy thing. As long as Airthings continues to only temporarily block things when over the limit, it's not major issue. Thanks

I upgraded to 1.2.1 and it sets short poll to the minimum for devices, which is good, but it keeps resetting it to that minimum over again after I change it to something longer. I suspect it's during the next polling cycle because It doesn't happen right away. Part of my reason for setting it longer is that it helps prevent hitting API rate limit for those times when I have to restart the plug-in or reboot. (I have 8 devices.) While this isn't a daily thing, of course, it often comes in clumps with more than one restart, which ends up blowing the limit. With this in mind, in addition to letting people be able to set their own short poll, could the plug-in save a timestamp of the last time it did a poll such that it lives through restarts?

No problem. I noticed the messages started before midnight so I went to grab yesterday's log file from the archive and PM'ed that file too. There appears to have been some successful updates before 2AM but then things got stuck repeating the error. Thanks.

@Jimbo.Automates, it happened again overnight only this time there was no sign of API limit or any other problem. At least not to me. I had to restart the plug-in to get data updates to resume. After last time I changed log level to Debug and will send you today's log via PM.

I noticed that my ISY nodes for Airthings weren't getting updated today so I checked logs and found a boat load of these sequences: 2024-07-16 03:02:30.244 Thread-867 (handler_poll) udi_interface ERROR Controller:_query_all: Previous query still running 2024-07-16 03:02:30.244 Thread-867 (handler_poll) udi_interface INFO Controller:shortPoll: exit 2024-07-16 03:07:00.248 Thread-869 (handler_poll) udi_interface INFO Controller:shortPoll: enter 2024-07-16 03:07:00.248 Thread-869 (handler_poll) udi_interface INFO Controller:_query_all: enter 2024-07-16 03:07:00.248 Thread-869 (handler_poll) udi_interface ERROR Controller:_query_all: Previous query still running 2024-07-16 03:07:00.248 Thread-869 (handler_poll) udi_interface INFO Controller:shortPoll: exit 2024-07-16 03:11:30.249 Thread-870 (handler_poll) udi_interface INFO Controller:shortPoll: enter 2024-07-16 03:11:30.249 Thread-870 (handler_poll) udi_interface INFO Controller:_query_all: enter 2024-07-16 03:11:30.250 Thread-870 (handler_poll) udi_interface ERROR Controller:_query_all: Previous query still running 2024-07-16 03:11:30.250 Thread-870 (handler_poll) udi_interface INFO Controller:shortPoll: exit 2024-07-16 03:16:00.259 Thread-872 (handler_poll) udi_interface INFO Controller:shortPoll: enter 2024-07-16 03:16:00.259 Thread-872 (handler_poll) udi_interface INFO Controller:_query_all: enter While there appears to have been an update made around 2AM early this morning, the log before and after that update is just full of the above messages I did make some tweaks yesterday that included changing short poll time and doing a restart. This did result in reaching the API limit but only once, which I blamed on the restart causing some short shifting. Maybe, though, reaching the API limit (even only once) caused the problem? I've had API limit messages in the past but things always sorted themselves out assuming short poll is reasonable (I always set it above 30 X number of devices). A restart of the plug-in did fix the problem - at least for now. Airthings-C_7-16-2024_113452_AM.zip