Skip to content
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

Closed
ScoutKBT opened this issue Mar 17, 2024 · 9 comments
Closed

Add a configurable delay between commands #28

ScoutKBT opened this issue Mar 17, 2024 · 9 comments
Labels
enhancement New feature or request

Comments

@ScoutKBT
Copy link

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:

3/17/2024, 7:07:32 AMHomeThingConnectorHubTargeted: [ 'Roller Blinds 07-4c752518d7b9', 100 ]
3/17/2024, 7:07:32 AMHomeThingConnectorHubTargeted: [ 'Roller Blinds 14-4c752518d7b9', 100 ]
3/17/2024, 7:07:33 AMHomeThingConnectorHubTargeted: [ 'Roller Blinds 08-4c752518d7b9', 100 ]
3/17/2024, 7:07:33 AMHomeThingConnectorHubTargeted: [ 'Roller Blinds 26-4c752518d7b9', 100 ]
3/17/2024, 7:07:33 AMHomeThingConnectorHubTargeted: [ 'Roller Blinds 10-4c752518d7b9', 100 ]
3/17/2024, 7:07:33 AMHomeThingConnectorHubTargeted: [ 'Roller Blinds 03-4c752518d7b9', 100 ]
3/17/2024, 7:07:33 AMHomeThingConnectorHubTargeted: [ 'Roller Blinds 04-4c752518d7b9', 100 ]
3/17/2024, 7:07:33 AMHomeThingConnectorHubTargeted: [ 'Roller Blinds 25-4c752518d7b9', 100 ]
3/17/2024, 7:07:33 AMHomeThingConnectorHubTargeted: [ 'Roller Blinds 01-4c752518d7b9', 100 ]
3/17/2024, 7:07:33 AMHomeThingConnectorHubTargeted: [ 'Roller Blinds 24-4c752518d7b9', 100 ]
3/17/2024, 7:07:33 AMHomeThingConnectorHubTargeted: [ 'Roller Blinds 23-4c752518d7b9', 100 ]
3/17/2024, 7:07:33 AMHomeThingConnectorHubTargeted: [ 'Roller Blinds 06-4c752518d7b9', 100 ]
3/17/2024, 7:07:33 AMHomeThingConnectorHubTargeted: [ 'Roller Blinds 05-4c752518d7b9', 100 ]
3/17/2024, 7:07:33 AMHomeThingConnectorHubTargeted: [ 'Roller Blinds 13-4c752518d7b9', 100 ]
3/17/2024, 7:07:33 AMHomeThingConnectorHubTargeted: [ 'Roller Blinds 12-4c752518d7b9', 100 ]
3/17/2024, 7:07:33 AMHomeThingConnectorHubERRORFailed to set Roller Blinds 02-4c752518d7b9 to 100: No response from hub
3/17/2024, 7:07:33 AMHomeThingConnectorHubERRORFailed to set Roller Blinds 09-4c752518d7b9 to 100: No response from hub

Great work with this project! Let me know where I can donate.

@ScoutKBT ScoutKBT added the enhancement New feature or request label Mar 17, 2024
@gormanb
Copy link
Owner

gormanb commented Mar 21, 2024

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, 1.1.7-beta.0, which makes both of these values configurable in the "Debug Settings" section of the plugin's config. Could you try installing that version and adjusting the "Retry Delay" and/or "Max Request Retries" values, to see if that resolves the problem?

@ScoutKBT
Copy link
Author

Thanks, will try this out. Can you provide sample config syntax? This is my first dive into the homebridge world. Appreciate it!

{
"platform": "ConnectorHub",
"connectorKey": "blah",
"hubIp": "192.168.xxx.xxx",
}

@gormanb
Copy link
Owner

gormanb commented Mar 27, 2024

@ScoutKBT: the best way to set these is via the plugin's UI configuration, as shown below:

ui_config


retry_settings
If you need to use the raw JSON config, you can set them as follows:

{
    "platform": "ConnectorHub",
    "connectorKey": "blah",
    "hubIps": [
        "192.168.xxx.xxx"
    ],
    "maxRetries": 2,
    "retryDelayMs": 250
}

@gormanb
Copy link
Owner

gormanb commented Mar 27, 2024

One thing I notice about your config is that it contains the following line:

"hubIp": "192.168.xxx.xxx"

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:

No device IPs configured, defaulting to multicast discovery

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 maxRetries or retryDelayMs settings, first try replacing the hubIp line with the following and see if it fixes the issue:

"hubIps": [
    "192.168.xxx.xxx"
]

@ScoutKBT
Copy link
Author

I'm using Hoobs so the GUI config looks like this:
image
If you populate the IP field you end up with the outdated config I sent before, which you can see in the "advanced" view which is basically the txt editor view which looks like this:
image
...but obviously this is with the updated syntax.

I am using the beta (see right side "installed" panel):
image

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!

@gormanb
Copy link
Owner

gormanb commented Mar 28, 2024

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!

@ScoutKBT
Copy link
Author

ScoutKBT commented Apr 2, 2024

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.

@gormanb
Copy link
Owner

gormanb commented Apr 2, 2024

@ScoutKBT: excellent, happy to hear that the issue has been fixed! I'll go ahead and promote this beta version to a full release 😄

@ScoutKBT
Copy link
Author

ScoutKBT commented Apr 2, 2024

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.

@gormanb gormanb closed this as completed in 8302b83 Apr 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants