Failed to deliver message: <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074>

[ecchodun]

The problem

Never had an issue and now I'm getting the following error on various Zigbee devices - Failed to deliver message: <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074>

What version of Home Assistant Core has the issue?

core-2024.8.2

What was the last working version of Home Assistant Core?

core-2024.8.1

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Zigbee

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Logger: homeassistant.components.automation.new_automation_closet
Source: components/automation/__init__.py:776
integration: Automation (documentation, issues)
First occurred: 7:25:55 PM (1 occurrences)
Last logged: 7:25:55 PM
Error while executing automation automation.new_automation_closet: Failed to send request: Failed to deliver message: <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074>

Additional information

This has occurred sporadically over the past few days. I did add a Nortek dongle along with my existing Zigbee dongle, but even after unplugging it I'm still getting this error.

[home-assistant]

Hey there @dmulcahey, @Adminiuga, @puddly, @TheJulianJES, mind taking a look at this issue as it has been labeled with an integration (zha) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of zha can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign zha Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

zha documentation
zha source
_{^{(message by IssueLinks)}}

[ufondu88]

I'm having the same issue. I have a group of Ikea blinds that I control. Some of the blinds are triggered, but some are not. The logs show the same error

[puddly]

This will likely be improved by zigpy/bellows#646 (in the next beta) if your devices are battery operated. Note that nothing changed between 2024.8.1 and 2024.8.2 (and in many many months beforehand) so any issues you're experiencing are with your environment.

[ufondu88]

My environment has not changed in many months. This issue started after the upgrade to 2024.8.2. And, yes, my devices are battery operated

[puddly]

My environment has not changed in many months.

If you haven't changed the stick firmware, something in your RF environment has changed. It doesn't mean that you changed something, just that it has changed. New neighbors (or old neighbors who added new equipment), wifi router moved its 2.4GHz network channel, temperatures changed and your device's battery voltage has dropped, new SSD nearby, etc.

This issue started after the upgrade to 2024.8.2

They may have started at the same time but if you downgrade to 2024.8.1, things will remain exactly the same.

[ecchodun]

I will say, that my environment did change in that in addition to my existing Silicon Labs Sonoff Zigbee dongle, I added a new Nortek Z-Wave/Zigbee to take advantage of the Z-wave frequency (the Zigbee is not active on the dual-device). It may have been coincidental that when I did so, I started to get the error, but yesterday I added a 10' USB extension cable to the Z-wave dongle (the Sonoff already had one) and I haven't had the error 3074 in over 24 hours. It could be a coincidence and I'll certainly keep this thread updated, but it's worth noting.

[jamestalbot3]

I have also had this error pop up on IKEA battery operated blinds out of nowhere today. I haven't added or changed my zigbee devices in any way. They just refuse to communicate at all

[ecchodun]

Just got it again after not seeing it for over 24 hours - Error while executing automation automation.new_automation_closet: Failed to send request: Failed to deliver message: <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074>

[chicagoandy]

Yes, also getting these starting yesterday. No network changes. There are enough people having this that rules our typical device incompatibility.

[jgandhi19]

I started receiving these errors after upgrading as well. No other changes, this doesn't seem to be a coincidence that others are experiencing the same issues.

I will mention that the devices I'm seeing as failing are Sengled light bulbs, not battery powered.

[chuckie007]

Also started getting this in the last few days. No changes in months to zigbee devices.

[puddly]

As mentioned above, there have been no changes to ZHA in the past few releases. More fundamentally, however, ZHA does not have control over routing to your devices. It asks the stick to send a message and the stick responds with the status code you're seeing. If this changed all of the sudden, this is 100% a result of your environment. You can verify by downgrading HA Core.

That being said, if downgrading helps, please enable ZHA debug logging, leave it running for half an hour and toggle some devices to generate log data, and disable debug logging to generate a log. Please do this on a version that works and one that does not and we can see what the difference is between the logs.

[bryanklingner]

Just here to say I experienced very similar symptoms:

