Hallo zusammen,
ich versuche in die Zigbee Welt einzusteigen. Bevor ich meine bestehende Installation zerstöre durch Unwissen habe ich einen frischen Raspi 3B+ mit aktuellem Bookworm aufgesetzt. FHEM installiert mit
attr initialUsbCheck disable 1
define Zigbee2MQTT MQTT2_SERVER 1883 global
Mit etwas Anlaufschwierigkeiten habe ich Zigbee2MQTT gemäß dem Wiki (https://www.zigbee2mqtt.io/guide/installation/01_linux.html#installing) installiert.
In der /opt/zigbee2mqtt/data/configuration.yaml habe ich
mqtt:
base_topic: zigbee2mqtt
server: mqtt://localhost:1883
client_id: 'zigbee_pi'
Ich verwende einen
root@raspyfhem2025dev:~# ls -l /dev/serial/by-id/
total 0
lrwxrwxrwx 1 root root 13 Jan 8 22:39 usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_e2f00086488aef119a8fb8a3ef8776e9-if00-port0 -> ../../ttyUSB0
in einer anderen Testinstallation konnte ich im Frontend von Zigbee2MQTT eine Verbindung zu den Thermometern herstellen, ich glaube es war der Button Beitritt erlauben. Wenn ich diesen jetzt nutze kommt aber nicht der Countdown für die Verbindung. Ich bin auch der Meinung im Forum gelesen zu haben das ich die Geräte im Frontend anlernen muss.
die configuration.yml sieht momentan so aus:
version: 4
mqtt:
base_topic: zigbee2mqtt
server: mqtt://localhost:1883
client_id: 'zigbee_pi'
serial:
port: /dev/ttyUSB0
adapter: zstack
baudrate: 115200
rtscts: false
advanced:
log_level: info
channel: 11
network_key:
- 45
- 142
- 30
- 68
- 68
- 202
- 162
- 71
- 52
- 212
- 244
- 6
- 71
- 3
- 44
- 71
pan_id: 51531
ext_pan_id:
- 172
- 50
- 119
- 114
- 13
- 104
- 224
- 247
frontend:
enabled: true
port: 8080
homeassistant:
enabled: true
Ich weis wirklich nicht was ich beim ersten Installationversuch anders gemacht habe, da wurden die Geräte ja erkannt und das anlernen war möglich.
Gruß
Micha
Vorab:
1. Das FHEM-Forum ist eigentlich nicht die richtige Anlaufstelle für Fragen rund um Anlauf- und Installationsprobleme zu zigbee2mqtt.
2. Eventuell würde es helfen, wenn du in die logs schaust, die zigbee2mqtt schreibt.
Auf die Schnelle würde ich ein paar Dinge anders machen:
a) Verwende in der yaml die eindeutige Adresse "by-id" (OT für docker-User: reiche die Schnittstelle beim mappen mit der eindeutligen Adressierung durch).
Erklärung: Wenn du um 22:39 Uhr die Abfrage machst, danach dann z.B. einen nanoCUL einstöpselst und dann den Rechner nochmal startest, kann es sein, dass "ttyUSB0" um 22:40 Uhr nicht mehr stimmt...
(b) Weiterführend: Starte den Dienst nicht mit einem user, der sudo-Berechtigungen hat (und sorge dafür, dass der dialout und plugdev-Mitglied ist und natürlich auf das Installationsverzeichnis zugreifen kann))
c) bookworm ist doch nicht akutell...
Nachtrag:
d) Wenn du Homeassistant nicht im Einsatz hast, sollte die betreffende Option deaktiviert werden. Sonst: ignoreRegexp setzen.
Ich sehe zigbee als eigenes Thema. Entweder man bindet es per HUE-Modul ein oder per MQTT. In jedem Fall würde das auch ohne FHEM weiterlaufen.
Also kümmere Dich um ein funktionierendes Zigbee-Netz. Dann binde die Steuerung per FHEM ein, bei Dir wahrscheinlich per MQTT.
Somit gilt der erste Satz von Beta-User.
Vielen Dank Euch. Ich habe es ausgelagert und bin hoffentlich an der richtigen Stelle (https://github.com/Koenkk/zigbee2mqtt/discussions/30573). Ich kann jetzt das Frontend nutzen und Geräte anlernen, allerdings nur nach der Installation von mosquitto, wo ich hier im Forum ja gelesen habe das es eigentlich nicht notwendig ist. Als nächstes werde ich dann irgendwie die Brücke zu FHEM schlagen müssen, das mir die Werte jetzt auch in FHEM angezeigt werden. An das ein und ausschalten von Licht denke ich jetzt mal nicht gar nicht.
Gruß
Micha
Dein Ansatz mit deinem MQTT2_Server ersetzt den mosquitto.
Beide Varianten funktionieren.
Was Du brauchst damit die z2m Geräte in FHEM auftauchen ist eine Verbindung von FHEM zu dem MQTT Server (mosquitto). Dafür stehr das Modul MQTT2_CLIENT bereit.
Ich habe noch ein MQTT2_DEVICE angelegt vom Modell zigbee2mqtt_bridge um z2m selbst steuern zu konnen.
Grüße Sidey
Ich werde nochmal neu anfangen ohne mosquitto und mit MQTT2_Server.
Wenn ich Dich richtig verstehe sollte dann auch das Frontend von Zigbee2MQTT nutzbar sein.
Mein erster Testlauf mit Zigbee2MQTT und mosquitto auf einem frisch eingerichteten Trixie endete damit das nach erfolgreich angelegten vier Geräten plötzlich kein anlernen mehr möglich war und im Log nur zu finden ist z2m: WebSocket error: Invalid WebSocket frame: RSV1 must be clear.
Ich kann dir nur empfehlen die Docker Container jeweils zu verwenden.
Damit funktioniert es wunderbar.
Grüße Sidey
Zitat von: mfeske am 09 Januar 2026, 14:35:13Wenn ich Dich richtig verstehe sollte dann auch das Frontend von Zigbee2MQTT nutzbar sein.
Ja, unbedingt. Ohne ist es nervig, weil man dann alles über irgendwelche MQTT Kommandos konfigurieren muss.
Zitat von: mfeske am 09 Januar 2026, 14:35:13WebSocket error: Invalid WebSocket frame: RSV1 must be clear.
Das ist einfach ein frontend-Problem, weil das Frontend websockets benutzt um mit deinem Browser zu kommunizieren (und umgekehrt). Hat nichts damit zu tun wie du das installiert hast, solange du jetzt keinen reverse proxy benutzt, sondern direkt über den port (8080) auf das z2m frontend zugreifst.
Siehe: https://github.com/Koenkk/zigbee2mqtt/issues/23097
und (ähnlich): https://github.com/Koenkk/zigbee2mqtt/pull/18388
Vielleicht einfach mal einen anderen Browser probieren?
Das mit dem Wechsel des Browsers hatte leider nicht funktioniert.
Das es ja glücklicherweise ein Testsystem ist und Beta-User mich aus dem Schlaf gerissen hat mit bookworm, habe ich erneut begonnen und erstmal trixie installiert, dann fhem, dann Zigbee2MQTT (da gab es dann versionsprobleme mit node ich musste ein paar updates machen).
Jetzt habe ich ein funktionierendes Zigbee2MQTT Frontend mit gekoppelten Thermometern.
Eine frische FHEM Installation mit define Zigbee2MQTT MQTT2_SERVER 1883 global.
Offenbar habe ich nicht alles ganz falsch gemacht es tut sich was. Es sind jetzt zwei MQTT2_DEVICEs vorhanden:
mqttjs_3b412520 offline
zigbee_pi online
wobei ich eigentlich nur mit dem netteren gerechnet hatte.
Beide haben ziemlich lange Listings.
Wie komme ich den jetzt an Temperatur und Luftfeuchte der Sender ?
Gruß
Micha
Zitat von: mfeske am 09 Januar 2026, 16:31:23Beta-User mich aus dem Schlaf gerissen hat
;D immer wieder gerne...
Zitat von: mfeske am 09 Januar 2026, 16:31:23Es sind jetzt zwei MQTT2_DEVICEs vorhanden:
Das kommt daher, dass du die ClientId erst mal noch nicht vergeben hattest. Das erste kannst du löschen, für den Rest ginge es weiter wie im FHEM-Wiki beschrieben.
Wenn ich dich nochmal mit wecken darf: Verwende für zigbee2mqtt docker!
Hier mal mein "docker run" (auszuführen in /opt/zigbee2mqtt, damit da alle Daten landen):
docker run --name zigbee2mqtt --restart=unless-stopped --device=/dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_abcdef3c0fe7ec119854b3d05adebb74-if00-port0:/dev/ttyACM0 -p 8079:8080 -v $(pwd)/data:/app/data -v /run/udev:/run/udev:ro -e TZ=Europe/Amsterdam ghcr.io/koenkk/zigbee2mqtt:latestAnmerkungen dazu:
Das "by-id"-Device wird nach /dev/ttyACM0 gemappt, das ist der Standard in der default-yaml, soweit ich mich entsinne. Für einen anderen Stick (mit zstack-Chipset) kann ich dann einfach den run-Befehl anpassen, was z.B. in einem Rutsch nach einem update erfolgen kann (ich habe denselben nochmal mit einer anderen ID als backup, es muss dann aber die coordinator-Kennung für das zigbee-Netzwerk auch gemappt werden, da habe ich aber die passende Stelle grade nicht im Kopf).
Als Port würde ich die 8080 frei halten, weil "jeder" Dienst mit Web-Interface dazu neigt, sich diesen zu krallen... Daher erreicht man ihn mit diesem Mapping unter 8079 (wie FHEM auf 8083).
Warum docker? Diese Infrastruktur läuft hier zum einen sowieso wegen anderer Dienste, und - wichtiger - bei der ersten Installation "damals" (vor sehr langem...) hat mir z2m so viele "vulnerabilities" gemeldet, dass ich das damals nicht mehr weiter verfolgen wollte und lange deconz im Einsatz hatte. Daher jetzt also der "Sandkasten" docker drumrum...
Hallo Beta-User,
delete mqttjs_3b412520 ausgeführt, auch wenn ich dachte in der yaml vor dem FHEM Start client_id: 'zigbee_pi' gesetzt zu haben.
Port ist geändert auf 8079
Ich hoffe ich bekomme meine produktive Installation schadlos von bookworm auf trixie :-(
Der zweite Weckruf hört sich aber danach an das ich da wohl ein Zusatzstudium betreiben muß :-( Ich habe bisher einmal sowas wie einen Docker Container genutzt und das war auf meinem Synology NAS um ecoDMS zu installieren und das war ganz schön viel hin und her.
Wiki (https://wiki.fhem.de/wiki/Zigbee2mqtt) hatte ich gefunden und gelesen, aber ich glaube ich muss das mehrfach durcharbeiten bis ich es überhaupt ansatzweise verstehe. Ich glaube ich hatte mir das wirklich etwas einfacher vorgestellt und habe die Installation unterschätzt.
Bin auch davon ausgegangen das ich den USB Stick in der yaml korrekt eingebunden habe und mit attr initialUsbCheck disable 1 in FHEM alles erforderlich getan zu haben. Deshalb verstehe ich zum Beispiel nicht "Weiter sollte der CC2531 auch in FHEM und zigbee2mqtt by-id eingebunden werden".
"In der Regel sollte dieses automatisch erstellt werden" ist bei mir dann wohl nicht passiert oder ist das mein zigbee_pi ?
Ich hatte die Hoffnung nach dem ich FHEM neu installiert habe und Zigbee2MQTT, das nach erfolgreichem anlernen und Verbindung die Daten fast automatisch ausspuckt.
Gruß
Micha
der Eventmonitor spuckt ja schon "irgendwas" aus:
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi level: info
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi message: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/TS0201_03', payload '{"battery":82,"humidity":30.8,"linkquality":96,"temperature":21.7,"update":{"installed_version":268513281,"latest_version":268513281,"state":"idle"}}'
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi update_state: idle
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi battery: 82
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi temperature: 21.7
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi update_installed_version: 268513281
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi humidity: 30.8
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi linkquality: 96
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi update_latest_version: 268513281
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi level: info
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi message: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/TS0201_03', payload '{"battery":82,"humidity":33.6,"linkquality":99,"temperature":21.7,"update":{"installed_version":268513281,"latest_version":268513281,"state":"idle"}}'
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi update_state: idle
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi temperature: 21.7
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi update_installed_version: 268513281
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi battery: 82
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi humidity: 33.6
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi update_latest_version: 268513281
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi linkquality: 99
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi update_state: idle
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi temperature: 21.7
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi update_installed_version: 268513281
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi battery: 82
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi humidity: 33.6
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi update_latest_version: 268513281
2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi linkquality: 99
Zitat von: mfeske am 09 Januar 2026, 17:06:58Zusatzstudium
Na ja, erste Erfahrungen hast du ja schon...
Im Ernst: Das ist kein "muss", aber eben eine nachdrückliche Empfehlung, auch von anderer Seite.
Zitat von: mfeske am 09 Januar 2026, 17:06:58Deshalb verstehe ich zum Beispiel nicht "Weiter sollte der CC2531 auch in FHEM und zigbee2mqtt by-id eingebunden werden".
Für konstruktive Änderungsvorschläge bin ich offen. Gemeint ist: du kannst den Pfad in der yaml ändern und auch dort "by-id" angeben, ganz ohne den docker-Umweg.
Zitat von: mfeske am 09 Januar 2026, 17:06:58"In der Regel sollte dieses automatisch erstellt werden" ist bei mir dann wohl nicht passiert oder ist das mein zigbee_pi ?
Genau das ist das Device. Und da finden sich dann eben alle Geräte-Infos, ohne dass eine (m.E.) "brauchbare" Zuordnung stattfindet.
Deswegen "sortiert" das (vorschlagsweise) per attrTemplate konfigurierte "bridge"-Device (das den Dienst an sich repräsentieren soll) alle eingehenden Nachrichten fortan um, so dass in der Tat für jedes Stück Hardware dann jeweils eine MQTT2_DEVICE-Instanz angelegt werden sollte.
Was dann mit diesen Instanzen anzufangen ist, hängt von der Hardware ab...
PS: Dass alles, was zu einer Hardware gehört, dann auch in einer FHEM-Instanz landet, war für mich der wesentliche Grund, wieder von deconz weg zu gehen.
Zitat2026-01-09 17:09:07 MQTT2_DEVICE zigbee_pi message: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/TS0201_03',
Sach mal, hast Du in zigbee2mqtt die IDs der devices bearbeitet?
Das sollte man am besten gar nicht tun, und wenn doch, dann nur, wenn man wirklich weiß, WAS man da tut.
Aber auf keinen Fall als Anfänger in der Materie.
@Beta-User erste Erfahrungen ;-) Docker habe ich mir mal notiert, ob ich das hinbekomme oder noch mehr cos bei mir anstelle ist mal dahingestellt. Es war auch auf gar keinen Fall negative Kritik. Ich bin über jeden Wiki Artikel oder Forums Eintrag dankbar an dem man sich langhangeln kann, deshalb schätze ich das hier alles. Ich vermute nur es geht Dir genauso wie mir auf Arbeit. Ich dokumentiere da auch das ein oder andere was für mich sonnenklar ist und was ich ja täglich mache. Kommt trotzdem der ein oder andere Kollege weil er es nicht versteht, vermutlich weil für mich alles klar war.
Das mehr man auch an der ein oder anderen Wiki Anleitung wer es schon 100 Jahre macht schreibt halt anders.
@betateilchen, ja hatte ich gemacht über zigbee2mqtt um die Geräte unterscheiden zu können dachte auch nicht das es nicht gemacht werden sollte.
Ich habe das mit den Templates jetzt auch geschnallt und schon wurden neues Devices angelegt, nach dem ich dann diesen auch die passenden Templates verpasst habe erfolgt auch eine vernünftige Anzeige. Jetzt werde ich noch probieren ob ich es vielleicht optisch schöner hinbekomme farbiger Kreis mit Temperatur und Feuchte aber dazu habe ich noch nichts gefunden, vermutlich wäre das ja das richtige https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#top-page.
Etwas sorgen macht mir noch die node Version wenn ich das jetzt auf mein produktiv system übertragen, ich glaube das brauchte ich ja auch für die Alexa Anbindung und die mag ich mir eher nicht kaputt machen.
Gruß
Micha
Zitat von: mfeske am 09 Januar 2026, 19:15:23Docker habe ich mir mal notiert, ob ich das hinbekomme
Keine Sorge, das geht alles grundsätzlich auch ohne Docker.
Lass Dir nix anderes einreden.
Zitat von: mfeske am 09 Januar 2026, 19:15:23@betateilchen, ja hatte ich gemacht über zigbee2mqtt um die Geräte unterscheiden zu können
Diesen "Fehler" machen viele Anwender am Anfang - mich eingeschlossen.
Wenn Du die Geräte in der z2m Oberfläche unterscheiden möchtest, kannst Du dort das Feld "Beschreibung" verwenden, wie im Anhang dargestellt.
Die ID der Geräte selbst solltest Du besser immer so lassen, wie sie ist.
In FHEM kannst Du für die Geräte einen passenden Namen oder ggf. einen alias verwenden.
Zitat von: Beta-User am 09 Januar 2026, 16:51:39Wenn ich dich nochmal mit wecken darf: Verwende für zigbee2mqtt docker!
Hier mal mein "docker run"
Am besten man nutzt nicht docker run, sondern docker compose und ein entsprechendes compose file.
Mit docker run sind sämtliche Parameter mit denen man den container startet nur extrem schlecht reproduzierbar (allenfalls über die Terminal-history). Das ist meiner Meinung nach alles eher ungeeignet für Container, die ständig laufen sollen und von deren (Docker-)Konfiguration man auch ein vernünftiges Backup haben will.
Zitat von: betateilchen am 09 Januar 2026, 17:22:30Das sollte man am besten gar nicht tun, und wenn doch, dann nur, wenn man wirklich weiß, WAS man da tut.
Dem möchte ich widersprechen.
Die einzige Situation, in der das problematisch wird, ist, wenn man ein Gerät löscht und es dann neu einbindet: Bevor man es wieder umbenannt hat, wird erstmal nichts von FHEM empfangen, weil das Gerät bis dahin noch auf dem falschen Topic sendet.
Aber sonst habe ich nach inzwischen knapp 3,5 Jahren Z2M-Nutzung mit umbenannten Geräten seit Tag 1 noch kein Szenario erlebt, in dem es ein Problem war, dass alle meine Geräte sinnvolle Namen haben. Wäre es so gefährlich wie hier suggeriert, gäbe es die Option doch auch gar nicht so prominent im Z2M UI.
Ich sehe darin nahezu nur Vorteile, weil es alles
sehr viel übersichtlicher macht.
Zitat von: passibe am 09 Januar 2026, 21:12:30Dem möchte ich widersprechen.
Alles andere hätte mich auch sehr gewundert... 🫤
Wie gesagt: wenn man weiß, was man tut und welche Auswirkungen das hat, kann man das machen.
Aber es gibt durchaus noch mehr Problemfälle als den einen von Dir beschriebenen.
Die da wären?
z.B. Leerzeichen
Na gut. Das lernt man dann einmal und dann passiert das nicht wieder. Bei FHEM kann ich ja auch keine Leerzeichen in NAME verwenden. (Vor allem merkt man auch sofort, dass es nicht funktioniert.)
Wenn das das größte Problem ist, finde ich diese Dramatik
Zitat von: betateilchen am 09 Januar 2026, 17:22:30Das sollte man am besten gar nicht tun, und wenn doch, dann nur, wenn man wirklich weiß, WAS man da tut.
eher nicht angezeigt.