After update 1.35.2 to 1.35.3 ZigBee2MQTT Started and next 30 second Stopped #566
Comments
|
remove and insert the USB coordinator, it helped me |
I tried it, completely disconnected the power, turned it on, the error did not go away. How to go back to 1.35.2? |
|
+1 The same here . |
|
I have the same problem in version 135.2-1 and also in 135.3-1 |
|
I tried to solve the problem by switching back to version 1.35.2-1 (backup of Home Assistant), but without success. |
|
Only 135.1-1 works for me, all subsequent versions have the problem. The 135.1-1 runs without any problems. |
|
Same problem here with |
|
@asan84 can you provide me your z2m configuration.yaml? |
Hello Koenkk, here is my configuration.yaml. X = Secret :-) homeassistant: true |
|
I have two Sonoff Dongles:
Zigbee2MQTT-Version |
|
|
I think it's because of the |
Hi Koenkk, thanks for the feedback. Unfortunately no change in behavior. The adapter restarts every 3-4 minutes for me. I am back to version 1.35.1, no problems there, the adapter runs stable. |
|
the same issue Current version: 1.35.3-1 |
I didn't turn off the I don't understand what the problem is with the new version. |
|
@asan84 can you SSH into your system, execute the following and see if the issue is fixed? Make sure to not restart the addon via the HA interface, these changes will get lost. |
It did not work, now the process is rebooting again. The last time it gave an error and stopped: The process started stably after 5 minutes, after several falls. But, process stopped again: [22:41:52] INFO: Preparing to start... Reboot and Stopped again: Zigbee2MQTT:debug 2024-02-18 23:08:42: Received MQTT message on 'homeassistant/update/0x54ef44100092676b/update/config' with data '{"availability":[{"topic":"zigbee2mqtt/bridge/state","value_template":"{{ value_json.state }}"},{"topic":"zigbee2mqtt/0x54ef44100092676b/availability","value_template":"{{ value_json.state }}"}],"availability_mode":"all","command_topic":"zigbee2mqtt/bridge/request/device/ota_update/update","device":{"identifiers":["zigbee2mqtt_0x54ef44100092676b"],"manufacturer":"Aqara","model":"TVOC air quality monitor (VOCKQJK11LM)","name":"0x54ef44100092676b","sw_version":"2020\u0000www.","via_device":"zigbee2mqtt_bridge_0x0c4314fffe57545e"},"device_class":"firmware","entity_category":"config","entity_picture":"https://github.com/Koenkk/zigbee2mqtt/raw/master/images/logo.png","json_attributes_template":"{\"in_progress\": {{ iif(value_json['update']['state'] == 'updating', 'true', 'false') }} }","json_attributes_topic":"zigbee2mqtt/0x54ef44100092676b","latest_version_template":"{{ value_json['update']['latest_version'] }}","latest_version_topic":"zigbee2mqtt/0x54ef44100092676b","name":null,"object_id":"0x54ef44100092676b","origin":{"name":"Zigbee2MQTT","sw":"1.35.3","url":"https://www.zigbee2mqtt.io"},"payload_install":"{\"id\": "0x54ef44100092676b"}","state_topic":"zigbee2mqtt/0x54ef44100092676b","unique_id":"0x54ef44100092676b_update_zigbee2mqtt","value_template":"{{ value_json['update']['installed_version'] }}"}' /app/node_modules/winston-transport/node_modules/readable-stream/lib/_stream_writable.js:264 |
|
But it looks like the |
No. |
|
|
|
Maybe. I can’t repeat it again because the process keeps stopping. [23:27:49] INFO: Preparing to start... |
|
@asan84 this is probably caused by an issue with the new adapter implementation, soon this will be improved, keep an eye on Koenkk/zigbee-herdsman#918 |
|
For the ezsp users, make sure you use the proper configuration for @asan84 from your first post, you are using a very old firmware version. That definitely could cause issues (note that you will have to re-pair everything after update; I wouldn't hope for anything else). @Koenkk for the winston stuff, I found several open issues that seem to come and go over the years (in the repo and in packages using winston), but since I don't know winston... 😉 |
|
Hello, I still have the same problem. I use the Skyconnect but if I set the rtscts parameter to "true", even version 135.1-1 no longer starts for me. With my current settings, version 135.1-1 runs without any problems. This error message appears when I set rtscts to true: |
|
@Rookman2022 Can you try again with herdsman debug ON and provide the logs? Also what firmware supplier are you using (Nabu Casa, darkxst, etc)? |
|
I have tested again Version 135.1-1 also runs with "rtscts: true" after the update to 135.3-1 the error appears, see log. I have installed the firmware from Nabu Casa on my SkyConnect V7.3.2.0 build 212 |
|
That would seem to indicate your SkyConnect does not like @kirovilya Do you have a SkyConnect to run some tests on this (I don't)? I'm wondering if |
|
I don't have a skyconnect. I checked on the flashed sticks of ZB-GW04. |
Under 135.1-1 it works with rtscts true and false under 135.2-1 and 135.3-1 neither. |
|
This is a strange problem you are having. With 1.35.2, that somewhat could make sense, if your adapter isn't supporting But from 1.35.2 to 1.35.3, there were no change to anything serial-related, and no change at all in ezsp... I would expect the behavior to be identical to 1.35.2 here... |
|
Hello, the dev version runs in version 135.3 with rtscts: true without any problems so far LOG: info 2024-02-22 15:17:14: Logging to console and directory: '/config/zigbee2mqtt/log/2024-02-22.15-17-14' filename: log.txt |
|
Looks like kirovilya's fix is working then. Good to know, thank you for the feedback! |
|
ZB-WG04 forks fine for all day with no restart, now i switch Sonoff Dongle V2 (EFR) from ZHA to z2m, we will see tomorrow. |
|
I am seeing similar symptoms after updating both the HA core to 2024.2.3 and Zigbee2mqtt to 1.35.3-1. Using Sonoff ZB Pro (ESP32 based) with latest Tasmota. I am using Supervised (supervisor-2024.02.0). I have lost all Z2m connectivity due to Zigbee2mqtt stopping within 30 seconds from starting it. I see no errors on logs, and Tasmota console tells me "TCP: Got connection from 192.168.1.x", so at least it connects, but then something suddenly stops. If the fix by kirovilya can be expected to cure this, please either advice how to implement it to the current system (mind you, cannot keep the zigbee2mqtt container running, seems to stop itself) or publish a fixed version for the larger public to use. |
|
This is the log (referring above): [11:30:40] INFO: Preparing to start... |
|
I have just migrated from supervised to the latest HA OS (to not get caught with unsupported notice), using the backup from this morning. Unfortunately it did not solve the problem. I suspect that this has something to do with the interplay between core 2024.2.3 and z2m 1.35.3-1, as it did not manifest until I had to reboot the Raspi 4. |
|
A bit more data in the log now: Zigbee2MQTT:error 2024-02-25 18:18:05: Error while starting zigbee-herdsman |
@myllo If your adapter is EZSP based, then this is a problem, your logs show it is trying to use zStack. serial:
adapter: ezsphttps://www.zigbee2mqtt.io/guide/configuration/adapter-settings.html PS: Regarding kirovilya's fix, it will go live with next Z2M release (every 1st of the month), so it isn't far. But it is only for |
|
OK. So I have bumped into something else. Please take note. My configuration for that part is
During the day, I have rolled back to Zigbee2Mqtt version 1.34.0-1. That works with my current settings now. To me, a layman, it seems likely that the initial connection time is longer than allowed by the version 1.35.3, and version 1.34.0-1 either has more leeway with timeouts or the combination of z2m 1.34.0-1 and core 2023.11.3 ( that was my latest backup still available before the Jan 1, 2024, when z2m 1.35 first got rolled out.) together run slower and my adapter gets itself sorted out in time. |
|
I would also recommend everyone chime in on home-assistant/core#109030 Right now, that MR seems feature complete, the original author just put it back to draft. But I think with more input from others, he might actually push it forward again. |
|
I have also had issues with starting Z2M in HA since about December and I concluded it had something to do with the significant amount of traffic at the start simply as I don't have a problem once it is started. I am using the Sonoff-E and found that reducing the concurrency setting from the default ("null") to 1 or 2 seems to slow the traffic down enough for it to start. I had thought it was the Zigbee traffic but having read about the large amount of MQTT traffic on startup it could well be that. |
|
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 |
Description of the issue
After update 1.35.2 to 1.35.3 ZigBee2MQTT Started and next 15-30 second Stopped :(((
In Log:
/app/node_modules/winston-transport/node_modules/readable-stream/lib/_stream_writable.js:264
var er = new ERR_STREAM_WRITE_AFTER_END();
^
Error: write after end
at writeAfterEnd (/app/node_modules/winston-transport/node_modules/readable-stream/lib/_stream_writable.js:264:12)
at File.Writable.write (/app/node_modules/winston-transport/node_modules/readable-stream/lib/_stream_writable.js:300:21)
at DerivedLogger.ondata (/app/node_modules/winston/node_modules/readable-stream/lib/_stream_readable.js:629:20)
at DerivedLogger.emit (node:events:517:28)
at DerivedLogger.Readable.read (/app/node_modules/winston/node_modules/readable-stream/lib/_stream_readable.js:451:26)
at flow (/app/node_modules/winston/node_modules/readable-stream/lib/_stream_readable.js:858:34)
at File.pipeOnDrainFunctionResult (/app/node_modules/winston/node_modules/readable-stream/lib/_stream_readable.js:690:7)
at File.emit (node:events:517:28)
at onwriteDrain (/app/node_modules/winston-transport/node_modules/readable-stream/lib/_stream_writable.js:453:12)
at afterWrite (/app/node_modules/winston-transport/node_modules/readable-stream/lib/_stream_writable.js:441:18)
How to downgrade or fix a this error?
Addon version
1.35.3
Platform
Home Assistant 2024.1.6
Supervisor 2024.01.1
Debian 12
OS Agent 1.6.0
Docker 25.0.3
Coordinator firmware version: 6.6.5.0 build 204, type: EZSP v7
Logs of the issue (if applicable)
No response
The text was updated successfully, but these errors were encountered: