Überarbeitung "Systemübersicht"

[Beta-User]

Danke für die Rückmeldungen.

@krikan: Manches, was ich schon geschrieben habe, war durchaus ein Schnellschuß , nur in der Regel nicht im Wiki zu zentralen Dingen, da bin ich "etwas" vorsichtiger...

@Wernieman
Das "Wunderding" Dummy will ich lieber nicht anfassen, da schwirren nach meinem Geschmack schon zu viele rum . Zumal gerade dieses Modul nicht "von allein" irgendwas macht.

Der Eindruck, es sei genug drauf (und implizit: lieber eher noch was weglassen, als noch was dazupacken (das kann man dann ggf. bei dem jeweiligen Detailartikel machen...)) ist eine wichtige Rückmeldung, Danke auch dafür!

Interessiert hätte mich aber wirklich eine detaillierte Rückmeldung zur Frage, wie man am besten die "Überlappung/Wechselwirkung zwischen "Interface" und "Server"" ausgestaltet.

Konkret schwirrt mir grade folgendes im Kopf rum:
- Da irgendwas zu überlappen, ist eine Frickelei, wenn man es "genau" haben will
- An sich "docken" die IO's doch einfach an den Server an, oder? Von daher wäre es für mich ok, wenn die beiden IO-Kästen (bzw. deren Rahmen) den "Server"-Rahmen schlicht berühren würden (im Sinne einer nicht näher spezifizierten Verbindung)...
=> "Server-Kasten" rechts etwas schmaler (damit der Rand links neben Konfiguration gleich groß wird wie rechts neben "Module", dann "Nativ" und "Externe" andocken und den Rahmen jeweils so, dass die ganzen Boxen darin sauber in der Mitte übereinander sind.

Das hier wird vermutlich zu viel (und auch verwirrend):
Noch die beiden "Interface" Blöcke in der Mitte so auseinanderziehen, dass auch ein TCP/IP-Block dazwischenpaßt, der eine direkte Verbindung rein nach "Komponenten" bekommt (Shelly mit Shelly.pm, HTTPMOD)?

Aber in dem Zusammenhang: die Pfeilüberschneidungen zwischen "Interface" und "Komponente" könnte man etwas entzerren, wenn man ZWave direkt unterhalb von SlowRF ansiedelt (@DasQ: das wäre klasse; und PeMue's Vorschläge passen selbstredend auch).

[ph1959de]

... und werte das bisherige Schweigen mal wieder als "mach ruhig"...

Diese Einschätzung meiner Haltung stimmt zu 100% ... hab sowohl den Thread als auch die bisherigen Wiki-Änderungen beobachtet - und hätte mich gemeldet, wenn's mir in eine falsche Richtung gelaufen wäre.

Also: einfach weiter so. Freut mich, dass die Systemübersicht aktiv weiterentwickelt und aktualisiert wird (war einer meiner ersten umfangreicheren Beiträge zu FHEM - lang ist's her).

Peter

[DasQ]

Sobald ich bissi Luft hab, Bau ich die erste finale Version.

Im Augenblick schmilze ich nur 

@Beta-User:

Aktuell von mir auch keine weiteren Anmerkungen. Mann könnte nur mit einem "Dummy" noch zeigen, das es noch vieieiel mehr gibt, was FHEM steuern (könnte).

Es soll bekanntlich "nur" eine Übersicht sein und da finde ich das jetzige Diagramm scho0n sehr ... gefüllt.

Mir schwägt da ne zweite Grafik im Hinterkopf. Wo dann auch ein wenig das nicetohave und wtf Features von FHEM etwas mehr in Vordergrund kommt.
Von Dummy, doif, presence, Pollen, Wetter, Kalender und was sonst noch hervorhebenswert ist.
Das aber in nem eigenen Thread.

[Wernieman]

Ich meinte mit Dummy nicht das Dummy Modul ... sondern z.B. ein Leeres Kästchen mit "..." um zu zeigen, das vieles eben nicht im Diagramm ist.

Dann kann man eventuell problembehaftete Teile im Diagramm auch weglassen ...

Wie ich schon gesagt hatte (und Du  auch verstanden hast). Weniger ist manchmal mehr ...

[Beta-User]

@Peter: Ausdrückliches Danke für den Artikel, mir hat der immer mal wieder sehr geholfen und als Referenz zum Verlinken aus dem Forum usw. gedient!

Die Idee, klarer rauszuarbeiten, dass das nur Beispiele sind, finde ich gut, weitere grafische Elemente eher nicht. Als Minimallösung je ein ", z.B.:" hinter "Intern/USB/UART" und "Soft-/Hardware" und in den "Komponenten"-Kasten oben?

Denn weglassen: Wenn ja, was? (Am ehesten SlowRF? Ist aber (neben MQTT/Shelly/ESPEasy) die günstigste Variante...)
HM/HM-IP sollte man drin lassen (warum hatte ich schon erläutert), aber es gehört m.E. mind. noch ein zweites vergleichbares System rein, daher ZWave (oder von mir aus auch EnOcean). Meine Befürchtung: Andernfalls entsteht wieder der Eindruck, dass man am besten CUL+HM nutzt (einer der vermuteten Effekte des Einsteiger-pdf's), weil es nichts anderes gibt oder das am besten funktioniert. Und mangels Kaufbarkeit wird's dann eben HM-IP (mit einem nutzlosen CUL...) Ist zwar überspitzt, aber ihr versteht vermutlich, worauf ich raus will.

@DasQ:
Über deine Auswahl, was wichtig ist, kann man trefflich streiten, aber den Ansatz, das ggf. als Baukasten zu nutzen, in den man dann evtl. die jeweiligen Module, die grade Erklärgegenstand sind, einfach eintragen könnte, kann evtl. hilfreich sein (so kamen wir ja auch rückwärts überhaupt hier zu diesem Thema...).
Aber bitte ein's um's andere... erst machen wir diese Grafik, dann mache ich den MQTT-Artikel fertig (da hat auch keiner mehr gemotzt...), und dann kann mal jemand anders Dinge visualisieren lassen, die ihm wichtig sich. (Für den Perl-Artikel brauche ich das eher nicht (vermutlich...); Mist, da muß ich die Jungs auch nochmal schubsen...)

Die Idee, die Verbindung Server/IO durch sich berührende Umrahmungen darzustellen, gefällt mir übrigens immer noch. Da auch an der Stelle bisher keiner gemeckert hat: Würdest du das bitte so umsetzen...?

[LuckyDay]

Da es nur eine Übersicht darstellt, würde ich auf die Bepfeilungen verzichten.

die zwei Kästen Native I/Os und Externe Soft/Hardware räumlich etwas auseinander ziehen.
und auch deutlich machen, dass es sich nur um Beispiele(Auszug) handelt, dort auch nur Schlagworte verwenden , es gibt viele Wege nach Rom.

Die Fhem Eigenentwicklungen, wie Homebrew... Nanocul usw ,Bastelecke , (blödes negativ behaftes Wort), (Eigenwerbung) fehlt
----
Den Block Fhem, in die Mitte des Bildes positionieren, und außenrum die entsprechenden Kästen . Gui, Inet Dienste Wetter Kalender usw, Fhem-SchnittstellenBlock API,   

Wenn man sich die Fhem Forums Struktur - Gliederung anschaut, sieht man dass in der Übersicht doch noch einiges fehlt.

---
zu warm für noch mehr geistigen Erguss

[Beta-User]

zu warm für noch mehr geistigen Erguss

... trotz Hitze: Danke ... (auch an Christoph)

Anmerkungen:

- Bepfeilung:
-- Wenn die Farbgebung paßt (OWServer z.B. noch nicht, HM s.u.), könnte das ein Weg sein. Dann würde ggf. statt "SlowRF" als IO "Beispiel-Interface" (?) stehen, als "Hardware" dann "Gerät, das mit Beispiel-Interface kommunizieren kann" stehen? (Ist vielleicht sperrig, würde aber die ", z.B." Variante erübrigen)
-- Für HM müßte dann die CCU3 tatsächlich schraffiert werden und für HM-BidCoS und HM-IP die beiden verwendeten, unterschiedlichen Farben gewählt werden

- IO-Varianten auseinander ziehen:
mehr Platz zu ver(sch)wenden, finde ich nicht unbedingt richtig, aber eine deutlichere optische Unterscheidung wäre evtl. gut?
=> würde vorschlagen, für "Komponenten" eine etwas andere Hintergrundfarbe zu wählen und dann den Interface-Bereich zu schraffieren, und zwar mit jeweils einer anderen Hintergrundfarbe, aber dann einem Farbverlauf von der "Server"-Farbe zur "Komponenten"-Farbe (bin noch unsicher, ob das gut kommt, aber vielleicht macht das deutlicher, dass es eben ein Übergangsbereich zwischen allen Welten ist?)

- "Bastelecke" usw.
-- finde ich auch schade, dass das keinen wirklichen Raum hat (und man das als Einsteiger evtl. schnell erst mal nicht wahrnimmt, welche tollen Projekte dass es so gibt; bei mir sind das aber faktisch tatsächlich eher Basteleien - auch wenn die Begrifflichkeit ansonsten wirklich "na ja" ist...)
-- ABER: wäre noch mehr Info, und damit gegen "weniger ist mehr". Werde aber in den Text einige Hinweise einbauen, ok?

- Was weitere Elemente+Positionierung angeht:
-- Das ist eine Abwägungsfrage. Tendiere selbst eher dazu, eher was wegzulassen als noch was dazuzuflicken, was man dann zum einen näher erklären muß, zum anderen irgendwo (sinnvoll) unterbringen.
-- An sich finde ich die optische Gliederung im Moment ziemlich passend, das Schaubild ist halt erst mal hardwarenah, ABER:
-- vielleicht wäre es eine Idee, die jetzige Inter-/Intranet-Wolke deutlich zu vergrößern, den "da durchgehenden" Kommunikationspfeil etwas nach rechts zu ziehen und dann eine Wolke in der Wolke mit "Web-Daten-Quellen und -Anwendungen, z.B. Kalender, Webseite (Wetter, ...), Messenger" einzufügen mit einem weiteren Doppelkommunikationspfeil zur "Server"-Box (keine konkrete Stelle da)?

Vollständig (v.a. über der Zeit...) wird/ ist das vermutlich nie, was auch nicht der Anspruch sein kann; aber so hat man auch dazu eine "Verortung"?

Sonstiges:
- Bei Konfiguration evtl. statt eigene.cfg configDB und beides dann einklammern. Also: "Konfiguration (fhem.cfg/configDB)"
- (OWX) hat ein Leerzeichen oä. davor.

[ph1959de]

Noch mal "so reingeworfen" ein paar Worte zu meiner ursprünglichen Intention für die Seite / das Bild:

• Dinge / Komponenten des Gesamtsystems benennen, damit man sie eindeutig identifizieren kann (damit nicht alles unter dem Begriff "mein FHEM tut nicht" läuft)
• Darstellung der Kommunikation zwischen Komponenten, Geräten, etc.
• ... aber nicht alle Details, sondern: Funk, unidirektional / Funk, bidirektional / Draht-/Kabelgebunden / ...
• aus diesem Gesichtspunkt könnten HomeMatic (BidCos) und HomeMatic (IP) durchaus zusammengefasst werden, zumal sie auch (zumindest überlappend) über gleiche Gateways betrieben werden können
• d.h.: jeweils die Prinzipien dargestellt; zusätzliche Systeme nur, wenn in wichtigen Aspekten anders, als schon beschriebene

Was jetzt (fällt mir gerade auf) unter den obigen Gesichtspunkten noch fehlt wäre FHEM2FHEM - ist aber vermutlich nicht ganz einfach darzustellen.

Peter

[Beta-User]

Hmm, spräche eher wieder für das Beibehalten der "Pfeile" (und SlowRF)...? (Kann ich nachvollziehen, bin aber "neutral")

Was "Benennung" angeht: fehlt dir da grade was (ich war daher darum bemüht, in Klammern jeweils die Modulnamen zu verwenden, gerade um es sehr konkret zu machen)?

HM - Finde ich schwierig, das zusammenzufassen; die Trennung ist zwar auch nicht ganz korrekt, aber im Prinzip kommunizieren auch HM-IP-Komponenten nicht direkt mit BidCoS-Komponenten, sondern brauchen dazu eine CCUx (OT: dto für wired). Finde es daher "as is" (schraffiert) den einleuchtenderen Kompromiss (zumal auch die CCUx ja mit einem CUL kann und SlowRF usw.. usf.... => uferlos...)

"Zusätzliche Sys nur..." - sollte irgendwas raus? (Bin geneigt, eher HM rauszuwerfen als ZWave, wenn das der Vorschlag wäre )

FHEM2FHEM/RFHEM: kann m.E. recht einfach in die "Intranet-Wolke"? (Finde ich gut, auch wenn ich dazu nix sagen kann und wenn, dann eher MQTT@MQTT2 dafür nutzen würde...) Im Prinzip verbirgt sich doch (fast) alles (sonst nicht explizit aufgeführte), was wir vorher unter TCP/IP "verstanden" hatten an dieser Stelle, oder?


Nachtrag zu HM:
wir könnten da bei BidCoS noch CUL_HM und HMCCUCHN (? oder doch HMCCUDEV??) ergänzen und bei HM-IP dann nur HMCCUCHN (?). Dann hätten wir es wieder etwas konkretisiert mittels Modulnamen (sollte aber noch jemand die Begrifflichkeiten verifizieren, der sowas schon mal in der Hand hatte...)

[DasQ]

Kurzer Zwischenstand,
Also nur weil augenblicklich nix neues von mir zu sehen ist, heißt das nicht, es geht nix vorwärts.
Naja vorwärts ... ich beweg mich grad so ein kleinwenig auf der Stelle und zwar kämpf ich mit Farbverläufen (Server die hellblauen Kästen) in Vektorgrafiken unter Photoshop ... und ich hab auch schon die Lösung -> Illustrator AI

Das ist aber für euch eher uninteressant, wollt nur mal eben Bescheid geben was los ist.

BTW. Ist das päuschen aber so wie ich hier mit les, garnicht so verkehrt.
Ich hau heut einfach noch ein Entwurf mit den neuen Informationen (reduziert) raus. Dann kann man das mal ,,optisch" wirken lassen und man hat neue gesprächsgrundlagen.


****** edit *******
ist ne Gratwanderung zwischen vektorgrafik (SVG) und kleine dateigröße, oder optisch hübscher aber große datei (PNG)


*** edit zwecks verwirrungsvermeidung und datenreduktion anhang gelöscht ***

[Beta-User]

Das mit den Pfeilen ist m.E. jetzt "im Prinzip" optisch passabel gelöst, aber inhaltlich inkonsistent und teilweise falsch:
- Falsch: Verbindung HMUARTLGW zu HM-IP (das funktioniert ja grade nicht und war der Grund, warum es so viele HM-Boxen gibt...)

- Warum ist manches gestrichelt und anderes durchgezogen? Wenn durchgezogen = verkabelt, ist das nur 1-wire und KNX (ja, es gibt auch eine RF-Variante...), und bei MQTT weiß man es nicht, kommt auf die Komponente an... Ich würde das tendenziell als Funkverbindung kennzeichnen, da das überwiegend der Fall ist.
Wenn RF-Zeug gestrichelt sein soll, dann muß IT/LaCrosse _anders_ gestrichelt werden, da ohne Rückkanal.


Eine ganze Anzahl von Schreibfehlern ist nicht verbessert. Möglichst bitte nochmal die letzten Beiträge hier dazu durchsehen.


Was "Komponenten" angeht:

Wäre es nicht das einfachste, hier "Sensor o. Aktor" drüberzuschreiben? Dann kann "Komponente" überall entfallen...

Die vergrößerte I/I-net-Wolke (mit FHEM2FHEM, RFHEM und einem Pfeil zur Serverbox) finde ich immer noch eine gute Idee?
Wenn niemand was dagegen äußert: Bitte umsetzen .


Die Idee mit dem Farbverlauf betraf den "Interface"-Bereich.

[DasQ]

Also das mit den Pfeilen, hatten wir ja schon. Gestrichelt, Farbe, etc.
Die obersten beid n Pfeile sind auf dein Gedanken, es geht um eine Funkverbindung blau und gestrichelt.
Das war's aber dann auch schon mit der Logik, weshalb ich dann den Entschluss gefasst hab, die andern Wolken zu stricheln, aber in Farbgebung an das jeweilige Interface angelehnt (bis auf ccu3 da weicht die Farbe minimal vom ,,normalen" hm ab, zwecks Unterscheidung.
Hier geht's mir auch nicht drum das des jetzt final ist, ich wollte vielmehr zeigen, in wie weit man die Verbindungen visuell unterscheidbar zu machen.

Ich könnt also auch stichpunktierung anders gestalten, nur um die verfolgbarkeit zu erleichtern. (Und ich will garnicht erwähnen, das es Menschen gibt mit farbsehschwäche (usebility und Barrierefreiheit ein Graus)).

Mir sind eben Aspekte, an die du vielleicht nie denken würdest, sehr viel wichtiger, als jetzt der fachliche Inhalt, dafür seit ihr zuständig. Da bin ich plumper befehlsempfänger. (Drum mag dir des auch teilweise müßig erscheinen, wenn du wieder und wieder das selbe sagst. Ich hab dich schon soweit verstanden, aber die Sachen Bau ich immer alles auf einmal ein, damit ich fachlich nicht zu sehr verwirr).

Mir wär also sehr recht, wenn logisch und optisch alles passt, ich von dir ne korrigierte pdf bekomm, dann änder ich des sofort.

Bin ein plastischer Mensch und bei so ner Grafik kann man herrlichen drin rum malen.

[Beta-User]

...du bekommst die Tage dann irgendwann 'ne überpinselte Fassung, kann halt nicht garantieren, dass du das auch lesen kannst... (oder "Farbverkäufe" erkennen).

@All:
Bitte wehren, wenn jemand "Aktor o./u. Sensor" statt "Komponente" nicht gut findet!

Dto. zu der vergrößerten Intra/Internet-Wolke.

[DasQ]

bissi was anders gemacht ...
ich hoff es sind jetzt die fehler raus, ansonsten bitte nochmals zusammen kopieren aus den  postings. Danke

*** edit zwecks verwirrungsvermeidung und datenreduktion anhang gelöscht ***

[DasQ]

und noch ein


*** edit zwecks verwirrungsvermeidung und datenreduktion anhang gelöscht ***