Zigbee-Außensensor am Raspberry Pi

FatManStanding

Lieutenant
Registriert
Aug. 2021
Beiträge
696
Hi,

ich habe zu Hause einen pi mit display der u.a. als Wetterstation dient. Als innensensoren nutze ich esp32 die die Daten per WLAN übertragen. Da ich kein Bastler bin wollte ich für den außensensor keinen ESP mehr nutzen, v.a. weil ich keine regengeschützte stelle habe der brauchbare Werte misst. Es gibt dich fertige die über zigbee senden. Spielt es da eine rolle von wem Empfänger und Sender sind oder ist jedes zigbee-gerät mit jedem anderen kompatibel? Es gibt ja USB dongles für zigbee.
 
Ich habe einen Conbee III USB-Stick an meinem RaspberryPi auf dem HomeAssistant läuft. Funktioniert sehr zuverlässig und bisher konnte ich alle meine Zigbee Geräte auch damit verbinden
 
  • Gefällt mir
Reaktionen: Engaged und SonyXP
Bei Zigbee gibt es Endgerät, Koordinator und Router.
So ein Zigbee-Stick wäre der Koordinator und ein Sensor ein Endgerät. Router sollte nahezu jedes Zigbee-Gerät mit fester Stromversorgung sein (z.B. Zigbee-Steckdosen).

E. als Außensensoren nutze ich irgendwelche Aqara-Dinger ohne Display. Sind zwar nicht für draußen gedacht, aber wenn sie einigermaßen wettergeschützt platziert sind, geht das recht gut.
 
Zuletzt bearbeitet:
Schließe mich @Toms an - Homeassistant und selbe Konfiguration bei mir (Conbee III als Koordinator am Pi, per USB-Verlängerung), die Zigbee Router (in meinem Fall Steckdosen) und Endgeräte (Sensoren) sind wahlweise von Nous und Sonoff, also verschiedenen Herstellern.

Und so solls auch sein - sofern das Zigbee-Protokoll unterstützt wird, hast Du da in der Regel freie Auswahl.
 
Zuletzt bearbeitet:
Bei Modellen von tuya und aqara steht dau,Fass die zwingend ein hub/Gateway benötigen. Ich kenne das von einem fingerbot der ohne Gateway nicht lief. Glaube der ist auch von tuya.
 
Router sind aktive Komponenten, wie bspw. Steckdosen, die das Zigbee-Meshnetzwerk erweitern. Im Gegensatz dazu gibt es passive Komponenten (Endgeräte), wie Schalter, Sensoren usw., die nur batteriebetrieben sind (und wegen fehlender Netzspannungs-Versorgung nicht als Router agieren).

Wenn ein Endgerät, z.B. ein Schalter, dann betätigt wird, sucht er sich den besten "Pfad" im Zigbee-Netzwerk, um sein Signal abzusetzen bzw. mit dem Koordinator zu kommunizieren. So kann er sein Signal entweder direkt zum Koordinator schicken, oder den "Umweg" über Router (wie Zigbee-Steckdosen) gehen, wenn die Signal-Qualität (man nennt das LQI) bzw. der Pfad über diese besser sind.

Router (wie Steckdosen) sind also "optional", sofern das Grundsignal zwischen Koordinator und Endgerät ausreichend stark ist. Es hängt von der räumlichen und baulichen Situation im Raum/Haus und der Entfernung zwischen den Zigbee-Geräten ab.

Du kannst jederzeit einfach Zigbee-Steckdosen dazu kaufen und einbinden, um die Reichweite des Meshnetzwerkes zu erhöhen und Signalqualität-/laufzeit zu verbessen. Alternativ natürlich auch weitere Koordinatoren.

Der hier schon mehrfach empfohlene Conbee III funktioniert sehr zuverlässig mit Zigbee-Geräten aller gängigen Hersteller. Das wäre dann Dein Koordinator, Hub, Gateway - der zentrale "Knoten". Falls Du keinen USB-Koordinator nutzen möchtest oder kannst, gibt es auch noch PoE-fähige, die direkt via LAN bzw. RJ45 ins Netz gespeist und mit Spannung versorgt werden. Alternativ kann die Spannungsversorgung auch über USB(C) erfolgen.

