Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[GombersIOB]

Etwa ein Jahr hat es funktioniert, nun nicht mehr. Ich habe an meinem Raspi 4 ein Conbee III Gateway stecken und damit waren bis vor ein paar Wochen zwei Fenster/Tür-Sensoren verbunden. Weil ich Problem mit dem einen Sensor, einem Aqara, hatte habe ich alles Mögliche probiert und irgendwann den Kontakt zum Gateway verloren. Fehlermeldung:

"Starting zigbee-herdsman problem : failed to start adapter connection to firmware."

Das frage ich mich doch, wer ist "herdsman"?

Ich habe nun das Conbee III auf neue Firmware gehoben

• Gatway-Version: 2.31.2
• Firmware-Version: 264F0900

Und auch ZigBee unter IOBroker deinstalliert und neu installiert. Es ist jetzt auf dem Stand 3.3.4.

Mein Verständnis von diesem Ablauf ist, dass im Zuge der Conbee-Installation die deConz-Software als Webserver auf dem Raspi hochgezogen wird und der IOBroker per Rest-API den Status der mit dem Gateway verbundenen Geräte abfragt. Mit dem Webserver kann ich mich auch über den Browser über Port 80 auf dem Raspi connecten und den Nicht-Aqara-Sensor mit dem Gateway verbinden. Aqara blinkt und leuchtet, verbindet sich aber nicht.

Mir fehlt hier das große Bild.
Auf der einen Seite gibt es das Conbee III Gateway, was die Verbindung zu den Geräten hält.
Dann gibt es die Software deConz, die an den Ports 80 und 443 lauscht und auf der anderen Seite mit dem Stick "redet".

Auf iOBroker-Seite gibt es die ZigBee-Instanz und den ZigBee-Coordinator. Die beiden kriege ich nicht sauber auseinandergehalten. Der Coordinator scheint mir so eine Art GUI für die Geräte zu sein. Das was ich da sehe, sehe ich im Prinzip auch auf dem deConz-Webserver.
Die ZigBee-Instanz beschreibt die Verbindung zum Gateway. Wenn man ein zweites Gateway noch hätte, hätte man vermutlich auch eine zweite Instanz. GInge das überhaupt? Einen zweiten Webserver an Port 80 kann es ja nicht geben.
Und wozu braucht es alle diese Attribute:

• Die COM-Id beschreibt vermutlich die Hardware-Adresse des Gateways
• die ExtPanID und PanID sind mir nicht klar. Wenn ich sie in der IOBroker-ZigBee-Instanz setzen kann, wieso hat das Auswirkung auf die Geräte am Gateway? Die reden doch mit dem Gateway und nicht mit der Instanz. Und wieso wird sie an der Instanz gesetzt. Irgendwo habe ich gelesen, dass das Gateway selber eine random vergibt. Wie passt das zusammen?
  jedenfalls hat die Instanz eine ExtPanID und PanID vorgeschlagen. Ist die auch random? Oder hat sie die vom Gateway? Und wenn sie sie vom Gateway hat, dann hätte die Instanz ja Verbindung.
  Wieso sagt dann der Coordinator, er hätte keine?

Ich bin gerade restlos verwirrt.

Und dann gibt es im IPBroker auch noch den deConz-ZigBee-Adapter. Was der soll ist mit auch nicht klar.

[mcm1957]

@arteck
@asgothian

Die Fragestunde ist wohl was für euch :-)

[Asgothian]

@GombersIOB sagte in IOBroker verbindet sich nicht mit Conbee III Gateway.:

[...snip]
Ich habe nun das Conbee III auf neue Firmware gehoben

• Gatway-Version: 2.31.2
• Firmware-Version: 264F0900

Und auch ZigBee unter IOBroker deinstalliert und neu installiert. Es ist jetzt auf dem Stand 3.3.4.

Mein Verständnis von diesem Ablauf ist, dass im Zuge der Conbee-Installation die deConz-Software als Webserver auf dem Raspi hochgezogen wird und der IOBroker per Rest-API den Status der mit dem Gateway verbundenen Geräte abfragt. Mit dem Webserver kann ich mich auch über den Browser über Port 80 auf dem Raspi connecten und den Nicht-Aqara-Sensor mit dem Gateway verbinden. Aqara blinkt und leuchtet, verbindet sich aber nicht.

