Artikelstruktur zu MQTT-Themen

Beta-User · 12 Juli 2019, 13:07:16

Gefällt mir aus mehreren Gründen weniger, auch wenn ein paar Dinge gut sind (angefangen bei den Pikrogrammen, die sind hübsch!):

- Durch die andere Ausrichtung und die fehlende Verortung im FHEM-Serverbereich ist m.E. die gedankliche Brücke zum "allgemeinen Schaubild" praktisch nicht zu schlagen. Wir sollten daber bei der grundsätzlichen Ausrichtung von links nach rechts bleiben. Die Alternative wäre hier, deutlich zu vereinfachen, aber dann müßten z.B. die ganzen MQTT2_DEVICE-Piktogramme trotzdem in die "FHEM"-Box (wie auch immer die dann intern aussähe).

- Die gedankliche Brücke wird weiterhin dadurch durchbrochen, dass plötzlich ein neuer Block im FHEM-Server auftaucht (MQTT2_CLIENT). Da tue ich mich schwer, das zu erklären bzw. im Moment fehlt mir jede Idee dazu...

- (MQTT2_DEVICE-Piktogramme müssen (!) in die "FHEM"-Box, optimalerweise irgendwie in "Module", aber was dieses letztere Detail angeht, lasse ich dann ggf. mit mir reden, wenn jemand Argumente liefert; zum ersten Teil ist ein ominöser Kreispfeil jedenfalls keine hinreichende Klammer: Die MQTT2_DEVICE-Instanzen "leben" nur in FHEM, nicht außerhalb).

- D2-D5 müßten E1-E4 sein, oder übersehe ich was? (Oder anders gefragt: Wo ist der Bezug zu D1?)

- Der Bereich, der jetzt D3-D5 "oben" beheimatet, sollte benachbart sein zu einem anderen freien Bereich, der für "normale" Devices (nicht-MQTT) reserviert ist, die wir dann via MQTT_GENERIC_BRIDGE "verMQTTen", also wieder vom Server (IO-Bereich) aus gut zu erreichen ist...
- mosquitto ist mir persönlich optisch zu dominant. Wenn wir den optisch rausheben wollen (der MQTT-Server ist für MQTT schon zentral, keine Frage...), dann lieber durch Farbe.

Grundsätzlich: M.E. wollen wir vorrangig nicht MQTT als Technik erläutern, sondern die Frage, wie die Schnittstelle von FHEM zu MQTT aussieht. Und da ist FHEM genauso "groß" wie alles, was extern liegt (m.E.). Darüber können wir gerne diskutieren, ob die Haltung die richtige ist, ich versuche damit nur plastisch zu machen, was mir im Kopf dazu rumgeht...

DasQ · 12 Juli 2019, 13:55:46

also die bezeichnungen von D1 - Dx ist aus deinem entwurf!
dann zur ausrichtung sprechen eben mehr gründe für dieser ausrichtung als für eine von links nach rechts.

hochkant ist besser für mobil fähigkeit (mobile first)
flussdiagramme werden i.d.R. hochkant erstellt
logisch kann es auch von oben nach unten laufen, hauptsache hochkannt
es entsteht optisch der eindruck eines baumwuchs oder auf dem kopf stehende pyramide
im web wird eben rauf und runter gescrollt und nicht nach links und rechts

im alten entwurf stört mich am meisten, das die optischen übergänge nicht gegeben sind. und dabei erinner ich an dein wunsch den morquitto gegen den mqtt2 server/client auszutauschen, der dreisatz hat mich persönlch schier zur verzweiflung gebracht da des optisch einfach kacke ausschaut.

also wollte ich eine etwas luftigere, einfachere grafik gestalten. wir haben bei der systeminfo gesehn, das zuviel input eben genau das gegenteil erzeugt.(in mein augen ist die andere grafik kaput getuned).

und das allerwichtigste,

ES IST EIN ENTWURF .... also gesprächsgrundlage zum brainstormen.