Wichtig bei USB-Koordinatoren, wie dem Conbee III (gilt auch für alle anderen) - idealerweise sind diese nicht direkt in den steuernden Rechner/Client einzustecken, sondern per USB-Verlängerung, um etwas Abstand zum Gerät zu haben. Das wird auch so vom Hersteller empfohlen, da die Sticks recht anfällig für Crosstalk (Strahlung von angrenzenden USB-Ports/in den Rechner führende Kabel) sind. Auch sollte nicht unbedingt der Heimrouter direkt daneben stehen, sofern Wifi über 2.4GHz genutzt wird, dieselbe Frequenz nutzt auch Zigbee.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: h00bi und Pjack
Ich habe mir für einen kleinen Preis den ConBee II (nicht III) gekauft und 2 Sonof-Sensoren. Ich habe zunächst mal einen Test unter Ubuntu 24.04 durchgeführt. Dazu die deCONZ-App installiert. Die ganze Sache war komisch. Ich bekomme die Anzeige wie hier https://phoscon.de/en/conbee2/install#ubuntu angezeigt (der Dongle wurde also erkannt). Dort steht dann:

Now the first Zigbee devices can be paired via the Phoscon App.Further information can be found in the PhosconApp documentation.

Unter "App" verstehe ich dann das Webinterface das man mit localhost:80 erreicht. Dort kann ich auf "Sensor verbinden" klicken, die Sensoren werden aber nicht erkannt. Gehe ich zurück deCONZ sehe ich plötzlich 2 neue Geräte - ich vermute das sind die Sensoren.

Werte werden mir aber keine angezeigt. Ist deCONZ nur für das Paring/das Management zuständig? Wie kann ich jetzt sehen ob Werte ausgelesen werden?
 
Nicht Phoscon mit deconz verwechseln.
Deconz ist das "Backend" und Phoscon das Frontend bzw. die App.

Phoscon nimmst du für das Pairing.
Für Sensoren musst du in das entsprechende Untermenü und dann "Neuen Sensor verbinden".

1771323007722.png


Dann am Sonoff die Pairing Sequenz einleiten.

Um zu sehen, ob Werte erfasst werden und wann zum letzten Mal, einfach einen der Sensoren anklicken.

1771323134371.png
 
Und genau das geht nicht. deconz habe ich jetzt aus, die deconz-systemd-Unit muss aber gestartet sein, denn sonst geht das Webinterface nicht. Hier im Webinterface bin ich wie von dir gezeigt auf "Neuen Sensor verbinden" gegangen, da wurde aber nichts erkannt. Erst dachte es ich es liegt an der parallel laufenden Deconz-App. Geht aber auch dann nicht, wenn die geschlossen ist.

Ich hatte auch Probleme beim Login im Webinterface. Da wird mir der USB-Stick angezeigt mit dem zuletzt angelegten Gateway-Namen und "localhost". Klicke ich darauf kommt aber keine Passwortabfrage (wie man es erwarten würde wenn ein User/Konto - oder wie man das auch nennt - angelegt wurde), sondern ich muss den Gateway-Namen erneut eingeben inkl. 2 Passwörter. Ich lege also einen neuen User an, jedesmal wenn ich das Webinterface starte. Irgendwie ist es mir vorhin gelungen mich einzuloggen - jetzt geht das irgendwie nicht mehr.
 
Deconz muss immer im Hintergrund laufen. Das ist wie gesagt das "Backend" inkl. Datenbank für die Geräteverwaltung und Treiber für den Conbee.

Hast du das ganze per Docker aufgesetzt? Persistentes Volume gemountet?
Hast du mal versucht dich per VNC mit Deconz zu verbinden?
Welchen Sonoff Sensor hast du denn gekauft und versuchst du zu verbinden? Lange den Reset Knopf gedrückt, bis die LED beginnt zu blinken?

