WTH: Hard coded connection timeouts in integrations - why not configurable?

A while back I raised a specific connection timeout issue for a particular UI only integration - I’ve worked around it on my installation by modifying the hard-coded connection timeout in the code. I’m reasonably comfortable doing this as I have a development background (albeit not in Python), however I’ll need to remember and maintain that change until any fix is deployed.

In my specific integration case, increasing a connection timeout from 2 seconds to 3 prevented the component from becoming unavailable for 5 seconds multiple times per hour despite running on a good quality internal network.

However, given the Month of WTH and the frequency that connection timeouts seem to be reported as issues for different integrations, I have to ask why they are being hard coded rather than made available as a configuration option?

The various flavours of HA are used in a variety of installation methods and a range of hardware on networks from no internet access to high-end fibre.
Given this, it would seem reasonable to surface any connection timeouts (within an acceptable range) for adjustment by users to prevent slow connectivity and static in the logs.

NB: I appreciate that this might place additional load on integration code-owners, and I’m not suggesting that this should be ‘big-bang’ mandatory requirement but perhaps something to aim for?

Even a global setting would be nice. I have the same issue from time to time while running ha on a backup 4g link.

1 Like