-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Version 1.16.0 overall slow network response #4884
Comments
@ChrisHae has anything changed in the Conbee implementation that could cause this? |
@Koenkk is there a possibility for you to build a 1.16.1 version with the old 1.15.0 Deconz code in it? I can then try if that runs smoothly and maybe pinpoint the problem a bit better. |
I can confirm that Zigbee network became much slower in 1.6.X version. One ON action leads to network flood with attributeReports. |
@Imaginous if running bare metal, you can downgrade the zigbee-herdsman library (which contain the driver code) to the 1.15.0 version when executing in @2x4ever does downgrading to 1.15.0 fix your issue? |
Can confirm the same slowdown on 1.6.X with a conbee II adapter. Looking at the MQTT feed, there would be anywhere from 0.5 to several seconds delay between pressing a button, and the corresponding MQTT message showing up. Return to 1.5.X and the response time immediately returned to normal (MQTT message appears almost immediately as a button is pressed). Did not have a chance to do any further troubleshooting but I'd be happy to run any diagnostics that would help narrow this down. |
@Koenkk I have done a couple of test. I run bare metal, so I have downgraded herdsman to 0.13.11 in my 1.16.0 installation. As I can conclude, the difference must be somewhere in the herdsman code. Since the problem disappears after downgrading the herdsman code. Note: When the button is pressed I send 2 individual MQTT commands to the 2 gang dimmer module to turn on each lamp. BTW: is there a json command to set both states at the same time? Here are the results of different installations. Hybrid version: 1.16.0 with downgraded herdsman 0.13.11, reacts normalSingle press on, on the Ikea button:
Single press off on the Ikea button:
Version: 1.16.1, reacts slowSingle press on, on the Ikea button:
Single press off, on the Ikea button:'Nov 08 12:53:29 domoticapi1 npm[31538]: Zigbee2MQTT:info 2020-11-08 12:53:29: MQTT publish: topic 'zigbee2mqtt/Alarm_Knop_IKEA', payload '{"action":"off","battery":87,"click":"off","linkquality":200,"update":{"state":"idle"},"update_available":false}' Version: 1.16.0, reacts slowSingle press on, on the Ikea button:'Nov 08 12:47:07 domoticapi1 npm[31093]: Zigbee2MQTT:info 2020-11-08 12:47:07: MQTT publish: topic 'zigbee2mqtt/Alarm_Knop_IKEA', payload '{"action":"on","battery":87,"click":"on","linkquality":199,"update":{"state":"idle"},"update_available":false}' Single press off, on the Ikea button:'Nov 08 12:47:54 domoticapi1 npm[31093]: Zigbee2MQTT:info 2020-11-08 12:47:54: MQTT publish: topic 'zigbee2mqtt/Alarm_Knop_IKEA', payload '{"action":"off","battery":87,"click":"off","linkquality":199,"update":{"state":"idle"},"update_available":false}' Version: 1.15.0, reacts normalSingle press on, on the Ikea button:'Nov 08 12:40:57 domoticapi1 npm[30463]: Zigbee2MQTT:info 2020-11-08 12:40:57: MQTT publish: topic 'zigbee2mqtt/Alarm_Knop_IKEA', payload '{"action":"on","battery":87,"click":"on","linkquality":199,"update":{"state":"idle"},"update_available":false}' Single press off, on the Ikea button:'Nov 08 12:41:35 domoticapi1 npm[30463]: Zigbee2MQTT:info 2020-11-08 12:41:35: MQTT publish: topic 'zigbee2mqtt/Alarm_Knop_IKEA', payload '{"action":"off","battery":87,"click":"off","linkquality":199,"update":{"state":"idle"},"update_available":false}' |
@ChrisHae there seems to be some regression in performance for the Conbee II in herdsman 0.13.11 - 0.13.26, can you investigate this? |
@Koenkk I have found another strange behavior, I don't think it is directly related. However when I send: So turn both lights on in one command, there is the same 1-1.5 second delay between turning on each lamp as in version 1.16.0, but in this case it also happens in version 1.15.0. Don't know if it is related, but maybe it is. Later this week, if I find some time, I will try another Raspberry Pi with a Slaesh CC2652 Stick. |
I have slowed down data transmit a bit to improve stability when sending many commands at once (Some devices did not respond when sending many requests to fast). I could tweak the times to make it a bit faster again. Delay should be around 1sec. 3 or more seconds would indicate a very busy network I think. You could also use group commands when controlling many lights at once. This should be much faster. @Imaginous How do I use that command: |
@ChrisHae would it be possible to make the delay a parameter in the settings of zigbee2mqtt? As a programmer I think delays are best avoided. If you can point me to the source code, I can have a look at it. I send commands directly after one another and never experienced any problems. On the other hand the zigbee protocol should take care of resends. The command is send to a single zigbee device with 2 lamps. |
There were Issues of user who sent many requests (about 10 -20) nearly at the same time (#4215) . Some devices did not respond or the messages did not arrived there. I think it is best to use group commands then but never the less I think there should be some time between the messages so that the devices and the coordinator can better handle it. So did not hard coded a delay between the sending of the messages but instead the coordinator waited until a data request got confirmed before sending the next one. This usualy took about 800ms. Now I have added a parameter that defines the delay between two requests. I have halved the time and it still works pretty stable. You could test it if the speed is acceptable now. It is in the newest herdsman commit. It would be also possible to let the user change this parameter in the configuration if @Koenkk would let me add this parameter to the configuration.yaml. Let's call it packet_spacing or send_delay or so. |
From an end user perspective 800ms is a massive delay. E.g. I did not get full buy-in from the wife until I changed "multiple_press_timeout" on the Philips Hue remotes from 250ms to 0. 250ms meant the difference between walking into a room, turning on a light and it almost immediately turning on, vs. pressing and consciously waiting for the light to turn on. I agree that a user configurable value would make more sense. |
Sorry for the long answer. Was looking for a way to downgrade the hass.io add-on version. |
@2x4ever I'm speaking about a delay from about 400ms to 1s. Some User reported several seconds. This should be another issue here. Also pressing a button on a zigbee remote should not be affected by this. Remotes are bound and communicate directly to the lights. |
@ChrisHae not all use cases allow remotes to be bound directly to lights. Previous to this change, using a remote to trigger automations in HASS was still pretty snappy, especially with "multiple_press_timeout" set to 0ms. |
@ChrisHae My Ikea button does not communicate directly to the lights. The button press is caught by my software and then the 2 commands are send to the lights. I would say that the delay with the 1.16.0 version might be 1 second. I did not time it. How can I clone / add only the latest Herdsman version into the existing version? |
@Imaginous I can't say if this also works. I cloned the zigbee-herdsman repository to my raspberry and added the path to /opt/zigbee2mqtt/lib/zigbee.js Or you wait until Koenkk merged this into the newest version of zigbee2mqtt |
@ChrisHae I don't see any new commits to https://github.com/Koenkk/zigbee-herdsman/commits/master ? |
@Koenkk Oh sorry forgot to push. Now it's online. |
It's in the latest dev now. @ChrisHae next time you make a change to zigbee-herdsman, you can trigger a new release by going to https://github.com/Koenkk/zigbee-herdsman/actions?query=workflow%3A%22Create+new+release%22 , press "Run workflow" -> press "Run workflow" (you can leave Release type patch as is). This will automatically create a new release and makes a PR to Zigbee2MQTT to update zigbee-herdsman (which I will get a notification for). |
I recently left the zzh and returned to conbee 2, however, as I was used to the delay of the zzh, when I returned to conbee 2, I noticed some delay of this in relation to the zzh. What's the reason for that? (Ps. I'm running the herdsman version to 0.13.11 with the conbee. |
Today I installed the latest dev version of 1.16.1. If I understood correctly this should contain the latest modifications of Chris.
This version has still got the slow response with the Conbee II stick. Maybe I did something wrong, please let me know if so. |
After my previous post, To fix the home assistant bug, I updated yesterday the dev version, which removed the herdsman version to 0.13.11. And I noticed that the slowness continues. I went back to the herdsman version to 0.13.11. |
As long as there are still delays added (even if they are halved) there will be a noticeable slowness. Even the adjustable 250ms delay on the Hue Dimmer Remote was noticeable. @ChrisHae @Koenkk do you think we will be able to get a user-customizable option to remove the delays added with this fix? It seems a pity to negatively impact usability for use cases that benefit from response time over reliability, just to fix the use case where someone wants to send commands to many zigbee devices simultaneously. Is there a reason they can't use group messaging in that scenario? |
@Imaginous The version 1.16.1 is released 16 days ago, so I think it does not contain the new code. I think it would be nice if I could add a parameter to the configuration.yaml. Where the user could chosse a delay between 10 to 1000ms. it could default to 200 if not specified. @Koenkk Is it possible for me to do that? in my driver.ts of deconz adapter there is already a variable for it. |
Hi wanted to test the adjustments in the adapterdelay settings and updated the dev coming from a build yesterday. Zigbee2MQTT:info 2021-02-09 09:34:27: MQTT publish: topic 'homeassistant/sensor/0x842e14fffe3daeed/energy/config', payload '{"availability":[{"topic":"zigbee2mqtt/bridge/state"}],"device":{"identifiers":["zigbee2mqtt_0x842e14fffe3daeed"],"manufacturer":"TuYa","model":"10A UK or 16A EU smart plug (TS0121_plug)","name":"eettafel apparaten","sw_version":"Zigbee2MQTT 1.17.1-dev"},"device_class":"energy","json_attributes_topic":"zigbee2mqtt/eettafel apparaten","name":"eettafel apparaten energy","state_topic":"zigbee2mqtt/eettafel apparaten","unique_id":"0x842e14fffe3daeed_energy_zigbee2mqtt","unit_of_measurement":"kWh","value_template":"{{ value_json.energy }}"}' Could this be related to the changes made which has been made related with the adapter delay settings? (running the non dev build now btw and that works) |
fwiw, I've found that |
@snippem yes sorry, a bug slipped through while commiting my code yesterday. I have uploaded a fix now. |
Fix will be in dev in 1 hour from now. |
Current dev version is still unstable. Even with adapter_delay set to 30 it gets bogged down (especially when adjusting light groups) and eventually crashes. Required physical reboot of the conbee stick. Going back to version 15 is 99.9% stable. It seems as if the changes made in v16 were solving for a very rare problem and have ended up breaking usability for a much larger group of users. Maybe best to go back to v15 and review what changes are actually needed or not. |
Getting delayed/missed group messages even when rolled back to v15. Too many variables - think my zigbee network may need time to settle down. Going back to dev version, no value set for adapter_delay, and will give it 24 hours to settle. |
@Imaginous Did you tested the last dev version with the @ChrisHae latest fix? |
I will try it tonight... @Koenkk Will keep you informed. Something came up... will test Thursday evening. |
After 12 hours or so I can say the current Dev version is mostly stable. Definitely faster than the old values in v15. That speed does seem to lead to more missed commands (e.g. having to press remote buttons twice) but as long as you're not pressing multiple buttons repeatedly it seems fine. |
@Koenkk I did some testing with the latest Dev version. All seems okay. I didn't have any missed events (button presses). Every thing is as smooth as with my edited driver.js. For me this dev version seems a go. I don't have any groups, so every device gets it's own packets. Can't elaborate on the issues of @srnoth. However it seems that he is being hunted by multiple factors at once ;) |
@Imaginous all is mostly well with the new settings. The only issue seems to be with automations that send multiple Zigbee commands one after the other. For example I have a remote bound to a light (so the on/off commands are straight from the remote to the light) but I also have an automation that sets the light to a predefined color when the "on" button is pressed. These new settings are so fast that the "color" command is being received too soon after the "on" command, and is being ignored. Added a delay to the automation and now it's working fine. Not complaining though, folks use their zigbee networks in different ways and I guess that's where having a tunable delay value is best. |
@srnoth I have my own automation behind it and I do the same thing for some lights, when I get an On event of a lamp I adjust the brightness to a certain level, did not experience any strange behavior... But maybe my code is just slow ;) |
@Imaginous lol! I should add that the only light that is giving this trouble is one that I know for a fact is behind a repeater/router rather than directly connected to the conbee. |
@srnoth Non of my tested lights or switches are directly connected to the Conbee II, they al have at least one hop. |
Happy to report mostly smooth sailing for 3 days now. Changed my automations to avoid any "swarm" of commands being sent all at once and have had zero issues since. Hopefully the last changes have put this issue to bed once and for all! Thanks for the all the hard work @Imaginous, @ChrisHae and @Koenkk . |
everything is perfect here and faster. very good job! |
I've just tested the latest form dev, I've got a network of 46 devices, when I tell google to turn off all the lights, with that version, it leaves some of the off. I dunno if this helps in any way, but I can get the logs if you want :) |
Information you could share is for example you settings in the configuration.yaml. |
sorry, yeah, it's conbee 2, and here are the logs:
Also the reason for me not do this by creating a group is because this happens when I tell google home to turn off al the lights of the house 😅 |
@julioyg Does google home can not turn off a group? |
@ChrisHae i see what you mean, yeah I could, but then i'd have to create a group to group all the lights in the house and add them manually each time a I add a new one, then I could expose that group to google home, but... it doesnt feel like a solution, more of a workaround I guess 😅. |
@julioyg But that's the purpose of a group - controling many lights at once. That is the reason there is such thing as group commands in the zigbee protocol. Controlling many lights with single commands will always produce high network traffic and cause problems. Ok but therefore I added the higher adapter_delay setting. Good to hear that it helps to reduce the failures - of course the tradeoff is the speed. |
@julioyg lights can also be part of multiple zigbee groups - e.g. my four kitchen lights are part of both a "kitchen" group and a "downstairs" group. That way I can turn the entire downstairs on/off with one zigbee command instead of dozens of commands to individual bulbs. As your number of devices expands, it becomes impractical to send individual commands to each bulb. One other advantage of zigbee groups - all the bulbs in a group turn on/off in sync - which is visually much nicer than noticing the different bulbs turning on/off at slightly different times. |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days |
Hi, is it possible that the Adapter Delay parameter in Z2M GUI in HA is inactive? The actual delay doesn’t change at all no matter what I set there, even numbers like 3000. Z2M 1.28.2.0. |
What happened
When pressing a zigbee button or sending in MQTT command to a lamp takes about 1.5 seconds. When sending 2 commands directly after one another to turn on 2 lights. They will turn on about 1.5 - 2.0 seconds after each other.
This started since version 1.16.0. Copied back my 1.15.0 version and everything runs smoothly again.
What did you expect to happen
Thate the commands would be almost instantanious.
How to reproduce it (minimal and precise)
Upgrade to version 1.16.0 -> zigbee network becomes slow.
Restore to version 1.15.0 -> zigbee network is fast again.
No devices have been added or changed between the upgrade.
Debug info
Zigbee2MQTT version: 1.16.0
Adapter hardware: Conbee II
Adapter firmware version: 0x26660700
Hardware: Raspberry Pi 3
The text was updated successfully, but these errors were encountered: