zh:ember:uart:ash: Received ERROR from adapter, with code=ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT #23761
Comments
|
It has happened today twice :c I see some of |
|
You are getting different errors here, so, at first glance, it would point to the adapter being unstable. Did you look into removing possible sources of interference for the USB? (I see you are on a Pi, so, powered USB hub, extension cable, etc...) Note: September 1st release should also help on some edge-cases interference issues (2.4GHz ones). |
|
Thank you very much @Nerivec! I will make sure that power supply isn't the problem - I need to find somewhere a 5V 3A power supply, currently I'm using strong phone charger. The dongle is connected directly to the RPi. Also I'll be waiting for the September 1st release to check it will help somehow :D Thank you so much for your reply @Nerivec. PS PPS |
|
Interference can result is various errors that don't actually have any meaning because they are randomly triggered. Once this is improved/fixed, then we can see what errors remain, if any. The Pi is known for causing USB troubles. Make sure to use a USB extension cord to connect the adapter to it, so you can place it farther away from the Pi. A powered USB hub (a USB hub with it's own power supply, so it doesn't draw on the Pi) also fixed several problems for other users in the past. As for your router, if you haven't already, make sure your 2.4GHz WiFi and your ZigBee use very different channels. Usually, channel 20 or 25 for ZigBee is your best bet. You can also check channels usage around you with ember-zli.
|
|
Now I'm using the v1.40.0-1 of zigbee2mqtt and the problem has happened again... :/. In a period of 2 hours (before the fatal error occurred) I got five times And these were the last errors: Before I try to test the USB cable extension / powered USB hub, perhaps I should reflash my adapter with firmware with a different baud rate? Currently I'm using the 230400 version, should I use the 115200 version? What do you think @Nerivec? The rest of the log ("duplicates" removed) |
rrakso
changed the title
|
I don't think the baudrate would create this particular issue, but 115200 is definitely more tested than any other. |
|
@Nerivec could you please tell me what these errors mean? Maybe I can find out how to fix this too, haha After these errors the zigbee2mqtt stopped working. Now I am using a better power supply with a better cable (but I still don't have the you know the strong 5V 3A real one - but it worked so long with the old type :c really strange), but the baud is still The rest of the logPS |
/** The direction flag in the frame control field was incorrect. */
ERROR_WRONG_DIRECTION = 0x32,
/**
* The truncated flag in the frame control field was set, indicating there was not enough memory available to
* complete the response or that the response would have exceeded the maximum EZSP frame length.
*/
ERROR_TRUNCATED = 0x33,
/**
* The overflow flag in the frame control field was set, indicating one or more callbacks occurred since the previous
* response and there was not enough memory available to report them to the Host.
*/
ERROR_OVERFLOW = 0x34,From https://github.com/Koenkk/zigbee-herdsman/blob/master/src/adapter/ember/enums.ts#L755 But as mentioned before, with the varying errors, it looks like interference, which may result in errors that would not necessarily mean anything (except something interfered 😛).
Try to temporarily remove that device from the network if you can, see if it works better after that. That device creates some strange behaviors for sure. |
|
So after a week of testing I have unplugged the ZY-M100-S_2 and everything seems to work pretty good! I still have the problem that I have to disconnect and reconnect the adapter after rebooting the Raspberry Pi1, but I was able to switch to the previously used power supply two days ago and everything still works fine! In the next two weeks I plan to temporarily run my HA with Z2M on an old laptop (with a better processor than RPI, and with 4GB of RAM instead of the 1GB it currently has). And then I will try again to use the occupancy sensor. Footnotes
|
|
Quick note, not sure what step you are on, but make sure to update to 7.4.4 too, it seems to have fixed several problems for a few users. |
|
I was getting |
|
I get the following error everytime I restart or start z2m. zh:ember:uart:ash: Received ERROR from adapter while connecting, with code=ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT. If I rebbot the coordinators before starting the z2m instance no error. Running latest firmware, latest z2m on 3 separate instances. there are 0 interference issues all 3 installs are SLZB06M. |
|
Stumbling upon the same issue all the time and troubleshooting. When this error happens the only way to put network back online is to restart Home Assistant, restarting Z2M just gives me same error instantly.
Fortunately I have two locations with completely same zigbee configuration and after recent changes on one of them the error happens once every 1-2 days. And the other location is stable for 4 days already. So maybe some externat interferences are in play. Will report about new developments in my networks. EDIT: ok one mistake about sameness of the 2 locations setup. In the "stable" location I had SLZB06M coordinator firmware from .dev branch and in the unstable it was v2.3.6. Upgraded to latest v2.6.8.dev16 and will see. |
|
For me, this was solved by changing my WiFi channel. I was having lots of ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT errors, which were causing Zigbee2MQTT to restart. I could reproduce it almost always by recreating the map. I found i had the Ember coordinator on Zigbee channel 25 and my 2.4GHz WiFi on Channel 11. These channels overlap according to the diagram above. Moving my WiFi to channel 4 mostly solved the problem. Significantly less frequent errors and restarts. However, what I'm unclear on, @Nerivec , is why a timeout should require Zigbee2MQTT to restart? There are people on HA's forum having problems too: https://community.home-assistant.io/t/error-messages-trying-to-ota-update-devices-using-z2m-on-a-ha-yellow/788913/2 |
|
Whenever an ERROR frame is received from the adapter, it means the adapter has entered a "failed state", after which, the only recourse is to restart the stack. In a lot of cases, it's only about keeping proper synchronization between the adapter and the application. As for the error itself, most of the reports here look like interference indeed (you may not realize how bad it can get in some situations, and not necessarily from your environment, but neighbors too; the SLZB06M also seems particularly susceptible), but the adapter should handle this better nonetheless. I suspect a firmware issue when the radio comes under stress, but we'll have to wait for silabs on that one... |
|
@Nerivec so restart of just Z2M zhould be enough to bring network back online? Why this issue is so annoying for me is that Home Assistant restarts Z2M plugin, but it just keeps crashing in a loop with same error, what exhausts watchdog restart counter and the network fails permanently. Manual restarts of Z2M by me, after few hours when I realized the network is down, still leads to the error. The only way is to restart Home Assistant as a whole. This is the strange part for me. |
|
@szwacz And that happens with SLZB06M (TCP-based)? If it were with a USB device, I'd say something goes wrong with the USB on HA, but I assume the TCP adapter is not connected directly to the HA machine? |
|
@Nerivec you are correct, I use it via ethernet cable. |
|
It is strange that it requires a full HA restart to fix it though. Since you upgraded your network, I assume you have the old adapter laying around somewhere? Can you use it with Ember ZLI to scan for networks + channels, to see what the environment is like around you for reference (preferably closer to the new adapter)? https://github.com/Nerivec/ember-zli/wiki/Stack#scan-network Can you also take a look at the CPU usage on your machine around the time these errors happen? |
|
@ortofan what core firmware version do you have on the SLZB06M? Versions around 2.5.6 are known to have a bug that slows down the ESP side. That is reflected in the Zigbee side with timeouts. |
|
v2.6.8.dev16 and Zigbee: FWIW I have 5-8 NOUS A1Z Smart plugs on all my networks (I run 3 z2m instances all with the same coordinator and firmware). This is an invaluble plug for me becouse it has very unique feature. Over voltage protection. I frequntly have over 260v AC Mains on the phase of the house where large number of solar installations are present in my hood. INSANE I know but the power company wont fix it for a while. Till then NOUS and a few UPS saves me important gear as it turns off instantly when over 258v. |
|
@Nerivec Thank you for that explanation. Indeed I have NOUS A1Z in my network. So this issue should be separate of the one here. Thankfully failure of the network just happenedn, so I had the chance to observe it better. The hunch about CPU usage is intresting one, because I use Raspberry PI 3B+. First attaching logs of when the fail happened. I've discovered it after half an hour, and clicked just "start" in the Z2M addon options again. This is memory and cpu usage recorded during events from the log file above. After restarting whole HA everything went back to normal. Indeed maybe I should try upgrading my raspberry.... |
|
This happens to me as well. Once or twice a day my Zigbee network crashes. As far as I can see it often when it's under "high" load (As in a lot of devices are asked to do things at the same time). I can also reproduce the issue by trying to push an update to one of my Hue lamps. It will fail because of the crash. Adapter: Sonoff ZBDongle-E Logs |
|
@Nerivec I also did channel scan as you asked (man this is nice tool! :) ) My network is on channel 26 (moved there few weeks ago out of desperation). Didn't detect different zigbee networks than mine. I also ordered more powerful raspberry and will try run HA with more RAM. |
|
Im getting this error daily now, switched from a slae.sh stick to the 06M, using channel 25, my own wifi networks are on 1 and 6. Some Neighbors are on 11 but it is not particularly crowded here and these houses are well isolated. Unfortunately im at a loss on what i can do to improve this, running the latest firmware on the 06M as well. |
|
Ok, I can report major improvements. Upgraded from RaspberryPI 3B+ 1GB RAM, to RaspberryPI 4B 4GB RAM. On old setup (pi3): New setup (pi4): This is night and day. I don't know if processing power or RAM was the issue, but since I had two identical installations and after upgrade both improved this way I can pretty safely say that if you use Home Assistant with Zigbe2MQTT aim at Pi4 with at least 2 gigs of RAM. The |
|
@szwacz this is very good to know. I have the same RPi Model 3B+ 1GB hardware and ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT errors every couple of minutes, leading to Zigbee2MQTT restarts. It's also running openHAB 4.2, which has become unresponsive for sometimes a minute at a time since installing Z2M and connecting a handful of very talkative routers. Like you, I figured I needed to upgrade. I considered an RPi 4B or 5B, but for just over half the money I've bought an off-lease HP EliteDesk 800 G3 Mini with 16GB RAM and 256 NVMe. Based on your investigation, I think my hunch that this will at least improve the timeouts might pay off! |
|
With this in mind i increased the resources available to my z2m VM, it sits in a low resource alpine container. i increased it to 2 cores and 1GB ram, however it still crashed about a day later just like before. what i’ve done now is increased the ACK timeout delay to 2000, disabled OTA for some devices (these were a bit spammy) and made some changes in the tcp keep alive options in my vm. |
|
Just a sidenote, but from HA specs sheet, they seem to recommended Pi 4 or above. That would be for home assistant alone, you add add-ons and integrations, every time you increase the requirements a little (not so little for anything AI related). Z2M alone should use around 100MB of RAM (likely ~70 in most cases), and a small amount of CPU. It's not quite clear yet what could be essentially resulting in serial interference when the resources become low, but we've had enough reports to confirm it appears to be (HA). Some work is being done to reduce the requirements of Z2M a bit further, but it is already pretty low, so in most cases, the other "resource takers" should be looked at more closely (or the hardware specs indeed). @Kuchiru can you expand on the exact changes you applied to ACK & TCP? (If you have some before/after logs, that would be great too!) Also, are you running the original core firmware on the 06m, or a esphome firmware? |
|
Hi @Nerivec, Im running 2.6.8 dev21 for both logs with the latest dev firmware available for zigbee, 202411xx i believe. Changes in sysctl for tcp keepalive: I've attached the logs as well, for the before log i had debug enabled in the hopes of catching something extra, unfortunately i did not. |
That setting does not exist (i.e. this does nothing). There is a rather large spike in "stale neighbor" around midnight in your after log (https://nerivec.github.io/z2m-ember-helper/). |
Good to know, I’ll remove it!
I've looked through the log but did not find any mention of NEIGHBOR_STALE, nothing is set specifically to change after midnight though so im not sure what is causing this. did you see any specific devices that were stale? |
Yes. I red those guidelines, but I had Pi3 already laying around so just gave it a try. The thing is that everything was working fine. Except once in a while cascading crash due to error discussed in this thread happened. Since all troubleshooting materials about zigbee always focus on wifi or other signal interference and firmware updates this is what I was troubleshooting first few weeks. Nothing was telling me that performance bottleneck might be the culprit. |
|
@Kuchiru |
|
Yeah it bothers me too, housely activity obviously comes to a halt around midnight but all routers remain powered so im not sure whats happening here. Z2M did crash every morning shortly after we wake up, however, since the TCP changes and disabling OTA requests for some devices it has not crashed and has remained up for about 3 days now. I've had chatgpt analyze my logs to find any offenders that are spamming the network and reconfigured some reporting as well for good measure. edit: z2m started crashing again, i've created a home assistant automation to restart my z2m instance in proxmox when it disconnects, this works around the issue but is sub-optimal to say the least. |
|
Hi, I encountered a similar issue with Zigbee2MQTT as an add-on in Home Assistant running on Proxmox. My solution was to create a new VM and restore my configuration from a backup. After that, Zigbee2MQTT was stable. I think the issue is comming from Home Assistant Operation System. |
Unfortunately, a giant leap in CPU and memory hasn't eliminated my restarts. Despite using only up to 5% of the CPU and 55% of the RAM available to the container (Proxmox), over the past three days I've had 367 restarts. It's very unpredictable: sometimes it goes for hours without any restarts, but on the other hand between 2-3pm on 4 Jan, it restarted 33 times. The cause has been a mix of these two errors:
and
I'll try to use Z2M Ember Helper on the log files. |
|
@microneer you said before that you solved it. I assume it then came back? Any particular event that brough it back? |
|
First of all, @Nerivec, I want to sincerely thank you for your ongoing attention to this issue.
I said it was mostly solved by changing my WiFi channel. But it may have just appeared to be much better, because it now seems the reboots come and go throughout the day. In any event, I've now migrated off my RPi 3 as it looked at the time like moving to gruntier hardware would help things. It's possible that now the x64 virtualised environment is worse, but it's hard to tell.
Sonoff ZBDongle-E. I've only tried 7.4.3.
Unfortunately I don't think the instructions are applicable to my setup: I only use containers (aka LXC) not VM, the serial port TBH I'm very confused: are these ASH_ERROR_TIMEOUTS and ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT announcing serial, or radio issues? Initially we were talking about radio interference, now we're talking about, what, serial buffer overflows? I don't know which area to focus on, and would be grateful if you could please clarify what they mean. This post on HA, someone says it's caused by >6s of no response from the dongle - does that sound right? And such a delay could be caused by (very bad) CPU latency... but sounds more like a firmware issue to be honest. In any event, I've upped the CPU priority and capacity for my Zigbee2MQTT container to see if that helps. The whole Proxmox setup is at 1-2% CPU usage so I don't think Z2M will have been starved of resources, but you never know. This person updated to 7.4.4 and it resolved the issue, but later in the same thread, another person had no such luck. I guess I'll try that next. |
|
👍
So, it should amount to between 10 and 12 seconds... Tip You can use the following in the There are several ways this can happen (and most have been represented by different users from what I gathered):
More cases... but you get the gist. 8.1.0 appears to be centered on bugfixing, so hopefully it will improve several areas on the firmware side. Unfortunately, looks like it has a breaking bug around software flow control, so, we will likely have to wait for the next release since a few adapters still use that (which just so happens are the most affected)... 😞 |
|
Thanks for the insights. I would agree that 6s is an extraordinarily long timeout - a message has definitely gone AWOL. Last night I took out the USB cable and plugged my DongleE straight into the same port. I left it overnight, hoping for the best... How wrong I was: Z2M restarted every 1m 40s since then. It takes 34s to start, so the error was getting logged reliably every 1m 06s after Here's where it gets even more bizarre. I put the USB cable back in. It was 21m 40s to the first restart. Now it reboots every:
It looks like exactly every minute after Z2M starts, something happens, perhaps a message is sent to the coordinator. 6s after that event, there's a chance of a timeout. So, what happens every minute after |
|
Can be a lot of things, an automation on your end, some updates from Z2M (like availability depending on config), receiving device updates... could also be something on the host/guest machine, some kind of "heartbeat"-type thing... Are you sure your passthrough config is "as optimized as it can be". @Ricc68 can I ask for your insights? My knowledge of proxmox is still nil 😜 |
|
Sure @Nerivec 😉 I have found the hard way that for some reason the Proxmox passthrough of my USB device (ZBDongle-E) tends to stall every now and then. Another thing about Proxmox is that I think is worthless to keep resources low.
With this configuration my z2m in HAOS VM in Proxmox is rock solid. I've also read that @Kuchiru changed drastically the keepalive timeout (ok this is about TCP, not much about Proxmox):
while the Linux defaults (also in Proxmox) are:
When chatting with the z2m dongle, and this apply over both TCP and serial connection, the chat is very busy so I don't see how changing the TCP keepalive timers may affect the stability of the TCP connection: if there are stalls, they are somewhere else not in the TCP protocol (if you have stalls in the TCP protocol then you've got much worse problems with your network than just z2m not working). To try to avoid stalls I would rather further increase the resources allocated for the VM as 1GB of ram seems quite small to me.
Of course this wouldn't affect stalls that are located on the Zigbee adapter, which need to be fixed in the adapter itself. |
|
Thank you for your suggestions @Ricc68. As I noted a few posts above, I'm
already passing through the serial port rather than the USB, I believe so
anyway, and have been extremely generous with RAM and CPU.
@Nevirec I don't think this is interference from the host or guest or
network since the restarts appear at intervals of precisely N minutes + 6s
(the timeout period) from z2m starting. There is not going to be anything
on the host, or guest, that is precisely correlated to minute intervals
after with those restarts. Except z2m itself, or something in the firmware
or network that kicks off every 1m after the coordinator comes up.
My guess is that z2m sends something every 1m that sometimes causes the
firmware to hang. For most of the time for most people it's fine - maybe
there's something on the network like a particular device, or serial
timing, but whatever the reason there's a firmware race condition that
shows up at least in 7.4.3.
I'm going to try different firmware and turning on as much trace level
debugging as possible to find out what happens every 1 minute after (but
not at) z2m startup. I have had a busy weekend though.
…On Sat, 11 Jan 2025, 11:47 pm Ricc68, ***@***.***> wrote:
Sure @Nerivec <https://github.com/Nerivec>.
I have found the hard way that for some reason the Proxmox passthrough of
my USB device (ZBDongle-E) tends to stall every now and then.
My suggestion to @microneer <https://github.com/microneer> to rule out
the USB passthrough potential instabilities is to passthrough the serial
port rather than the USB device. I have explained how to do it with Proxmox
in the z2m installation guide
<https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start_crashes-runtime.html#error-regular-crashes-with-timeout-errors-or-failure-to-start-after-the-serial-port-is-opened>.
Also, as you are investigating, don't underestimate the quality of the USB
*2* cable (this is not related to Proxmox, but a bad cable gives errors
which can confuse the investigation a lot).
Another thing about Proxmox is that I think is worthless to keep resources
low.
In my HAOS VM to avoid resources bottlenecks I've set:
- 2GB minimum ram with 4GB maximum ballooning ram (means that it stays
at 2GB min and grows up to 4GB on demand but releases it if no more needed,
sharing with the host).
- 2 cores
- Serial0: /dev/serial/by-id/usb-ITHEAD_SONOFF_serial_device_etc_etc
With this configuration my z2m in HAOS VM in Proxmox is rock solid.
I've also read that @Kuchiru <https://github.com/Kuchiru> changed
drastically the keepalive timeout (ok this is about TCP, not much about
Proxmox):
- net.ipv4.tcp_keepalive_time = 60 # 1 minute of idle time
- net.ipv4.tcp_keepalive_intvl = 10 # 10-second interval between probes
- net.ipv4.tcp_keepalive_probes = 5 # 5 probes before declaring dead
while the Linux defaults (also in Proxmox) are:
- net.ipv4.tcp_keepalive_time = 7200
- net.ipv4.tcp_keepalive_intvl = 75
- net.ipv4.tcp_keepalive_probes = 9
When chatting with the z2m dongle, and this apply over both TCP and serial
connection, the chat is very busy so I don't see how changing the TCP
keepalive timers may affect the stability of the TCP connection: if there
are stalls, they are somewhere else not in the TCP protocol (if you have
stalls in the TCP protocol then you've got much worse problems with your
network than just z2m not working).
In my opinion changing these settings from the default has the result of
injecting unnecessary noise into the network.
To try to avoid stalls I would rather further increase the resources
allocated for the VM as 1GB of ram seems quite small to me.
Just for your reference, my HAOS VM in Proxmox is using much more than
that and my configuration is not that complicated:
immagine.png (view on web)
<https://github.com/user-attachments/assets/f1455c39-05a3-4363-9b0f-677fee27f1b7>
Of course this wouldn't affect stalls that are located on the Zigbee
adapter, which need to be fixed in the adapter itself.
—
Reply to this email directly, view it on GitHub
<#23761 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHL4RK7B5HA5DVIHN5QTRL2KDZDNAVCNFSM6AAAAABNH3J5UGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBVGIYDANRWGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Depends on setup, if using some kind of monitoring software, it could trigger when Z2M (NodeJS) starts. Though agreed, more of a stretch.
Should be easy enough to find this in the debug logs if there is one. @Ricc68 correct me if I'm wrong, but microneer mentioned the adapter was visible at |
|
@microneer consider that I'm using firmware 8.0.2 on my ZBDongle-E which was, at least for me, a significant improvement over 7.4.4. |
|
I've got stable operation for 8+ hours now by disabling polling of the 4x Tuya TS011F_plug_3's on my network. I tried this because with debug enabled I noticed in startup four entries like this, corresponding to those Tuya TS011F_plug_3's: It may be helpful to note that I found three of these messages just before the error is first logged: Anyway, so I disabled polling, although I didn't restart. Z2M ran for an hour and a half without the error. After Z2M restarted it ran for over 8 hours before I tried enabling polling again - at which point it errored after 1m 6s. It restarted but only lasted 3m 6s. Then 4m 6s. I think this is enough evidence to say that disabling polling on those devices has fixed my Z2M restarts. The strange thing is that the docs for that device say that polling is required because firmware > 1.0.5 doesn't broadcast the power. In my experience - and Z2M says I have firmware 1.0.5 on the devices - they broadcast plenty of updates, much more often than 60s. And polling them leads to disaster. Possible next steps?
|
|
@microneer can you try out a firmware in https://github.com/Nerivec/silabs-firmware-builder/releases/tag/v2024.6.2-update5 @Ricc68 if you're up for testing if the old way you had to pass serial through works better on these firmware, I'd be curious to know the result too. |
|
@Nerivec at the moment I don't have much time for this experiment as it requires to reconfigure both proxmox VM and HAOS, maybe in the next few weeks. |
|
2024.6.2-update5 is working much better with my ZBDongle-e on HASS VM running on Proxmox, I was using20250107 by darkxst before. I tried passing just the serial port, removing the usb extension and changing channels and it didn't seem to be helping at all. Eventually, it would crash z2m. I was using ZBDongle -p before and was hoping it was going to be an easy upgrade but I had this issue and in the beginning z2m wouldn't start because of this error: This is the error I was getting before: Right now, I am only seeing this info: |
... and .... (drumroll) ... problem solved! 24 hours now without a single restart, including when I enabled polling on 4x devices that actually don't need it (previously I found that this would cause errors almost every minute). So version 8.0.2 (which is what's linked above) is a solution, or at least a massive improvement. Like @tdashmike I'm seeing ROUTE_ERROR_MANY_TO_ONE_ROUTE_FAILURE for "nnnnn". Apparently that INFO message doesn't necessarily mean anything is wrong, according to the ever-helpful @Nerivec in #22516. Thank you all. |
and others
What happened?
My ZigBee network just stopped working. And I got this error message:
zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available.EDIT:
It seems that this is the main error message
zh:ember:uart:ash: Received ERROR from adapter, with code=ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT.It is also worth mentioning, that when I'm restarting the Home Assistant, then somehow Z2M after reboot causes HA to reboot again, but this time Z2M is not running. I had to switch
autostartof Z2M to false, because in other case I will end in reboot loop.To fix this all I must do is:
Unplug adapter
>reboot Home Assistant>Start Zigbee2MQTT (it will fail, ok, there is no adapter plugged in)>Start Zigbee2MQTT again>wait some time (2 to 4 s)>plug in adapter.From now on everything is working perfectly!
What did you expect to happen?
I expected that everything should work smoothly as always 😁
How to reproduce it (minimal and precise)
I don't know how to reproduce it. It has happend second time.
Zigbee2MQTT version
1.39.1
Adapter firmware version
7.4.3
Adapter
Sonoff ZBDongle-E with ember
Setup
HA on a Raspberry Pi 3 (
rpi3-64)Debug log
Expand to see
[2024-08-28 09:42:23] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/sensor', payload '{"detection_delay":0,"fading_time":2,"illuminance_lux":233,"last_seen":"2024-08-28T09:42:23+02:00","linkquality":200,"maximum_range":5,"minimum_range":0,"presence":false,"radar_sensitivity":4,"target_distance":0}' [2024-08-28 09:42:24] error: zh:ember:ezsp: ERROR Transaction failure; status=ERROR_WRONG_DIRECTION. Last Frame: [FRAME: ID=52:"SEND_UNICAST" Seq=135 Len=26]. [2024-08-28 09:42:24] error: zh:ember:ezsp: ERROR Transaction failure; status=ERROR_WRONG_DIRECTION. Last Frame: [FRAME: ID=52:"SEND_UNICAST" Seq=135 Len=26]. [2024-08-28 09:42:24] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/sensor', payload '{"detection_delay":0,"fading_time":2,"illuminance_lux":233,"last_seen":"2024-08-28T09:42:24+02:00","linkquality":196,"maximum_range":5,"minimum_range":0,"presence":false,"radar_sensitivity":4,"target_distance":0}' [2024-08-28 09:42:51] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/sensor', payload '{"detection_delay":0,"fading_time":2,"illuminance_lux":233,"last_seen":"2024-08-28T09:42:51+02:00","linkquality":200,"maximum_range":5,"minimum_range":0,"presence":false,"radar_sensitivity":4,"target_distance":0}' [2024-08-28 09:42:53] error: zh:ember:ezsp: ERROR Transaction failure; status=ASH_ERROR_TIMEOUTS. Last Frame: [FRAME: ID=52:"SEND_UNICAST" Seq=139 Len=7]. [2024-08-28 09:42:53] error: zh:ember: !!! ADAPTER FATAL ERROR reason=ASH_ERROR_TIMEOUTS. !!! [2024-08-28 09:42:53] info: zh:ember: Attempting adapter reset... [2024-08-28 09:42:53] info: zh:ember:uart:ash: ASH COUNTERS since last clear: [2024-08-28 09:42:53] info: zh:ember:uart:ash: Total frames: RX=2291, TX=2766 [2024-08-28 09:42:53] info: zh:ember:uart:ash: Cancelled : RX=0, TX=0 [2024-08-28 09:42:53] info: zh:ember:uart:ash: DATA frames : RX=2237, TX=673 [2024-08-28 09:42:53] info: zh:ember:uart:ash: DATA bytes : RX=52490, TX=17515 [2024-08-28 09:42:53] info: zh:ember:uart:ash: Retry frames: RX=41, TX=5 [2024-08-28 09:42:53] info: zh:ember:uart:ash: ACK frames : RX=13, TX=2088 [2024-08-28 09:42:53] info: zh:ember:uart:ash: NAK frames : RX=0, TX=0 [2024-08-28 09:42:53] info: zh:ember:uart:ash: nRdy frames : RX=0, TX=0 [2024-08-28 09:42:53] info: zh:ember:uart:ash: CRC errors : RX=0 [2024-08-28 09:42:53] info: zh:ember:uart:ash: Comm errors : RX=0 [2024-08-28 09:42:53] info: zh:ember:uart:ash: Length < minimum: RX=0 [2024-08-28 09:42:53] info: zh:ember:uart:ash: Length > maximum: RX=0 [2024-08-28 09:42:53] info: zh:ember:uart:ash: Bad controls : RX=0 [2024-08-28 09:42:53] info: zh:ember:uart:ash: Bad lengths : RX=0 [2024-08-28 09:42:53] info: zh:ember:uart:ash: Bad ACK numbers : RX=0 [2024-08-28 09:42:53] info: zh:ember:uart:ash: Out of buffers : RX=0 [2024-08-28 09:42:53] info: zh:ember:uart:ash: Retry dupes : RX=41 [2024-08-28 09:42:53] info: zh:ember:uart:ash: Out of sequence : RX=0 [2024-08-28 09:42:53] info: zh:ember:uart:ash: ACK timeouts : RX=5 [2024-08-28 09:42:53] info: zh:ember:uart:ash: Port closed. [2024-08-28 09:42:53] info: zh:ember:uart:ash: ======== ASH stopped ======== [2024-08-28 09:42:53] info: zh:ember:ezsp: ======== EZSP stopped ======== [2024-08-28 09:42:53] info: zh:ember: ======== Ember Adapter Stopped ======== [2024-08-28 09:42:54] info: zh:ember: ======== Ember Adapter Starting ======== [2024-08-28 09:42:54] info: zh:ember:ezsp: ======== EZSP starting ======== [2024-08-28 09:42:54] info: zh:ember:uart:ash: ======== ASH Adapter reset ======== [2024-08-28 09:42:55] info: zh:ember:uart:ash: RTS/CTS config is off, enabling software flow control. [2024-08-28 09:42:55] info: zh:ember:uart:ash: Serial port opened [2024-08-28 09:42:55] info: zh:ember:uart:ash: ======== ASH starting ======== [2024-08-28 09:42:56] info: zh:ember:uart:ash: ======== ASH connected ======== [2024-08-28 09:42:56] info: zh:ember:uart:ash: ======== ASH started ======== [2024-08-28 09:42:56] info: zh:ember:ezsp: ======== EZSP started ======== [2024-08-28 09:42:57] info: zh:ember: Adapter EZSP protocol version (13) lower than Host. Switched. [2024-08-28 09:42:57] info: zh:ember: Adapter version info: {"ezsp":13,"revision":"7.4.3 [GA]","build":0,"major":7,"minor":4,"patch":3,"special":0,"type":170} [2024-08-28 09:42:57] info: zh:ember: [STACK STATUS] Network up. [2024-08-28 09:42:57] info: zh:ember: [INIT TC] Adapter network matches config. [2024-08-28 09:42:57] info: zh:ember: [CONCENTRATOR] Started source route discovery. 1248ms until next broadcast. [2024-08-28 09:42:58] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/sensor', payload '{"detection_delay":0,"fading_time":2,"illuminance_lux":233,"last_seen":"2024-08-28T09:42:58+02:00","linkquality":136,"maximum_range":5,"minimum_range":0,"presence":false,"radar_sensitivity":4,"target_distance":0}' [2024-08-28 09:43:25] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/sensor', payload '{"detection_delay":0,"fading_time":2,"illuminance_lux":233,"last_seen":"2024-08-28T09:43:25+02:00","linkquality":200,"maximum_range":5,"minimum_range":0,"presence":false,"radar_sensitivity":4,"target_distance":0}' [2024-08-28 09:43:25] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/sensor', payload '{"detection_delay":0,"fading_time":2,"illuminance_lux":233,"last_seen":"2024-08-28T09:43:25+02:00","linkquality":200,"maximum_range":5,"minimum_range":0,"presence":false,"radar_sensitivity":4,"target_distance":0}' [2024-08-28 09:43:26] error: zh:ember:uart:ash: Received ERROR from adapter, with code=ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT. [2024-08-28 09:43:26] error: zh:ember:uart:ash: ASH disconnected | Adapter status: ASH_NCP_FATAL_ERROR [2024-08-28 09:43:26] error: zh:ember:uart:ash: Error while parsing received frame, status=ASH_NCP_FATAL_ERROR. [2024-08-28 09:43:27] error: zh:ember: !!! ADAPTER FATAL ERROR reason=HOST_FATAL_ERROR. !!! [2024-08-28 09:43:27] info: zh:ember: Attempting adapter reset... [2024-08-28 09:43:27] info: zh:ember:uart:ash: ASH COUNTERS since last clear: [2024-08-28 09:43:27] info: zh:ember:uart:ash: Total frames: RX=97, TX=109 [2024-08-28 09:43:27] info: zh:ember:uart:ash: Cancelled : RX=0, TX=0 [2024-08-28 09:43:27] info: zh:ember:uart:ash: DATA frames : RX=77, TX=42 [2024-08-28 09:43:27] info: zh:ember:uart:ash: DATA bytes : RX=1512, TX=569 [2024-08-28 09:43:27] info: zh:ember:uart:ash: Retry frames: RX=17, TX=3 [2024-08-28 09:43:27] info: zh:ember:uart:ash: ACK frames : RX=1, TX=63 [2024-08-28 09:43:27] info: zh:ember:uart:ash: NAK frames : RX=0, TX=0 [2024-08-28 09:43:27] info: zh:ember:uart:ash: nRdy frames : RX=0, TX=0 [2024-08-28 09:43:27] info: zh:ember:uart:ash: CRC errors : RX=0 [2024-08-28 09:43:27] info: zh:ember:uart:ash: Comm errors : RX=0 [2024-08-28 09:43:27] info: zh:ember:uart:ash: Length < minimum: RX=0 [2024-08-28 09:43:27] info: zh:ember:uart:ash: Length > maximum: RX=0 [2024-08-28 09:43:27] info: zh:ember:uart:ash: Bad controls : RX=0 [2024-08-28 09:43:27] info: zh:ember:uart:ash: Bad lengths : RX=0 [2024-08-28 09:43:27] info: zh:ember:uart:ash: Bad ACK numbers : RX=0 [2024-08-28 09:43:27] info: zh:ember:uart:ash: Out of buffers : RX=0 [2024-08-28 09:43:27] info: zh:ember:uart:ash: Retry dupes : RX=17 [2024-08-28 09:43:27] info: zh:ember:uart:ash: Out of sequence : RX=0 [2024-08-28 09:43:27] info: zh:ember:uart:ash: ACK timeouts : RX=3 [2024-08-28 09:43:27] error: zh:ember:uart:ash: Error while parsing received frame, status=ASH_NCP_FATAL_ERROR. [2024-08-28 09:43:29] error: zh:ember:uart:ash: ASH disconnected: ASH_ERROR_RESET_FAIL | Adapter status: ASH_NCP_FATAL_ERROR [2024-08-28 09:43:29] error: zh:ember:uart:ash: ASH disconnected: ASH_ERROR_RESET_FAIL | Adapter status: ASH_NCP_FATAL_ERROR [2024-08-28 09:43:33] info: zh:ember:uart:ash: Port closed. [2024-08-28 09:43:35] info: zh:ember:uart:ash: ======== ASH stopped ======== [2024-08-28 09:43:36] info: zh:ember:ezsp: ======== EZSP stopped ======== [2024-08-28 09:43:36] info: zh:ember: ======== Ember Adapter Stopped ======== [2024-08-28 09:43:37] error: zh:ember:ezsp: ERROR Transaction failure; status=ASH_ERROR_TIMEOUTS. Last Frame: [FRAME: ID=0:"VERSION" Seq=0 Len=0]. [2024-08-28 09:43:37] error: zh:ember: !!! ADAPTER FATAL ERROR reason=ASH_ERROR_TIMEOUTS. !!! [2024-08-28 09:43:37] info: zh:ember: Attempting adapter reset... [2024-08-28 09:43:37] info: zh:ember:uart:ash: ASH COUNTERS since last clear: [2024-08-28 09:43:37] info: zh:ember:uart:ash: Total frames: RX=0, TX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: Cancelled : RX=0, TX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: DATA frames : RX=0, TX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: DATA bytes : RX=0, TX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: Retry frames: RX=0, TX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: ACK frames : RX=0, TX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: NAK frames : RX=0, TX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: nRdy frames : RX=0, TX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: CRC errors : RX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: Comm errors : RX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: Length < minimum: RX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: Length > maximum: RX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: Bad controls : RX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: Bad lengths : RX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: Bad ACK numbers : RX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: Out of buffers : RX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: Retry dupes : RX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: Out of sequence : RX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: ACK timeouts : RX=0 [2024-08-28 09:43:37] info: zh:ember:uart:ash: ======== ASH stopped ======== [2024-08-28 09:43:37] info: zh:ember:ezsp: ======== EZSP stopped ======== [2024-08-28 09:43:37] info: zh:ember: ======== Ember Adapter Stopped ======== [2024-08-28 09:43:37] info: zh:ember: ======== Ember Adapter Starting ======== [2024-08-28 09:43:37] info: zh:ember:ezsp: ======== EZSP starting ======== [2024-08-28 09:43:37] info: zh:ember:uart:ash: ======== ASH Adapter reset ======== [2024-08-28 09:43:38] info: zh:ember:uart:ash: RTS/CTS config is off, enabling software flow control. [2024-08-28 09:43:38] info: zh:ember:uart:ash: Serial port opened [2024-08-28 09:43:38] info: zh:ember:uart:ash: ======== ASH starting ======== [2024-08-28 09:43:38] info: zh:ember: ======== Ember Adapter Starting ======== [2024-08-28 09:43:38] info: zh:ember:ezsp: ======== EZSP starting ======== [2024-08-28 09:43:38] info: zh:ember:uart:ash: ======== ASH Adapter reset ======== [2024-08-28 09:43:38] info: zh:ember:uart:ash: ======== ASH starting ======== [2024-08-28 09:43:39] info: zh:ember:uart:ash: ======== ASH connected ======== [2024-08-28 09:43:40] info: zh:ember:uart:ash: ======== ASH started ======== [2024-08-28 09:43:40] info: zh:ember:ezsp: ======== EZSP started ======== [2024-08-28 09:43:40] info: zh:ember:uart:ash: ======== ASH started ======== [2024-08-28 09:43:40] info: zh:ember:ezsp: ======== EZSP started ======== [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] info: zh:ember: Adapter EZSP protocol version (13) lower than Host. Switched. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] info: zh:ember: Adapter EZSP protocol version (13) lower than Host. Switched. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] info: zh:ember: Adapter version info: {"ezsp":13,"revision":"7.4.3 [GA]","build":0,"major":7,"minor":4,"patch":3,"special":0,"type":170} [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] info: zh:ember: Adapter version info: {"ezsp":13,"revision":"7.4.3 [GA]","build":0,"major":7,"minor":4,"patch":3,"special":0,"type":170} [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember:ezsp: Found no buffer in queue but ASH layer sent signal that one was available. [2024-08-28 09:43:40] error: zh:ember: Failed to reset and init adapter. Error: Failed to register endpoint '1' with status=ZIGBEE_EZSP_ERROR. [2024-08-28 09:43:40] info: zh:ember:uart:ash: ASH COUNTERS since last clear: [2024-08-28 09:43:40] info: zh:ember:uart:ash: Total frames: RX=37, TX=75 [2024-08-28 09:43:40] info: zh:ember:uart:ash: Cancelled : RX=0, TX=0 [2024-08-28 09:43:40] info: zh:ember:uart:ash: DATA frames : RX=36, TX=37 [2024-08-28 09:43:40] info: zh:ember:uart:ash: DATA bytes : RX=246, TX=394 [2024-08-28 09:43:40] info: zh:ember:uart:ash: Retry frames: RX=0, TX=0 [2024-08-28 09:43:40] info: zh:ember:uart:ash: ACK frames : RX=0, TX=37 [2024-08-28 09:43:40] info: zh:ember:uart:ash: NAK frames : RX=0, TX=0 [2024-08-28 09:43:40] info: zh:ember:uart:ash: nRdy frames : RX=0, TX=0 [2024-08-28 09:43:40] info: zh:ember:uart:ash: CRC errors : RX=0 [2024-08-28 09:43:40] info: zh:ember:uart:ash: Comm errors : RX=0 [2024-08-28 09:43:40] info: zh:ember:uart:ash: Length < minimum: RX=0 [2024-08-28 09:43:40] info: zh:ember:uart:ash: Length > maximum: RX=0 [2024-08-28 09:43:40] info: zh:ember:uart:ash: Bad controls : RX=0 [2024-08-28 09:43:40] info: zh:ember:uart:ash: Bad lengths : RX=0 [2024-08-28 09:43:40] info: zh:ember:uart:ash: Bad ACK numbers : RX=0 [2024-08-28 09:43:40] info: zh:ember:uart:ash: Out of buffers : RX=0 [2024-08-28 09:43:40] info: zh:ember:uart:ash: Retry dupes : RX=0 [2024-08-28 09:43:40] info: zh:ember:uart:ash: Out of sequence : RX=0 [2024-08-28 09:43:40] info: zh:ember:uart:ash: ACK timeouts : RX=0 [2024-08-28 09:43:40] info: zh:ember:uart:ash: Port closed. [2024-08-28 09:43:40] info: zh:ember:uart:ash: ======== ASH stopped ======== [2024-08-28 09:43:40] info: zh:ember:ezsp: ======== EZSP stopped ======== [2024-08-28 09:43:41] info: zh:ember: ======== Ember Adapter Stopped ======== [2024-08-28 09:43:41] error: z2m: Adapter disconnected, stopping [2024-08-28 09:43:41] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload '{"state":"offline"}' [2024-08-28 09:43:41] info: z2m: Disconnecting from MQTT server [2024-08-28 09:43:41] info: z2m: Stopping zigbee-herdsman... [2024-08-28 09:43:41] info: z2m: Stopped zigbee-herdsman [2024-08-28 09:43:41] info: z2m: Stopped Zigbee2MQTTThe text was updated successfully, but these errors were encountered: