Vorteil Conbee gegenüber Herstellerbridge?

[morrpheus]

Moin Moin.
Ich überlege mir einen Conbeestick anzuschaffen. Aber welche Vorteile gegenüber z.B. dem Tradfri-Gateway hat der Stick?
Und welche E14 RGB LED funktionieren damit alles?
MfG Jan

[MKeY]

Die Vorteile ggnü Tradfri kenne ich nicht im Detail, aber du kannst mit dem Conbee folgende Sorten steuern: Philips Hue, IKEA TRÅDFRI, Xiaomi Aqara, OSRAM SMART+, Busch-Jaeger, GIRA, JUNG, Paulmann und Paul Neuhaus

Die Übersicht findest du hier:
https://phoscon.de/de/conbee/compatible

[Beta-User]

ConBee II kann für deconz und zigbee2mqtt eingesetzt werden, beides open-source-Lösungen.
Bei einer Hersteller-Bridge muss man immer an deren API anknüpfen, oder die Webschnittstelle auslesen oder sowas, das kann sich also ändern. Ich finde es auch gut, dass der Stick direkt an meinem Server steckt und nicht via Netzwerk angesprochen werden muss.
Supportete Geräte (Leuchten, ...) kann man (nicht nur für deconz) unter "blakadder" finden, da steht auch halbwegs aktuell, welche Lösung welche Hardware (schon) unterstützt.

[Mitch]

und wichtig, es wird gepushed und nicht gepolled

[st0ne]

Hallo, interessanter Thread. Ich habe einen Conbee 2 und wusste bis eben nicht, das ich statt deconz auch zigbee2mqtt nutzen kann. Ich kenne zigbee2mqtt nicht, hat es den Vorteile gegenüber deconz?

Mein aktuelles Septup Conbee 2 + Raspberry 3 + Pi OS mit FHEM und Google Assistant. Darüber steuer ich ein paar Hue Lampen, Lidl Steckdosen, Shelly Plug, Android Box, LG TV.

[MadMax-FHEM]

Hallo, interessanter Thread. Ich habe einen Conbee 2 und wusste bis eben nicht, das ich statt deconz auch zigbee2mqtt nutzen kann. Ich kenne zigbee2mqtt nicht, hat es den Vorteile gegenüber deconz?

Mein aktuelles Septup Conbee 2 + Raspberry 3 + Pi OS mit FHEM und Google Assistant. Darüber steuer ich ein paar Hue Lampen, Lidl Steckdosen, Shelly Plug, Android Box, LG TV.

Vorteile/Nachteile...

Je nachdem wer die Frage liest wirst du Antworten kriegen die dir nicht helfen werden...

Ich nutze deCONZ weil ich "keine Lust" auf mqtt habe...
Ich warten kann bis deCONZ neue Geräte eingebunden hat (da ist wohl zigbee2mqtt etwas/minimal schneller)...

deCONZ hat eine "App" (phoscon) da lernt man Geräte an und dann holt man sie mit dem HUE-Bridge-Modul nach fhem...

Bei zigbee2mqtt halt per mqtt

Ansonsten ist es wohl besser sich mit den genannten Stichworten einen Überblick zu verschaffen und eine "Vorliebe" zu entwickeln...

EDIT: du hast doch schon HUE-Zeugs? Wie eingebunden?

Gruß, Joachim

[st0ne]

Hi,

für mich ist DeCONZ und Phoscon ein Paket, das eine ist der Treiber und das andere die GUI. Aus meiner Laiensicht Ich habe meine Hue Geräte über Phoscon eingebunden.

MQTT als Protokoll ist mir gänzlich neu, deswegen meine Frage. Aber die war scheinbar zu allgemein formuliert, ich nehme sie zurück

Da bei mir alles läuft, never change a running system.

Schönen Weihnachten dir.

[morrpheus]

Ich habe mich jetzt für einen Conbee II Stick entschieden. Den kann man ja auch mit Phoscon bedienen.
Funktioniert das nur mit den Aktoren die mit Conbee verbunden sind oder geht das auch mit Lampen die per MQTT2 mit fhem verbunden sind? Z.b. über die fhem HUE Bridge?

[MadMax-FHEM]

Also:

der Conbee II kann entweder per zigbee2mqtt und dann Einbindung in fhem per MQTT (Device? mit entspr. Templates?) genutzt werden ODER von deCONZ und dann Einbindung in fhem per HUE-Bridge-Modul.
EDIT: es gibt evtl. auch noch eine dritte Methode aber da fällt mir aktuell nicht mal der Name ein

