Restart IoX restarts Airthings plug-in

[johnnyt]

Hi @Jimbo.Automates,

Whenever I restart IoX both my active Airthings-C plug-ins restart. For one of them it causes the plug-in to exceed the API limit for multiple update cycles that can last up to 45 mins when I look back to previous restarts.

The plug-in that violates the API contract supports 9 devices with short poll of 330 (5 1/2 mins), which is sufficient in terms of not exceeding API limit (anything over 270 is enough) unless a plug-in restart occurs. The other active plug-in doesn't hit the API limit but it only has 4 devices and a 200 sec short poll.

Unfortunately, for several reasons I need to restart IoX with some regularity, meaning a regular violation of the API contract with Airthings. Ideally could you put in a delay of short poll duration at plug-in restart to ensure there is no API limit violation? Desirable would also be no automatic restart when one is just calling for an IoX restart. That seems like a bug to me but I see other plug-ins restart too so maybe there's a reason for it that I'm not seeing? I guess it's not a big deal if one doesn't have an API call limitation but is more problematic when there is one.

I will PM you my log (set to Info) for today. There was an automated restart just before 2AM and a manual one around 8:12 AM. Let me know if you need a lower level of debug logs. It's easy to change and replicate the issue.

Here's a screenshot showing how PG3 has been running for a couple of weeks now while the plug-in has only been running for less than an hour (when I took the screenshot).

Note that this has been happening for a while. i just haven't taken the time to report it until now. 

Thanks

 

[johnnyt]

Just to provide a visual, I have a program that notifies me by email when Airthings API Limit has been exceeded. Here's an example of what I get in my inbox when I restart IoX:

 

[Jimbo.Automates]

On startup the plugin must poll all to set initial values. I'll have to review the code but it should wait the defined time to poll again, but it might try more frequently after a failure.

But really you shouldn't need to restart IoX every day.

Sent from my Pixel 8 Pro using Tapatalk

[johnnyt]

Thanks for your reply.

Does the plug-in actually need to restart just because one restarted IoX? Can't IoX just read/pull the values still there in the plug-in table (if it hadn't been restarted) to set the initial values in the IoX nodes? I was assuming a pull was possible because I see a "Query" and "Query All" buttons in AC as well as the option do it in programs for the Airthings nodes.

If not / alternatively, can either a 'pull' function be added so a push is not needed (much cleaner), or something be added to stop/start the plug-in from a program in IoX? With the latter, one could write a program to stop the plug-in before doing an IoX restart (at least when it's a planned one), and another program that starts the plug-in 10 mins after IoX restarts. Or stop the plug-in when API Limit is exceeded, wait some period of time, then restart it.

 

You're right that one should not have to Restart IoX regularly. Unfortunately, I have a number of issues that UDI either can't reproduce (so can't fix) or won't fix for a while because they have other higher priorities and very limited capacity. One of the unresolved problems is IoX spontaneously restarting, which can happen at highly inopportune time. These happen after IoX has been running for a while so I'm managing the issue by automating restarts to happen in middle of the night when no one notices. Right now weekly restarts at 2AM has avoided random restarts. It also means cleaner shutdowns instead of the hard crash of a random one. I might stretch that to 2 weeks but it's unfortunately become a necessary evil to avoid inopportune restarts, at least until either I and/or UDI can find/fix the root cause. I'm not hopeful that will happen soon, if at all.

 

[johnnyt]

I was monitoring udx log during a Restart IoX and noticed that a restart of IoX does a restart of PG3 (twice, actually, in the test I monitored). See below. What's weird is that the uptime number for PG3 didn't/doesn't reflect this apparent PG3 restarts. It continues to show uptime since last system reboot (see my original post).
 

Thu Jul 31 08:25:58 EDT 2025|/usr/local/etc/udx.d/static/udx_startup.sh: stopping isy service ...
Thu Jul 31 08:26:05 EDT 2025|/usr/local/etc/udx.d/static/udx_startup.sh: starting isy service ...
Thu Jul 31 08:26:05 EDT 2025|/usr/local/etc/udx.d/static/udx_startup.sh: starting pg3x service ...
Thu Jul 31 08:26:05 EDT 2025|/usr/local/etc/udx.d/static/udx_startup.sh: starting ud_pkg_stat service ...
Thu Jul 31 08:26:05 EDT 2025|/usr/local/etc/udx.d/static/udx_startup.sh: successfully started udx 3.9.0_9
Thu Jul 31 08:26:05 EDT 2025|/usr/local/etc/udx.d/static/udx_startup.sh: isy id = 349
Thu Jul 31 08:26:05 EDT 2025|/usr/local/etc/udx.d/static/udx_startup.sh: polyglot id = 349
Thu Jul 31 08:26:05 EDT 2025|/usr/local/etc/udx.d/static/udx_startup.sh: /etc/rc.conf has matter support
Thu Jul 31 08:26:05 EDT 2025|/usr/local/etc/udx.d/static/ud_pkg_stat: wifi.ops is not being called as a comamnd
Thu Jul 31 08:26:08 EDT 2025|/usr/local/etc/udx.d/static/udx_startup.sh: restarting pg3x because it didn't start 0 ...
Thu Jul 31 08:26:11 EDT 2025|/usr/local/etc/udx.d/static/udx_startup.sh: pg3x started successfully ...
 

I guess this means there's nothing you can do about the Airthings plug-in restarting when IoX restarts? So what about storing the short poll timing somewhere and recalling it at startup so the plug-in never exceeds the API limit? Similar to the INIT function in IoX.

Thanks for considering it.