Was noch sein kann, dass die von dir gekauften Sensoren nicht unterstützt werden. Dann sieht man im Deconz nur eine Speicheradresse "0xafb2a" oder so ähnlich.
Dann hilft u.U. ein Update.
Ist hier die Deconz Kompatibilität gelistet? https://zigbee.blakadder.com/

Falls nicht, einfach im Github ein Device Request aufmachen und innerhalb von 24h hast du ein DDF, was du einfach in den Devices Ordner wirfst und dann funktioniert das Gerät. Die sind da ziemlich auf Zack.
Aktuell sind in Sachsen aber Ferien. Vielleicht dauerts daher bis nächste Woche :P
 
Ja, deconz läuft im Hintergrund, das Webinterface zeigt sonst überghaupt nichts an. Diese Loginprobleme lagen scheinbar am Aufruf per localhost. Nutze ich die IP geht scheinbar alles.

Nein, per Docker habe ich das nicht gemacht sondern normal über apt wie hier https://phoscon.de/en/conbee2/install#ubuntu beschrieben.

Ich drücke an beiden mit diesen kleinen Metallstiften 5sek lang den Resetknopf. Der leuchtet 1-2x schnell rot und geht dann aus. Muss das so sein? Wenn ein Gerät im Pairingmode ist sollte es doch dauerhaft blinken? So kenne ich das.

Leider steht auf den Verpackungen der beiden Sensoren keine genau Modellbezeichnung. Laut der Bilder scheinen es aber dieser https://zigbee.blakadder.com/Tuya_IH-K009.html und dieser https://zigbee.blakadder.com/Tuya_WSD500A.html zu sein. In der deconz-GUI (nicht das Webinterface) steht dann aber unter Manifacterer: Zbeacon. Ist das am Ende doch etwas exotisches?
 
FatManStanding schrieb:
Das ist genau der, den ich oben in Beitrag #11 gezeigt habe. Den habe ich in der Garage stehen. Siehst du am _TZ3000_xr3htd96

Das Teil braucht auch kein Custom DDF und sollte plug n play funktionieren.

Wie sieht denn dein Mesh aus, wenn du die Deconz GUI aufrufst?
Unbekannte Geräte sehen so aus:
1771355819582.png


Das blaue 0x0000 Device ist der Conbee.


Welche Version hast du hier stehen?
1771356051421.png



WICHTIG:
Es gibt einen Unterschied zwischen Conbee I / II und III
Port, Baudrate und FlowControl unterscheiden sich!

Conbee 1+2
Javascript:
serial:
  port: /dev/ttyACM0
  adapter: deconz
  baudrate: 57600
  rtscts: true

Conbee 3
Javascript:
serial:
  port: /dev/ttyUSB0
  adapter: deconz
  baudrate: 115200
  rtscts: false

Hat mich auch nen ganzen Abend gekostet bis ich das rausgefunden habe, als ich vom 1er auf den 3er umgestiegen bin.
https://github.com/Koenkk/zigbee2mqtt/discussions/19785

Schau mal, ob du das bei deiner Installation irgendwo anpassen kannst.
 
Zuletzt bearbeitet:
Laut dem Webinterface ist der Dongle doch die Version 1 nicht die 2. Wenn du schreibst, dass es Änderungen zur Version 3 gibt sollte das aber gehen. Bei Gateway-Version steht 2.32.5, bei Firmware 26400500.

Ich habe mal einen Screenshot gemacht wie das bei mir aussieht.
Ergänzung ()

Da ich mich in der Version geirrt habe werde ich nochmal die Installation der Software für die v1 durchführen.
 

Anhänge

  • 2026-02-18_12-22-46.png
    2026-02-18_12-22-46.png
    31,9 KB · Aufrufe: 28
17714145716094657236968831339603.jpg

Der große ist der 1er. Der kleine der 2er. Grundsätzlich funktionieren beide gleich gut mit Zigbee. Wichtig ist ein kurzes Verlängerungskabel am USB Anschluss zu nutzen und den Stick nicht direkt am Gerät zu betreiben.
Senkrechte Montage bringt die beste Reichweite.