Und ja klar: es gehen nur Geräte (Lampen, FBs, Sensoren, ...) die am Conbee II "angelernt" sind. Entweder eben mit "Mechanismen" die bei zigbee2mqtt notwendig sind (kenne ich aber zu wenig/nicht) oder eben per phoscon (das ist die "deCONZ-App") an deCONZ angelernt sind.

EDIT:

Funktioniert das nur mit den Aktoren die mit Conbee verbunden sind oder geht das auch mit Lampen die per MQTT2 mit fhem verbunden sind? Z.b. über die fhem HUE Bridge?

Wie geschrieben: entweder MQTT oder HUE-Bridge. Soweit ich weiß hat MQTT mit HUE-Bridge nichts zu tun... Das Hue-Bridge-Modul dient dazu eben eine Hue-Bridge (echt oder "Clone" wie deCONZ) in fhem einzubinden.
Was fhem nat. kann ich zwischen beiden Welten "vermitteln". D.h. du hast einen Schalter per MQTT und kannst dann mittels notify/DOIF/... eben eine Lampe schalten die per HUE-Bridge-Modul eingebunden ist...
Aber wenn beides Zigbee ist, dann würde ich beides über den gleichen Weg einbinden (und auch versuchen den Vorteil zu nutzen, dass es auch ohne laufende Bridge und fhem geht)...

Gruß, Joachim

[Beta-User]

Doppelt genäht hält besser:

für mich ist DeCONZ und Phoscon ein Paket, das eine ist der Treiber und das andere die GUI.

Jein...

phoscon kommt zwar mit dem deconz-Paket mit, ist aber was separates, und es gibt auch deCONZ-GUI; letzteres ist die eigentliche Admin-Oberfläche, die aber (unter Linux) X11 braucht, was man via remote ssh -X-Zugang haben kann.

phoscon ist eine Browser-App, man kann die deconz-API aber auch mit "normalen" Handy-Apps wie HUE-Essentials "bedienen". Genau das macht auch das Modul HUEBridge, es greift auf die deconz-API zu. phoscon ist dabei deutlich "langsamer" in der Integration neuer Devices wie deconz, das merkt man auch irgendwann, wenn man "China-Gadgets" einkauft... Die kann man NUR mit deCONZ-GUI zumindest der Spur nach einbinden, via phoscon sieht man da gar nichts...

Das alles hat mit MQTT nichts zu tun. Die Integration von MQTT-Geräten in FHEM kann auf mehrere Weise erfolgen, m.E. zu empfehlen ist die mit Hilfe der MQTT2_.* Module.

Man kann den ConBee II stattdessen auch mit mehreren ganz anderen Softwares wie deconz betreiben, die vermutlich am häufigsten eingesetzte ist zigbee2mqtt. Das ist aber (für denselben Stick) "entweder oder", von daher ist diese Frage schlicht falsch gestellt:

Funktioniert das nur mit den Aktoren die mit Conbee verbunden sind oder geht das auch mit Lampen die per MQTT2 mit fhem verbunden sind?

Bei ZigBee ist es wie bei Z-Wave: die gepairten Geräte werden auf dem Interface gespeichert, also auf dem ConBee II (oder dem CC253x oder was auch immer). Daher kann man z.B. einen ConBee II auch einfach an einen anderen Rechner anstöpseln und hat direkt alle Geräte verfügbar (getestet mit deconz).
Ein ZigBee-Gerät kann gleichzeitig auch immer nur mit einem Coordinator verbunden sein, da überschreibt einfach ein späteres Pairing ein früheres.

Kurz: Man kann daher effektiv mehrere Mesh-Netzwerke mit mehreren Coordinator-Geräten betreiben, aber nie dasselbe Gerät über zwei unterschiedliche Lösungen ansprechen, die nichts miteinander zu tun haben. Ergo:
phoscon+HUE-Essentials+HUEBridge/HUEDevice (und deCONZ-GUI) gehen parallel mit einem einzigen ConBee II, da alle im Hintergrund deconz ansprechen, aber zigbee2mqtt benötigt (wie deconz) exklusiven Zugriff auf den Stick, sonst geht nichts.

