-
-
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
Zigbee2MQTT stops with 'Adapter disconnected' error and does not restart #17809
Comments
I'm experiencing the same thing but not in a docker environment. (Running Home Assistant in Proxmox) Adapter: SONOFF Zigbee 3.0 USB Dongle Plus-P error 2023-05-31 11:48:26: Adapter disconnected, stopping |
If it can help you I had a similar problem as soon as I touched the adapter, my raspberry or my SSD the adapter disconnected. The problem came from the charger of my SSD which had an alternating current leak on the USB ground. To solve this problem I grounded |
Is this similar to this bug: #17947 |
No, that one is of different origin - i do not have problems finding the radio, the problem is that z2m does not reboot properly on failure. |
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 |
I am having this issue once every two hours, nearly on the dot, but using a PoE adapter. |
I am also seeing this frequently. I have zigbee2mqtt running in docker, connected to zigstar UZG-01 over ethernet. The docker container dies frequently with below error
it would be preferable for zigbee2mqtt to be more resilient to connectivity errors |
I, too, am using a UZG-01 over ethernet. I did a continuous port check every 500ms to the UZG-01 on the port Z2M is connecting to, as well as the web interface, my home assistant box, etc, and didn't see the zigbee port go down, nor any of the others I was checking, but the Z2M docker gave that same error after 1h 59m 55s and does this repeatedly once the connection time eaches that same point: error 2023-12-05 15:16:52: Adapter disconnected, stopping
info 2023-12-05 15:16:52: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload 'offline'
info 2023-12-05 15:16:52: Disconnecting from MQTT server
info 2023-12-05 15:16:52: Stopping zigbee-herdsman...
error 2023-12-05 15:16:52: Failed to stop Zigbee2MQTT |
Good observation. I setup my docker with auto restart, and see the issue repeat every 2 hours. the adapter is up, but disconnects still happen at the 2 hour mark I saw the issue you reported: #20148 |
I have the same problem. As soon as I realize the zigbee network ios down I check the coordinator, in its IP, and it looks like the coordinator is ok. I have to re-start the addon in order to have it working again. Do you solve it? |
A few of us who had a disconnected adapter, showing that uptime of the connection reset at the same time as the addon restarting were able to fix it (so far, it seems, at least) my setting static IP on the coordinator. Not sure if yours is the same, though. |
I'm experiencing a similar problem. Except it USB connected. |
Any resolution on this? my system was working without issues until few weeks ago - i've resorted to add a cron job to restart the Zigbee2MQTT docker every two hours. 0 */2 * * * /usr/bin/docker restart zigbee2mqtt >/dev/null 2>&1 Not the most elegant solution but it is working, I know that if the timing aligns with the reload my scripts will not trigger. |
I had the same issues today. ser2net -h tells me: Or it is because of some bad systemd-woodoo for ser2net on an old raspi1. |
Same problem here: Adapter disconnected, stopping |
I added code to reboot whenever disconnect detected. I log the date and
time.
Here is the log.
Tue 09 Jan 2024 06:11:15 PM PST
Tue 09 Jan 2024 07:09:41 PM PST
Wed 10 Jan 2024 01:55:15 PM PST
Wed 10 Jan 2024 02:33:00 PM PST
Wed 10 Jan 2024 05:40:45 PM PST
Fri 12 Jan 2024 12:46:18 PM PST
Fri 12 Jan 2024 01:22:16 PM PST
Fri 12 Jan 2024 03:13:30 PM PST
Sat 13 Jan 2024 10:48:08 AM PST
Thu 25 Jan 2024 03:54:54 PM PST
Sat 27 Jan 2024 12:30:26 PM PST
Mon 29 Jan 2024 03:29:15 PM PST
Thu 01 Feb 2024 05:23:51 PM PST
Sun 04 Feb 2024 01:01:43 PM PST
…On Sat, Feb 10, 2024 at 12:52 AM Kowi030 ***@***.***> wrote:
Same problem here: Adapter disconnected, stopping
—
Reply to this email directly, view it on GitHub
<#17809 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGJXT55NVXRWM3JDI3ETWLYS4YJZAVCNFSM6AAAAAAYRCHYMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZWHEZTOMRYHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Can you post the code please? |
I have the same problem, I'm using a Sonoff Dongle Plus E. Z2M runs without any problems, but when I start more than one OTA the adapter disconnects after a few seconds. When I update a device one by one then sometimes it completes, but most of the time the error occurs and I have to stop z2m, edit state.json and start z2m because otherwise the update hangs and cannot be restarted. |
I am having the same problem except for me it gets disconnected whenever I change a device parameter i.e: when I set calibration to 0 on a zigbee plug. I Sonoff Dongle Plus E I have read that the dongle E is experimental so I ordered a version P |
Does any of you know what 'adapter disconnected' means? I'm wondering if this is a problem with the hardware and if the adapter really isn't reachable. Or if this is an issue with Z2M. What would be the best way to figure out? |
What I can tell is that it's a real disconnect. I am running Home Assistant with zigbee2mqtt as local addon and when I get the message I see the USB getting reset in que qemu logs. |
Same here but dongle directly into the machine. is the situation worsening!? here some data Home assistant green not always the log.txt has the last things happening (while is stopping) log.txt: info 2024-02-17 14:58:48: Zigbee2MQTT started! info 2024-02-17 20:09:40: MQTT publish: topic 'zigbee2mqtt/Felice Armario Center Left', payload '{"brightness":254,"color_mode":"color_temp","color_options":null,"color_temp":357,"linkquality":144,"power_on_behavior":null,"state":"ON","update":{"installed_version":50331664,"latest_version":50331664,"state":"idle"},"update_available":null}' |
are you using the serial port as per the instruction in the add on install guide: port: /dev/ttyUSB0 I was having this issue last year, and changed to the full path, and this fixed my issue. My config looks like port: >- |
In my case, yes I was using the full path. meanwhile I read that the sonoff dongle-E was experimental and somehow buggy. I ordered a dongle-P, started from scratch. Since then everything is running fine again. moreover, I was having issues with OTA where updates were running for days without finishing. and indeed adding new devices was a no-go Z2M restarting in the middle of the interview. since the dongle-P FW updates run fine. BTW not sure if DEVs are reading this thread but I am also on a HA forum where ppl seem to suffer the same kind of issues with conbee's. |
I just finished the migration of ~100 devices from DeConz, I'm not keen on re-pairing all of them again. In my case OTA updates are the only cause of these errors. Updates of non-battery devices sometimes works, sometimes it doesn't. But after editing state.json the updates resume and finally complete. I can live with that. But the tradfri switches take a long time to update (4-10 hours), and for those the update always starts from scratch. |
I'm not using full path but i'm using specific dev link /dev/ttyZIGB defined using usb-serail.rules it worked flawless for many months without issue, and it recently started having problems. My ZigBee adapter a nortek gocontrol husbzb-1 - I have OpenHab running natively and Home Assistant/ZigBee2MQTT running as docker containers. Everytime there is a disconnect I do not see any usb errors on the host logs - even with the two hours Z2M docker container restart I still have few disconnects, I disable the OTA Automatic check to see if it helps. I wonder if this is a docker bug and not an Z2M issue. `lrwxrwxrwx 1 root root 7 Feb 13 11:28 /dev/ttyCADDX -> ttyUSB2 SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="FT9JX8IX", SYMLINK+="ttyCADDX" Using '/app/data' as data directory ` |
Same problem here. Docker setup and using a SLZB-06 over Ethernet PoE, not USB. Z2M quits with "adapter disconnected" and doesn't restart. |
Sorry to not get back. it runs as a script from the console when it fails I log date and reboot
here are the important parts of my "watchdog" it does a graceful shutdown of other processes, then calling os._exit(-1)
My code runs from .bashrc and I log date and reboot
current bootlog
|
Also same same here |
I am also experiencing the exact same problem as described in the issue. I am not sure if zigbee2mqtt quitting due to "Adapter disconnected, stopping" is a bug, though. But the container not restarting even when configured to |
I literally threw the Dongle-E in the trash after repairing over 100 devices with a new Dongle-P coordinator (it took me globally less time this than trying to find a solution). In the occasion I setup a HA vm on a proxmox which runs like charm (especially the reboot takes less than half the time then having HA running directly on the miniPC) |
After I switched to use Ember all my issues are gone now for weeks with the dongle-e. |
This is the output of the docker daemon when I disconnect the stick (and docker is not restarting the container):
I think this error is indicating that docker's "restartmanager" encountered a problem which led to not restarting the container: The error is generated here in the source code: But I fail to understand what is happening there or why. Does anyone know what "restartmanger wait error" means or in which situation it happens? |
Hm, I think this is intended behavior of docker: As mentioned here: So, is there a bug here involved at all?
Would you agree? If yes: what to do here to make the container restart without manual interaction? Any good ideas for a workaround? |
I'm also interested in knowing how to restart without manual interaction. Any ideas? |
I was able to use udev to automatically restart on reconnect:
Works like a charm |
Not sure if this is relevant here or not. I recently noticed that all my zigbee devices would be disconnected, including my bridge, for (what I assumed to be) no reason. Restarting HA resolved the issue so I didn't think anything of it. It happened again last night and I was confused as to why. I confirmed the bridge was connected to my network, and HA could see it using the ping integration. I then went to Zigbee2MQTT and saw it wasn't running, starting it would get everything up and running again. THEN IT CLICKED. I updated my unifi network when this issue arose, meaning the connection between HA and the bridge was lost, causing what I assume to be a fatal error within Zigbee2MQTT. I can replicate the issue by either disconnecting HA from my network, or disconnecting my bridge from my network. For context, I'm running HA on a NUC, and I have a POE bridge ([HamGeek POE Zigbee 3.0). As a bit of a band-aid fix, I've created an automation that triggers when the bridge state changes from disconnected to connected, and has to remain that way for 2 min, with a condition that HA can ping the bridge. It will then start the Zigbee2MQTT again. Automation YAML is below if anyone is curious:
|
I've made a fairly robust version of what others have posted/alluded to. Youi'll want to change the alerts to your own alerting preferences/setup.
|
Damn, you've gone and one upped me 😉 One thing that my automation doesn't do, that I think would be good, is to at a counter to track restart attempts, and to stop the automation after X amount of retries, send a notification or something to inform of the issue. I like your solution tho! |
Same here with USB connector. Container is stopped but never restarted
Portainer shows this when inspected though I can see the device still there under the same path
|
had the same problem 2 weeks ago with my slaesh usb adapter on my hassio and again today. I suspected the usb cable the first time and replugged it. but the second time I didn't touch it. for me the only solution was a full reboot. so my pov is that this is a code issue, not hardware related. thanks.
|
Hi @Koenkk, crashed today again... how can I help?
|
I am thinking the container is trying to restart and I think the USB is not available for a short period in the moment of the restart: |
In my case, the issue is that I generally reconnect the USB adapter and expect that my is there a way to force I say that because my problem is hardware, not software. If I fix the "hardware" problem (which happens 2 times a month on avg.) I would love for it to just restart itself, instead of making me log into portainer to manually start a "stack" that has |
To me, everything is working as designed. What folks are asking for is Z2M to add more resilience. That's one approach to resilience, but another is externally applied resilience. Should a component retry more often for long periods of time? Maybe. But until it does, there's an easy way for us to supply that same behavior. |
It seems that script is only usable if you are running a Home Assistant server, right? |
I would assume so... In my case Home Assistant is just another container on my RPi server, managed by portainer, and zigbee2mqtt is yet another container. I'm not sufe if it's useful for me either. |
Ahh, yes. I assumed too much. But the same (or simpler) could be
implemented as a crontab script, for example
…On Tue, Dec 17, 2024, 11:15 Luiz Eduardo Carneiro ***@***.***> wrote:
It seems that script is only usable if you are running a Home Assistant
server, right?
I would assume so...
In my case Home Assistant is just another container on my RPi server,
managed by portainer, and zigbee2mqtt is yet another container.
I'm not sufe if it's useful for me either.
—
Reply to this email directly, view it on GitHub
<#17809 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB32XY2FWXRFT3ERL34OSFD2GBL3RAVCNFSM6AAAAAAYRCHYMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBZGA4DAMJRHE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
to be honest, external scrips are more of a workaround than actually a fix. it's really weird for a piece of software to stop "successfully" when something WRONG happens, if the that's why it caught me off-guard when |
Totally agree. From an IT mindset, that's not an "ended successfully"
situation. Absolutely the return code should indicate an error. Only a
successful requested shutdown should return a 0 return code.
…On Tue, Dec 17, 2024, 11:30 Luiz Eduardo Carneiro ***@***.***> wrote:
to be honest, external scrips are more of a workaround than actually a fix.
it's really weird for a piece of software to stop "successfully" when
something WRONG happens, if the zigbee2mqtt lost communication with the
adapter, it should fail instead of "well, guess I will just end my shift
early, then... See ya!".
that's why it caught me off-guard when restart: always wasn't sufficient,
there was clearly a problem (no adapter available) and the container
decided that "the work is finished with success, no need to restart"... on
a failure. So the watchdog (Docker) that watches for a failure looks into
it and see "well, no failure here, I guess this is just expected and I
won't restart it, then"
—
Reply to this email directly, view it on GitHub
<#17809 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB32XY35EU6ZGWDFR5I6FUL2GBNU5AVCNFSM6AAAAAAYRCHYMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBZGEYTQMJQGA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Sorry, I am a bit confused: does |
This really helped me, thank you. As you mentioned it require to create a new integration (for the ICMP Ping of the device), adjust the entity id names in the code and also create the script that notifies my device. Appreciate you sharing this. |
Yes, this is at least what I understand by the documentation as well. https://docs.docker.com/engine/containers/start-containers-automatically/ |
For me, this error is happening because of power issues with the USB port to which I have my adapter connected. It would be nice to have a good solution for when something like this happens, to either retry connections to the adapter before crashing or to crash in such a way that the docker restart option can pick up on it. I tried |
On Unraid Another workaround could be to run a script on a cronjob on your server to restart the container twice a day. Afaik the USB only disconnects after a longer period of time (but I'm not sure). In any case, the script could be as simple as this: #!/bin/bash
echo "Restarting Zigbee2MQTT service at $(date)"
docker restart zigbee2mqtt |
Thanks for the info, docker on ubuntu doesn't work for me with |
What happened?
Dear All,
I am running Zigbee2MQTT in a docker with Sonoff zStack3x0 Coordinator revision 20210708 radio.
Every now and then I discover Zigbee2MQTT exiting operation without restart with following error:
below is my docker starting command which instructs explicitely to restart the container:
Regards,
What did you expect to happen?
If an error aqures, the container restarts....
How to reproduce it (minimal and precise)
No response
Zigbee2MQTT version
1.30.4 commit: b2dd21e
Adapter firmware version
20210708
Adapter
SONOFF Zigbee 3.0 USB Dongle Plus-P
Debug log
The text was updated successfully, but these errors were encountered: