-
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
Implement Command Retry Methods when ISY Overwhelms Insteon Network #184
Comments
I've been using a slightly modified version of pyisy that supports retries for quite a while and it really improves the reliability of the integration. All the retry logic is already in place, it's just inactive because you're returning here. Simply removing that line causes the retry logic later in the function to kick in. I had temporarily reverted to the released pyisy when changes in the 2023.2.0 beta made mine incompatible and immediately started seeing lights not turning on as expected due to the ISY rejecting the commands. I'm going to remove that |
A few questions:
Just removing the return statement there has some knock-on effects elsewhere, so the proper fix is to add an argument (like The general recommended method is still going to be to use Scenes or ISY Programs to trigger the bulk changes, because there are times when you want it to fail immediately and not keep retrying 5 times (e.g. a command we know is bad or sent to the wrong address)--it's not possible (currently) to tell those apart from brute-forcing the Insteon network if they both return 404. Also, coming in the next version, the module will listen to |
It's still an ISY994 running 5.3.4.
It's only 4 or 5, including a couple of scenes for 3-way switches. It's really not a lot, but I can clearly see
Yes, it gives me a 404, which has always seemed like the wrong response code. It's been like this for many, many years. I agree that it seems like 503 is the right response, but there didn't seem to be much appetite to address it at UDI when I brought this up on their forum years ago. The "ok, ok, ok, I have no idea what device you're talking about" response sequence is just bizarre. It looks like |
Thanks for the details.
Yes, it needs to be a new parameter, since ok404 won't trigger a retry. Let me make some more progress on v4--I'd like to just resolve this with watching for the ISY being busy if I can. If you have the capability -- you could test v4 running separately from Home Assistant and see if it's correctly flagging "Busy" in the log when you try and control the lights from HA. You just need a computer with Python 3.9+ on it: python3 -m pip install pyisy-beta==4.0.0.dev5
python3 -m pyisy http://your-isy-ip admin "yourpassword" You should see it show something like below: 2023-01-30 22:32:17 DEBUG [pyisy.events.websocket] ISY HEARTBEAT: 2023-01-30T22:32:17.108252
2023-01-30 22:32:39 INFO [__main__] System Status Changed: Busy
2023-01-30 22:32:39 INFO [__main__] System Status Changed: Not Busy |
Sure, I'm happy to help test. I'll run that separately and see if the logs are correlated. Edit: I just kicked that off and I'm getting a ton of errors at startup, but it seems to have settled down. Things like:
and
and
I'll keep an eye on it |
Thanks for testing... this should take care of a few of those errors:
|
Yep, that helped. I just triggered the automation that typically exhibits the issue and sure enough, I got this:
Over that same period of time, I got this with
Eventually all the lights did come on, but this one came on a bit later and I'm sure wouldn't have come on at all if I didn't have retries in place. It's usually the one that stays off.
That corresponds with this line, where it succeeded a couple of seconds later:
It definitely was busy doing stuff at |
Ok. So it's definitely registering that's its busy. I can work with that. It does seem like it's getting overloaded very easily though, and I don't know if that's a function of the Insteon network or the ISY994 (FWIW, I just switched to polisy and holy crap is there a speed difference--~15s load time to <2s) Can you do the same test again, but run the pyisy-beta command with a |
Sure. Here are the HA logs:
And the output from the
I also made a small change to my automation to reduce the spam a bit. I have two lights in my garage and a PyScript app that turns the other one on if one turns on, so it can get a little spammy if they're both turned on as a group (which I was doing). I still saw the typical several second delay in the torchiere lights turning on, though, undoubtedly due to the retries. |
Thanks. I don't see anything out of the ordinary doing additional work, but something is bogging down your ISY more than it needs to be--it should be able to handle that traffic. For reference, I just tested 7 Insteon devices, tied to several different programs and variable updates, and it didn't balk... There was a 2s delay, but no errors. Maybe there's better tolerance and buffer on the Polisy side. 2023-01-31 03:55:35.710 DEBUG (MainThread) [pyisy] ISY Request: http://192.168.30.9:8080/rest/nodes/57%202F%20F2%201/cmd/DON
2023-01-31 03:55:35.711 DEBUG (MainThread) [pyisy] ISY Request: http://192.168.30.9:8080/rest/nodes/23%20B5%2068%201/cmd/DON
2023-01-31 03:55:35.711 DEBUG (MainThread) [pyisy] ISY Request: http://192.168.30.9:8080/rest/nodes/42%20B4%201C%201/cmd/DON
2023-01-31 03:55:35.711 DEBUG (MainThread) [pyisy] ISY Request: http://192.168.30.9:8080/rest/nodes/23%20B5%2098%201/cmd/DON
2023-01-31 03:55:35.712 DEBUG (MainThread) [pyisy] ISY Request: http://192.168.30.9:8080/rest/nodes/23%20D5%206%201/cmd/DON
2023-01-31 03:55:35.712 DEBUG (MainThread) [pyisy] ISY Request: http://192.168.30.9:8080/rest/nodes/25%209%208B%201/cmd/DON
2023-01-31 03:55:35.712 DEBUG (MainThread) [pyisy] ISY Request: http://192.168.30.9:8080/rest/nodes/57%203B%20C5%201/cmd/DON
2023-01-31 03:55:35.728 DEBUG (MainThread) [pyisy] ISY Response Received: /nodes/57%202F%20F2%201/cmd/DON
2023-01-31 03:55:35.728 DEBUG (MainThread) [pyisy] ISY command on sent to 57 2F F2 1.
2023-01-31 03:55:35.728 DEBUG (MainThread) [pyisy] ISY Response Received: /nodes/23%20B5%2068%201/cmd/DON
2023-01-31 03:55:35.728 DEBUG (MainThread) [pyisy] ISY command on sent to 23 B5 68 1.
2023-01-31 03:55:35.730 DEBUG (MainThread) [pyisy] ISY Response Received: /nodes/42%20B4%201C%201/cmd/DON
2023-01-31 03:55:35.730 DEBUG (MainThread) [pyisy] ISY command on sent to 42 B4 1C 1.
2023-01-31 03:55:36.048 DEBUG (MainThread) [pyisy] ISY Updated Node: 57 2F F2 1
2023-01-31 03:55:36.050 DEBUG (MainThread) [pyisy] ISY Updated Program: 0016
2023-01-31 03:55:36.053 DEBUG (MainThread) [pyisy] ISY Updated Program: 0015
2023-01-31 03:55:36.055 DEBUG (MainThread) [pyisy] ISY Updated Program: 000B
2023-01-31 03:55:36.056 DEBUG (MainThread) [pyisy] ISY Updated Program: 000B
2023-01-31 03:55:36.056 DEBUG (MainThread) [pyisy] ISY Updated Variable: 2.17
2023-01-31 03:55:36.097 DEBUG (MainThread) [pyisy] ISY Updated Program: 000B
2023-01-31 03:55:36.097 DEBUG (MainThread) [pyisy] ISY Updated Program: 000C
2023-01-31 03:55:36.640 DEBUG (MainThread) [pyisy] ISY Updated Node: 23 B5 68 1
2023-01-31 03:55:36.641 DEBUG (MainThread) [pyisy] ISY Updated Program: 006E
2023-01-31 03:55:37.124 DEBUG (MainThread) [pyisy] ISY Updated Node: 42 B4 1C 1
2023-01-31 03:55:37.127 DEBUG (MainThread) [pyisy] ISY Updated Program: 009F
2023-01-31 03:55:37.128 DEBUG (MainThread) [pyisy] ISY Updated Program: 0046
2023-01-31 03:55:37.130 DEBUG (MainThread) [pyisy] ISY Updated Program: 00A0
2023-01-31 03:55:37.131 DEBUG (MainThread) [pyisy] ISY Updated Program: 0046
2023-01-31 03:55:37.133 DEBUG (MainThread) [pyisy] ISY Updated Variable: 2.24
2023-01-31 03:55:37.165 DEBUG (MainThread) [pyisy] ISY Updated Program: 0046
2023-01-31 03:55:37.167 DEBUG (MainThread) [pyisy] ISY Updated Program: 006E
2023-01-31 03:55:37.785 DEBUG (MainThread) [pyisy] ISY Response Received: /nodes/23%20B5%2098%201/cmd/DON
2023-01-31 03:55:37.785 DEBUG (MainThread) [pyisy] ISY command on sent to 23 B5 98 1.
2023-01-31 03:55:37.785 DEBUG (MainThread) [pyisy] ISY Response Received: /nodes/23%20D5%206%201/cmd/DON
2023-01-31 03:55:37.785 DEBUG (MainThread) [pyisy] ISY command on sent to 23 D5 6 1.
2023-01-31 03:55:37.786 DEBUG (MainThread) [pyisy] ISY Response Received: /nodes/25%209%208B%201/cmd/DON
2023-01-31 03:55:37.786 DEBUG (MainThread) [pyisy] ISY command on sent to 25 9 8B 1.
2023-01-31 03:55:38.108 DEBUG (MainThread) [pyisy] ISY Updated Node: 23 D5 6 1
2023-01-31 03:55:38.110 DEBUG (MainThread) [pyisy] ISY Updated Program: 009F
2023-01-31 03:55:38.112 DEBUG (MainThread) [pyisy] ISY Updated Program: 00A0
2023-01-31 03:55:38.114 DEBUG (MainThread) [pyisy] ISY Updated Program: 0041
2023-01-31 03:55:38.115 DEBUG (MainThread) [pyisy] ISY Updated Program: 0040
2023-01-31 03:55:38.149 DEBUG (MainThread) [pyisy] ISY Updated Program: 0015
2023-01-31 03:55:38.688 DEBUG (MainThread) [pyisy] ISY Updated Node: 23 B5 98 1
2023-01-31 03:55:39.207 DEBUG (MainThread) [pyisy] ISY Updated Node: 25 9 8B 1
2023-01-31 03:55:39.620 DEBUG (MainThread) [pyisy] ISY Response Received: /nodes/57%203B%20C5%201/cmd/DON
2023-01-31 03:55:39.620 DEBUG (MainThread) [pyisy] ISY command on sent to 57 3B C5 1.
2023-01-31 03:55:39.626 DEBUG (MainThread) [pyisy] ISY Updated Program: 000C
2023-01-31 03:55:39.627 DEBUG (MainThread) [pyisy] ISY Updated Program: 0041
2023-01-31 03:55:39.628 DEBUG (MainThread) [pyisy] ISY Updated Program: 0040
2023-01-31 03:55:39.629 DEBUG (MainThread) [pyisy] ISY Updated Program: 0041
2023-01-31 03:55:39.630 DEBUG (MainThread) [pyisy] ISY Updated Program: 0040
2023-01-31 03:55:39.993 DEBUG (MainThread) [pyisy] ISY Updated Node: 22 E5 E5 1
2023-01-31 03:55:39.995 DEBUG (MainThread) [pyisy] ISY Updated Program: 000C
2023-01-31 03:55:40.159 DEBUG (MainThread) [pyisy.events.websocket] ISY HEARTBEAT: 2023-01-31T03:55:40.159691
2023-01-31 03:55:40.473 DEBUG (MainThread) [pyisy] ISY Updated Node: 57 3B C5 1
2023-01-31 03:55:41.186 DEBUG (MainThread) [pyisy] ISY Updated Node: 25 8 20 1
2023-01-31 03:55:41.187 DEBUG (MainThread) [pyisy] ISY Updated Program: 000C
2023-01-31 03:55:41.189 DEBUG (MainThread) [pyisy] ISY Updated Node: 56 D3 A5 6
2023-01-31 03:55:41.190 DEBUG (MainThread) [pyisy] ISY Updated Program: 0016
2023-01-31 03:55:41.191 DEBUG (MainThread) [pyisy] ISY Updated Program: 0015
2023-01-31 03:55:42.269 DEBUG (MainThread) [pyisy] ISY Updated Program: 00A0
2023-01-31 03:55:42.272 DEBUG (MainThread) [pyisy] ISY Updated Node: 25 9 8B 3
2023-01-31 03:55:42.274 DEBUG (MainThread) [pyisy] ISY Updated Program: 009F
2023-01-31 03:55:42.274 DEBUG (MainThread) [pyisy] ISY Updated Program: 00A0
2023-01-31 03:56:10.183 DEBUG (MainThread) [pyisy.events.websocket] ISY HEARTBEAT: 2023-01-31T03:56:10.183024 Also, for PyScript, just an FYI but you can set your own context for a call and check to see if it was called by your script to make sure you don't have any duplicate calls (see attached), and in general, I make sure anything that is just a status update (e.g. a slave dimmer with no load) has a 1-2 second delay to get out of the way of the other traffic. |
Yeah, it does seem to get bogged down easily. I moved all the logic to HA a long time ago, so there are no programs or anything that should be taxing it. Because of that, I would seriously consider just moving to the PLM integration rather than spending money on updated UDI equipment at this point. But if the isy994 can be made to work more reliably, I'll stick with it. It's just a glorified PLM for me with a UI to manage devices and scenes. |
This is all mine is now (the Polisy was bought during the first batch before I was all in for HA). I know you're trying to keep the ISY side minimal, but if you have anything you control in a group of 2 or more devices you're going to have significantly better reliability by making them a Scene, even if there's no controller beside the PLM/ISY. Those scenes are stored in the devices themselves as 1 link, so it's not only a single command to the ISY, but a single command to the Insteon network as well. If they aren't something I need exposed in Home Assistant, I add them in the ISY then make them Hidden in Home Assistant to just use them for the automations. I'm slowly working on getting rid of the need for the ISY console, but i haven't gotten to group updates yet. About the only other thing I use the ISY for now is programs that 'sync' other insteon device statuses (e.g. Update a slave KPL button when the load is directly controlled from HA). |
I suppose I can create very custom scenes for specific use cases. It's annoying because I typically have mixed Insteon, ZWave, and Zigbee devices that need to be controlled, and all of the latter two are only in HA. So I'll need to create a group that includes that special scene + any non-Insteon devices. Doable, just cumbersome. |
Yep, that's essentially what I do. Insteon and Zigbee use native groups wherever possible for response time (Zigbee groups function the same as Insteon scenes--single command to multiple devices), then add in anything else that HA controls. If it's something that I want to control from Insteon (like from a KPL button) I have a second group that excludes the Insteon scene and an automation that listens for the # Groups without _hass include ISY Scenes.
# These allow control repsonse from an ISY All Off without duplicating
# the Insteon traffic
group:
all_off_exit:
name: All Off Exit
entities:
- switch.all_off_exit # ISY Scene
- group.all_off_exit_hass
all_off_exit_hass:
name: All Off Exit Hass
entities:
- light.zb_all_off_exit # Zigbee native group
- group.all_off_exit_zwave # Manual HA Z-Wave Group
- light.living_room_lamps
- light.mirror_art
- light.game_room_tv_leds
- light.living_room_tv_leds More convoluted than I'd like, but response time is damn-near instantaneous. Hitting the all-off button on a KPL will kill all the Insteon lights and Zigbee Lights (100+ devices) in <1s, with the Z-Wave tailing a bit behind because of the individual commands required. |
I created a script sequence to initiate multicast commands for ZWave and then a template switch to call them so that it could be included in a group. I've since moved to Zigbee (which is super-fast with native groups), but that's one way to improve the ZWave performance and make it more like Zigbee groups & Insteon scenes. In any case, I agree that scenes are preferable and I'll see how I can optimize my ISY communication this weekend. The basic problem will still remain, and but may can wait for pyisy4 for a long-term solution. |
Reference from #145
Thanks for the pointer to this discussion. It does seem like the retry mechanism that you're discussing would help with the issue that I'm seeing, but unrelated to the issue above. The typical case for me is that turning on a bunch of lights causes the ISY to sporadically respond with "404" (not found) errors via REST, resulting in the light not being turned on and the error mentioned in that issue. It's been happening forever with no indication that UDI will change the behavior, and it seems like an inappropriate error message to indicate that the Insteon network is "busy" (as UDI has diagnosed). In any case, I look forward to having commands retried if they fail.
Originally posted by @rccoleman in #145 (comment)
The text was updated successfully, but these errors were encountered: