Prevent the entire Homebridge from being blocked if PiHole is offline about homebridge-pihole

[arendruni]

Hi @snetwork-dev,
I understand the problem you're having, but by looking at the issue you referenced I don't think it's a good thing invoking the callback before the request has a received a response.

If you want to try and integrate this change you can open a PR and I will review it, so for now I'm leaving this issue open to see if other users have the same issue.

[arendruni]

Hey @snetwork-dev
I just released a new beta version of the plugin that should fix this issue (from #29), I skipped passing the value received from the http response to the Homebridge callback which does no longer need to wait for a value and shouldn’t block the entire Homebridge.
To test it you just need to add beta tag to the package name: npm install homebridge-pihole@beta. Please let me now if this does fix this "bug".

[snetwork-dev]

I just released a new beta version of the plugin that should fix this issue (from #29), I skipped passing the value received from the http response to the Homebridge callback which does no longer need to wait for a value and shouldn’t block the entire Homebridge.

I installed the beta version. Unfortunately, when the iOS / macOS home app is restarted, all devices are still displayed with "no answer" if the PiHole server cannot be reached.
As soon as you click on an individual device, however, it updates its status and can also be switched. Unfortunately this is not the right solution yet ...

[arendruni]

I tested the plugin with a slowed down mock server and I could reproduce the same scenario: Homebridge will hang till the plugin has received a status and all devices are displayed with "no answer". So, the main pain in this case is the callback on the GET status, which in this case must wait for a value, this is a protocol limitation of HAP, which only allows one concurrent request per connection and the request is blocking.