Do not block home bridge updates

[okonet]

It feels like thet backoff feature blocks the Home.app / home bridge update until completed. Which means, in worst case with the default config it takes 3200ms for the home app to update the status of all devices connected via home bridge. I'm not sure why this is happening yet but I blame this plugin since it didn't happen before and it's consistent with delays printed in the logs.

@vieira maybe you can point me into right direction but I'd like the updates to be optimistic and then do the real query. Feasible?

[vieira]

I am not sure if I remember correctly, but I think that's one of the approaches I tried, however it was not possible to call the callback that homebridge passes twice, i.e., when I tried to react optimistically it would work, but then, when the real query would come back the second call of callback (e.g. on

homebridge-yeelight-wifi/bulbs/bulb.js

Lines 193 to 200 in 865db8c

	.on('set', async (value, callback) => {
	try {
	await this.setPower(value);
	callback(null, value);
	} catch (err) {
	callback(err, this.power);
	}
	})

) would produce an error. This might have changed meanwhile, I have not tried again in a long while.

An alternative might be to react optimistically but proactively broadcast discover messages and update the acessory status when these messages are received from the lamps with their current state. This might introduce some noise in the network and might let the lamps show a wrong state for a while in HomeKit (until we hear something back from them).

Currently, there are configuration options under connection, namely, retries and timeout that can be tweaked to reduce the delay if you are confident that the connection to the lamps is good and if they don't reply it's because they are turned off or something.

[okonet]

Interesting... I'll poke this part of code a bit to see if things has been improved on HomeKit side.

I'm in a situation where most lamps are actually not connected to the grid most of the time. So ideal behavior for me would be to wait till their appear online and then sync the state (and actually send the changes that accumulated in the meantime to them). But maybe that's also a wrong strategy. Not sure.

I choose your plugin because it's actually the only one that works reliable with this kind of behavior (lamps being offline and becoming online later).

[vieira]

Ah ok, I see. To be honest that use case was not my main motivation as I kept them, mostly, always connected.

However for some reason, they would frequently fail to respond to commands or become unreachable for a few seconds, that's why the default config retries for so long.

Maybe it's worth trying to reduce the number of retries and the timeout and experiment to see if it works better for your needs, at least until a better strategy can be found.

[okonet]

Yeah I had same issues with them also then they were connected to the grid. I'll experiment with settings and try something out if I'll find time.

[RealDyllon]

@okonet slightly unrelated to the actual issue, but what I did was put the Yeelight plugin in a different homebridge instance, so when it froze during updating, my other devices were still functional.

I used pm2 to manage the different hombridge instances.

[vieira]

I would recommend looking into homebridge child bridges which is a easy way of having this plugin run on its own process and not blocking the main bridge when bulbs are slow to respond.