Homebridge 1.3.1 / The read handler for the characteristic 'On' was slow to respond!
NorbertM21 opened this issue · 9 comments
[homebridge-http-switch] This plugin slows down Homebridge. The read handler for the characteristic 'On' was slow to respond! See https://git.io/JtMGR for more info.
Hi - any chance of updating the plugin to resolve this problem? Much appreciated.
This really depends on your setup. As the http-switch plugins queriers the http url you specify when it gets a request from HomeKit.
Thus, when the warning appears that a request handled by this plugin took longer than 3s (or longer) it really means that your http service was slow to respond and took longer than e.g 3 seconds to respond.
I can mitigate the warning (e.g. return early with a cached result) and use the updated value for the next request coming.
But I can't fix the problem, which is your http service being slow to respond.
To get a better understanding of the problem, it might help to get a log output to check how often this warning appears, or if it only appears within certain conditions (e.g. when multiple clients query at once). The plugin could indeed be advance such that multiple request coming (roughly at the same time) from different HomeKit clients result only in one http request to the http service.
As recommended in my Link above, I solved it for me:
getStatus: function (callback) {
const value = this.homebridgeService.getCharacteristic(Characteristic.On).value;
callback(null, value);
}
and than with a seperate
getStatusTT: function (callback) {
...
http.httpRequest(this.status, (error, response, body) => {
...
this.homebridgeService.getCharacteristic(Characteristic.On).updateValue(switchedOn);
...
}
Thats exactly what I meant with:
I can mitigate the warning (e.g. return early with a cached result) and use the updated value for the next request coming.
But I can't fix the problem, which is your http service being slow to respond.
This will e.g. not allow to immediately report errors back to HomeKit should e.g. the http request fail for some reason.
I'm not yet sure how to deal with that and if I really wan't to go the route you proposed.
@Supereg
this came up with Hombridge 1.3 (same problem with other plugins). Looks like they don't accept any delay to improve the system.
So I set pulltimer to a tempvalue of 100ms and get a quick response in HomeKit by getStatusTT - everything fine for me :-)
regards
this came up with Hombridge 1.3 (same problem with other plugins). Looks like they don't accept any delay to improve the system.
I know. I'm one of the guys who developed the warning system 🙃 Its about speeding about the general bridge, as the bridge is as slow to respond as the slowest plugin.
Its just, this requirements doesn't fit very fell for the use case of this plugin.
Though, of course, the plugin will need to adapt in one or another way, I just need to check how I make this change without breaking anybody's setup.
Hello,
Could you add the proposed workaround, this seems useful in any case :
I can mitigate the warning (e.g. return early with a cached result) and use the updated value for the next request coming.
But I can't fix the problem, which is your http service being slow to respond.
@matthieularge that's definitely the plan, though requires some minor architectural changes of the plugin.
I currently can't make any promises in regards to timing, don't want it to be a rushed, half baked change.
There is functionally and in terms of behavior no difference to running this plugin with previous versions of homebridge. Its just that homebridge v1.3.x starts to print the warning now.
strange, i have written the HTTP service i'm polling for the state on my own and it definetly doesn't take more than 3 seconds to respond, it's more like 50-100miliseconds for any request - but still i got these warnings printed after homebridge is running for like one two hours - for my taste, the states are pulled way too often as i see in the logs - sometimes two-three times in the same second...