Letzteres ist btw. immer wieder die Ursache für diverse Irritationen von noobs, wenn die _irgendwo_ generische Namen wie "ttyACM0" verwenden. Immer (!) eindeutige Bezeichnungen wählen! Beim Weiterreichen der Schnittstelle an deconz direkt, bei docker, bei anderen Virtualisierungen, für CUL's&Co in FHEM. Einfach IMMER!

Details bzg. FHEM: https://wiki.fhem.de/wiki/Mehrere_USB-Ger%C3%A4te_einbinden

[Beta-User]

Sorry, das hier hatte ich vorhin übersehen:

Aber wenn beides Zigbee ist, dann würde ich beides über den gleichen Weg einbinden (und auch versuchen den Vorteil zu nutzen, dass es auch ohne laufende Bridge und fhem geht)...

Sehe ich _im Prinzip_ genauso, aber hier gibt es einen ziemlich gravierenden Unterschied zwischen deconz und zigbee2mqtt.

Bei deconz macht man "Verknüpfungen" typischerweise via phoscon, das redet "irgendwie" mit der Hardware. Im Ergebnis weiß man also nie, ob die Geräte notfalls auch wirklich direkt miteinander kommunizieren, oder ob immer deconz (oder nur der Coordinator?) noch mit beteiligt sind.

zigbee2mqtt (und auch zigbee2tasmota") kennen dagegen "bind"-Befehle. Damit müßten (nach meinem bisherigen Verständnis) die Geräte wirklich direkt miteinander reden. Prinzipiell ist sowas innerhalb des ZigBee-Ökosystems auch vorgesehen, allerdings gibt es immer mal wieder Berichte von Problemen (v.a. mit IKEA-Hardware), bei denen schon irgendwas auf dem Gerät gespeichert ist, was dann zu verhindern scheint, dass der Coordinator (z.B.) alle Meldungen einer Fernbedienung erhält. Meine Vermutung geht  dahin, dass ein verlässlicher Betrieb von Verknüpfungen ohne Coordinator eher nicht funktioniert, schon gleich nicht, wenn man irgendwelche Schwellenwerte berücksichtigt haben will, also z.B. eine Lampe über einen Bewegungsmelder nur dann anschalten, wenn es grade dunkel ist.

(OT: ZWave macht das mAn. besser, so jedenfalls meine bisherigen Eindrücke von den zwei Bewegungsmelder-Geräten, die ich bisher in der Hand hatte; praktische Erprobung steht aber noch aus; damit wird aber ZigBee für mich eher eine Nischenlösung für Nebengeräte und Sensorik, v.a., weil manche der Tradfri-Geräte sich immer mal wieder "weghängen").

zigbee2mqtt hat den weiteren "Vorteil" (ist was subjektives): Alle Infos landen erst mal an derselben Stelle. Ein Bewegungsmelder => alle Readings bei einem MQTT2_DEVICE, Umgebungslicht, Bewegung, Temperatur, whatever. deconz muss das (wohl prinzipbedingt) auf mehrere Geräte verteilen, da gilt: ein Sensor-Endpunkt, ein HUEDevice.

zigbee2mqtt hat aber scheinbar auch einen kleinen Nachteil: Hier hat Snocksman den subjektiven Eindruck mitgeteilt, dass deconz irgendwie deutlich schneller in der Ausführung von Aktionen wäre.

Ihr habt die "Qual der Wahl"...

[MadMax-FHEM]

Bei deconz macht man "Verknüpfungen" typischerweise via phoscon, das redet "irgendwie" mit der Hardware. Im Ergebnis weiß man also nie, ob die Geräte notfalls auch wirklich direkt miteinander kommunizieren, oder ob immer deconz (oder nur der Coordinator?) noch mit beteiligt sind.

Ja, das stimmt mitunter.
Lässt sich aber leicht rausfinden: deCONZ beenden und schalten

EDIT: daher ist mir ZigBee auch ein wenig "suspekt" und ich nutze es aktuell nur wenig. Hauptsächlich halt für Beleuchtung, weil da ist es einfach toll... Ansonsten nutze ich eher Homematic (noch/Historie), ZWave und EnOcean...

EDIT: gut vielleicht liegt es auch an der deCONZ-Einbindung...   Aber für die Dinge die ich damit mache finde ich es ok. Und für zigbee2mqtt fehlt mir die Zeit (also das [auch noch] auszuprobieren)...

Ihr habt die "Qual der Wahl"...

Wie so oft...

Gruß, Joachim