zigbee2mqtt | Warum muss denn ein Einstieg immer so kompliziert sein

Begonnen von holle75, 18 Februar 2025, 21:50:19

Vorheriges Thema - Nächstes Thema

holle75

Ihr Lieben, ich frage mich gerade mal wieder, ob ich (zu) alt werde.


Das https://wiki.fhem.de/wiki/ZigBee mehrmals gelesen. Auch https://wiki.fhem.de/wiki/Zigbee2mqtt durchgearbeitet.

Dann lande ich irgendwann bei https://www.zigbee2mqtt.io/guide/getting-started/

um mich weiterzuhangeln nach https://www.zigbee2mqtt.io/guide/adapters/


... und weiß immer noch nicht welche (Kommunikations-)Hardware denn jetzt am besten mit fhem läuft, oder welche Schritte genau vonnöten sind.



Bitte erbarme sich einer und lasst mich wissen:

- das hab ich probiert und war Mist (optional)
- dann hab ich das probiert und war auch Mist (optional)
- und dann habe ich den supereinfachen Weg mit diesem (Beispiel) USB-Stick gefunden, ihn so geflasht und so integriert, die Möglichkeiten sind maximal ausgeschöpft und ich bin total happy damit

... und diesen Thread könnte man dann anpinnen und jeder der sich mit dem Thema auseinandersetzen will bekommt die Chance sich nicht als VollDepp zu fühlen und schnell in die Materie zu finden ;) ... oder, anstatt, die Essenz als Unterabschnitt im Wiki zu verewigen könnte auch dem Ein oder Anderen zügig weiterhelfen.

Es geht mir um eine Wegweisung, keine Anleitung. Auch alles was "danach" kommt (fhem intern), ist mir recht klar ...

Tausend DANK!








passibe

Eigentlich brauchst du nur einen Zigbee-Stick. Den bindest du dann in z2m ein und dann kannst du dort Geräte anlernen, etc. Danach reichst du die Geräte per MQTT an FHEM weiter. z2m sendet dann die Statusänderungen der Geräte per MQTT an FHEM und du kannst von FHEM aus MQTT-Nachrichten verschicken, die die Geräte schalten, usw.

Ich habe selbst keine Erfahrungen damit, welcher Zigbee-Stick aktuell "state of the art ist", ich benutze seit ca. 3-4 Jahren den Conbee II. Da gibt es inzwischen natürlich neuere Sticks (der Conbee II funktioniert bei mir aber nach wie vor problemlos).

Du kannst mal hier lesen, demnach dürfte wohl der "SONOFF Zigbee 3.0 USB Dongle Plus" ein guter und günstiger Einstieg sein.
Wenn du etwas mehr Geld ausgeben willst und in der Platzierung des Sticks flexibler sein willst (z.B. weil dein Server im Keller steht und deine ganzen Geräte deshalb sehr weit weg sind) scheint wohl der SMLight SLZB-06 die beste Wahl zu sein. Den kann man per PoE anbinden und damit an jedem Ort, an dem ein LAN-Kabel liegt, platzieren (falls du keinen PoE-fähigen Switch hast, brauchst du natürlich noch einen PoE-Injector). Kannst dafür (aber auch für alle anderen Sticks) auch mal auf Youtube nach Reviews schauen, davon gibt es haufenweise.

tl;dr: Kauf dir einen für deine Situation passenden Zigbee-Stick, installier z2m und wenn es dann noch Probleme/Fragen gibt, melde dich nochmal.

Hoffe das hilft erstmal!

holle75

Danke!

"Eigentlich brauchst du nur einen Zigbee-Stick. "

.... das sollte der erste Satz in jedem Wiki sein ;)


"Den bindest du dann in z2m ein und dann kannst du dort Geräte anlernen, etc. "

Genau an dem Punkt hakts bei mir, resp. verstehe ich es nicht ganz .... AUF dem Stick, Box, etc LÄUFT zigbee2mqtt? MIT dem Stick/Box verbinden sich die Zigbee-EndGeräte und sprechen dann VOM Stick/Box via MQTT mit fhem ?


Der Sonoff Stick ist gelobt, aber ist der "standalone", braucht also nur Strom via usb, oder läuft dann zigbee2mqtt auf dem Device an dem der Stick hängt?


Habe noch das Ding hier gefunden -> https://uzg.zig-star.com/product/

Das Prinzip fände ich top. Ein alleinstehendes Gerät mit WebGUI, ohne auf nem Raspi oä an dem ein Stick hängt noch groß was instalieren zu müssen ... und dann MQTT2-Server auf fhem die Daten bekommt/sendet. Verstehe ich das richtig?



passibe

Zitat von: holle75 am 18 Februar 2025, 23:52:49Genau an dem Punkt hakts bei mir, resp. verstehe ich es nicht ganz .... AUF dem Stick, Box, etc LÄUFT zigbee2mqtt? MIT dem Stick/Box verbinden sich die Zigbee-EndGeräte und sprechen dann VOM Stick/Box via MQTT mit fhem ?
Nein, zigbee2mqtt läuft, wenn du nur einen Server hast, auf dem gleichen Server auf dem dein FHEM auch läuft. Auf dem Stick oder der Box läuft nix von Relevanz und da kann auch gar nix drauf laufen, weil die kein vollwertiger Computer sind. Sonst könntest du die Dinger auch nicht zu dem Preis kaufen. Sofern es ein Stick oder eine Box ist, die per Ethernet angeschlossen ist (so wie der eben von dir verlinkte), läuft da natürlich eine kleine Firmware drauf, die es ermöglicht, Verbindungsparameter (IP-Adresse, etc.) einzustellen, aber das wars dann auch schon.

zigbee2mqtt läuft immer auf einem vollwertigen PC. Ganz vereinfacht gesprochen ist der Stick oder die Box nichts anderes als eine Antenne mit Ethernet oder USB-Anschluss vorstellen. Mehr sind die Dinger nicht. Und die Software (zigbee2mqtt), die die Signale, die die Antenne empfängt, auswertet bzw. der Antenne sagt, welche Signale sie senden soll, ist immer extern.

Zitat von: holle75 am 18 Februar 2025, 23:52:49ohne auf nem Raspi oä an dem ein Stick hängt noch groß was instalieren zu müssen
Da wirst du nicht drumrum kommen. Es ist um ehrlich zu sein aber auch kein Hexenwewrk. Du installierst halt zigbee2mqtt und damit ist es dann auch getan.

Wenn du etwas willst, was mehr in Richtung all-in-one-Lösung gehst, musst du zu Home Assistant wechseln. Da kriegst du ZHA (so heißt deren Äquivalent zu zigbee2mqtt) mitgeliefert. Aber ich gehe mal davon aus, dass du FHEM nicht verlassen willst, deshalb ergibt es keinen Sinn, Home Assistant zu nutzen, denn du willst die Geräte ja später auch direkt in FHEM haben und nicht noch einen zusätzlichen Umweg über Home Assistant nehmen müssen. Und ich glaube auch nicht, dass Home Assistant, gerade wenn man von FHEM kommt, insgesamt am Ende des Tages wirklich so viel einfacher einzurichten ist.

Wie gesagt: Je nach dem wo dein Server im Verhältnis zu den zu steuernden Geräten steht entweder einen der etablierten USB- oder Ethernet-Sticks/Box kaufen, den anschließen, zigbee2mqtt installieren und fertig.

Beta-User

Dein Verständnisproblem fängt m.E. hier an:
Zitat von: holle75 am 18 Februar 2025, 21:50:19... und weiß immer noch nicht welche (Kommunikations-)Hardware denn jetzt am besten mit fhem läuft

Das führt dann zu Sätzen wie
Zitat von: holle75 am 18 Februar 2025, 23:52:49... das sollte der erste Satz in jedem Wiki sein

NOPE!

Der Reihe nach:
Wir sprechen von einem modularen Gesamtsystem, das man auf vielerlei Weisen zusammenbasteln kann. Deine Aufgabe als Nutzer wird immer bleiben, die jeweils für dich beste Variante zu finden.

Was das Wiki angeht, kann man bestimmt vieles an den von dir zitierten Artikeln verbessern, aber der Einstieg ist und bleibt imo richtig, wenn man sagt: Richte zigbee2mqtt ein, wie dort in dessen Wiki beschrieben => da sind nämlich die jeweils aktuellen Hardwareschnittstellen (Adapter) beschrieben, und das muss nicht mehr unbedingt ein USB-Stick sein.