Die beiden grauen Devices werden deine Aktoren sein. So wie sie da jetzt sind, sind sie nicht unterstützt.
Es deutet aber darauf hin, dass deine Installation und die Kommunikation mit dem Conbee grundsätzlich in Ordnung ist und funktioniert.

Toggle einen von den grauen auf (1), selektiere die Basic Cluster (evtl. per Doppelklick) (2) und dann auf der linken Seite auf Read Attributes (3). Dann drückst du kurz den Knopf am entsprechenden Sensor. Dieser blinkt dann kurz und im Deconz solltest du auch ein kurzes Blinken am Device sehen.

Anschließend stehen die ausgelesenen Device Attribute auf der linken Seite in der Tabelle (4).
Das postest du dann hier.

1771415104187.png


Die Firmware 26400500 auf dem Stick ist vom 18.08.2021. Eine neuere gibt es nicht.
https://deconz.dresden-elektronik.de/deconz-firmware/

Wichtiger ist die Gateway (Phoscon) Version, da in dieser die Unterstützung für die Geräte enthalten ist.
Da hast du schon die neuste.
https://phoscon.de/en/changelog
 
Zuletzt bearbeitet:
Toggle einen von den grauen auf (1), selektiere die Basic Cluster (evtl. per Doppelklick) (2) und dann auf der linken Seite auf Read Attributes (3). Dann drückst du kurz den Knopf am entsprechenden Sensor. Dieser blinkt dann kurz und im Deconz solltest du auch ein kurzes Blinken am Device sehen.

Das habe ich gemacht für einen der beiden grauen. Es wurde danach die Verbindungslinie zum Gateway hergestellt.

Ich verstehe aber weiterhin den unterschied nicht zwischen der GUI-Anwendung (in der ich das jetzt gemacht habe) und dem Webinterface. Unter Ubuntu kann ich das Webinterface aufrufen wenn
a.) die GUI-App läuft und ich 192.168.10.22:80 aufrufe
oder
b.) wenn ich die GUI-App schließe, in systemd deconz starte und dann die IP starte.

Scheint das gleiche zu sein. ABER: Wieso muss ich im Webinterface nochmal den Sensor suchen? Wieso wird das nicht "übernommen"? Erkannt und gepaired wurden beide ja. Im webinterface wird dann kein Sensor mehr gefunden.
Ergänzung ()

Ist denn im Interface unter Geräte / Sensoren überhaupt ein Temperatursensor gemeint? Das Icon sieht eher nach einem Bewegungssensor aus.
 
FatManStanding schrieb:
Scheint das gleiche zu sein. ABER: Wieso muss ich im Webinterface nochmal den Sensor suchen?
Das Deconz UI musst du eigentlich NIE aufrufen. Das nutze ich nur, wenn ich einen nicht unterstützten Aktor habe um damit ein DeviceRequest im Github aufzumachen.

FatManStanding schrieb:
Wieso wird das nicht "übernommen"?
Wird es in der Regel. Außer eben für unbekannte Aktoren. Die sind dann im Deconz grau und nur mit einer 0xabcd zu sehen. Im Phoscon Web UI tauchen die nicht auf.
FatManStanding schrieb:
Ist denn im Interface unter Geräte / Sensoren überhaupt ein Temperatursensor gemeint?
Da sind alle Arten von Sensoren gemeint.
Ergänzung ()

FatManStanding schrieb:
Das habe ich gemacht für einen der beiden grauen. Es wurde danach die Verbindungslinie zum Gateway hergestellt.
Und was steht dann in der Basic Cluster Attribute Liste? Teile doch mal einen Screenshot.
 
Hier ein Screenshot. Diese Attribute Liste ist für beide Sensoren absolut gleich? Ist das korrekt?
 

Anhänge

  • 2026-02-19_13-22-22.png
    2026-02-19_13-22-22.png
    65,3 KB · Aufrufe: 25
Zurück
Oben