Solved the issue.
As noted, the sensor_info.py script did succeed, but took 2 minutes 30 seconds to execute, which exceeded the 120 second timeout.
Running the script as "python3 -m trace --trace ./sensor_info.py" showed that the culprit was:
connection.py line 73 sock.connect(sa), which paused for 2 minutes and 30 seconds before succeeding.
This indicated to me that it was likely that the script was first trying to connect with IPv6, timing out, and reverting to IPv4.
I do not run IPv6 on my internal networks, so I found the (new?) setting under system>settings>general to "prefer IPv4 over IPv6" when both are present.
Note that m ISP supports both IPv4 and IPv6, so apparently the fact that the WAN interface had an IPv6 address, even though the LAN interface did not configure IPv4 was enough for the software to consider IPv6 was configured and to try to use that address.
Selecting "prefer IPv4 over IPv6" solved the issue.
As noted, the sensor_info.py script did succeed, but took 2 minutes 30 seconds to execute, which exceeded the 120 second timeout.
Running the script as "python3 -m trace --trace ./sensor_info.py" showed that the culprit was:
connection.py line 73 sock.connect(sa), which paused for 2 minutes and 30 seconds before succeeding.
This indicated to me that it was likely that the script was first trying to connect with IPv6, timing out, and reverting to IPv4.
I do not run IPv6 on my internal networks, so I found the (new?) setting under system>settings>general to "prefer IPv4 over IPv6" when both are present.
Note that m ISP supports both IPv4 and IPv6, so apparently the fact that the WAN interface had an IPv6 address, even though the LAN interface did not configure IPv4 was enough for the software to consider IPv6 was configured and to try to use that address.
Selecting "prefer IPv4 over IPv6" solved the issue.
"