Mir fehlt hier das große Bild.
Auf der einen Seite gibt es das Conbee III Gateway, was die Verbindung zu den Geräten hält.
Dann gibt es die Software deConz, die an den Ports 80 und 443 lauscht und auf der anderen Seite mit dem Stick "redet".

Auf iOBroker-Seite gibt es die ZigBee-Instanz und den ZigBee-Coordinator. Die beiden kriege ich nicht sauber auseinandergehalten. Der Coordinator scheint mir so eine Art GUI für die Geräte zu sein. Das was ich da sehe, sehe ich im Prinzip auch auf dem deConz-Webserver.
Die ZigBee-Instanz beschreibt die Verbindung zum Gateway. Wenn man ein zweites Gateway noch hätte, hätte man vermutlich auch eine zweite Instanz. GInge das überhaupt? Einen zweiten Webserver an Port 80 kann es ja nicht geben.
Und wozu braucht es alle diese Attribute:

• Die COM-Id beschreibt vermutlich die Hardware-Adresse des Gateways
• die ExtPanID und PanID sind mir nicht klar. Wenn ich sie in der IOBroker-ZigBee-Instanz setzen kann, wieso hat das Auswirkung auf die Geräte am Gateway? Die reden doch mit dem Gateway und nicht mit der Instanz. Und wieso wird sie an der Instanz gesetzt. Irgendwo habe ich gelesen, dass das Gateway selber eine random vergibt. Wie passt das zusammen?
  jedenfalls hat die Instanz eine ExtPanID und PanID vorgeschlagen. Ist die auch random? Oder hat sie die vom Gateway? Und wenn sie sie vom Gateway hat, dann hätte die Instanz ja Verbindung.
  Wieso sagt dann der Coordinator, er hätte keine?

Ich bin gerade restlos verwirrt.

Und dann gibt es im IPBroker auch noch den deConz-ZigBee-Adapter. Was der soll ist mit auch nicht klar.

Da gehen viele Dinge durcheinander:

1. Du hast einen conbee III Koordinator in deinem PI4 stecken. Der Koordinator ist ein Stück Hardware mit einer entsprechen passenden Firmware, die einer Software die Möglichkeit gibt ein Zigbee Netzwerk aufzubauen und zu administrieren
2. Solange du die deconz Software dazu nutzt dann ist die Kombination deconz + conbee III dein Gateway (als logisches Objekt). Als physikalisches Objekt wird damit der gesamte PI4 dein Gateway.
3. Es gibt alternative Softwarepakete um das Gateway (als logisches Objekt) aufzubauen. Die bekannteste und meines Wissens am meisten genutzte Lösung ist Zigbee2mqtt.io. Wahrscheinlich gibt es weitere, die auch mit dieser Hardware arbeiten - das ist aber für Deine Frage nicht relevant.
4. Es gibt auch noch eine hybride Lösung, bei der der ioBroker selber zum (logischen) Gateway wird - das ist dann der ioBroker.Zigbee Adapter.

Die verschiedenen Gateway-Lösungen schliessen sich gegeneinander aus. Solange die deconz Software läuft kann weder der Zigbee Adapter noch zigbee2mqtt mit dem Koordinator (dem Conbee III in deinem Fall) kommunizieren.

Der Herdsman ist eine Bibliothek die sowohl vom Zigbee Adapter als auch von zigbee2mqtt.io genutzt wird um die Hardware anzusprechen.

@GombersIOB sagte in IOBroker verbindet sich nicht mit Conbee III Gateway.:

Etwa ein Jahr hat es funktioniert, nun nicht mehr. Ich habe an meinem Raspi 4 ein Conbee III Gateway stecken und damit waren bis vor ein paar Wochen zwei Fenster/Tür-Sensoren verbunden. Weil ich Problem mit dem einen Sensor, einem Aqara, hatte habe ich alles Mögliche probiert und irgendwann den Kontakt zum Gateway verloren. Fehlermeldung:

"Starting zigbee-herdsman problem : failed to start adapter connection to firmware."

Das frage ich mich doch, wer ist "herdsman"?