Ob du dann docker haben willst (in welcher Form auch immer) oder den Dienst nativ installieren, mußt du selbst entscheiden.

Ob du dann einen externen MQTT-Server haben willst, oder den FHEM-internen verwenden, mußt du auch selbst wissen.

Wenn du dann zigbee2mqtt grundsätzlich am laufen hast, gibt es genau eine Anpassung, die für FHEM@MQTT2_SERVER wichtig ist, und das war es dann auch schon, der Rest ist "generisch".

Zitat von: holle75 am 18 Februar 2025, 23:52:49Das Prinzip fände ich top. Ein alleinstehendes Gerät mit WebGUI,
Imo ist das ein großer Irrtum: selbst ein recht potenter Chip wie ein ESP32, der da drin die "Übersetzung" (?) und  Netzwerkanbindung macht, kann imo nicht alle "Spezialitäten" abbilden (schon gleich nicht aktuell halten), wie das eine Softwarelösung wie zigbee2mqtt (oder deconz) kann.
Es gibt auch noch tasmota2zigbee, das auch keinen externen "Softwaredienst" braucht, um ZigBee-Endpunkte nach MQTT/JSON abzubilden. Aber das willst du nicht in FHEM konfigurieren, da bin ich mir ziemlich sicher (vielleicht noch, wenn es nur um ein paar Sensoren geht, aber das war es im Prinzip schon).

Nachdem es an anderer Stelle (https://forum.fhem.de/index.php?topic=140320.0) mal ziemlich "wild" zugegangen ist, hier mal eine Kurzfassung, wie ich das heute empfehlen würde:

Besorge einen Adapter wie in zigbee2mqtt empfohlen. Ich mag USB, wer eventuell auf Netzwerk umsteigen will, sollte ggf. das bereits hier genannte Hybrid-PoE-Modell wählen.

Wenn das dann da ist, installierst man das auf dem "docker -run ..."-Weg und schließt den Adapter erst mal an USB an. Dabei vorab ein Verzeichnis anlegen, in dem dann die Konfiguration und logfiles von zigbee2mqtt landen werden, bei mir ist das /opt/zigbee2mqtt (Rechte weiß ich grade nicht).

MQTT2_SERVER haben viele sowieso schon laufen, ansonsten den halt auch aktivieren.

docker dann so konfigurieren, dass der Dienst automatisch beim booten mit gestartet wird (Details habe ich grade nicht im Kopf).

Zu guter Letzt sollte zigbee2mqtt entweder gestartet sein, oder aber mit irgendeiner Fehlermeldung (typischerweise was mit "herdsman" oder "mqtt server not available") nicht.

Dann editiert man "die yaml", paßt dort (!) den Pfad zum Adapter, den Typ, die Angaben zum MQTT-Server (falls noch nicht in der docker -run-Anweisung drin), die ClientID und "frontend" an, und startet dann erfolgreich zigbee2mqtt. Danach sollte es direkt weitergehen wie im FHEM-Wiki-Artikel zu zigbee2mqtt beschrieben.

PS: Das wiki lebt vom Mitmachen, konstruktive Vorschläge werde ich ggf. auch konstruktiv berücksichtigen, ansonsten steht es auch jedermann frei, eine Account zu beantragen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

Und wenn es um Fragen zu zigbee2mqtt geht, ist diese Diskussion hier ohenhin im falschen Unterforum.

Zitat von: holle75 am 18 Februar 2025, 21:50:19... und diesen Thread könnte man dann anpinnen und jeder der sich mit dem Thema auseinandersetzen will bekommt die Chance sich nicht als VollDepp zu fühlen

Ich weiß nicht, wie oder als was Du Dich jetzt fühlst, aber es gibt hier im Unterforum einen einzigen angepinnten Thread, und selbst Du, der hier gerade "Anpinnen" vorschlägt, hast ihn nicht gelesen.

https://forum.fhem.de/index.php?topic=94234.0

(Den Button zum verschieben findest Du übrigens unten auf dieser Seite)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: holle75 am 18 Februar 2025, 21:50:19... und weiß immer noch nicht welche (Kommunikations-)Hardware denn jetzt am besten mit fhem läuft, oder welche Schritte genau vonnöten sind.

...

- und dann habe ich den supereinfachen Weg mit diesem (Beispiel) USB-Stick gefunden, ihn so geflasht und so integriert, die Möglichkeiten sind maximal ausgeschöpft und ich bin total happy damit

1. Der zigbee2mqtt Teil

Ich habe an meinem zigbee2mqtt zwei Mal diesen Stick im Einsatz: https://amzn.eu/d/1OLJw9l
Und zwar genau so, wie ich ihn aus der Lieferung erhalten habe.
Ohne irgendein Rumgeflashe oder HokusPokus - hat auf Anhieb funktioniert.

In zigbee2mqtt habe ich in der Konfigurationsdatei lediglich den USB port und den Typ des Sticks (zstack) eingetragen.
Dann noch die Zugangsdaten zum mqtt-Server (bei mir ein mosquitto) in die Konfigurationsdatei geschrieben.

Fertig. Damit hatte ich ein funktionsfähiges zigbee2mqtt und konnte erste Geräte damit verbinden.

2. der FHEM Teil

Auf FHEM Seite habe ich das ganze Gedöns mit Bridge und autocreate erstmal weggelassen, um zu verstehen, wie die Verbindung eigentlich funktioniert und welche Daten wirklich aus zigbee2mqtt in FHEM angekommen. Die Geräte habe ich dann manuell angelegt - und das war bei allen 15 Geräten, die inzwischen in Betrieb sind, völlig problemlos und dauerte pro Gerät weniger als 2 Minuten.

Wenn man mal einen PIR (als Beispiel) konfiguriert hat, kann man ihn ja einfach kopieren und die ID anpassen, schon hat meinen zweiten. Auch ohne Template.



Bei der Einarbeitung in zigbee2mqtt ging es mir im Vorfeld beim Lesen übrigens ähnlich wie Dir - eine Überflutung mit Informationen, von denen man > 80% für den Beginn gar nicht braucht.

Bei der Inbetriebnahme von z2m bin ich genau nach dieser Anleitung vorgegangen:

https://www.zigbee2mqtt.io/guide/installation/01_linux.html

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

#7
Zitat von: holle75 am 18 Februar 2025, 23:52:49Genau an dem Punkt hakts bei mir, resp. verstehe ich es nicht ganz .... AUF dem Stick, Box, etc LÄUFT zigbee2mqtt? MIT dem Stick/Box verbinden sich die Zigbee-EndGeräte und sprechen dann VOM Stick/Box via MQTT mit fhem ?


Der Sonoff Stick ist gelobt, aber ist der "standalone", braucht also nur Strom via usb, oder läuft dann zigbee2mqtt auf dem Device an dem der Stick hängt?

Fangen wir mit dem zweiten Teil Deiner Frage an.

"Der Stick" ist einfach nur ein Stück Funkhardware, so wie ein CUL oder eine Homematic USB Stick. Auf dem Stick selbst "läuft" nichts weiter, als seine eigene Firmware. Damit wird der reine Funkverkehr zwischen den zigbee-Geräten selbst abgewickelt.


Nun zum ersten Teil Deiner Frage:

Wie hängen FHEM & zigbee2mqtt & zigbee zusammen und was läuft eigentlich wo?

zigbee ist - vereinfacht gesagt - lediglich der Name des verwendeten Datenprotokolls, so wie "Homematic" oder "FS20" oder "Enocean".


zigbee2mqtt selbst ist ein Softwarepaket, das genau wie FHEM, eine Hardwareplattform braucht, auf der es installiert wird. Das kann eine Linux VM oder ein Docker Container oder was auch immer sein. Das musst Du nach Deinen Bedürfnissen und Deinen Möglichkeiten entscheiden. Theoretisch kann z2m sogar auf der gleichen Plattform laufen wie Dein FHEM selbst, aber dazu raten würde ich nicht.


zigbee2mqtt verwendet "den Stick", um darüber die "Befehle" an die zigbee-Geräte zu verschicken und Rückmeldungen von den zigbee-Geräten (z.B. Schaltern oder Bewegungsmeldern) zu empfangen. In der Regel ist der Stick also an die gleiche Plattform angeschlossen, auf der auch z2m installiert ist. (prinzipiell geht es auch anders, aber das sind dann Sonderlösungen)

  • Die Befehle erhält z2m von FHEM als mqtt-Nachrichten über einen mqtt-Server.
  • z2m packt diese Nachrichten aus und generiert daraus die notwendigen Funkdaten gemäß des benötigten Funkprotokolls
  • Diese Funkdaten werden dann über den Stick an die zigbee-Geräte verschickt.

Um die Punkte 2+3 musst Du Dich als Anwender nicht kümmern, das ist die Aufgabe von zigbee2mqtt.


  • umgekehrt empfängt z2m über Funk die Rückmeldungen der zigbee-Geräte im vorgeschriebenen Datenprotokoll (vergleich zum Homematic Protokoll)
  • z2m baut daraus mqtt-Nachrichten, diese werden an den festgelegten mqtt-Server verschickt
  • FHEM empfängt diese mqtt Nachrichten vom mqtt-Servcer und baut daraus die readings für die entsprechenden mqtt2-devices


Um die Punkte 1+2 musst Du Dich nicht kümmern, das ist Aufgabe von zigbee2mqtt.


Zitat von: holle75 am 18 Februar 2025, 23:52:49Ein alleinstehendes Gerät mit WebGUI, ohne auf nem Raspi oä an dem ein Stick hängt noch groß was instalieren zu müssen ... und dann MQTT2-Server auf fhem die Daten bekommt/sendet.

Naja, wenn Du zigbee2mqtt und den Stick auf einem Raspberry installierst, hast Du ja letztlich genau das. Die WebGUI bringt zigbee2mqtt von Haus aus schon mit.

Dahinter steckt die oben schon von mir beschriebene, von Dir zu klärende Frage, wo Du zigbee2mqtt installierst und laufen lässt. Das kann selbstverständlich auch ein "standalone Gerät" sein.



Ist es für Dein Verständnis jetzt ein bisschen klarer geworden?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

eisman

hi,

 Warum muss denn ein Einstieg immer so kompliziert sein?

 ja, man möchte doch die Datensammelwut unterstützen, daher sollte man weiter Tante G fragen.

 nein, bei deConz(phoscon) kommt man sehr schnell zum ziel! nur kann es nicht alles...


gruss

1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian, Homematic,ZigBee         / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian,MQTT                               / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S

tobi01001

Zitat von: holle75 am 18 Februar 2025, 21:50:19und weiß immer noch nicht welche (Kommunikations-)Hardware denn jetzt am besten mit fhem läuft, oder welche Schritte genau vonnöten sind

Ich fühle mit dir und häng mich hier mal dran für den Fall, dass ich irgendwann mal auf zigbee erweitern möchte/muss....
FHEM@UbuntuServer on Lenovo ThinkCentre M900 [i5-6500T / 8GB RAM] MySQL-DbLog, Grafana, FTUI3 / HmIP incl. CCU3 / LGESS / Wärempumpe über TA CMI und CANoE / Shellies u.v.m.

TomLee

Zitat1. Der zigbee2mqtt Teil

Ich habe an meinem zigbee2mqtt zwei Mal diesen Stick im Einsatz:

Zwei Sticks in einer z2m-Instanz? Das geht doch nicht wirklich, oder?
Kann man einen Stick auch als Repeater einbinden oder was ist der Hintergrund der Verwendung von zwei Sticks bei Dir?

betateilchen

Zitat von: TomLee am 19 Februar 2025, 11:05:28Zwei Sticks in einer z2m-Instanz? Das geht doch nicht wirklich, oder?
Kann man einen Stick auch als Repeater einbinden oder was ist der Hintergrund der Verwendung von zwei Sticks bei Dir?

Das ist überhaupt nicht Thema dieses Threads.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

holle75

#12
Vielen Dank euch. Werde das mal durcharbeiten, aber "der Weg" wird klarer.

Zitat von: betateilchen am 19 Februar 2025, 08:53:28es gibt hier im Unterforum einen einzigen angepinnten Thread, und selbst Du, der hier gerade "Anpinnen" vorschlägt, hast ihn nicht gelesen.

Doch, hatte ich gelesen. Aber selbst beim zweiten lesen jetzt, ob deines Einwandes, wüsste ich nicht adhoc, warum mein Thread im anderen Forum besser aufgehoben wäre. Das eine heißt zigbee, das andere mqtt. Mir gehts erstmal um wie bekomme ich zigbee in fhem (über mqtt). Andererseits ist es mir egal, wo dieser Thread ist. Ich verschiebe ihn auch gerne, wenn du darauf bestehst. Und Nein, auf github möchte ich dieses Thema nicht diskutieren.

betateilchen

Zitat von: holle75 am 19 Februar 2025, 11:15:10Und Nein, auf github möchte ich dieses Thema nicht diskutieren.

Musst Du ja auch nicht, deshalb wird der mqtt Bereich hier im Forum ja als Alternative angeboten.

Zitat von: holle75 am 19 Februar 2025, 11:15:10selbst beim zweiten lesen jetzt, ob deines Einwandes, wüsste ich nicht adhoc, warum mein Thread im anderen Forum besser aufgehoben wäre.

Nur um das klarzustellen: der angepinnte Beitrag stammt nicht von mir, sondern von der Forumadministration, die das gerne so hätte. Insofern musst Du Dir keine Gedanken über das "warum" machen.

Zitat von: holle75 am 19 Februar 2025, 11:15:10Der eine heißt zigbee, der andere mqtt. Mir gehts erstmal um wie bekomme ich zigbee in fhem (über mqtt).

Na dann ist doch mqtt eher der richtige Ort - Du bestätigst es ja gerade.

Zitat von: holle75 am 19 Februar 2025, 11:15:10Andererseits ist es mir egal, wo dieser Thread ist. Ich verschiebe ihn auch gerne, wenn du darauf bestehst.

Mir ist das wurscht, wo der Thread steht. Aber gemäß der Forumregeln und der schriftlich festgehaltenen/angepinnten Hinweise ist er halt hier an der falschen Stelle, wenn es Dir hauptsächlich um mqtt geht.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

holle75

Zitat von: betateilchen am 19 Februar 2025, 11:21:25Mir ist das wurscht, wo der Thread steht. Aber gemäß der Forumregeln und der schriftlich festgehaltenen/angepinnten Hinweise ist er halt hier an der falschen Stelle, wenn es Dir hauptsächlich um mqtt geht.


Mir eben auch. Komm, lassen wir das. Ich widme meine Zeit jetzt lieber deinen Informationen ;) vielen Dank dafür. Umfangreich und verständlich.

