Plugin slows down homebridge if destination is unreachable

[Zer0x00]

Issue Summary: A blinds control unit in my setup is temporarily malfunctioning and has become unreachable. This issue is causing a significant slowdown in the entire Homebridge system, rather than just triggering periodic warnings.

Detailed Description:

- Current Behavior: When one of the blinds control units fails, instead of generating a warning at regular intervals, it is noticeably slowing down the entire Homebridge system. - Expected Behavior: The system should handle the unreachable unit by issuing warnings without impacting overall performance. - Workaround Mentioned: While using child bridges is a suggested workaround, it should not be a necessary step for handling such issues.

Attached Logs: Below are the logs from the malfunctioning blinds control unit for further diagnosis.

[28/12/2023, 12:21:31] [Blind1] Error sending request (HTTP status code not defined): Error: connect EHOSTUNREACH 192.168.0.151:80
[28/12/2023, 12:21:31] [Blind1] undefined attempt(s) failed after 14694 ms
[28/12/2023, 12:21:31] [Blind1] Body: undefined
[28/12/2023, 12:21:31] [Blind1] setCurrentPositionByUrl failed; invalid response (should be 0-100): (missing or error)
[28/12/2023, 12:21:37] [Blind1] Error sending request (HTTP status code not defined): Error: connect EHOSTUNREACH 192.168.0.151:80
[28/12/2023, 12:21:37] [Blind1] undefined attempt(s) failed after 13110 ms
[28/12/2023, 12:21:37] [Blind1] Body: undefined
[28/12/2023, 12:21:37] [Blind1] setCurrentPositionByUrl failed; invalid response (should be 0-100): (missing or error)
[28/12/2023, 12:21:46] [Blind1] Error sending request (HTTP status code not defined): Error: connect EHOSTUNREACH 192.168.0.151:80
[28/12/2023, 12:21:46] [Blind1] undefined attempt(s) failed after 15294 ms
[28/12/2023, 12:21:46] [Blind1] Body: undefined
[28/12/2023, 12:21:46] [Blind1] setCurrentPositionByUrl failed; invalid response (should be 0-100): (missing or error)
[28/12/2023, 12:21:59] [Blind1] Error sending request (HTTP status code not defined): Error: connect EHOSTUNREACH 192.168.0.151:80
[28/12/2023, 12:21:59] [Blind1] undefined attempt(s) failed after 12775 ms
[28/12/2023, 12:21:59] [Blind1] Body: undefined
[28/12/2023, 12:21:59] [Blind1] setCurrentPositionByUrl failed; invalid response (should be 0-100): (missing or error)
[28/12/2023, 12:22:00] [homebridge-blinds] This plugin slows down Homebridge. The read handler for the characteristic 'Current Position' was slow to respond! See https://homebridge.io/w/JtMGR for more info.
[28/12/2023, 12:22:06] [homebridge-blinds] This plugin slows down Homebridge. The read handler for the characteristic 'Current Position' didn't respond at all!. Please check that you properly call the callback! See https://homebridge.io/w/JtMGR for more info.

[dxdc]

I'm not sure that other plugins gracefully handle this situation. PRs are welcome to specifically handle network connection issues.

For the moment, you can disable retries by setting maxAttempts to 1 or just disable this blind until you have your network issues fixed.

[dxdc]

You can also try setting the timeout parameter to something shorter, or tuning other settings for the requests / requestsretry packages. But, I'm not sure if this will work for EHOSTUNREACH. Those plugins consume the HTTP parameters.

    "up_url": {
        "url": "http://1.2.3.4/window/up?pos=%%POS%%",
        "body": "{}",
        "headers": {
            "API-Token": "aaabbbcccddd"
        },
        "method": "PUT",
        "maxAttempts": 5,
        "timeout": 1000,
        "retryDelay": 2000,
        "time": true
    },

[Zer0x00]

It isn't a major problem for me, I just removed the accessory for the time being.

Just wanted to notify you. Feel free to close it if fixing it would take too much time.

[dxdc]

What you describe is a general problem with HTTP connections where the network request times out, and I'm not sure other plugins handle this situation gracefully either. For example, the popular homebridge-http-switch which relies on homebridge-http-base appears like it would have the same problem, but I haven't tested it personally.

One option of course would be to internally disable the plugin for some amount of time if this error occurred, but I can see cases where people may not find that desirable.

Can you try the timeout setting I mentioned on your end? If you have a different proposal to implement this, I'm open to hearing about it, but since it's definitely not a general problem for most users (rather, a situation with your/intermittent network connectivity) I'm not sure when I would be able to get around to investigating it.

[Zer0x00]

I tried the timeoutsetting but unfortunately it didn't have any effects.