Überarbeitung "Systemübersicht"

[Prof. Dr. Peter Henning]

Na, dann lasst mich mal meinen Senf aus 45 Jahren Lehre dazugeben:

- Wer ist die Zielgruppe? Anfänger, oder eher Experten?
- Was soll vermittelt werden? Vielfalt? Oder Details, etwa, dass KNX mit einem TUL zu machen ist?

Im Moment ist das Bild jedenfalls für Experten nicht detailliert genug (siehe Shelly/ESP), und für Anfänger viel zu überdetailliert (wieso gibt es zwei Wege für 1-Wire?).

Statt der 35 Boxen untereinander sollte man "Vielfalt" durch gestapelte Kästen (nennt man 2,5-dimensional) andeuten, und nur EIN Beispiel drin lassen. Dann zu jedem Protokoll Text und separates Bild.

LG

pah

(Etwa so - ein Bild aus dem genannten Buch)

[Wernieman]

Zustimmung ...

[Beta-User]

Also nochmal zurück auf Anfang...

Der Artikel war "schon immer" prominent auf der Hauptseite verlinkt, gehört also zu den Grundlagendokumenten. Zielgruppe ist daher erst mal jeder, der sich irgendwie in FHEM "einlesen" will. Wenn man "Anfänger" so verstehen will, würde ich sagen, das ist die Zielgruppe. Dazu kommen dann ggf. die, die nach dem Einstieg nochmal wiederkommen, um dann etwas systematischer in die tieferen Ebenen einzusteigen.

Paßt das für Euch als Zielgruppenbeschreibung?
Damit ist aber leider noch wenig darüber gesagt, welchen Kenntnislevel man eigentlich voraussetzen sollte; da stellen wir fest: sehr unterschiedlich, was Neuanmelder im Forum so fragen...

Tendenziell wäre es wünschenswert, auch die Leute "abzuholen", die sich einfach mal einen Shelly bestellt haben, weil ihnen jemand zugerufen hat, das sei ein passabler Einstieg (es sei betont: das ist ausnahmsweise nicht besonders ironisch gemeint, das ist auch nach meiner Meinung ok, um erst mal zu lernen...).




Noch was grundsätzlicheres:

Der "Anfänger in o.g. Sinn findet auf der Hauptseite u.A. "das pdf" (das eigentlich renovierungsbedürftig ist, oder für das man einen Ersatz bräuchte, um einen dem heutigen Stand der Möglichkeiten entsprechenden Einstieg zu bieten), und weiteres Material.

Vielleicht sollte man auch darüber nochmal nachdenken, ob es nicht sinnvoll wäre, deutlicher unterschiedlichere Level zu addressieren (einige von den kompletten Noobs scheinen die einfache Tatsache zu verdrängen, dass man Betriebssysteme updaten muß, GPIO-Spielereien am PI konfigurieren, wenn man sowas haben will, was aber in der nächsten Revision eines bestimmten Boards/OS dann ggf. wieder ganz anders aussieht usw. Der "Experte" wird lachen, wenn man dazu was schreibt, aber wir haben auch diese "Interessengruppe" (von "Zielgruppe" mag ich nicht reden, habe meine Zweifel, ob (u.a.) FHEM für diesen potentiellen Nutzerkreis überhaupt das richtige ist)).


Back to topic:

