Zigbbee2mqtt funktioniert nicht

Könntet ihr mal bitte ausprobieren, ob z2m bei euch startet, wenn ihr in der /opt/zigbee2mqtt/data/configuration.yaml unter serial bei port: ‘’ (zwei einzelne Anführungszeichen, sodass der port quasi leer ist) und bei adapter: auto eintragt?

Dann neustarten mit sudo systemctl restart zigbee2mqtt.service und prüfen mit journalctl -f -u zigbee2mqtt.service. Wenn es nicht funktioniert, versucht z2m alle 10 Sekunden neuzustarten, das würdet ihr im journal verfolgen können. Wenn es funktioniert solltet ihr normal aufs Interface von z2m unter IP:8099 zugreifen können.
Im Zweifel könntet ihr auch erstmal Node-RED stoppen um zu sehen ob da irgendwas blockiert.
Bei mir hat es aber mit der oben genannten älteren Firmware des Sticks funktioniert.

Leider hat das bei mir nicht funktioniert. Es schlägt mit der Meldung Error: No path provided and failed to auto detect path fehl.

Ich habe mal testweise Z2M auf die neueste Version upgedated. Ich hatte die Hoffnung, dass die Auto-Discovery dort besser funktioniert. Der Adapter wird da allerdings als zstack erkannt und funktioniert folglich nicht. Der ZBDongle-E nutzt ember. Der ZBDongle-P (die alte Version) nutzt zstack.

Also laut hier Silabs Firmware Flasher | Web based flasher for ZB-GW04 and ZBDongle-E. MultiPAN RCP firmware enables these devices to be used with Silabs Multiprotocol Addon in Home Assistant. Allow Zigbee and Thread to co-exist on the same dongle. Get ahead of the tech an experiment with Matter! gibt es selbst bei den E-Dongeln 2 Versionen, so wie ich das verstehe unterscheiden die sich aber nur in der Serial Schnittstelle, nicht im Zigbee Controller.

@Vincent
Vielen Dank erstmal für die Antwort, leider klappt es nicht, auch nicht mit deaktiviertem NodeRed. Auch nicht mit ember oder auto.

Blockquote
zigbee2mqtt.service: Main process exited, code=exited, status=1/FAILURE
Feb 14 09:28:18 pekaway systemd[1]: zigbee2mqtt.service: Failed with result ‘exit-code’.
Feb 14 09:28:18 pekaway systemd[1]: zigbee2mqtt.service: Consumed 8.486s CPU time.
Feb 14 09:28:28 pekaway systemd[1]: zigbee2mqtt.service: Scheduled restart job, restart counter is at 6224.
Feb 14 09:28:28 pekaway systemd[1]: Stopped zigbee2mqtt.service - zigbee2mqtt.
Feb 14 09:28:28 pekaway systemd[1]: zigbee2mqtt.service: Consumed 8.486s CPU time.
Feb 14 09:28:28 pekaway systemd[1]: Started zigbee2mqtt.service - zigbee2mqtt.

Hier einmal die .yaml

homeassistant: false
permit_join: true
mqtt:
base_topic: zigbee2mqtt
server: mqtt://localhost:1883
serial:
port: ‘’
adapter: ember
baudrate: 115200
advanced:
network_key:

  • 46
  • 78
  • 191
  • 52
  • 181
  • 104
  • 220
  • 222
  • 1
  • 90
  • 110
  • 116
  • 203
  • 102
  • 157
  • 50
    log_level: info
    log_output:
    -console
    frontend:
    port: 8099
    experimental:
    new_api: true
    homeassistant_legacy_entity_attributes: false
    legacy_api: false
    legacy_availability_payload: false
    device_options:
    legacy: false

@Tristan @Vincent Ich glaube tatsächlich, dass das Problem der automatischen Erkennung in der unterschiedlichen Seriellen Schnittstelle liegt.

tl;dr - Ich habe einen Fehler bei zigbee2mqtt gemeldet. Vielleicht kann da jemand zeitnah helfen: SONOFF ZBDongle-E automatically detected as zstack · Issue #26909 · Koenkk/zigbee2mqtt · GitHub

Das Problem mit dem blockierten Port, wenn NodeRed läuft, bleibt aber auch bei mir weiterhin.


Langversion