wie man dann versucht plastisch rüber zu bringen wie was zusammen gehört steht auf einem anderen blatt. und ach ja dieses blatt wurde schon tausendfach beschrieben, spich es gibt sogar zum teil genormte symboliken/flussdiagramme/programmablaufplan/nassi-shneiderman/whatever da müssen wir also das rad nicht neu erfinden.

hält man sich nur ansatzweise an bestehende konvetionen, erreicht man in mein augen die breiteste masse und der rest kanns ergooglen.

kästelchen mit pfeilchen dazwischen ist jetzt nicht das grosse problem zu zeichnen, aber das es dann auch verstanden wird, das ist was anderes. (für mich war das die logische 1zu1 skizze aus dem bild in « Antwort #78 am: 03 Juli 2019, 11:21:35 »)

die grösse der kästen rührt einzig und allein daher, das man an einem kleinen kasten, weniger "verbindungen anbringen" kann, als an einen breiten. das hat nix mit "hervorheben" zu tun. das ist einzig und allein ein platzproblem und das wünsch ich mir, das man die optischen probleme des zeichners erkennt. ich kann die verbindungen auch bündeln, das schaut aber dann wieder *würg* aus

btw. war dann auch noch aus schludrigkeit (entwurf) ein fehler drin.

Beta-User · 12 Juli 2019, 14:43:19

OK, Entwurf, und ich will auch nicht ausschließen, dass das mit D1 auf meinem M..haufen gewachsen ist

... Ist/war trotzdem falsch/irreführend. Die Xn-Geräte gehören logisch zusammen, weil irgendwo eine Hardware oder ein Dienst eine "Bridge" zu vielen anderen macht (war übrigens auf dem zitierten und von mir als prizipiell i.O. gelobten Bild in #78 noch korrekt).

Das mit dem mobilen Scrollen leuchtet mir ein; damit müßten wir aber die Ausgangszusammensetzung innerhalb des FHEM-Server aufgeben - das finde ich aber nicht allzu schlimm. Dann sollten wir aber mit der Optik des ursprünglichen Bilds im Bereich "FHEM Server" ganz brechen, oder?

Ob man das als Flußdiagramm sehen will? Weiß nicht, es ist da nicht wirklich so, dass man "oben" was reingießt und "unten" kommt was raus, von daher finde ich hier "hin und her" passender, aber das ist zweitrangig...

OK ist auch, wenn die MQTT-Kommunikationspfeile dann bei der MQTT2_SERVER-Variante nicht mehr auf ein Objekt außerhalb des FHEM-Servers zeigen, sondern auf das entsprechende Modul-Objekt innerhalb des FHEM-Servers. Das "Raum greifen" war eine optische Idee (die wir im übrigen eigentlich sowieso ziemlich weitgehend wieder verworfen hatten), weil ohne das scheinbar nicht so recht klar war, welche Funktionen der MQTT2_SERVER hat, aber das geht auch anders darzustellen.

Was Konventionen usw. angeht, mache ich mich gerne schlau, wüßte dann aber gerne, wo ich eine für "Gelegenheitsuser" wie mich geeignete Intro dazu finde (Flußdiagramme mit visio habe ich schon erstellt, aber hier geht es m.E. um was anderes, da sollten eher die IT-üblichen Konventionen passen). Bis dato bin ich davon ausgegangen, dass wir über ein erweitertes "FHEM-Übersichts-Modell" reden, und da sollten die Dinge dort ihren entsprechenden Platz haben. (Ob der "normale User" sich das dann ergoogelt, wage ich mal zu bezweifeln; oft ist "man" ja schon nicht in der Lage, konkret gegebenen Links einfach mal zu folgen - wie jüngst "unser" Kandidat mit der GenericBridge, der partout den m.E. recht ordentlichen Beispiel-Thread nicht finden wollte...).

Und m.E. brauchen wir die Grafik hier auch nicht "kaputt" zu tunen. Hier haben wir es mit mehreren Grafiken zu tun, die aufeinander Bezug nehmen, aber nicht ganz gleich sein müssen. Es wäre mir auch lieber, wir könnten den relativ raumgreifenden Teil MQTT_GENERIC_BRIDGE erst mal weg lassen, und dann z.B. in einer auf die Basis aufbauenden Variante den "bekannten Rest" verkleinern und dadurch Raum schaffen, für den Rest würde eigentlich als "Actuators & Sensors" A, B und C1-C3 (eine typische Bridge wie zigbee2mqtt & 2 Zigbee-Geräte) reichen.

Nochmal: Der Vorschlag mit den Piktogrammen ist gut und schön plastisch, wegen mir müssen da keine konkreten Beispiele rein (bzw. nicht viele).

[Hier OT]
Wir können gerne nochmal den Versuch unternehmen, die andere Grafik auch zu entschlacken. Das gilt insbesondere, wenn das mit gängiger Symbolik ginge...
Aber solange es relativ konkret ist, was die "Actuators & Sensors" angeht, muß es auch dort eben akkurat passen/viele Details beinhalten.
[/OT]

DasQ · 12 Juli 2019, 14:47:16

du mir ist wurscht wie der server aussieht, hab da eh mit einem "server" pictogramm geliebäugelt, also eher so in richtung towerpc ... mal schaun, vielleicht bastel ich da was FHEM eigenes angelehnt an die "bestehende" server grafik.

und ich wollte eben genau von der systeminfo wieder ein wenig weg, weil weniger ist mehr. bissi bunt, dezente symbolik rest logik.

anbei bin ich über die FHEM internen svg-icons gestolpert und hab die dann gleich für unsere zwecke missbraucht.

Beta-User · 12 Juli 2019, 15:08:45

Ähm, V. 1_3 war mir irgendwie entgangen...

Ein Tower-PC Icon finde ich nicht unbedingt zwingend, da der FHEM-Server und der Mosquitto ja auf derselben Murmel hausen können.

Mal ausgehend von V. 1_3:

Unten eine Box mit dem FHEM-Pictogramm (gerne groß im Hintergrund) ohne Überschrift? Da sollte dann MQTT2_CLIENT oben drinstehen (als Box), aber nicht größer (eher kleiner) wie die mosquitto-Box darüber, und mit den "gekreisten Pictogrammen" in der FHEM-Box und dem Kreispfeil von und zur MQTT2_CLIENT-Box.

Als Idee (tb discussed): Unten drin dann noch eine "Frontend"-Box, die mit einem neuen Element darunter kommuniziert ("Browser")? Dann hätten wir den "üblichen Datenfluß aus Sicht des Anwenders"?

DasQ · 13 Juli 2019, 17:03:07

mt dem frontend und browser muss ich mal schaun ... bzw. brauch ich nen hit

Beta-User · 13 Juli 2019, 17:37:38

Sieht aufgeräumt aus

.

Oben ist es fast ok, aber alles, was "durch" D durchgeht, sollte auch einen "D"-Kenner haben, nicht "E" (in der vorherigen gab es ein "danebenstehendes" "D1"-Gerät, das war der Punkt, auf den ich dort hinweisen wollte...).
Dann ist nicht ganz klar, warum sich die MQTT-Kommunikationslinien von B und C vereinen. Sollte m.E. so sein, dass da jedes "für sich" kommuniziert.

Unten würde ich die FHEM-Box wirklich groß machen (darf optisch weiter so durchscheinend sein). Oder gibt es einen "allgemeinen" Grund, warum die "virtuellen" Geräte außerhalb sein sollten?

(Wenn die "Browser"-Kommunikation da irgendwie noch zwischen den MQTT2_DEVICE-Icons durchgeht (zum FHEM-Server), wird das sonst verwirrend, oder?)

DasQ · 13 Juli 2019, 20:00:11

so in etwa?

und achja, bevor fragen auftauchen, die fehlenden "leitungen" fehlen bewusst.

Beta-User · 13 Juli 2019, 20:19:18

Kommt ziemlich gut hin.

Dein Eindruck?

DasQ · 15 Juli 2019, 19:43:02

also von mir aus immer super

, das müssen andere augen beurteilen, da bin ich voll und ganz kritik fähig.

für das bündeln der "leitungen" im mqtt2_server wär ich für ein vorschlag offen.

Beta-User · 15 Juli 2019, 21:17:18

Hmm, also:

- weiß noch nicht, ob ich im MQTT-Bereich ein "B"-Device mit nur einer Verbindung so top finde. Kann es zwar geben, ist aber die Ausnahme; wenn, paßt das Reglersymbol m.E. nicht, das wäre dann ein reiner Sensor, der nur publisht.

- D4 (=Lampe) oben wäre m.E. typischerweise bei zigbee auch ein bidirektionales Device

- Die Boxen um Frontend und MQTT(2)-Client/Server müssen m.E. auch nicht sein. Nur die Rahmenlinien aller Devices bzw. Funktionsblöcke im FHEM-Bereich sollten einheitlich sein (die inneren Boxen sind derzeit noch ohne abgerundete Ecken, und ob es dieselbe Farbe ist, kann ich nicht richtig erkennen).

- Was die Kommunikationspfeile zu MQTT2_SERVER angeht, fände ich mehrere (hier: 4) nicht schlecht. Tatsächlich wird ja für jede Verbindung eine (temporäre) Instanz aufgemacht (was den einen oder anderen auch schon verwirrt hat...), das wäre dann leichter zu erläutern (aber zugegebenermaßen optisch unübersichtlicher). Und eine Direktverbindung zwischen MQTT-Devices (die nicht zugleich Server sind) gibt es nicht; das wäre dann auch klarer. Bei insgesamt 4 Verbindungen geht das aber m.E. grade noch (auf eines der Devices A/B/C könnten notfalls wir auch verzichten, dto. auf 2 der 4 zigbee-"Satelliten").

DasQ · 16 Juli 2019, 17:42:34

ich hab jetzt nicht alle änderungen von dir eingebaut um weiter zu layouten

schau dir des mal an

Beta-User · 16 Juli 2019, 17:54:44

Soweit ok, bis auf die Verbindungen oben im zigbee-Bereich.

Was das "Frontend" angeht: Das muß nicht ganz so groß sein (? darf schon, bin da unentschlossen), aber m.E. sollte etwas Platz zwischen den MQTT2_DEVICE-Icons und dem Frontend sein. Beides ist zwar "in FHEM", hat aber darüber hinaus eigentlich keine engere Verbindung; das Frontend ist halt eine Möglichkeit (unter vielen), Anweisungen an ein MQTT2_DEVICE-Gerät zu geben, mehr aber auch nicht...
Daneben könnte (bitte nur den Gedanken mitdenken, aber nicht zeichnen...) auch Alexa oder sonst eine Sprachsteuerung stehen (mit "Manipulationspfeil") oder ein internes "at" ganz ohne "Verbindung nach außen".

DasQ · 18 Juli 2019, 11:23:12

Beta-User · 18 Juli 2019, 11:44:24

Für mich passen die beiden soweit. Wie soll ich den fragenden Smiley deuten? Fragen von deiner Seite dazu?

Was da in der MQTT2_CLIENT-Fassung nicht abgebildet ist, ist das A_00...MQTT2_DEVICE. Stelle mal zur Diskussion, ob man nicht "irgendein" Element an den linken Pfeil von MQTT2_CLIENT zu den Devices anfügt, oder einen (klein gehaltenen) Text (z.B.: "optional: bridgeRegexp"). Würde dann auch zu MQTT2_SERVER passen, nur ist es da nicht sooo essentiell und mit einem konkreten template-Namen verbunden. Ist zwar klar, dass das keiner auf das erste Mal versteht, aber so kann man es wenigstens "lokalisieren"?

Was 00_MQTT.pm angeht: Das wäre vom Layout her (ohne bridgeRegexp-Zusätze!) identisch zu der jetzigen Fassung für MQTT2_CLIENT, nur sollte unter "MQTT" (das MQTT2_CLIENT ersetzt) ein (klein gehaltener) Klammerzusatz mit dem vollen Modulnamen sein, um Verwirrungen möglichst vorzubeugen. (Und die Devices sind dann von einem anderen TYPE => MQTT_DEVICE).