Wait for ISY to be ready when retrying commands#380
Open
Conversation
Collaborator
Author
|
@rccoleman - Would you mind testing this version with Home Assistant? You'll need to update the following to use ./homeassistant/homeassistant/components/isy994/manifest.json
./homeassistant/requirements_all.txt
./homeassistant/requirements_test_all.txt |
Collaborator
Author
|
@rccoleman Alternatively, test with this branch of Home Assistant: https://github.com/shbatm/home-assistant-core/tree/isy994_wait-for-ready |
Contributor
|
Sure, passes a basic smoke test for me:
I created the Insteon scene as we discussed and collapsed all that activity down into what should be one command, but I'll temporarily revert and see what happens. |
Collaborator
Author
|
Thanks, in theory if you overwhelm the network you should see the following in the debug log:
|
Contributor
|
I'm still seeing this (now with debug enabled): |
Collaborator
Author
|
Very strange behavior (by the ISY). This must be something they fixed in the IoX versions because I can't replicate it-even trying to control 20 Insteon devices individually. The last 4 lines above--was that you retrying the command or it did it just trail behind? |
Contributor
|
I didn't do anything special, just ran the actions of an automation that turns on several ISY scenes in succession. The same thing has been happening for years and I even tried swapping the SD card at one point. I don't know what else I could do to experiment. For completeness, the action looks like this: where the first is an Insteon device, the next 3 are Insteon scenes, and the last is a light group that contains an Insteon device and a Zigbee group. I've replaced it with this: which controls an Insteon scene and a Zigbee group. I've so far found the scene to be a bit less reliable, presumably because I don't think devices respond ack/nak to the broadcast scene command, but it probably also means that there's some noise interfering with the Insteon traffic. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Use the system status reported by the websocket to hold off on retrying a command until the system reports that it is ready.
This will always still try the command first, even if the system has reported it's busy. If the command returns a
404error, then instead of just failing or using the throttled backoff for the retry, it will wait up to 5 seconds for the ISY to report it isNOT_BUSYbefore retrying again. If the system is still busy after 5 seconds, an ISYConnectionError is raised.Fixes #184