Jetzt wirds etwas technisch: Ich habe mich mal durch den z2m Quellcode gewühlt, wie dort die automatische Erkennung funktioniert und diese läuft über die vendor ID, product ID, manufacturer-Namen und dem Pfad unter dem das Gerät unter /dev/serial/by-id zu finden ist. Hier wird bei den Sonoff Sticks zwischen dem ZBDongle-P und ZBDongle-E unterschieden und laut dem Code handelt es sich bei der Vendor- und Product-ID meines Sticks um einen ZBDongle-P, obwohl es ein E ist. Diese IDs beziehen sich allerdings auf den USB zu Serial - Chip und nicht auf den Zigbee Chip. Dass das Vincents Stick problemlos funktioniert, könnte daran liegen, dass es noch die Version mit dem anderen Chip ist und dieser korrekt als E erkannt wird. Das könnte auch erklären, warum Vincents Stick als ACM0 erkannt wird und unserer als USB0.

Das sieht doch schonmal sehr verdächtig aus.
Jedoch verstehe ich die Lösung im GitHub nicht wirklich.

In dem frischen Image das du dort meinst, sprichst du von einem frischen Vanpi oder hast du Zigbeetomqtt solo installiert ?

Welchen Stick genau das du?

Bei mir hat es mit Ember und fester Port ID unter Vanpi nicht funktioniert. Mit zwei gleichen Dongle E.
Aus meinen alten Logs oben sehe ich, das diese als Zstack erkannt werden.
Ich Versuche nachher nochmal etwas über meinen herauszufinden.
Jedes mal ein sehr müseliges raussuchen der Linux befehle, da mir da absolut die Routine fehlt :smiley: die gängigsten Dos Befehle sind immer noch eingebrannt.

Unter Windows wird er als Silikon labs CP210X erkannt. Damit wäre das ja genau der Kandidat der den seriellwandler des P Stick mit dem Ember Zigbee Controller des E Stick hat

Ich habe die neuste Version von Zigbee2MQTT frisch auf dem VanPi Image installiert. Es wurde auch bereits ein Fix in Z2M geliefert, dafür müsste man aber erst auf die nächste offizielle Version warten. Ich konnte den Fix aber mit meinem Stick verifizieren. Damit läuft die automatische Konfiguration. Allerdings sagen sie auch

The serial metadata is already slim to begin with, but between errors in config from Sonoff (some E have the metadata of the P…), and conflicts between versions, it’s almost impossible to detect all variants properly…

Ich habe auch einen ZBDongle-E mit CP210X.

Ich verstehe nur nicht was jetzt die Lösung ist?
Mit einer manuellen konfiguration auf ember läuft es ja ebenfalls nicht.

Ich habe jetzt mal ein neues Raspi Stock Os aufgesetzt und die Zigbe2mqtt Anleitung befolgt. (Inkl Mosquitto)

Hier bekomme ich es auch nicht ans laufen, jedoch schmiert es schon ab bevor ich den Dienst gestartet bekomme.

pi@raspberrypi:/opt/zigbee2mqtt $ pnpm start

zigbee2mqtt@2.1.3 start /opt/zigbee2mqtt
node index.js

Starting Zigbee2MQTT without watchdog.

/opt/zigbee2mqtt/node_modules/.pnpm/js-yaml@4.1.0/node_mo dules/js-yaml/lib/loader.js:183
return new YAMLException(message, mark);
^
YAMLException: bad indentation of a mapping entry (30:6)

27 | # # Location of the adapter
28 | # # USB adapters - use format "p …
29 | # # Ethernet adapters - use form …
30 | port: /dev/serial/by-id usb-Ite …
-----------^
31 | # # Adapter type, allowed values …
32 | adapter: ember
at generateError (/opt/zigbee2mqtt/node_modules/.pnpm /js-yaml@4.1.0/node_modules/js-yaml/lib/loader.js:183:10)
at throwError (/opt/zigbee2mqtt/node_modules/.pnpm/js -yaml@4.1.0/node_modules/js-yaml/lib/loader.js:187:9)
at readBlockMapping (/opt/zigbee2mqtt/node_modules/.p npm/js-yaml@4.1.0/node_modules/js-yaml/lib/loader.js:1182 :7)
at composeNode (/opt/zigbee2mqtt/node_modules/.pnpm/j s-yaml@4.1.0/node_modules/js-yaml/lib/loader.js:1441:12)
at readBlockMapping (/opt/zigbee2mqtt/node_modules/.p npm/js-yaml@4.1.0/node_modules/js-yaml/lib/loader.js:1164 :11)
at composeNode (/opt/zigbee2mqtt/node_modules/.pnpm/j s-yaml@4.1.0/node_modules/js-yaml/lib/loader.js:1441:12)
at readDocument (/opt/zigbee2mqtt/node_modules/.pnpm/ js-yaml@4.1.0/node_modules/js-yaml/lib/loader.js:1625:3)
at loadDocuments (/opt/zigbee2mqtt/node_modules/.pnpm /js-yaml@4.1.0/node_modules/js-yaml/lib/loader.js:1688:5)
at Object.load (/opt/zigbee2mqtt/node_modules/.pnpm/j s-yaml@4.1.0/node_modules/js-yaml/lib/loader.js:1714:19)
at Object.read (/opt/zigbee2mqtt/lib/util/yaml.ts:23: 29)
ELIFECYCLE Command failed with exit code 1.