juergen012

Moin,
mein Einstieg in Zigbee war auch sehr "holperig". Nachdem ich Endlich zigbee2mqtt installiert bekam, wollte sich der Stick nicht verbinden. Ich habe dann sehr lange herumexperimentiert. Angefangen habe ich mit einem ConbeeII, dann ConbeeIII, Sonoff ZigbeeDogle Plus. Inzwischel läuft z2m in einem LXC unter Proxmox mit einem SMLIGHT SLZB-06. Wenn man sich an das WIKI von z2m hält, ist es eigenlich sehr leicht zu installieren.
https://www.zigbee2mqtt.io/guide/installation/01_linux.html
Wenn z2m läuft, dann in FHEM den MQTT-Server installieren...
Viel Erfolg!!
Gruß
Jürgen K.
Fhem unter Proxmox

Elektrolurch

Hallo,

bei mir sind vor einigen Wochen ein paar FS20 Bewegungsmelder über die Wupper gegangen und ich mußte mich auch mit zigbee beschäftigen.
Als Stick habe ich den SONOFF 3.0 gekauft und ein paar Aqara Bewegungsmelder.
Z2M habe ich noch auf eine alte HW (cubietruck) installiert, auf dem ansonsten auch noch für die Sprachsteuerung die homebridge läuft. Z2M habe ich  in einem docker laufen.
Sonoff Stick und die HW sind im Keller. Um die Signale über mehrere Stockwerke zu verteilen, habe ich die recht kostengünstigen Steckdosen von Sonoff genommen, die bauen automatisch ein mash-Netzwerk auf.
Man kann sich das dann auch in Z2M auf der GUI ansehen.
Z2M ist ein Client. Man braucht dann noch eine zentrale Instanz, die das verteilen von mqtt übernimmt. In fhem gibt es zwar auch einen broker, den zu verwenden, würde ich aber nicht empfehlen, wenn fhem mal etwas länger rechnen muss, ist bei mir um 24:00 Uhr der Fall (Heinzelmänchen), bricht die Verbindung zum broker ab. Daher habe ich auf dem Rechner, auf dem fhem läuft in einem docker container mosquito installiert.
Z2M muss man dann in der yaml - Datei noch erzählen, wo der der broker ist.
Zuerst lernt man dann ein Gerät in Z2M an, ändert den Namen suw.
Dann aktiviert man autocreate in fhem und schaltet das Gerät und schon ist es auch in fhem.
Am Anfang hat mich das wiki auch verwirrt... aber dann war es insgesamt doch einfacher als ich dachte und mittlerweile habe ich nicht nur ein Teil von  meinen FS20 ersetzt, sondern auch so feine Dinge wie Wasserwächter, Wetterstation von Aqara oder Glasbruchsensor installiert.
Da hat der Umstieg also auch noch einen technischen Mehrwert gehabt.
a) Alle Komponenten haben auch einen Rückkanal, man sieht also, ob sie geschaltet haben.
b) die, die am Strom hängen, verteilen auch das Netzwerk, so dass man getrost auf weitere  REpeater für hzigbee verzichten kann.

