Artikelstruktur zu MQTT-Themen

[Beta-User]

Optisch so ähnlich (Beschriftungen sind immer noch zu ändern!), nur:

- Den MQTT-Teil im Server in die besagte alles inkludierende "Module/FHEM-Geräte-Box" und drehen, so dass das IO (MQTT2_CLIENT bzw. 00_MQTT.pm) rechts steht.
- die beiden anderen Blöcke übereinander, "non-MQTT" unten (da kann es auch andere Verbindungen zwischen FHEM und dieser Art Aktor/Sensor geben (für diese Grafik wäre es aber an sich egal)
Dazu evtl. den Mosquitto-Kasten innerhalb MQTT nach unten links, und Zigbee2mqtt rechts unten ("dahinter"), damit die Verbindung dann von dort aus nach unten in den "non-MQTT"-Kasten leichter darzustellen ist.

[DasQ]

so?

[Beta-User]

Noch nicht ganz ...

Anbei zwei Scans, Erläuterungen dazu:

Fang bitte erst mit der MQTT2_CLIENT-Version an (aber noch nicht (1) einarbeiten, da das der Punkt ist, der die 00-MQTT.pm-Version von der MQTT2_CLIENT-Version unterscheidet):

A Grundlayout:

- (3) Die Server-Box darf etwas kleiner werden, die MQTT-Box und die non-MQTT-Box jeweils größer, Mosquitto darf etwas weiter nach links, dafür die HUE-Bulb (4)/Zigbee-Boxen etwas nach rechts, die non-MQTT-Box sollte nicht in einer "Achtung"-Farbe gehalten sein (5). (Ja, es entsteht relativ viel freie Fläche in der non-MQTT-Box... Genau das ist beabsichtigt!)
-- "FHEM-Modul" sollte FHEM-Modules/FHEM-Devices belabelt werden (wenn Englisch, dann ganz, (6)) und die Farbgebung des Hintergrunds (zur Systemübersicht unverändert) das dunklere Blau bleiben (2).
-- Ob man eine Box für FHEM-Devices in der Modules-Box braucht? finde ich tendenziell nicht, aber wenn, gehört der Rahmen auch um MQTT2_CLIENT
- Die Farbgebung des Hintergrunds der einzelnen Devices würde ich einheitlich halten, aber nicht unbedingt weiß, optional einheitlich zu den Sensoren/Aktoren in den MQTT/non-MQTT-Boxen. "...CLIENT" wäre dabei ein Sonderfall, das könnte denselben Hintergrund haben wie die Mosquitto-Box (?)

Wenn das soweit ist, bitte melden. Was dann (u.A., zu MQTT_GENERIC_BRIDGE kommen wir später) als nächstes folgt:

B 00_MQTT.pm-Variante
Wenn wir das soweit haben, können wir die 00_MQTT.pm-Variante finalisieren. Da wäre nur die Überschrift zu ändern in "FHEM MQTT  communication (using 00_MQTT.pm)", das IO-Device mit "MQTT (00_MQTT.pm)" zu belabeln und statt MQTT2_DEVICE müßte MQTT_DEVICE stehen (2. Seite des pdf).

C Finalisieren der MQTT2_CLIENT-Variante:
- da fehlt dann noch das "spezielle" MQTT2_DEVICE "A_00_MQTT2_CLIENT_general_bridge"
-- Farbgebung wie das IO (MQTT2_CLIENT)
-- Anordnung: entweder über die anderen MQTT2_DEVICE-Geräte (Rest rutscht nach unten) oder untendrunter (im Moment fände ich drunter fast besser, im pdf ist es noch andersrum...

Hoffe, so kannst du mit meinen "handschriftlichen" Anmerkungen halbwegs was anfangen...

[DasQ]

schau dir des mal an, ich hab bei den grössen von den non-mqtt`s jetzt nix geändert, weil ichs nicht ganz verstanden hab. aber das kannst mir ja am neuen entwurf sagen.

[Beta-User]

 

Das ist ziemlich nahe an meinen Vorstellungen!

Funktional ist alles so i.O. (nur wie besprochen erst mal noch ohne das fehlende weitere Gerät betr. MQTT2_CLIENT).

Zu "Mosquitto":
- Die Box - könnte vielleicht etwas kleiner werden und zur unteren linken Ecke hin schrumpfen (30%-halbe Größe würde reichen);
- Dahinter ein Stern ("Mosquitto*"), unten dann eine Erläuterung (darf wieder sehr klein sein): "*or other external MQTT server software". Mosquitto ist eine Lösung unter vielen, vgl. z.B.http://www.steves-internet-guide.com/mqtt-hosting-brokers-and-servers/...
Wegen der Größe usw. nochmal der Versuch einer Erläuterung: Ich will diese Mosquitto-Box (deren Fläche) dann in dem MQTT2_SERVER-Schaubild dann einfach von diesem mit "vereinnahmen" lassen (Die Darstellung der Flächen soll also deutlich machen, dass funktional die Gleichung diese ist: MQTT2_CLIENT+Mosquitto=MQTT2_SERVER). Das würde übrigens noch einfacher gehen, wenn die MQTT2_CLIENT-Box auch nur so hoch wäre wie die Mosquitto-Box...
Ob das dann noch gut aussieht, mit den sehr geordneten Boxen rechts v. Mosquitto und links v. M2-C, ist eine andere Frage, aber das wäre m.E. nicht so tragisch. Geht ja vorrangig um's verstehen.

Zu non-MQTT:
In diese Box sollen dann im Rahmen der Erläuterung zu MQTT_GENERIC_BRIDGE weitere Aktor-Boxen rein, die dann aber keine Verbindung nach oben haben werden, sondern nach links zum (FHEM-) Server (ohne MQTT). Das werden 4 Stück werden (2xZWave (z1 und z2), 2x "XY Protocol Actor/Sensor x(1|2)"), mit je einem Interface pro Protokoll in der FHEM-Server-Box.
Ergo wäre es gut, die beiden vorhandenen "D2" und "D3" gleich etwas nach rechts zu verschieben (das können wir dann aber auch auf dem weiteren Schaubild tun).

[TomLee]

Hallo,

was ich mich Frage:

Code: [Auswählen]

Tasmota - Sonoff
sollte man nicht eher schreiben

Code: [Auswählen]

Tasmota / ESPEasy
     DEVICES
Weshalb ein Sonoff-Gerät erwähnen wenn doch eigentlich irgendein ESP-Gerät gemeint ist das Tasmotarisiert wurde.
Sonoff ist doch nur ein Hersteller.
Ja und ESPEasy wurde bisher ignoriert, warum ?

Gruß

Thomas

[DasQ]

Im Prinzip könnte mach schlicht ESPx-Controlled-device schreiben. Damit ist dann vom 8266-32 alles abgedeckt und die Dinger stecken ja in all diesen Produkten.

Sonoff, Shellys, espeasy, whatever... alles baut auf esp microcontroller auf

[Beta-User]

sollte man nicht eher schreiben

Code: [Auswählen]

Tasmota / ESPEasy
     DEVICES

Im Prinzip gebe ich dir recht...

Nachdem ich das jetzt nochmal hin und her betrachtet habe: Im Ergebnis neige ich dazu, nur noch "Tasmota" da reinzuschreiben, oder wir müssen noch (geringfügig) mehr ändern...

Richtig ist: sobald diese firmware auf einem Gerät läuft, ist es völlig egal, von welchem Hersteller die Hardware mal war (korrekte template-Einstellung (auf dem Gerät) vorausgesetzt).

Das gilt "im Prinzip" ganz genauso für ESPEasy. Nur: Historisch ist die Haupteinbindung hier nicht via MQTT, sondern mit den separaten Modulen. Man müßte also klarstellen, dass der MQTT-Mode gemeint ist (?). (Der läuft auch afaik nicht automatisch, sondern man muß das als user einstellen).
Dies gilt ähnlich auch für Shelly, nur dass dort der MQTT-Weg jedenfalls nicht "exotisch" ist (ca. 1:3, wenn man die FHEM-statistics Seite zugrunde legt)
Wenn, dann sollte man also zu ESPEasy und Shelly einen "*" setzten und in die MQTT-Box den Zusatz schreiben "* MQTT mode enabled".

Im Prinzip könnte mach schlicht ESPx device schreiben. Damit ist dann vom 8266-32 alles abgedeckt und Dinger stecken ja in den Produkten.

Auch richtig, aber vielleicht "zu technisch" gedacht. Schon jetzt kann man in Threads lesen "ich habe aber eine Blitzwolf/sonoff/Obi...", wenn man nach der Tasmota-Version fragt und "tele" im topicstring liest. Viele (lassen?) flashen und haben dann diese Feinheiten schon wieder vergessen.
Andererseits würde klarer, dass es weitere, ganz andere firmwares gibt, die was anderes tun (z.B. die MiLights steuern...)

Bin da aber recht leidenschaftslos, was das Thema angeht... Letztlich wird es nie perfekt sein, schon gleich nicht über der Zeit (gibt es nicht schon andere Hersteller/Chipsets, die von Tasmota unterstützt werden?).

[DasQ]

ja dann machen wir einen kasten als hardware variante, mit den gebräuchlisten hersteller (sonoff, shelly, obi, ...) und einen als software variante (espeasy, tasmota, milight, selfmade, ...)

[Beta-User]

Bitte aber nicht verkünsteln; ich fürchte, das wird sonst eher verwirrend (und MiLight war nur als Beispiel für dich als "Wissenden" gedacht, die Techik ist nichts, wofür man werben müßte...).

Dann eher eine Box (oder zwei nebeneinander/einen Stapel) mit langem Text über beide/alle wie "Device w/ firmwares in MQTT Mode, e.g. Tasmota, Shelly or ESPEasy"  (und zwei davon mit A und B belabelt).

[DasQ]

Das würde übrigens noch einfacher gehen, wenn die MQTT2_CLIENT-Box auch nur so hoch wäre wie die Mosquitto-Box...

schau dir nochmals das bild von meiner

« Antwort #65 am: 30 Juni 2019, 12:19:55 »

an. ich würde wieder auf diese anordnung der MQTT2_DEVICEs zurück gehen, das macht in dem oben genannten zusammenhang ein logisch besseres bild.

wär gut wenn wir das kurzfristig entscheiden, dann bau ich auf dem template auf.

[Beta-User]

Fand den Fluß von links nach rechts besser (bzw. zurück) und so ist die M2_S-Box optisch m.E. zu groß (muß das ggf. insgesamt überdenken, ob das Rausragen in die MQTT-Box rüber da Sinn macht; andererseits: s.u.). (Dass auch die alte Grafik "im Prinzip" gepaßt hat, hatte ich ja geschrieben ).

In jedem Fall sollte die "FHEM-Server-Box" unverändert bleiben, das mit dem veränderten Umlauf ist irgendwie "eckig". Mit der Vereinnahmung der mosquitto-Fläche sollte eine Art "Übergriffigkeit" angedeutet werden, die in der Sache sogar richtig ist: der M2_S muß nicht zwangsläufig jeden MQTT-Verkehr auch FHEM-intern weiterverarbeiten, sondern kann auch "ganz normal" eine Kommunikation zwischen anderen, externen MQTT-Clients ermöglichen, ohne dafür weitere M2-Devices anzulegen (=>autocreate aus).

Dass unten in der Module-Box ggf. Raum bleibt (oder leicht geschaffen werden kann), ist beabsichtigt. Wir müssen da später (bei M_G_B) 7 Geräte in einer bestimmten logischen Anordnung unterbringen...

[DasQ]

na ich hab jetzt so ein wenig das Problem, das ich erst zum „Schluss“ die maximal mögliche Fläche benutzen, aber jetzt schon abschätzen muss wieviel Platz das braucht. Von daher sollte man zunächst vielleicht das grundlayout so anpassen das auch alles rein passt. Verstehst wie ich mein?

Der mqtt2-Server gehört ja in den FHEM-Server Kasten mit rein. Logisch aber auch den Platz des externen mqtt einnimmt.  So quasi ein zwitter
Ich könnte natürlich, den mqtt2server so platzieren(ohne Transparents), das er im fhemserver Kasten ist und aber transparent in den mqtt überlappend hineinragt, oder gestrichelt ihn so verlängere.

[Beta-User]

na ich hab jetzt so ein wenig das Problem, das ich erst zum „Schluss“ die maximal mögliche Fläche benutzen, aber jetzt schon abschätzen muss wieviel Platz das braucht. Von daher sollte man zunächst vielleicht das grundlayout so anpassen das auch alles rein passt. Verstehst wie ich mein?

Also: Am meisten Einzelelemente wird das Schaubild zur Kombi MQTT2_CLIENT (M2C) mit MQTT_GENERIC_BRIDGE (MGB) enthalten.
Da fehlen im Vergleich zur in « Antwort #79 am: Gestern um 11:21:35 » enthaltenen Grafik folgende Elemente:
- ein (?) MQTT2_DEVICE (M2D) mit bridgeRegexp. Ich versuch's mal noch etwas näher zu erläutern: das steht eigentlich "quer" zu den übrigen M2D, oder noch genauer: eine beliebige Anzahl in beliebiger Kombination von M2D kann eine beliebige Zahl von bridgeRegex-Ausdrücken "attributiert" haben, die dann für "autocreate" als "Hilfsmittel" dienen, um das/die "richtige/n" "Abnehmer (M2D) für eine MQTT-Message von außen zu finden... Wenn du eine Idee hast, wie das/dieser Kauderwelsch grafisch umzusetzen ist: feel free . (Vielleicht: Stehend als eine Art (optisch im Hintergurnd stehender) Filter zwischen die M2D's und M2(C|D), teilweise von den M2D's überdeckt, Beschriftung dann M2D: bridgeRegexp, e.g. @A_00_MQTT2_CLIENT_general_bridge)? Das würde dann übrigens auch für M2S passen, allerdings würde ich dort den "e.g."-Teil weglassen, weil die Aufgabe des A_00... genau die ist, die (von Mosquitto "überschriebenen") ClientID's der eigentlichen, ursprünglichen Sender zu "erraten"; diese kennt M2S ja schon besser...).

- Unten:
Da fehlen wie gesagt 7 Elemente. Diese sind:
-- MGB
-- je zwei ZWave und x1 und x2 (als beliebiges Devices eines beliebigen Protokolls) und die beiden zugehörigen IO-Devices, also ZWDongle und XY-IO

Zur Anordnung: Der "Verarbeitungspfad" (beispielhaft für ZWave+M2C) geht von "non-MQTT" (=ZWave Z1) <=> ZWDongle <=> ZWave (FHEM-Device) <=> MGB <=> M2C <=> Mosquitto

Meine Idee war, das zum einen so zu gestalten, dass man einerseits sieht, dass evtl. noch was fehlt, andererseits nicht gleich auf der FHEM-Server-Seite sehr viel Platz zu reservieren für Themen, die ggf. nur noch von einem eher kleineren Teil der User effektiv benötigt werden. Man "braucht" MGB nur, wenn man genau diesen obigen Datenpfad haben will. Das war eigentlich mit '"reine" FHEM-Devices zu "verMQTTen" gemeint', das ich hier (sinngemäß) schon mehrfach geschrieben hatte

Der mqtt2-Server gehört ja in den FHEM-Server Kasten mit rein. Logisch aber auch den Platz des externen mqtt einnimmt.  So quasi ein zwitter
Ich könnte natürlich, den mqtt2server so platzieren(ohne Transparents), das er im fhemserver Kasten ist und aber transparent in den mqtt überlappend hineinragt, oder gestrichelt ihn so verlängere.

Zwitter finde ich eigentlich ganz passend . "Transparent reinragend" klingt jedenfalls ganz gut; wie gesagt/versucht anzudeuten: die Fläche für M2D sollte nicht gar zu umfangreich sein (auch Mosquitto ist ja "lightweight" , und muß in MQTT zwar einigermaßen Zentral, aber nicht zu groß dargestellt werden).

[DasQ]

weil mir der obere entwurf absolut nicht gefällt, hier mal ein neuer entwurf auf basis von HIER

die neue basis soll so allgemein gehalten als möglich. sprich ich stell mir vor das die erläuternden texte in die bildbeschreibung kommt.
so könnte man sich hersteller unabhänig auf die grafik beziehen. also je nach anwendungsfall, nutzt man die grafik im wiki und vergibt dann passend zu den "buchstaben" erläuterung zum hersteller.