Ich gehe jetzt mal davon aus, dass ich hier etwas bei der installation vergeigt habe, jedoch konnte ich den Fehler nicht finden.

Habe jetzt nochmal ein neues Vanpi 2.0.5 Aufgespielt und zigbee geupdatet über ./update.sh
und die serial id die sowie Adapter als ‘ember’ eingetragen.

Hier passiert jedoch nichts neues.
Was genau meinst du mit Zigbee2mqtt frisch installiert? es ist ja im Image bereits enthalten?
/opt/zigbe2mqtt komplett gelöscht und dann nach dieser Anleitung komplett neu aufgespielt? Linux | Zigbee2MQTT

EDIT:
Das war tatsächlich die Lösung!

Scheinbar habe ich unterm Stock OS irgendetwas falsch gemacht.
Jedoch hat es geholfen unter VanPI den Ordner /opt/zigbee2mqtt zu Löschen und es nach der obigen Anleitung neu zu installieren.
Jetzt komme ich zum ersten mal ins Frontend und kann mich morgen um das Node-Red Problem kümmern.

Entweder wurde das Problem was @kilian entdeckt hat bereits ins GIT aufgenommen und hat sich so bei der Installation übernommen, oder in der Vanpi Installation vom Zigbe2mqtt ist noch irgendwas anderes fehlerhaft.

@Tristan freut mich, dass es nun bei dir funktioniert! Der Fehler in dem Log deutet übrigens darauf hin, dass etwas mit der Einrückung in der configuration.yaml bei port nicht gestimmt hat. Yaml ist da sehr zickig und erwartet genau die richtige Anzahl an Leerzeichen vor einem Eintrag.

@Vincent Version 2.2.0 von Zigbee2MQTT wurde heute veröffentlicht, welche bereits den von mir genannten Fehler behebt. Diese Version beinhaltet außerdem noch eine coole Neuerung, die für das VanPi Image interessant sein könnte: Einen Onboarding Screen. Wenn keine configuration.yaml existiert, öffnet sich im Browser beim ersten Start eine Konfigurationsoberfläche und diese Einstellungen werden dann in die configuration.yaml übernommen. Das ist besonders für diejenigen interessant, die sich nicht so gut in der Shell auskennen.

Ahhh danke für den Hinweis.
Ich bin in Linux nicht so fit. Hab das Image inzwischen wieder überschrieben.

Dann hatte ich wohl das Glück bereits genau die Version 2.2.0 zu laden, da ich genau den Konfigurationsscreen bekam und mich schon wunderte :smiley:
Man kann dort den Stick direkt auswählen und ich vermute, er wird dann auch über einen USB Hub funktionieren.

Das sieht doch vielversprechend aus.

Man könnte im NR Dashboard eine Funktion einbauen, die das Onboarding startet (service stoppen falls aktiv, configuration.yaml löschen und pnpm start im z2m Ordner ausführen). Dann den Port auslesen und den Link dorthin dynamisch gestalten. Das würde auch gleichzeitig eine fehlerhafte Konfiguration resetten, der Service startet nur bei einer “richtigen” Konfiguration.

EDIT: Nutzer darauf hinweisen dass das Frontend beim Onboarding mit aktiviert werden muss. Evtl. auch einfach den Standardport auf 8080 lassen. Oder direkt auf 8099 ändern, weil 8080 ja sehr gängig ist

Für den User würde es das vereinfachen, man kann dann ja alles über das Onboarding machen.
Einen USB-Hub wollte ich sowieso mit einbauen, damit auch alle anderen Geräte darüber funktionieren.

1 Like