Viel Spaß

Elektrolurch
configDB und Windows befreite Zone!

holle75

Top. Danke für die weiteren Antworten. So langsam verstehe ich

.... und "den Weg weiterdenkend". Da will ich hin ...

- Zb im Büro entfernt vom Zuhause und fhem Server, stelle ich die og Box https://uzg.zig-star.com/product/ (über USB bestromt und via WLAN/Ethernet an den Router dort gehängt).

- Der Router ist via VPN mit meinem Heimnetz verbunden

- Die Box verbindet sich via VPN mit deinem zigbee2mqtt "Server" (hier fehlt mir die Begrifflichkeit) im Heimnetz, der zB auf dem selben raspi wie fhem läuft (oder eigenständiges Gerät). Falls eigenständiges Gerät, was würdet ihr als kleinstmögliches empfehlen? Will den sowieso ausufernden Fuhrpark so übersichtlich wie möglich halten. Noch einen Raspi? Auf dem selben Raspi wie fhem findet ihr nicht gut?

- in fhem läuft mqtt2-Server der den MQTT Verkehr auswertet.

- nicht zeitkritische zigbee devices (lasst es wenns hochkommt 10 Devices werden) verbinden sich über die Box im Büro via VPN, via zigbee2mqtt serverdevice (im Heimnetz), via MQTT mit fhem

hört sich für mich sexy an. Gangbar oder zu viele Umwege? Zu kompliziert, unsinnig? was meint ihr?

Beta-User

Zitatwas meint ihr?
Lass es!

Verstehe erst das (ZigBee-) System lokal, und binde dann das Büro als "autonomes System" ab (und ggf. in dein Haupt-FHEM ein).

Die weiteren Stichworte dazu lasse ich jetzt aber weg, das führt zu weit.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

Du willst von zuhause aus zigbee Geräte in Deinem Büro steuern?

Dann würde ich aber lieber zigbee2mqtt im Büro laufen lassen und per mqtt verbinden.

  • Also beispielsweise einen raspberrypi mit zigbee2mqtt und zigbee-Stick ins Büro stellen und mittels mqtt an einen mqtt-Server anbinden.
  • Dein FHEM zuhause an den gleichen mqtt-Server anbinden.

Schon hast Du die Verbindung von FHEM (zuhause) zu zigbee2mqtt (im Büro) hergestellt.

Für solche Zwecke habe ich einen mosquitto auf einem virtuellen Server bei Amazon Web Services in Irland laufen, der von überall aus dem Internet erreichbar ist. Darüber kommunizieren auch noch andere Systeme mit meinem FHEM, ohne dass ich mein FHEM aus dem Internet erreichbar machen müsste.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Zitat von: eisman am 19 Februar 2025, 10:41:43nein, bei deConz(phoscon) kommt man sehr schnell zum ziel! nur kann es nicht alles...
Für den TE ist deconz ggf. in der Tat eine Alternative, von daher könnte er auch einen Conbee (II oder III) besorgen - der "kann" mit beiden Lösungen.

Meine persönliche Einschätzung:
Die Einrichtung ist vielleicht geringfügig einfacher, das "tägliche Leben" und irgendwelche administrativen Tätigkeiten (deCONZ-GUI unter remoter ssh-X-window-session?!?) sind (teils deutlich) schwieriger.
Wenn man ausgereifte und gut bekannte Geräte hat, geht das (vielleicht auch als autonomes System mit Handy-App für's Büro), für mich war der (Rück-) Wechsel nach zigbee2mqtt der richtige Schritt.

(Das Büro würde ich auch per MQTT anbinden, aber mit einem _zusätzlichen_ MQTT-Server via Internet und MQTT_GENERIC_BRIDGE für den "zweiten MQTT-Pfad")...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

Zitat von: Beta-User am 19 Februar 2025, 13:01:26und MQTT_GENERIC_BRIDGE für den "zweiten MQTT-Pfad")...

Eine MQTT_GENERIC_BRIDGE ist m.E. für zigbee2mqtt komplett entbehrlich.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Zitat von: betateilchen am 19 Februar 2025, 13:05:11Eine MQTT_GENERIC_BRIDGE ist m.E. für zigbee2mqtt komplett entbehrlich.
Ja.

Vorausgesetzt, du hast eine 100% zuverlässige Verbindung zu deinem MQTT-Server im Internet.

Hat alles seine Vor- und Nachteile, daher hatte das hier geschrieben:
Zitat von: Beta-User am 19 Februar 2025, 12:22:53Die weiteren Stichworte dazu lasse ich jetzt aber weg, das führt zu weit.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

holle75

#23
Zitat von: Beta-User am 19 Februar 2025, 12:22:53Lass es!

Verstehe erst das (ZigBee-) System lokal, und binde dann das Büro als "autonomes System" ab (und ggf. in dein Haupt-FHEM ein).

Das wäre ja das Schöne an der Idee. IP´s bleiben alle gleich im VPN, ich kann alles zu Hause aufbauen und testen.

Ins Büro kommt dann das konfigurierte Kästchen (coordinator, gateway, whatever it is called) und die gepairten (wobei ich noch gar nicht weiß an welcher Stelle das pairing geschieht) Endgeräte. Das Kästchen muss ich dort nur noch an den Router anbinden.

Unterschied wäre der Datentransfer, anstatt schon MQTT, die Daten vom Kästchen an z2m (damit ist schon zigbee2mqtt gemeint?) "Server" im Heimnetz via VPN.

Als Vorteil könnte ich mir vorstellen, dass ich dann im Heimnetz den z2m "Server" laufen habe und Endgeräte (mit einer zweiten Box?) dann auch hier verbinden kann? Zigbee kann im Heimnetz interessant und langfristig mehr/größer werden, Büro werden 2- max 10 Devices sein.

Kann natürlich auch alles Quatsch sein, aber das ist der Vorteil eines Unwissenden ;)


und das macht auch unbedingt Sinn und ist auch das was @Beta-User wohl meint:

Zitat von: betateilchen am 19 Februar 2025, 12:28:26Dann würde ich aber lieber zigbee2mqtt im Büro laufen lassen und per mqtt verbinden.

    • Also beispielsweise einen raspberrypi mit zigbee2mqtt und zigbee-Stick ins Büro stellen und mittels mqtt an einen mqtt-Server anbinden.
    • Dein FHEM zuhause an den gleichen mqtt-Server anbinden.

Schon hast Du die Verbindung von FHEM (zuhause) zu zigbee2mqtt (im Büro) hergestellt.

.... bedeutet aber ein zusätzliches Gerät (Hardware für z2m) im Büro.

MQTT macht im Moment mqtt2-server in fhem.

Aber ja, wär dann auch kein viel größerer Aufwand. Allerdings sehe ich den Nachteil beim anderen Weg noch nicht so ganz. Einziger Unterschied welche Daten übers VPN müssen... vor z2m oder nach z2m. Die Menge sollte ähnlich sein.

Für den z2m "Server" fliegt jetzt wohl meine (zu) alte synology raus und so ein Ugreen Nas auf dem Docker laufen kann kommt rein. Wenigstens somit nur ein ersetztes, nicht zusätzliches Gerät. Wobei ich mir sogar den Schritt sparen könnte, wenn ich z2m mit auf den fhem-raspi packe. Warum genau ist das Mist? Zu viel Last?



betateilchen

Du hast das Funktionsprinzip offenbar immer noch nicht verstanden.
Und ich weiß nicht mehr, wie ich es Dir noch erklären soll.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

holle75

#25
Mmh, hattest du dir mal das Kästchen angeschaut? https://uzg.zig-star.com/product/

Habe ich es dann noch immer nicht verstanden?

Da dann die Docker Umsetzung als Beispiel -> https://www.youtube.com/watch?v=mGg_9FjDKHQ

