-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a configurable delay between commands #28
Comments
Hi @ScoutKBT - thanks for your kind words, glad you're (mostly) finding the plugin useful 😄 Regarding the issue you've described above: each accessory managed by the plugin sends requests independently, but they actually do use a 250ms delay between retries if they haven't received acknowledgement from the hub within that time limit, and they'll retry twice before giving up. I've just published a beta version, |
Thanks, will try this out. Can you provide sample config syntax? This is my first dive into the homebridge world. Appreciate it!
|
@ScoutKBT: the best way to set these is via the plugin's UI configuration, as shown below:
|
One thing I notice about your config is that it contains the following line:
This looks like an old setting from an earlier version of the plugin, when it only accepted a single hub IP. The plugin may therefore be ignoring this value entirely. You can check whether this is the case by restarting Homebridge and looking for the following message in the logs:
If you see this message, it's possible that the outdated configuration setting is the source of the problem you've been having, since requests will be sent via multicast rather than directly to the hub's IP. Before adjusting the
|
I'm using Hoobs so the GUI config looks like this: I am using the beta (see right side "installed" panel): So I had been seeing the 'no device IPs' error and wondered why (now I know thanks!!). Using the new config got rid of that error and dramatically improved reliability. I was getting a lot of no response errors in the Apple Home app and those are now gone. I can now trigger scenes without a failure until device #22. It consistently fails at device 22. I still think you are just sending the first-try commands to the hub too quickly. But I'll test out the retry later this week to see if it helps. Thanks again! |
Hey @ScoutKBT, thanks for the update! Pretty strange that Hoobs doesn't seem to update the GUI config to reflect changes in the plugin - that config screen is very outdated at this point, it's missing most of the options that are now available. Glad to hear that the responsiveness has improved, let me know how your experiments with max retries and retry delay turn out! |
Update: I set max retries to 3 and the delay to 2 seconds and have been able to trigger a 26 device scene from homekit several times without issue so I think this worked well! I have not experimented to with lower values. |
@ScoutKBT: excellent, happy to hear that the issue has been fixed! I'll go ahead and promote this beta version to a full release 😄 |
I’d say it’s been worked around. I think the fix is reducing the transaction rate of the initial request. A retransmission should not be the defacto fix to what appears to be a buffer overrun when there is a large number of devices being targeted in one action. But either way, without a doubt the retry adjustment is useful for this and possibly other scenarios and should remain. |
Problem: I have 26 Alta shades on one of their USB>Wifi bridges. One of my HomeKit scenes attempts to adjust 17 shades and pretty consistently fails at #15 or 16 through 17.
I noticed that the plugin appears to control all of them in the span of 1 second. I suspect it's filling a buffer on the Alta USB bridge.
Interestingly, the Alta Bliss app can execute the same scene scope flawlessly. I don't think the Alta USB bridge knows or cares how many shades you have or how many are in a scene because I suspect its shade capacity comes down to buffer size. So the speed the commands are issued is key to its capacity. When I use the Alta Bliss app it appears to trigger this 17 shade scene over the course of at least 5 seconds, based on when I can see them start moving. This would imply an approximate average 250ms delay between commands, though exactly how the app handles this is not totally clear. It may send the first 10-15 commands as quickly as the code can execute and then send the rest slower or it may just take the simple route and always use a 250ms or similar delay.
Therefore, what would be useful is to be able to set an optional config for a delay in ms between commands sent to the bridge. Extending the execution time to increase reliability is a good trade for something as slow as a shade.
Some log output from my 17 shade scene:
Great work with this project! Let me know where I can donate.
The text was updated successfully, but these errors were encountered: