-
Notifications
You must be signed in to change notification settings - Fork 22
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
Wait for ISY to be ready when retrying commands #380
base: v3.x.x
Are you sure you want to change the base?
Conversation
@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 |
@rccoleman Alternatively, test with this branch of Home Assistant: https://github.com/shbatm/home-assistant-core/tree/isy994_wait-for-ready |
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. |
Thanks, in theory if you overwhelm the network you should see the following in the debug log:
|
I'm still seeing this (now with debug enabled):
|
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? |
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. |
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
404
error, 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_BUSY
before retrying again. If the system is still busy after 5 seconds, an ISYConnectionError is raised.Fixes #184