EDIT: das Kästchen sehe ich als günstige Alternative zu zB https://www.amazon.de/LINEOPS-SLZB-06-funktioniert-Zigbee2MQTT-Assistant-Schwarz/dp/B0DGLZS7J6

betateilchen

Zitat von: holle75 am 19 Februar 2025, 15:52:49hattest du dir mal das Kästchen angeschaut?

Natürlich, aber es ist nicht das, was ich Dir für Dein Vorhaben raten würde.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

passibe

Zitat von: holle75 am 19 Februar 2025, 15:14:11Einziger Unterschied welche Daten übers VPN müssen... vor z2m oder nach z2m. Die Menge sollte ähnlich sein.
Ich verstehe den Gedanken, aber da sind unterschiedliche Protokolle im Spiel, weshalb das letztlich schon ein großer Unterschied ist.

Hast du z2m im Büro, sendest du MQTT über das VPN.
Hast du z2m daheim, sendest du serielle Daten über das VPN.

Das Problem ist, dass eine serielle Verbindung viel mehr Stabilität braucht und nicht dazu gedacht ist, über "weite Strecken" Daten auszutauschen. Anders als bei MQTT, das für einen solchen Datenaustausch gemacht ist, gibt es dort – vereinfacht gesprochen – keinen vernünftigen Umgang mit Paketverlust, usw.
Siehe zu allem hier: https://community.home-assistant.io/t/how-to-connect-zigbee-lan-coordinator-and-zha-via-wireguard-vpn/719057/5

Deshalb musst du in den sauren Apfel beißen und auch im Büro einen Raspberry o.ä. hinstellen, der dann z2m macht.

Ehrlicherweise würde ich dann aber ohnehin auch einfach ein zweites FHEM-System im Büro einrichten, so ein Raspi hat ja mehr als genug Rechenleistung. Dann funktioniert dort nämlich alles unabhängig vom Bestehen der VPN-Verbindung.

Kurz: Kauf dir einen zweiten Raspi o.ä., kauf dir einen günstigen USB-Dongle (das Sonoff Ding), stell beides ins Büro, installier FHEM und z2m, fertig.

(Noch was: Dass man für z2m irgendwie einen extra Computer braucht oder so und das nicht auf dem gleichen System wie FHEM laufen lassen soll, wie hier von manchen in den Raum gestellt (oder hab ich das falsch verstanden?), halte ich übrigens für maximalen Quatsch.)

holle75

#28
@passible. Auf den Punkt (wie du schon am Anfang schriebst) mit Erklärung warum meine Idee schlecht ist. vielen Dank.

So wirds dann wohl gemacht werden (müssen).

Ich danke euch

EDIT: noch als Info, warum zumindest der Ansatz nicht völlig abwegig war : https://smlight.tech/manual/slzb-06/guide/remote-vpn-conn/
Das hier habe ich nicht ganz durch und weiß nicht, ob es der selbe Ansatz ist -> https://community.home-assistant.io/t/two-zigbee-networks-joined-over-a-wireguard-vpn/584228



passibe

Ok interessant! Dann hätte ich vielleicht gar nicht so entmutigend sein sollen. Tatsächlich sind es ja auch TCP-Pakete ... also ja, könnte schon gut klappen.
Ausprobieren kannst du das natürlich sowieso, vor allem wenn da schon ein VPN läuft ist das ja keine große Sache.

Und ja, das ist beides mal der gleiche Ansatz. Gefühlt drehen sich aber 90% beider Tutorials einfach nur darum, WireGuard einzurichten. Wie gesagt, wenn da sowieso schon ein VPN (ohne nennenswerte Firewall) läuft, musst du eigentlich nichts anderes tun, als bei dir daheim auf deinem Raspberry zigbee2mqtt zu installieren und dort die IP-Adresse des Zigbee-Sticks aus dem Büro-Netzwerk eintragen.

Beta-User

Zitatzigbee2mqtt | Warum muss denn ein Einstieg immer so kompliziert sein
@holle75:

Nach etwas nachdenken über die "Büro-Frage": Vielleicht auch, weil du versuchst, gleich den 7. Schritt vor dem 1. zu machen und zu durchdenken?!?

Würde vorschlagen, hier erst mal nicht weiter "was geht denn ggf. noch"-Gedankenexperimente zu machen, sondern erst mal den Adapter und ein paar Testgeräte zu besorgen, und dann weiter zu machen, wenn dir klar ist, wie die Grundstruktur aufzubauen ist und "tickt".

Nur mal wieder meine 2ct.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

holle75

#31
Ihr beiden, ich werde jetzt den "klassischen Weg" gehen. Ins Büro kommt auch ein Raspi mit komplettem fhem. Es macht völlig Sinn das dort für die Zukunft, was auch immer noch kommen mag, autark zu halten. Wie ich MQTT/fhem (Büro/Home) verbinde wird dann die nächste Baustelle vor der ich mich eigentlich drücken wollte.

Wenn man z2m auf den selben Raspi packen kann, wird der Fuhrpark immerhin nicht größer.

Nochmal zum Wiki .... es ist mir bewußt, dass das alles ganz viel Arbeit ist. Jeder Wiki Autor hat vorher vielleicht schon x Stunden lang das zugehörige Modul programmiert, die eigentliche Sache kreiert, "dumme Fragen" beantwortet, einen Riesenbeitrag an die Community geleistet.... und ist in der Materie drinnen wie kein anderer. Das ist völlig unabhängig von fhem.

Mir fällt nur auf, mit jedem neuen "Teilbereich" der mich interessiert, dass ganz oft vergessen wird, dass jeder Neueinsteiger erstmal ein DAU ist.

Ich habe letzthin versucht die neue Batterie meiner Solaranlage über einen ESP32 in fhem einzubinden. Das ist so einfach, man glaubt es nicht. Trotzdem habe ich 3 Tage damit verbracht rauszufinden, wie man ESPhome ohne HA auf den ESP bekommt, welches Käbelchen an welchen Port muss, welche Hardware ich überhaupt brauche .... Am Ende wurde es dann kein einziges Kabel, nur der ESP und Bluetooth weil ausreichend funktional und einfach. Das hat erstmal nichts mit fhem zu tun, aber ist ein gutes Beispiel dafür, wie Entwickler ticken. Die Basics sind schon 300 Stunden entfernt.

Exkurs -> Zusammenfassung: https://forum.fhem.de/index.php?topic=137550.msg1316447#msg1316447 wenn man nach vorne blättert kann man die anfängliche Vezweiflung nachlesen ;)

Ein paar Sätze, eine "Beispiel-Verdrahtung" die den "Hardware-Fluss" erahnen lassen, kann sooooooo hilfreich sein. Primär muss ein Anfänger verstehen können, was arbeitet womit zusammen ... und dann können auch alle anfangen mitzudenken und zu verstehen.... und stellen weniger seltsame Fragen.

Dafür ist auch ein solcher Thread hilfreich. Entschuldigung es gedanklich dann im Lernen (dank eurer Antworten) verkompliziert zu haben.

Und vielleicht bin ich ein Einzelfall und allen sind die Basics immer schon klar.


juergen012

Moin,
mit einem SLZB-06 lässt sich eine VPN Verbindung mittels Wireguard einrichten..
Fhem unter Proxmox

holle75

#33
Zitat von: Beta-User am 20 Februar 2025, 08:44:56Nach etwas nachdenken über die "Büro-Frage": Vielleicht auch, weil du versuchst, gleich den 7. Schritt vor dem 1. zu machen und zu durchdenken?!?

.... ja und nein. Am Anfang habe ich das Hardware-Grundprinzip (was muss wie zusammengestöpselt werden und was läuft wo) nicht verstanden. Die VPN Idee im speziellen Fall kam dann mit dem Verstehen der Grundlagen auf (und ja, war undefiniert im Hinterkopf). Schadet ja nix gleich weiterzudenken.

Beta-User

Zitat von: holle75 am 20 Februar 2025, 12:19:08Schadet ja nix gleich weiterzudenken.
Schadet gar nicht, kann ich auch nur jedem empfehlen ;) .

Der Punkt ist: Wie wir u.a. an dem anderen Thread zu zigbee2mqtt gesehen haben, kann man an so vielen Stellen Probleme haben, über die man kaum mehr stolpert, wenn man es einmal erfolgreich eingerichtet hat.
Trotzdem sieht man dort: Wackelige MQTT-Server-Verbindungen und nicht (nachhaltig stehende) Verbindungen zum Coordinator schaffen massive Probleme. Ob das im jeweiligen Einzelfall tatsächlich auch ein Problem ist, kann man m.E. nur konkret am Einzelfall klären, und wenn du zwei (nicht per Mesh verbindbare) Orte hast, brauchst du nicht nur 2 St. Coordinator-Hardware, sondern auch 2 zigbee2mqtt-Instanzen.