Wie sollte das dann konkret aussehen? Wenn wir zum Ausgangspunkt (https://wiki.fhem.de/w/images/archive/a/ab/20190710141010%21System%C3%BCbersicht.png) zurückgehen:

Besteht denn Einigkeit, dass
- die Zahl der Elemente darauf an sich ok wäre?
- Die Grundsttruktur paßt?

Da ist/war manches konkrete "Material" drin, was m.E. einfach nicht mehr zeitgemäß ist bzw. irgendwie zufällig da steht (Arduino...). Für eine reine Prinzipdarstellung bräuchte man eigentlich statt der oberen drei Boxen in "Interfaces" nur einen "Stapel", aber mit welchem allgemeingültigen Label?!?
Dafür dann noch eine Box für "Herstellergeräte" (Label: tbd) wie die HUE Bridge, und statt "Ardiuno" stünde da MQTT (mit einem Pfeil auch zu den (TCP/)IP-Komponenten)?

[DasQ]

Also ganz ehrlich, ich find keine der Grafiken aussagekräftig.

Irgendwo wird's immer sehr künstlich, bzw. Zu theoretisch.
Systemübersicht sagt mir, wie was wo grob zusammenhängt. Mehr auch nicht. Wenn ich hier die Argumente hör in der einen speziellen Konstellation und irgendwie sowieso detailliert auf ein einziges Problem abdriftet, ist das in einer ,,allgemein Systemübersicht" 2much.

Jetzt ist die Frage ob man den Prozess besser mehr variabel gestaltet und nur auch verschiedenste Kommunikations.- und Funktionsprinzipe beschränkt und sich dann im Einzelfall darauf bezieht (andere Grafik mit den Buchstaben)

[Prof. Dr. Peter Henning]

ich find keine der Grafiken aussagekräftig

Macht nichts - aber der Autor, und mit hoher Wahrscheinlichkeit auch die Leser 

LG

pah

[DasQ]

Was ja jetzt eher hypothetisch ist ... er hätte ja kaum den Thread und somit die Änderung der Grafik angestoßen, wenn ihm die alte gefallen hätte. Sie ist gelindegesagt veraltet.

Bei deiner Grafik Steig ich garnicht durch. Das erklärt wohl im Ansatz ,,einen" Zusammenhang ... lässt aber auch extrem viel Interpretationsspielraum.

Die Frage bleibt, was will man eigentlich.

[Beta-User]

Bitte unterscheiden zwischen "gefallen" und veraltet. Ich habe die Diskussion angestoßen, weil ich sie veraltet fand, v.a., was die genannten Module angeht.

"An sich" fand ich auch die alte Grafik dahingehend völlig ok, als grundlegende Mechanismen darauf abgebildet waren (die Wahrheit iegt im Auge des Betrachters, das "sieht" evtl. jeder etwas anders...).

M.E. ist es weiter berechtigt, über den Kompromiß (in seiner jetzigen Fassung) zu diskutieren, siehe:

Nachdem @DasQ sich die Mühe gemacht hat, das neu zu machen, will ich die Änderungen der Grafik zunächst mal zur Diskussion stellen, überpinselter scan daher im Anhang. Ein paar Anmerkungen dazu:
- Vorneweg Sorry, dass es etwas umfangreicher geworden ist; das birgt immer das Risiko, dass die prinzipielle Aussage leidet; ob der Kompromiß ok ist, stelle ich ausdrücklich zur Diskussion durch "Wissende" [...]
- Zum einen sollten aktuelle (und ggf. auch empfehlenswerte) Module Verwendung finden; damit ist FHZ m.E. überholt;
- immer häufiger finden sich alternative Wege [...]

Ich habe ausdrücklich kein Problem damit, das ganze nochmal grundlegend neu - und ggf. auch ganz anders - zu machen. Im Moment tendiere ich stark zum Versuch, das mal ganz ohne Nennung konkreter Module anzugehen.

Dann würde sich die "rechte Seite" vielleicht beschränken auf:

"Interface" => "Dongle", "Manufacturer's box" und ("direct communication via IP Protocoll (TCP/IP,  MQTT)")
"Components" => "all type of sensor and/or actuator hardware, e.g.: (2,5d-Box)"

Ob man dann überhaupt noch verschiedene Pfeile zwischen "Interface" und "Components" macht, wäre die Frage; hier könnte man auch einfach "Physical Transport Layer + Protocol" reinschreiben?

Kann auch völlig verkehrt sein, vielleicht muß man das auch mal auf sich wirken lassen; die Idee will mir auch nicht aus dem Kopf, das irgendwie "kugelig" zu gestalten.
(Ihr kenn ja meine Malkünste, "notfalls" auch das...)

[DasQ]

man kann das natürlich auch in ein mindemap packen. das kommt wohl deiner kugel am nächsten

[Beta-User]

Mindmap müßte man sich ansehen, habe damit keine großen Erfahrungen. Was ich in die Richtung bisher gesehen habe, war eher unübersichtlich, aber das muß nichts heißen.

Vielleicht noch eine Sache: In den MQTT-Grafiken haben wir viele Icons verwendet, das ist eigentlich ziemlich plastisch. Als Beispiel mal: https://wiki.fhem.de/wiki/Datei:Mqtt2_client_v_extern_server.png (OT@DasQ: Könntest du da bitte die 4-fach-Verbindung zwischen MQTT2_CLIENT und dem mosquitto auch noch auf eine reduzieren (wie auf dem folgenden für 00_MQTT.pm))

Die Idee wäre: Oben ein "gestuftes Dreieck" mit "Components: Sensors&Actuators", z.B.
- links bis an die "Server"-Box (dafür müßten wir uns ggf. noch was überlegen, da gehört eigentlich ein nach links (?) offener "Server-Hardware"-Kasten drumrum), Kommunikation via TCP/IP andeuten;- in der Mitte ein "USB-Dongle-Symbol" (2.5D) an die Hardware/Server, darüber dann weitere 2.5D-Sensoren/Aktoren in das "Dreieck", Kommunikation über "Transport Layer + Protocol";- Rechts dann zwischen "Server" und "Sensors&Actuators" dann eine 2.5D-Box mit "Manufacturer Bridge", Kommunikation nach oben mit "Transport Layer + Protocol", nach unten mit "TCP/IP"?

Nach rechts hin könnte man das Bild dann erweitern um die Elemente ("Wolke", die heute in der Systemübersicht links oben sind)? Oder "Mitte" und "Links" tauschen, dann hätte man alle TCP/IP-Dinge beieinander und könnte die "Wolke" als verbindendes Element nutzen?

Hmm, schwierig, aber vielleicht "ohne viele Worte" erst mal besser zu verstehen?

[DasQ]

Du kein ding  hab grad nur den Kopf mit was anderem voll (räumungsklage), aber sobald ich inspirierativ wieder etwas besser grad aus seh, setzt ich dir das umgehend um.

[Prof. Dr. Peter Henning]

MindMaps dienen dazu, unstrukturierte Daten (etwa eine Diskussion) in konzeptionelle hierarchische Zusammenhänge zu bringen - aber nicht zur Visualisierung technischer Gegebenheiten.
Insofern ist die vorgetragene Idee, vorsichtig gesagt, nicht sinnvoll.

Im Übrigen noch einmal: Was soll eigentlich erklärt werden?

FHEM? Dann sollten bitte Hinweise auf einzelne Protokolle und Interfaces unterbleiben, und - so wie in meinem Beispiel - nur die 3 Möglichkeiten Funk, TCP/IP und Draht genannt werden.

Oder tatsächlich viele (oder gar alle) Protokolle und Systeme? Dann sollte es aber bitte eine logische Ordnung geben, man kann nicht die Vielzahl der über TCP/IP angekoppelten Systeme gleichsetzen mit dem einen HomeMatic-Interface.

LG

pah

[DasQ]

aber nicht zur Visualisierung technischer Gegebenheiten.

und warum nicht?

[Prof. Dr. Peter Henning]

Weil technische Gegebenheiten keine hierarchische (baumähnliche) Struktur aufweisen und unterschiedliche Klassen von Links (Kanten von Graphen) benötigen. MindMaps kennen nur eine Klasse von Links.

LG

pah

[Beta-User]

Im Übrigen noch einmal: Was soll eigentlich erklärt werden?

Das ist eine gute Frage, und ich komme immer mehr dahin, dass wir eine "andere" Grafik brauchen. Ich werde vermutlich selbst mal einen Versuch unternehmen, meine Gedanken dazu sind allerdings noch nicht ausgegoren... => Etwas Geduld .