Hier stellen sich 5 Fragen:

1. Was hast du für einen Unterbau für den ioBroker ?

• läuft der auch auf dem Pi4 ?
• ist der aktuell ?
• was sagt iob diag ?

2. wie hat es vorher funktioniert ?

• Welche Software hast du zur Kommunikation mit der Hardware genutzt ?
• Wie hast du diese an den ioBroker angebunden ?
• Wie hast du die Zigbee Geräte gesteuert / die Aktionen / Reaktionen der Geräte im ioBroker empfangen.

3. Was genau hast du probiert ?

• welche Adapter hast du installiert / deinstalliert / konfiguriert ?
• welche Software hast du auf dem System installiert / deinstalliert / konfiguriert ?

4. Was hast du neben den Sensoren noch in Deinem Zigbee Netzwerk ?
5. Wie liegen Zigbee Netzwerk und 2.4 GHz WLan zueinander ? Welche Kanäle werden wo benutzt ?

A.

Nachtrag: Alle weiteren Fragen zu Herdsman und den verschiedenen ID's lassen sich beantworten wenn etwas mehr klarheit besteht über dein Setup.

[GombersIOB]

@Asgothian sagte in IOBroker verbindet sich nicht mit Conbee III Gateway.:

@GombersIOB sagte in IOBroker verbindet sich nicht mit Conbee III Gateway.:

[...snip]

Da gehen viele Dinge durcheinander:

1. Du hast einen conbee III Koordinator in deinem PI4 stecken. Der Koordinator ist ein Stück Hardware mit einer entsprechen passenden Firmware, die einer Software die Möglichkeit gibt ein Zigbee Netzwerk aufzubauen und zu administrieren
   Der mag Koordinator heißen. Bei mir, auf den deConz-Server stellt er sich unter der Bezeichnung Gateway. Den Rest hatte ich mir, wie von Dir geschildert, vorgestellt.

2. Solange du die deconz Software dazu nutzt dann ist die Kombination deconz + conbee III dein Gateway (als logisches Objekt). Als physikalisches Objekt wird damit der gesamte PI4 dein Gateway.
   D'accord.

3. Es gibt alternative Softwarepakete um das Gateway (als logisches Objekt) aufzubauen. Die bekannteste und meines Wissens am meisten genutzte Lösung ist Zigbee2mqtt.io. Wahrscheinlich gibt es weitere, die auch mit dieser Hardware arbeiten - das ist aber für Deine Frage nicht relevant.

4. Es gibt auch noch eine hybride Lösung, bei der der ioBroker selber zum (logischen) Gateway wird - das ist dann der ioBroker.Zigbee Adapter.

Die verschiedenen Gateway-Lösungen schliessen sich gegeneinander aus. Solange die deconz Software läuft kann weder der Zigbee Adapter noch zigbee2mqtt mit dem Koordinator (dem Conbee III in deinem Fall) kommunizieren.
Ich war gerade mal kurz unterwegs. Da kam mir diese Idee auch. Dass die deConz-Software womöglich mit dem IOBroker ZigBee-Adapter konkurriert.

Der Herdsman ist eine Bibliothek die sowohl vom Zigbee Adapter als auch von zigbee2mqtt.io genutzt wird um die Hardware anzusprechen.
Ja, das hatte ich mir so schon vorgestellt.

@GombersIOB sagte in IOBroker verbindet sich nicht mit Conbee III Gateway.:

Etwa ein Jahr hat es funktioniert, nun nicht mehr. Ich habe an meinem Raspi 4 ein Conbee III Gateway stecken und damit waren bis vor ein paar Wochen zwei Fenster/Tür-Sensoren verbunden. Weil ich Problem mit dem einen Sensor, einem Aqara, hatte habe ich alles Mögliche probiert und irgendwann den Kontakt zum Gateway verloren. Fehlermeldung:

"Starting zigbee-herdsman problem : failed to start adapter connection to firmware."

Das frage ich mich doch, wer ist "herdsman"?

Hier stellen sich 5 Fragen:

1. Was hast du für einen Unterbau für den ioBroker ?

• läuft der auch auf dem Pi4 ?
  Ja!