Das sollte jetzt aber soweit klar sein, dass wir darüber nicht mehr weiter zu schreiben brauchen und du selbst entscheiden kannst, wo jeweils die Standorte der Teilsysteme sein sollen.

Zitat von: holle75 am 20 Februar 2025, 11:11:31Nochmal zum Wiki .... es ist mir bewußt, dass das alles ganz viel Arbeit ist. Jeder Wiki Autor hat vorher vielleicht schon x Stunden lang das zugehörige Modul programmiert, die eigentliche Sache kreiert, "dumme Fragen" beantwortet, einen Riesenbeitrag an die Community geleistet.... und ist in der Materie drinnen wie kein anderer. Das ist völlig unabhängig von fhem.
In dem konkreten Einstieg zu zigbee2mqtt ("schau im Wiki des Projekts, wie es geht!") gibt es NICHTS zu verbessern.

Über den Rest kann man diskutieren, und wir freuen uns alle, wenn du Lust hast, zum einen Mitzunotieren, worüber du (in der Rückschau: unnötigerweise) gestolpert bist und dann Vorschläge machst, wie es besser geht (oder es direkt änderst). Zu dem ganzen MQTT-Wiki-Zeug gibt es übrigens längere Threads hier im Forum, die v.a. von Usern geschrieben wurden...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

holle75

#35
Ich bastel mal und schreibe, wenns denn läuft, eine Zusammenfassung.

Bzgl Wiki, ja, wenn man die richtige Klickreihenfolge in den vielen Informationen (zigbee, mqtt, zigbee2mqtt, die Unterschiede oder Nichtunterschiede, das Zusammenspiel) beherzigt und versteht, ist hier ->

 https://www.zigbee2mqtt.io/guide/getting-started/

tatsächlich alles hardwareseitig und was läuft wo, erklärt. Irgendwie ist mir das in der anfänglich stundenlangen Recherche nicht untergekommen, oder ich habe den direkten Zusammenhang nicht verstanden. My bad.

Wenn du als Maintainer des Wikis damit glücklich bist ist alles ok. Das meine ich so.

Beta-User

Zitat von: holle75 am 20 Februar 2025, 13:29:56Wenn du als Maintainer des Wikis damit glücklich bist ist alles ok. Das meine ich so.
Glaube ich dir, dass das ernst gemeint ist, nur:

- ich bin nicht "Maintainer" des Wikis. Ich habe nur recht viel zusammengetragen, redigiert und hin- und her geschoben, was schon da war.
- "ich" bin (sehr) zufrieden mit dem, was da steht, wenn Neueinsteiger sich gut zurechtfinden. Das war und ist nicht immer einfach, und vermutlich gibt es auch nicht "den Königsweg", und manches ist halt einfach historisch gewachsen, mit dem heutigen Überblick und der heutigen Erfahrung würde ich persönlich vielleicht auch manches anders schreiben/machen/entscheiden/raten (wobei letzteres im Wiki eher verpönt ist)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

t.moori

Hallo zusammen,
vielen Dank für die interessanten Beiträge!
Ich möchte mich hier gerne mal einklinken. Zur Zeit betreibe ich einige Temperaturfühler (Technoline TX35 TX 35-IT, Temperatursender 868 MHz, LaCrosse) über JeeLink(USB) an einer Fhem-Instanz. Diese Verfahrensweise ist sehr Störanfällig, was mich dazu bewegt, ZigBee (ich bin ZigBee Anfänger) in Erwägung zu ziehen. Leider hatten meine Experimente mit ZigBee-Devices über eine HUE-Bridges anzubinden, keine Erfolge. Daher plane ich mittels eines Koordinator/Router SMLIGHT SLZB-06P10 über LAN/Wlan meine Temperaturwerte(ZigBee-Devices) einzusammeln und erhoffe mir eine höhere Stabilität und eine größere Reichweite.
Leider erschließt sich mir das Zusammenwirken der einzelnen Module, Router, Koordinator, zigbee2mqtt-Server/Client, Z2M, ZiggBee-Device, Fhem-Instanz nicht. Die einzelnen Beiträge habe ich gelesen, aber ein Blockschaltbild oder Flußdiagramm habe ich dazu nicht gefunden. Für mich stehen daher noch die Fragen, was benötige ich und wo installiere ich was?!
Für eure Tipps und Anregungen bedanke ich mich im Voraus! Bin gespannt!!

passibe

Zigbee-Gerät -> Zigbee-Stick -> zigbee2mqtt -> MQTT-Broker -> FHEM

  • Zigbee-Gerät = z.B. Temperatursensor
  • Zigbee-Stick = quasi eine Antenne mit USB/LAN-Anschluss
  • Zigbee2MQTT = "Verwalter und Dolmetscher", der die Geräte im Netzwerk verwaltet (anlernt, löscht, etc.) und die Signale, die über die Antenne empfangen werden, in MQTT-Nachrichten (d.h. Zahlen/Text) umwandelt
  • MQTT-Broker = übermittelt diese Nachrichten
  • FHEM = Macht irgendwas mit diesen Nachrichten

Der Ablauf dreht sich dann natürlich um, wenn du nicht nur Sensoren ausliest, sondern Geräte steuerst.

Zu deinem bisherigen Aufbau ändern sich zwei Dinge:
  • Die Antenne (jetzt: JeeLink) ist nicht mehr über USB angeschlossen, sondern, weil du den SLZB-06P10 ausgesucht hast, über LAN.
  • Es interpretiert nicht mehr FHEM direkt die Signale der Antenne (aktuell "spricht" FHEM ja direkt mit dem JeeLink), sondern es kommt Zigbee2MQTT dazwischen. Das übergibt dann über MQTT schon menschenlesbare Daten an FHEM.

Übrigens, der MQTT-Broker muss natürlich kein extra Programm wie z.B. mosquitto sein, sondern kann auch einfach als MQTT2_SERVER direkt in FHEM laufen.

tl;dr: Stick kaufen, zigbee2mqtt installieren, MQTT-Verbindung zu FHEM herstellen, Geräte anlernen, Geräte in FHEM anlegen (bzw. per autocreate anlegen lassen), fertig.

Beta-User

Zitat von: t.moori am 14 März 2025, 09:42:04erhoffe mir eine höhere Stabilität und eine größere Reichweite
ZigBee ist tendenziell eher von geringerer Reichweite als 868MHz-Geräte - ohne "Mesh" wirst du vermutlich das Teilziel "höhere Reichweite" nicht erreichen können!

Was "einfache" Raumsensoren für Temperatur und Luftfeuchtigkeit angeht, würde ich mal "Mija" und "Bluetooth" in den Raum werfen. Je nachdem, was du bereits an Equipment hast, brauchst du entweder keine Zusatzhardware, oder (ggf. verteilt!) ESP32-Boards mit passender firmware (würde als Suchwort mal "OpenMQTTGateway" in den Raum werfen, aber z.B. Tasmota ginge auch).
Die Dinger sind klein und unauffällig, haben (per Handy umgeflasht) eine "ewige" Batteriestandzeit und ein Display...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

eisman

1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian, Homematic,ZigBee         / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian,MQTT                               / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S

t.moori

