johnnyt

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

Smooth upgrade, although lots of stuff to upgrade so need to give it time. Thanks SO MUCH for fixing the backup process! Went from > 10 mins (with, remarkably, the Java Launcher consuming > 80% of CPU throughout) down to about a second. Will no longer be hesitant/strategic about doing them when I'm making lots of changes. Can anything be done to improve program loading speed too? Well before I reached 1000 (now at 1200), it's also been a start-and-go-grab-a-coffee kind of process. Thanks again.

Should eisy be able to see a Hue motion sensor connected to the Hue bridge? I see the hue bridge and a hue bulb no problem in eisy. I can also see the motion sensor (and its activity) in the Hue app but it doesn't come up as a node in PG3x or Admin Console.

Thanks for the alternatives. Question about "init". I do init my counters at regular intervals throughout the day, or when they are infrequently updated. I'm under the impression (from my early 994i days with 512MB SD Card) that "init" wears the SD card and needs to be done with some care. With probably >50 counters, many of them being incremented every minute or every time there's motion, I didn't want to init them each time I incremented them. Is that an old concern now that storage is abundant with, I think, wear leveling happening? I may just init everytime I change a counter.

Thanks @Geddy I can get eisy/Polisy to commit suicide using my Digital Loggers Webswitch or by configuring one of a few zwave outlets that has auto-ON-after-OFF capability but, like you, worry about the risk/cost of doing that. An important cost for me is that whenever I do a reboot or IoX restart, I first run a program that saves a bunch of variables that I use as usage counters and to control some devices. I do the latter so that when I replace a device I only need to change one program - the one that changes the variable. I lose a lot if/when there's a hard stop. If no one knows of a way to do a graceful OS and/or PG3 restart from IoX program, I guess I'll submit a feature request. I would actually like to see the ability to configure a program (using AC) to run before IoX does a restart of itself or reboots the hardware. Kind of like a "Run At Shutdown" feature.