• ist der aktuell ?
  Ja! Gerade heute, in dem Zusammenhang auch nochmal gewartet.

• was sagt iob diag ?

2. wie hat es vorher funktioniert ?
   Einfach straight forward, nach einer Installation. Ein Teil der Fragen hatte ich vorher schon, aber weil es direkt lief, habe ich nicht mehr daran gerührt. Weil es direkt lief, habe ich aber von Herdsman nichts gewusst.
   Ich denke nun mein Fehler war, die deConz-Software zu installieren. Ich bin da auf einen anderen Vorschlag der Installation gekommen, womöglich auf Phoscon.de selber. Und da wird die Installation beschrieben.
   Da ich den Zusammenhang nicht wirklich kenne, und ich auch die Installation von letztem Jahr nicht mehr auswendig wusste, ist mir dabei nichts komisch vorgekommen.

• Welche Software hast du zur Kommunikation mit der Hardware genutzt ?
  siehe oben

• Wie hast du diese an den ioBroker angebunden ?
  siehe oben.

• Wie hast du die Zigbee Geräte gesteuert / die Aktionen / Reaktionen der Geräte im ioBroker empfangen.
  Auswertung der Objekte. Die Instanz hat den Status in Objekten hinterlegt und die habe ich mit JavaScript ausgelesen.

Nachtrag: Alle weiteren Fragen zu Herdsman und den verschiedenen ID's lassen sich beantworten wenn etwas mehr klarheit besteht über dein Setup.
Das verstehe ich nicht ganz. Die Zielkonfiguration ist doch klar. Der Conbee III Coordinator kommt an eine USB-Port und über den "kommuniziere" ich mit den Sensoren, bzw erfahren den Fester//Tür-Status. Dazu gibt es unter IOBroker
den ZigBee-Adapter und noch einen ZigBee-Coordinator. und irgendqwo noch einen Layer der sich Herdmans nennt und quasi der Driver für den Conbee ist. So sieht es für mich jetzt aus. Einfluss auf Herdmanns habe ich wohl nur über
die Konfiguration im ZigBee-Adapter des IOBrokers.
Der Port zum Conbee ist derzeit von dem deConz-Webserver blockiert. Den muss ich runterfahren (schaffe ich heute aber nicht mehr. Ich habe Besuch und muss jetzt auch weg) und dann sollte alles laufen.

Die Beschreibung der Wirkungsweise de ExTPanID scheint davon doch unabhängig. Das ist, wie auch in der Hilfe beschrieben, eien Art SSID, wie man sie von WiFI-kennt. Ich wundere mich nur, wenn der ConBee die random vergibt,
wieso man sie im Adapter nochmal vergeben kann. Das ist mir weder von der Logik noch von dem Ablauf so richtig verständlich.

Sorry, es war lang aber trotzdem ziemlich bündig von mir. Ich muss nochmal darüber nachdenken, wollte aber die Antwort nciht schuldig bleiben.
Jetzt muss ich wirklich weg. Danek und Gute Nacht. ich melde mich morgen nochmal.

[Asgothian]

@GombersIOB Ich fürchte du musst deine Antwort nochmal überarbeiten - ich kann deine Antworten auf meine Fragen da nicht wirklich sauber erkennen.

Zum Thema PanID, ExtPanID und TransportKey

Diese 3 Parameter bestimmen die Netzwerk verschlüsselung des Zigbee Netzwerkes. Sie müssen allen Teilnehmern des Systems bekannt sein damit das Zigbee Netz funktioniert.

Der Koordinator selber 'vergisst' die eigentlich nie. Allerdings werden diese seitens der Gateway Software gesteuert. Bei der deconz Software geht das (auch) intern.

Allerdings hat die Zigbee-Herdsman Bibliothek anscheinend keine Möglichkeit diese vom Stick zu lesen - weswegen ein Wechsel von Deconz zum Zigbee Adapter / Zigbee2mqtt.io üblicherweise ein neuanlernen voraussetzt. Ein Experte bin ich in dieser Implementierung nicht - ich habe mich frühzeitig gegen Conbee entschieden, da die Unterstützung der TI und EZSP/Ember Chipsätze im Zigbee-Herdman besser its.

A.