Vielen Dank für die interessanten Antworten!
Hab mal das OpenMQTTGateway-Projekt überflogen. Das ist ja sehr universell einsetzbar.
Zu meinem Verständnis: die Bridge würde die BT-Informationen der Sensoren einsammeln und dann per mqtt über Lan an Fhem weitergeben.
Für meine Anwendung käme ja dann eine Theengs Bridge - ESP32 BLE MQTT gateway
(https://shop.theengs.io/products/theengs-bridge-esp32-ble-mqtt-gateway-with-ethernet-and-external-antenna)
und Xiaomi Mi Bluetooth Sensoren(AliE) in Frage.
Um mir ein Bild zu machen, werde ich wohl beide Varianten testen, ZigBee und BTLE.
Viele Grüße!!

Beta-User

#42
Na ja, bei mir laufen 2 GW - das sind aber simple ESP32-Dev-boards für ca. je 5 Euro...
Die LAN-Varianten kosten 2 € mehr... (ESP32-ETH).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

t.moori

@Beta-User
Das klingt ja nach einer sehr interessanten Alternative!
Bei Amazon sind die Bundle aber auch bei 30€?!
Wie oder mit welchem Image sind die geflasht?

t.moori

Hallo zusammen!
Heute mal der Stand meiner Testumgebung.
Zigbee-Endgeräte: Lidl-Steckdosenleiste + Maxcio Temp-und Luftfeuchtefühler ---> ZigbeeKoordinator SLZB-06P10 --->
Dockercontainer mosquitto_mqtt_1 + zigbee2mqtt ---> Fhem und MQTT2_Client:MQTT2_DEVICE:MQTT_GENERIC_BRIDGE
dann zwei MQTT2_Devices angelegt ---> Daten kommen im Fhem an. Was mich noch stört, ist das riesige Readings von Info. Im Device Steckdosenleiste finde ich keine Möglichkeit zum schalten der Steckdosen.
Wenn die Lieferung (Theengs Bridge - ESP32 BLE MQTT gateway und Xiaomi Mi Bluetooth Sensoren) ankommt, werde ich diese versuchen in Fhem einzubinden und dann einen Reichweite-Test machen.
Viele Grüße!!


Beta-User

Zitat von: t.moori am 24 März 2025, 08:34:24Heute mal der Stand meiner Testumgebung.
Zigbee-Endgeräte: Lidl-Steckdosenleiste + Maxcio Temp-und Luftfeuchtefühler ---> ZigbeeKoordinator SLZB-06P10 --->
Dockercontainer mosquitto_mqtt_1 + zigbee2mqtt ---> Fhem und MQTT2_Client:MQTT2_DEVICE:MQTT_GENERIC_BRIDGE
dann zwei MQTT2_Devices angelegt ---> Daten kommen im Fhem an. Was mich noch stört, ist das riesige Readings von Info. Im Device Steckdosenleiste finde ich keine Möglichkeit zum schalten der Steckdosen.
Das klingt nicht danach, als hättest du dich ans Wiki gehalten...

Du brauchst eigentlich weder mosquitto, noch MQTT2_CLIENT oder MQTT_GENERIC_BRIDGE.

Schalten geht nur mit setList, wie man die halbautomatisiert anlegt, steht im Wiki.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

t.moori

Zitat von: Beta-User am 24 März 2025, 10:49:21Das klingt nicht danach, als hättest du dich ans Wiki gehalten...
Hier meine Vorgehensweise:
https://www.zigbee2mqtt.io/guide/getting-started/ --->2.)Setup and start Zigbee2MQTT - 2.1) Configure Docker - 2.3) Start Zigbee2MQTT

https://wiki.fhem.de/wiki/MQTT --->Installation in FHEM Variante2(mittlere) Datenaustausch mit MQTT-Geräten, wenn MQTT2_CLIENT iVm. mosquitto als externem MQTT-Serverdienst verwendet wird

So dachte ich, zumal ich irgendwo gelesen habe man sollte von der Variante "MQTT2_Server" Abstand nehmen. Das ist wohl so nicht richtig??

Beta-User

#47
Zitat von: t.moori am 24 März 2025, 11:28:09So dachte ich, zumal ich irgendwo gelesen habe man sollte von der Variante "MQTT2_Server" Abstand nehmen. Das ist wohl so nicht richtig??
Wo steht denn sowas?

MQTT2_SERVER ist imo immer die "richtige" Wahl, wenn man MQTT praktisch nur zu FHEM-Zwecken einsetzen will.

(zigbee2mqtt ist in dieser "Denke" auch nur ein FHEM-Zweck).

Wichtig ist eigentlich nur, dass man den MQTT2_SERVER aktiviert hat, bevor man in zigbee2mqtt den MQTT-Server angeben muss - sonst startet z2m nicht.

Zu z2m ist klar, dass man (abgesehen von der Wahl des MQTT-Servers) die Installationsanleitung "von dort" verwenden muss; dass das geklappt hat, sieht man ja daran, dass Daten ankommen...

Zitat von: t.moori am 24 März 2025, 11:28:09https://wiki.fhem.de/wiki/MQTT --->Installation in FHEM Variante2(mittlere) Datenaustausch mit MQTT-Geräten, wenn MQTT2_CLIENT iVm. mosquitto als externem MQTT-Serverdienst verwendet wird
https://wiki.fhem.de/wiki/MQTT#Schnellstart_f%C3%BCr_Ungeduldige direkt überlesen, oder?!?
Und dann dieser Hinweis:
ZitatNeueinsteigern in das MQTT-Protokoll wird dringend empfohlen, MQTT2_SERVER, oder - sofern unbedingt ein externer Server zum Einsatz werden soll - MQTT2_CLIENT zu verwenden.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

t.moori

Da ich die Installationsanleitung w.o, angewendet habe, sind zwei Container entstanden, mosquitto_mqtt_1 und zigbee2mqtt. Wenn ich auf mosquitto verzichte, dann würde ich  zigbee2mqtt gern den Weg ohne Container gehen und dieses direkt auf der HW des Fhem installieren. Nur ist mir diese Vorgehensweise nicht ganz klar. Kannst Du mir hier unter die Arme greifen??? Ich scheue mich auch nicht nochmal von vorn zu beginnen!
Vielen Dank!!!

Beta-User

Zitat von: t.moori am 25 März 2025, 18:13:20Wenn ich auf mosquitto verzichte, dann würde ich  zigbee2mqtt gern den Weg ohne Container gehen und dieses direkt auf der HW des Fhem installieren.
M.E. macht es wenig Sinn zigbee2mqtt bare metal zu betreiben, wenn man mal verstanden hat, wie das mit docker funktioniert, und ich selbst habe das auch unter docker laufen.
Von daher kann ich da nicht groß weiter helfen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

t.moori

Hab Deinen Rat befolgt und einen Z2M Container, ohne mosquitto und eine Fhem-Instanz auf separater HW gebaut, um mal Mqtt-Client mit Mqtt-Server zu vergleichen.
Festgestellte Unterschiede:
Mqtt-Server legt Mqtt-Device an, legt aber alle Zustände in logging_message (z.B.z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/FK_1', payload '{"battery":100,"contact":true,"linkquality":153,"tamper":false}') ab.<=== Das ist falsch! Nach 10 Minuten warten wurde eine ellenlange Liste von Readings erzeugt!!
Mqtt-Server legt kein Mqtt-Device an, Handarbeit erforderlich. Nach publish'en, werden die Zustände in einzelnen Readings abgelegt(z.B. ***/state/battery":100, ***/state/contact":true, .....) --> gefällt mir besser, einfacher auszuwerten.
Was mir nicht gelungen ist, container mosquitto+zigbee2mqtt und zigbee2mqtt_fhem(für Mqtt-Server) gleichzeitig zu starten, die Ports habe ich unterschiedlich eingerichtet.
"Was tun sprach Zeus, ....."

Beta-User

Zitat von: t.moori am 27 März 2025, 15:27:51Hab Deinen Rat befolgt und einen Z2M Container, ohne mosquitto und eine Fhem-Instanz auf separater HW gebaut, um mal Mqtt-Client mit Mqtt-Server zu vergleichen.
Festgestellte Unterschiede:
Mqtt-Server legt Mqtt-Device an, legt aber alle Zustände in logging_message (z.B.z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/FK_1', payload '{"battery":100,"contact":true,"linkquality":153,"tamper":false}') ab.<=== Das ist falsch! Nach 10 Minuten warten wurde eine ellenlange Liste von Readings erzeugt!!
Mqtt-Server legt kein Mqtt-Device an, Handarbeit erforderlich. Nach publish'en, werden die Zustände in einzelnen Readings abgelegt(z.B. ***/state/battery":100, ***/state/contact":true, .....) --> gefällt mir besser, einfacher auszuwerten.
Was mir nicht gelungen ist, container mosquitto+zigbee2mqtt und zigbee2mqtt_fhem(für Mqtt-Server) gleichzeitig zu starten, die Ports habe ich unterschiedlich eingerichtet.
"Was tun sprach Zeus, ....."
Das kann ich alles (angefangen von sprachlichen Fragen und der Formatierung der "pseudo-Messages") nicht wirklich nachvollziehen:
das publish erfolgt bei zigbee2mqtt unabhängig davon, welcher Server-Typ das entgegennimmt.

"autocreate" wird per default nur bei MQTT2_SERVER aktiv, sobald das "bridge"-Device angelegt ist (und ggf. "autocreate" auch bei M2C aktiviert wurde), ist da aber eigentlich kein Unterschied mehr zwischen M2S und M2C...

Mehrere Server sind auch kein Problem, es sei denn, du hast einen anderen Zeus wie ich :P .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

t.moori

Zitat von: t.moori am 27 März 2025, 15:27:51Mqtt-Server legt Mqtt-Device an, legt aber alle Zustände in logging_message (z.B.z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/FK_1', payload '{"battery":100,"contact":true,"linkquality":153,"tamper":false}') ab.<=== Das ist falsch! Nach 10 Minuten warten wurde eine ellenlange Liste von Readings erzeugt!!
Hierzu möchte ich vermuten, dass zwischen den unterschiedlichen MQTT-Devices(Router, End-Device) das Anlegen der Readings unterschieden werden muss, da eine Verbindung zwischen den Routern besteht. Hat sich damit erledigt!
Zitat von: Beta-User am 28 März 2025, 10:54:30Mehrere Server sind auch kein Problem
Meinst Du auf den Fhem-Instanzen?

Beta-User

Zitat von: t.moori am 31 März 2025, 16:13:01Meinst Du auf den Fhem-Instanzen?
Eher: generell.
Ich habe - teils zum Testen - verschiedene mosquitto- und MQTT2_SERVER-Instanzen auf verschiedenen Rechnern am Laufen und kein Problem damit, weder auf meinem Haupt-FHEM, noch beim Testen. Man muss halt wissen, welcher Instanz für was gedacht ist und entsprechend adressieren....

Zitat von: t.moori am 31 März 2025, 16:13:01Hierzu möchte ich vermuten
Ich kann nicht mal "vermuten", weil mir die "Fehlermeldung" völlig unverstaändlich vorkommt. Aber schön, wenn sich das erledigt hat.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

t.moori

Hallo Beta-User!!
Ich bräuchte wiedermal Deine Hilfe.
Gestern ist die Theengs Bridge angekommen. Diese habe ich so konfiguriert, dass sie mit dem Docker mosquitto(IP:1883) kommuniziert. Wenn ich jetzt am Fhem_M2C show MQTT trafic einschalte sehe ich den gesamten trafic der Theengs Bridge im folgenden Format.
09:52:05.683 RCVD /mqtt_gw/BTtoMQTT/29DDB206196F {"id":"29:DD:B2:06:19:6F","rssi":-82}
09:52:05.768 RCVD /mqtt_gw/BTtoMQTT/5CC1D7A05F35 {"id":"5C:C1:D7:A0:5F:35","rssi":-89}
09:52:07.202 RCVD /mqtt_gw/BTtoMQTT/D8A35CB54D9D {"id":"D8:A3:5C:B5:4D:9D","name":"[TV] Samsung XXXXXX TV","rssi":-65}
09:52:07.824 RCVD /mqtt_gw/BTtoMQTT/A4C1381BA2EC {"id":"A4:C1:38:1B:A2:EC","name":"LYWSD03MMC","rssi":-47}
09:53:07.513 RCVD /mqtt_gw/SYStoMQTT {"uptime":7088,"version":"v1.7.5","rgbb":255,"disc":false,"ohdisc":false,"env":"theengs-bridge-v11","freemem":86728,"mqttp":"1883","mqtts":false,"msgprc":1190,"msgblck":0,"maxq":9,"minmem":18768,"tempc":50,"freestck":4532,"eth":false,"rssi":-47,"SSID":"fkw","BSSID":"FC:EC:DA:8D:5B:3C","ip":"192.168.178.34","mac":"D0:EF:76:23:D1:14","lowpowermode":-1,"modules":["BT"]}
09:53:07.565 RCVD /mqtt_gw/BTtoMQTT
{"bleconnect":false,"interval":55555,"adaptivescan":true,"intervalacts":55555,"intervalcnct":3600000,"scanduration":10000,"onlysensors":false,"randommacs":false,"hasspresence":false,"prestopic":"presence/","presuseuuid":false,"minrssi":-100,"extDecoderEnable":false,"extDecoderTopic":"undecoded","filterConnectable":false,"pubadvdata":false,"pubuuid4topic":false,"ignoreWBlist":false,"presenceawaytimer":120000,"movingtimer":60000,"forcepscn":false,"tskstck":2644,"crstck":3904,"enabled":true,"scnct":108}
09:53:10.959 RCVD /mqtt_gw/BTtoMQTT/8CEA4842F70F {"id":"8C:EA:48:42:F7:0F","rssi":-44} 

Wenn ich jetzt die Temp._Sensoren "Xiaomi Mi Bluetooth Sensoren"(LYWSD03MMC) handisch als Mqtt-Devices, z.B. "A4C1381BA2EC" anlege, bekomme ich keine Temp./Hum.-Daten.
In den Readings kommen viele ID's und deren rssi, sowie zum Device "A4C1381BA2EC" die Konfiguration der Theengs Bridge.
Muss ich die Xiaomi umflashen??
Kannst Du mir auf die Sprünge helfen?? Vielen Dank im Voraus!!!

betateilchen

Dieses konkrete Problem hat jetzt aber nichts mehr mit dem ursprünglichen Thema dieses Threads zu tun. Vielleicht wäre es sinnvoller, das in einen eigenen Thread zu packen.

Und es wäre schön, wenn Du mit code-Tags arbeiten würdest, wenn Du Logausgaben und ähnliches postest. Das erleichtert das Lesen ungemein.

Zitat von: t.moori am 02 April 2025, 10:36:02Wenn ich jetzt die Temp._Sensoren "Xiaomi Mi Bluetooth Sensoren"(LYWSD03MMC) handisch als Mqtt-Devices, z.B. "A4C1381BA2EC" anlege, bekomme ich keine Temp./Hum.-Daten.
In den Readings kommen viele ID's und deren rssi, sowie zum Device "A4C1381BA2EC" die Konfiguration der Theengs Bridge.

Aktuell sind in den von Dir geposteten Nachrichten keine Werte für Temp / Humi vorhanden.
Poste doch mal ein vollständiges list eines von Dir manuell angelegten Sensors.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Zitat von: betateilchen am 02 April 2025, 10:56:58Dieses konkrete Problem hat jetzt aber nichts mehr mit dem ursprünglichen Thema dieses Threads zu tun. Vielleicht wäre es sinnvoller, das in einen eigenen Thread zu packen.

Und es wäre schön, wenn Du mit code-Tags arbeiten würdest, wenn Du Logausgaben und ähnliches postest. Das erleichtert das Lesen ungemein.
Jedenfalls ich werde hier nichts mehr zu diesem ganz anderen Thema antworten, und auch mir würde eine "saubere Formatierung" (dann in dem neuen Thread) helfen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

t.moori

Ok und vielen Dank!
Ich werde das Problem unter "FHEM Forum FHEM - Hausautomations-Systeme MQTT" als neues Thema:
BT-Sensoren über Theengs Bridge in Fhem Mqtt2_Client einbinden, einstellen.

t.moori

@Beta-User
Wäre mein Thema besser hier zu zuordnen: OpenMQTTGateway support thread - im Speziellen: BT/BTLE ??

Beta-User

Zitat von: t.moori am 02 April 2025, 15:14:16@Beta-User
Wäre mein Thema besser hier zu zuordnen: OpenMQTTGateway support thread - im Speziellen: BT/BTLE ??
Mit direkter Verlinkung wäre das ggf. einfacher zu beantworten, aber eigene Threads sind doch kein Fehler oder gar Verbrechen?
Zumal du es anscheinend an der einen oder anderen Stelle "individuell" und "nochmal" wissen willst (warum macht man sich mit mosquitto unnötig das Leben schwer?!? Bitte Antwort ggf. dann im "eigenen" Thread!).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

Zitat von: Beta-User am 02 April 2025, 15:22:00warum macht man sich mit mosquitto unnötig das Leben schwer?

(offtopic)
Man macht sich mit mosquitto nicht das Leben schwer, sondern nach meinen Erfahrungen sehr viel leichter.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Zitat von: betateilchen am 02 April 2025, 15:23:34Man macht sich mit mosquitto nicht das Leben schwer, sondern nach meinen Erfahrungen sehr viel leichter.
OK, kann ich voll nachvollziehen.

Die Empfehlung gegen mosquitto gilt explizit nur, wenn man noch nicht weiß, wie MQTT an sich funktioniert, und was man _nicht_ tun sollte. Für unerfahrene Neu-Einsteiger - so jedenfalls meine bisherige Erfahrung - ist es schlicht eine zusätzliche Hürde, die man sich (in normalen FHEM-Installationen) sparen kann.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

t.moori