Deconz-rest-plugin: slow API when multiple requests
Describe the bug
The api is very slow if you send multiple requests.
If you press on and off 10 times each second for a light group with 6 lights, the response time stars to increase alot after just 4 clicks and all of a sudden you have a response time of many many seconds.
The same ofcorse happens if you turn off multiple lights from an external system such as home assistant.
So when I turn off indoor lightng at night, you can stand and watch all lights turning off with seconds in between.
I run deconz on a multithreaded ryzen server where the cpu is almost idle while this happens.
Steps to reproduce the behavior
If the problem is reproducable, list the steps here:
- Go to the old phoscon app
- Click on and off 10 times on a light group with at least 6 lights
look at the lights response time increasing drastically
4If the problem can't be reproduced and is sporadic, please provide some details
on how often and when the issue happens.
Expected behavior
a quick response when sending multiple requests to the api
Screenshots
Environment
- Host system: PC
- Running method: Windows
- Firmware version: 26580700
- deCONZ version: 2.05.79
- Device: ConBee II
- Do you use an USB extension cable: yes
deCONZ Logs
Additional context
joggs
All 3 comments
Sending commands to groups is slower then adressing a light. I think this is caused by the group call being a multicast call.
When I use a group call in the REST API with my plugin, I let a new call wait ca. 0,8 seconds. When I send a direct call for a light, a new call has to wait 0,1 second. I suspect Phoscon is doing a similar delay with sending the commands.
Sending a number of calls, like you are doing by pressing on and off repeatedly is causing a queue to build up, If you manage to send 10 commands in a second, the last command will be send out 8 seconds after you pressed it in my sample.
I think this is caused by the limits of group command handling in Zigbee, and probably not a bug in the REST API?
wvuyk
on 17 Aug 2020
As there hasn't been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
![stale[bot] picture](https://avatars3.githubusercontent.com/in/1724?v=4&s=40)
stale[bot]
on 7 Sep 2020
As there hasn't been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it isn't solved, request to get this opened again.
stale[bot]
on 15 Sep 2020
Related issues
tenholde
·
3Comments
ReeChip
·
5Comments
1onar
·
5Comments
g0dsCookie
·
3Comments
marthoc
·
6Comments
Most helpful comment
Sending commands to groups is slower then adressing a light. I think this is caused by the group call being a multicast call.
When I use a group call in the REST API with my plugin, I let a new call wait ca. 0,8 seconds. When I send a direct call for a light, a new call has to wait 0,1 second. I suspect Phoscon is doing a similar delay with sending the commands.
Sending a number of calls, like you are doing by pressing on and off repeatedly is causing a queue to build up, If you manage to send 10 commands in a second, the last command will be send out 8 seconds after you pressed it in my sample.
I think this is caused by the limits of group command handling in Zigbee, and probably not a bug in the REST API?