• Zigbee controller is Skyconnect, working fine for months
• Devices are IKEA Fyrtur motorized shades
• Started getting this error 3074, shade function highly sporadic

I have seen other similar reports eg https://community.home-assistant.io/t/connection-problems-with-zha/762314

Seems too widespread to just be a coincidence for all of us. I'll try to get some logs to post.

[rwarner]

Also chiming in here with the same issue. Was not seeing this until upgrading to 2024.8.3 today. Some buttons have rendered completely useless all of the sudden after this update.

I keep getting Zigbee requests sort of "pooled together" after a few minutes when trying to turn lights on and off. Then they all of a sudden execute and this error pops up.

[rwarner]

FWIW, I rolled back to 2024.8.1 last night to hopefully resolve this but ran into the same issue. Which is weird because I didn't have this issue until moving to 2024.8.3.

I have an issue running my script with a Zigbee button to toggle some lights for some reason which hits this error:

sequence:
  - entity_id:
      - light.master_bedroom_lights
    action: light.toggle
  - delay:
      milliseconds: 250
  - condition: state
    entity_id: light.master_bedroom_lights
    state: "on"
  - continue_on_error: true
    data_template:
      entity_id: light.master_bedroom_lights
      brightness_pct: |
        {% if now().hour >= 21 %}
          30
        {% elif now().hour <= 7 %}
          30
        {% else %}
          100
        {% endif %}
      color_temp: |-
        {% if now().hour >= 21 %}
          470
        {% elif now().hour <= 7 %}
          470
        {% else %}
          350
        {% endif %}
    action: light.turn_on

toggle_bedroom_lights: Error executing script. Error for call_service at pos 1: Failed to send request: Failed to deliver message: <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074>

I'll go to execute this script, then it won't work. So I'll go into Home Assistant to toggle the same lights, then that "pooling" action will happen and the lights will just turn on and off and on and off, etc..

Have also been getting a lot of zigbee devices notifying me they've gone "unavailable" suddenly

[rwarner]

I just downgraded to 2024.7.4 and do not run into this issue with my previous comment FWIW

[puddly]

Can you generate a debug log by enabling debug logging for ZHA, reloading the integration, and letting it run for half an hour while doing what you can to trigger the issue? Without a log from each version, it's hard to see what's different.

[rwarner]

Sure thing I can try to get you something hopefully soon. On the 2024.8.3 version? Or the 2024.7.4?

[puddly]

Both of them, if you could. One alone won't show what changed.

[ecchodun]

Here is my last log of it occurring from just today - Logger: zigpy.zcl
Source: runner.py:190
First occurred: August 26, 2024 at 2:09:41 PM (5 occurrences)
Last logged: 5:57:30 AM

[0x3E90:1:0x0020] Traceback (most recent call last): File "/usr/local/lib/python3.12/site-packages/zigpy/endpoint.py", line 265, in request return await self.device.request( ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/zigpy/device.py", line 339, in request await send_request() File "/usr/local/lib/python3.12/site-packages/zigpy/application.py", line 833, in request await self.send_packet( File "/usr/local/lib/python3.12/site-packages/bellows/zigbee/application.py", line 825, in send_packet raise zigpy.exceptions.DeliveryError( zigpy.exceptions.DeliveryError: Failed to deliver message: <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074> The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/local/lib/python3.12/site-packages/zha/zigbee/cluster_handlers/general.py", line 646, in check_in_response await self.fast_poll_stop() File "/usr/local/lib/python3.12/site-packages/zha/zigbee/cluster_handlers/__init__.py", line 83, in wrapper with wrap_zigpy_exceptions(): File "/usr/local/lib/python3.12/contextlib.py", line 158, in __exit__ self.gen.throw(value) File "/usr/local/lib/python3.12/site-packages/zha/zigbee/cluster_handlers/__init__.py", line 75, in wrap_zigpy_exceptions raise ZHAException(message) from exc zha.exceptions.ZHAException: Failed to send request: Failed to deliver message: <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074>
[0x7B00:1:0x0020] Traceback (most recent call last): File "/usr/local/lib/python3.12/site-packages/zigpy/endpoint.py", line 265, in request return await self.device.request( ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/zigpy/device.py", line 339, in request await send_request() File "/usr/local/lib/python3.12/site-packages/zigpy/application.py", line 833, in request await self.send_packet( File "/usr/local/lib/python3.12/site-packages/bellows/zigbee/application.py", line 825, in send_packet raise zigpy.exceptions.DeliveryError( zigpy.exceptions.DeliveryError: Failed to deliver message: <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074> The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/local/lib/python3.12/site-packages/zha/zigbee/cluster_handlers/general.py", line 646, in check_in_response await self.fast_poll_stop() File "/usr/local/lib/python3.12/site-packages/zha/zigbee/cluster_handlers/__init__.py", line 83, in wrapper with wrap_zigpy_exceptions(): File "/usr/local/lib/python3.12/contextlib.py", line 158, in __exit__ self.gen.throw(value) File "/usr/local/lib/python3.12/site-packages/zha/zigbee/cluster_handlers/__init__.py", line 75, in wrap_zigpy_exceptions raise ZHAException(message) from exc zha.exceptions.ZHAException: Failed to send request: Failed to deliver message: <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074>

[bryanklingner]

A bit more information:

I tried replacing the Nabu Casa SkyConnect with an old Sonoff Zigbee 3.0 USB stick, rebuilding my network from scratch. The flakiness and 3074 errors have disappeared.

So, at least anecdotally this may be an issue specific to the SkyConnect stick.

[ecchodun]

A bit more information:

I tried replacing the Nabu Casa SkyConnect with an old Sonoff Zigbee 3.0 USB stick, rebuilding my network from scratch. The flakiness and 3074 errors have disappeared.

So, at least anecdotally this may be an issue specific to the SkyConnect stick.

I have the issue with Sonoff Zigbee 3.0 USB stick. It's likely to pop up for you again.

[rwarner]

Both of them, if you could. One alone won't show what changed.

Sent you over the logs on Discord.

Of course, after I did the logging on 2024.7.4 and then upgraded my python installation to 2024.8.3 it has been working on 2024.8.3 just fine... haven't seen the error come back yet.

When going from 2024.7.4 to 2024.8.3 though I did get some pip errors and I'm curious if one of the libraries stuck to the old one or something. Got some of this:

ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
async-upnp-client 0.39.0 requires aiohttp~=3.9.1, but you have aiohttp 3.10.5 which is incompatible.
aiohttp-fast-url-dispatcher 0.3.0 requires aiohttp<3.10,>=3.8.5, but you have aiohttp 3.10.5 which is incompatible.
zha 0.0.30 requires bellows==0.40.3, but you have bellows 0.39.1 which is incompatible.
zha 0.0.30 requires zha-quirks==0.0.118, but you have zha-quirks 0.0.117 which is incompatible.
zha 0.0.30 requires zigpy==0.65.3, but you have zigpy 0.64.1 which is incompatible.
zha 0.0.30 requires zigpy-deconz==0.23.3, but you have zigpy-deconz 0.23.2 which is incompatible.
zha 0.0.30 requires zigpy-xbee==0.20.2, but you have zigpy-xbee 0.20.1 which is incompatible.
zha 0.0.30 requires zigpy-zigate==0.13.1, but you have zigpy-zigate 0.12.1 which is incompatible.
zha 0.0.30 requires zigpy-znp==0.12.4, but you have zigpy-znp 0.12.2 which is incompatible.

[ufondu88]

I have to say, I have not encountered this issue in a while. I have not changed anything about my environment and I am still on 2024.8.3. It has now been a few days since I have gotten this error. I have no idea what could have fixed the issue

[chicagoandy]

Same with me. Over the weekend I was getting this everywhere, for no reason. I rebooted, both soft and hard. I "reconfigured network". I removed and readded devices. Nothing worked.
Then it got better with 2024.8.3, or perhaps HAOS 13.1. No idea what went wrong, but the most frustrating aspect was the large number of unhelpful comments about incompatible devices. I hope this is just a ghost that goes away, but overall - the general flakiness of ZHA is confirmed for me.

[rwarner]

Coming back to this, still on 2024.8.4 however I rebooted like a few people noted and can concur that this fixes things for now again. If I get the timeouts and errors I've been seeing I'll try to grab debug logs. Also hoping to update to a 2024.9.x soon and see if this issues persist

[ecchodun]

I've not received this error now in over a week. I did change the channel of my ZHA Hub to 24. The error just eventually stopped showing up. Perhaps it was interference that has now somehow subsided. Not completely sure.

[brussene]

Did a restart of ZHA and ran a debug log for a couple of hours and stopped it when ZHA became unresponsive again.
Towards the end of the logfile I am seeing this:

2024-09-13 20:54:04.602 DEBUG (MainThread) [zigpy.application] Max concurrency (8) reached, delaying request (66 enqueued)
2024-09-13 20:54:04.602 DEBUG (Thread-12) [aiosqlite] executing functools.partial(<built-in method execute of sqlite3.Connection object at 0x7f900d35c9a0>, 'UPDATE devices_v13\n                    SET last_seen=:ts\n                    WHERE ieee=:ieee AND :ts - last_seen > :min_update_delta', {'ts': 1726253644.600438, 'ieee': 84:b4:db:ff:fe:67:f9:82, 'min_update_delta': 30.0})
2024-09-13 20:54:04.604 DEBUG (Thread-12) [aiosqlite] operation functools.partial(<built-in method execute of sqlite3.Connection object at 0x7f900d35c9a0>, 'UPDATE devices_v13\n                    SET last_seen=:ts\n                    WHERE ieee=:ieee AND :ts - last_seen > :min_update_delta', {'ts': 1726253644.600438, 'ieee': 84:b4:db:ff:fe:67:f9:82, 'min_update_delta': 30.0}) completed
2024-09-13 20:54:04.606 DEBUG (Thread-12) [aiosqlite] executing functools.partial(<built-in method commit of sqlite3.Connection object at 0x7f900d35c9a0>)
2024-09-13 20:54:04.607 DEBUG (Thread-12) [aiosqlite] operation functools.partial(<built-in method commit of sqlite3.Connection object at 0x7f900d35c9a0>) completed
2024-09-13 20:54:05.591 DEBUG (bellows.thread_0) [bellows.ash] Received data 726ab1a96b2a7d334fa6944a25aa559249984e27b412ce6763e17e
2024-09-13 20:54:05.591 DEBUG (bellows.thread_0) [bellows.ash] Received frame DataFrame(frm_num=7, re_tx=0, ack_num=2, ezsp_frame=b'(\x90\x01?\x00\x06\xfd\xff\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x1f\xff\x00\x00')
2024-09-13 20:54:05.591 DEBUG (bellows.thread_0) [bellows.ash] Sending frame AckFrame(res=0, ncp_ready=0, ack_num=0) + FLAG
2024-09-13 20:54:05.592 DEBUG (bellows.thread_0) [bellows.ash] Sending data  8070787e
2024-09-13 20:54:05.593 DEBUG (MainThread) [bellows.ezsp.protocol] Received command messageSentHandler: {'type': <EmberOutgoingMessageType.OUTGOING_BROADCAST: 6>, 'indexOrDestination': 65533, 'apsFrame': EmberApsFrame(profileId=0, clusterId=0, sourceEndpoint=0, destinationEndpoint=0, options=<EmberApsOption.APS_OPTION_SOURCE_EUI64: 1024>, groupId=0, sequence=31), 'messageTag': 255, 'status': <EmberStatus.SUCCESS: 0>, 'messageContents': b''}
2024-09-13 20:54:05.594 DEBUG (MainThread) [bellows.zigbee.application] Received messageSentHandler frame with [<EmberOutgoingMessageType.OUTGOING_BROADCAST: 6>, 65533, EmberApsFrame(profileId=0, clusterId=0, sourceEndpoint=0, destinationEndpoint=0, options=<EmberApsOption.APS_OPTION_SOURCE_EUI64: 1024>, groupId=0, sequence=31), 255, <EmberStatus.SUCCESS: 0>, b'']
2024-09-13 20:54:05.594 DEBUG (MainThread) [bellows.zigbee.application] Unexpected message send notification tag: (65533, 255)
2024-09-13 20:54:05.619 DEBUG (bellows.thread_0) [bellows.ash] Received data 026ab1a96b2a152283944a252a5592099c4e278554a867219a7e
2024-09-13 20:54:05.620 DEBUG (bellows.thread_0) [bellows.ash] Received frame DataFrame(frm_num=0, re_tx=0, ack_num=2, ezsp_frame=b'(\x90\x01?\x00\x00\x90\xda\x00\x00\x00\x80\x00\x00@\x00\x00\x00.\xb9f\x00')
2024-09-13 20:54:05.620 DEBUG (bellows.thread_0) [bellows.ash] Sending frame AckFrame(res=0, ncp_ready=0, ack_num=1) + FLAG
2024-09-13 20:54:05.620 DEBUG (bellows.thread_0) [bellows.ash] Sending data  8160597e
2024-09-13 20:54:05.621 DEBUG (MainThread) [bellows.ezsp.protocol] Received command messageSentHandler: {'type': <EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 'indexOrDestination': 55952, 'apsFrame': EmberApsFrame(profileId=0, clusterId=32768, sourceEndpoint=0, destinationEndpoint=0, options=<EmberApsOption.APS_OPTION_RETRY: 64>, groupId=0, sequence=46), 'messageTag': 185, 'status': <EmberStatus.DELIVERY_FAILED: 102>, 'messageContents': b''}
2024-09-13 20:54:05.621 DEBUG (MainThread) [bellows.zigbee.application] Received messageSentHandler frame with [<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 55952, EmberApsFrame(profileId=0, clusterId=32768, sourceEndpoint=0, destinationEndpoint=0, options=<EmberApsOption.APS_OPTION_RETRY: 64>, groupId=0, sequence=46), 185, <EmberStatus.DELIVERY_FAILED: 102>, b'']
2024-09-13 20:54:05.625 DEBUG (MainThread) [zigpy.application] Previously delayed request is now running, delayed by 191.60s

Requests are getting queued and are running delayed?
Which is an accurate description of the symptoms I and the rest of my not so happy family are seeing when we try to turn or off a light.

Have the full log file available if needed, but it is 62 MB...

[dmulcahey]

Zip the log and attach it here

[brussene]

home-assistant_zha_2024-09-13T18-54-22.972Z.zip

[puddly]

The error just eventually stopped showing up. Perhaps it was interference that has now somehow subsided.

I would stay away from channel 24. It overlaps directly with WiFi channel 6 and if you have any APs in the vicinity that can automatically pick channels, it's only a matter of time before it does.

Requests are getting queued and are running delayed?

From your log, there is a constant stream of network address requests coming from a couple of devices on your network (mostly 0xf137 and 0xe6f0). These requests are being sent very quickly but the devices aren't listening for a response, causing requests to queue up.

Please open a separate issue and attach the same log file, your issue isn't related to this one.

[TerminalAddict]

how can I provide debug logs etc to help solve this problem ?
Tonight, I open the HA companion app to turn some lights on and off .. nothing .. switch lights off . .nothing . .try turning them on .. nothing ...
Then 3 minutes later .. yes 3 minutes .. all the command come through to the lights and they go on and off until caught up with the commands I sent from HA companion app.
That is SUPER dumb ..
I'm four months into HA, the first month was awesome, now this dumb stuff happens

[stegitto]

Same issue here on 2024.9.1...
Zigbee network topology all green and a lot of <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074> messages in ZHA log.
Going back to 2024.8.1 (and rebooting the Zigbee routers) solved the issue...

[TerminalAddict]

Same issue here on 2024.9.1... Zigbee network topology all green and a lot of <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074> messages in ZHA log. Going back to 2024.8.1 (and rebooting the Zigbee routers) solved the issue...

well I'm tempted .. because living in a house where I can't control my lights (which are 100% zigbee) is super dumb.
It means I'd have to rewrite all my automations back to service instead of actions, but might be worth it

[Firewolf1337]

@TerminalAddict can you please try to reconnect the lights which are not working properly.
I had the same issue and after I have reconnected some devices this hasn't been occured to the devices i have reconnected.
Just to test if this could be a solution.

I've just put the lights in pairing mode and clicked "add Device" in Home Assistant.

[TerminalAddict]

@TerminalAddict can you please try to reconnect the lights which are not working properly. I had the same issue and after I have reconnected some devices this hasn't been occured to the devices i have reconnected. Just to test if this could be a solution.

I've just put the lights in pairing mode and clicked "add Device" in Home Assistant.

Here what I have
Heaps of TZ3000, TS0012 & TS0011 light switches (18 singles and 4 doubles)
Quite a few TZ3000, TS011F power switches, some as lights
Quite a few TZE200, TS0601 sensors
2 TZ3000, TS0203 door sensors
3 Philips Hue tap dial, RDM002
1 Frient A/S KEPZB-110
2 Schneider Electric CH/DIMMER/1

The main used devices are the TS0012, and TS0011 switches, it can be any one of them, or some of them.
I guess I could re-pair everything :/

[oliverhec]

@TerminalAddict you are using a SkyConnect stick as a coordinator right? According to your diagnostics the firmware of the stick is not up to date. I'd suggest to update it. Just connect it to your PC, visit https://connectzbt1.home-assistant.io/firmware-update/ and click the update firmware button.

[rwarner]

how can I provide debug logs etc to help solve this problem ?

@TerminalAddict - See @puddly's comment here: #124516 (comment)

Fwiw since rebooting haven't seen this again in 4 days fwiw. Will update to 2024.9.x soon.

@brussene Did you open up a separate issue for your logs?

[bakovari]

I have the same issue in last few weeks with SkyConnect and different devices (battery and non battery powered also)
According to your advice above I've updated the firmware. Let's see the result after couple of days.

[RomanAverin]

I have the exact same problem with sonoff zbdongle-e as a coordinator.
Periodically the switch on some of the smart plugs doesn't work. Voltage, current and other values are transmitted.

[stegitto]

Same issue here on 2024.9.1... Zigbee network topology all green and a lot of <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074> messages in ZHA log. Going back to 2024.8.1 (and rebooting the Zigbee routers) solved the issue...

No way. Still instability and 3074 error messages.
Just updated the SONOFF Zigbee 3.0 USB Dongle Plus V2 firmware to release 7.4.4 without getting better results.

I'm seriously thinking to buy a Hue bridge and drop all my sensors...

[hardelone]

So guys i have some news. my Zigbee mesh died, when even a restart didn't help, so I completely removed the integration (it hurt because I had 70 devices and 50 automations) but... I run new HA in parallel with the old home assistant, where I only run ZHA Integration (in addition to the standard ) and for a week without problems. But what is most strange is that the error 3074 still occurs in the logs, but everything runs as it should. So where is the real problem? Dňa st 18. 9. 2024, 13:39 stegitto ***@***.***> napísal(a):

…

Same issue here on 2024.9.1... Zigbee network topology all green and a lot of <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074> messages in ZHA log. Going back to 2024.8.1 (and rebooting the Zigbee routers) solved the issue... No way. Still instability and 3074 error messages. Just updated the SONOFF Zigbee 3.0 USB Dongle Plus V2 firmware to release 7.4.4 without getting better results. I'm seriously thinking to buy a Hue bridge and drop all my sensors... — Reply to this email directly, view it on GitHub <#124516 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWFZ6D6JIZZ7GZQ2DRMM7SDZXFQ5JAVCNFSM6AAAAABNBCHQKOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJYGIZTKNJQGI> . You are receiving this because you commented.Message ID: ***@***.***>

[dmulcahey]

So guys i have some news. my Zigbee mesh died, when even a restart didn't help, so I completely removed the integration (it hurt because I had 70 devices and 50 automations) but... I run new HA in parallel with the old home assistant, where I only run ZHA Integration (in addition to the standard ) and for a week without problems. But what is most strange is that the error 3074 still occurs in the logs, but everything runs as it should. So where is the real problem? Dňa st 18. 9. 2024, 13:39 stegitto @.> napísal(a):
…
Same issue here on 2024.9.1... Zigbee network topology all green and a lot of <sl_Status.ZIGBEE_DELIVERY_FAILED: 3074> messages in ZHA log. Going back to 2024.8.1 (and rebooting the Zigbee routers) solved the issue... No way. Still instability and 3074 error messages. Just updated the SONOFF Zigbee 3.0 USB Dongle Plus V2 firmware to release 7.4.4 without getting better results. I'm seriously thinking to buy a Hue bridge and drop all my sensors... — Reply to this email directly, view it on GitHub <#124516 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWFZ6D6JIZZ7GZQ2DRMM7SDZXFQ5JAVCNFSM6AAAAABNBCHQKOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJYGIZTKNJQGI . You are receiving this because you commented.Message ID: @.>

Are you using custom components? If so, safe mode is the first thing to try when there are issues like this…

[puddly]

@ecchodun still having issues? Or did the channel change fix things for you?

[ecchodun]

@ecchodun still having issues? Or did the channel change fix things for you?

Channel change to 24 worked for me for about 10 days, but then the error popped up once and not since. It's definitely more stable, but not convinced it's totally fixed.

[puddly]

For your problem, it's clear the issue is RF noise. Changing the channel will often help but if the noise moves around too (2.4GHz WiFi automatically picking channels), it's only a matter of time before it comes back. But a single delivery failures in 10 days seems perfectly fine.

I'm going to mark this issue as resolved.

If you're still having issues, please open a separate issue with debug logs!

[TerminalAddict]

@TerminalAddict you are using a SkyConnect stick as a coordinator right? According to your diagnostics the firmware of the stick is not up to date. I'd suggest to update it. Just connect it to your PC, visit https://connectzbt1.home-assistant.io/firmware-update/ and click the update firmware button.

ok, I'll try this tonight

[rwarner]

I know you closed this @puddly but I upgraded to 2024.9.2 yesterday and encountered this issue once again today after moving some lights around. Enabled the debugging when I saw it stopped turning them off and on and then tried to execute the button to turn the lights on and off again a couple times and saw the sl_Status.ZIGBEE_DELIVERY_FAILED: 3074 error again.

So finally have some debug logs when I caught this:

home-assistant_zha_2024-09-20T16-18-06.550Z.log

[CullumAttwell]

I am also still having the same issue.

[stegitto]

I am also still having the same issue.

me too....

home-assistant_zha_2024-09-20T17-37-58.067Z.log

[bryanklingner]

I'm also still experiencing this issue. I understand the desire to close the specific issue the OP posted, but this seems widespread enough that there should be some open tracking issue where people can report on it, if not this one--just let us know where!

I have partly mitigated this issue by adding an automation to restart the ZHA integration daily at 2am, following https://community.home-assistant.io/t/how-to-automatically-reload-integration-on-a-schedule/571065

[puddly]

@bryanklingner The error message you see in your logs may be the same but the error message isn't the problem, it's just a symptom. The root cause for OP's issue was RF interference so the fix is to address the RF interference (in this case, by changing the Zigbee network's channel). Unless your issue is also caused by RF interference, you have a different problem.

I'm going to lock this issue. As mentioned above, please open a separate issue, fully describe your problem and environment, and attach both ZHA debug logs and the ZHA diagnostic information: