Überarbeitung "Systemübersicht"

[Beta-User]

Hallo zusammen,

nachdem wir im Zusammenhang mit der Diskussion über die Darstellung von MQTT über diese Seite (und v.a. die dortige Grafik) "gestolpert" sind: M.E. sollte man die Grafik und den Artikel mal renovieren .

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" (allen voran und ausdrücklich: Markus Bloch, ph1959 und krikan)
- Zum einen sollten aktuelle (und ggf. auch empfehlenswerte) Module Verwendung finden; damit ist FHZ m.E. überholt;
- immer häufiger finden sich alternative Wege (OWX vs. OWServer, TUL vs. eibd, MQTT2_SERVER vs. mosquitto+MQTT (o. MQTT2_CLIENT), was bereits bei HomeMatic ein "Quell immerwährender Verwirrung" ist (aber technisch natürlich völlig i.O.).
Das v.a. für Homematic/HM-IP rauszuarbeiten, fand ich in dem Zusammenhang wichtig, es bedarf natürlich im folgenden Text dann auch der Erläuterung (und ggf. einer Markierung in der Grafik, auf die man Bezug nehmen kann).
(- @DasQ: HM-Wired habe ich rausgenommen, weil das m.E. zu speziell ist und dann wieder mehrfach zu nennen gewesen wäre, geht mWn. auch direkt via USB-Stick...)

Sonstiges:- Telnet darf m.E. hier drin bleiben, aber die "überzähligen" FHEMWEB-Instanzen sollten raus;- Ob FLOORPLAN noch promoted werden sollte? Da tut sich wenig, und wenn, dann eher verwirrendes.
- Die Fritte bei den Servern ist auch, ähm, na ja...
- unten bei den "drahtgebundenen" sollte wohl auf KNX als Modul verlinkt werden (statt dem veralteten EIB).

Jeweils eine kurze Rückmeldung wäre nett, dann mach' ich das bei Gelegenheit (oder einen Vorschlag, wenn unsicher), und ihr dürft dann Kritik üben, sofern erforderlich...

Gruß, Beta-User

[Wernieman]

Sofern ich weiß, hat FHEM doch kein ssh-Zuigang .. nur telnet over SSL ....

[Beta-User]

@Wernieman: Danke für den Hinweis.

(Das war auch auf der Ausgangsgrafik nicht drauf; @DasQ: nimmst du das auf die todo?!?)

Noch einen Link zu dem Artikel, um den es geht: https://wiki.fhem.de/wiki/System%C3%BCbersicht

[DasQ]

Also ich geh nur per ssh auf mein Linux ... 
da stand zuvor Putty ... was wohl mit ssh assoziiert wurde.

Ich bin der Meinung man sollte dort die Protokolle Telnet und SSH schreiben, anstatt der Anwendung putty. Kann das aber gern wieder zurück ändern.

[Beta-User]

Hmm, ich kenn mich in dem Bereich nicht hinreichend aus, aber im Moment würde ich das so deuten, dass wohl weder Putty noch SSH da stehen sollte?

@DasQ: Neben den bereits in das pdf reingemalten Änderungen, die du evtl. noch nicht gesehen hattest (?): Kannst du auch Node-Red da rausmachen?
MAn. verwirrt das eher, als es nützt; wenn überhaupt, müßte man den MQTT-Komponenten-Kasten etwas vergrößern und da dann unter der Überschrift MQTT eine Strichliste anfangen mit
- Komponenten
- Software-Clients wie
-- NodeRed
-- openHAB
Aber schon wie ich das hier schreibe: Das führt mMn. zu weit... Dieses Spezialthema kann gerne jemand im Rahmen von MQTT darstellen, aber hier?!? (Ich habe dazu in dem anderen Thread nur was geschrieben, weil die Frage war, warum man "andere" FHEM-Devices denn ver-MQTTen wollen sollte...)

Was ich an der Ausgangsgrafik noch gut fand:
- Kabelverbindungen waren ganzer Strich, "Luftschnittstellen" waren immer mal wieder unterbrochen (sind jetzt "nur wolkig", ist auch eine Lösung, aber eben "weniger deutlich"...)
- der "localhost-Pfeil" "neben" der Intra-...Wolke macht m.E. Sinn, sollte man auch nicht "entsorgen" (bitte aber auch nicht beschriften).

[Otto123]

Hi,

Im Artikel steht sowas:

Bei der Komponente Server muss unterschieden werden zwischen dem eigentlichen FHEM Hausautomations-Server (implementiert in der Perl-Datei fhem.pl) und der Hardware, auf der dieser Server ausgeführt wird.

Meine Gedanken/Meinung:
Der blaue Kasten ist auch ein bisschen diese "Mischung" Hardware/OS/FHEM
Man braucht Zugang zum "Server":
- Der Server-OS bietet sowas wie ssh oder RDP (Windows) oder Monitor und Tastatur oder oder oder
- Der Server-FHEM bietet Protokolle für den Zugang zur Systemschnittstelle: http, (telnet)

Gruß Otto

[DasQ]

kurzer zwischenstand

bei Homematic kann ich dir nicht ganz folgen bzw. kann ich mit dem begriff (BilCos) nix anfangen

- und bei Eib oder Eibd?
- das mit den pfeilen ist nicht entgültig. die mach ich erst zum schluss hübsch.

- Der Server-OS bietet sowas wie ssh oder RDP (Windows) oder Monitor und Tastatur oder oder oder
- Der Server-FHEM bietet Protokolle für den Zugang zur Systemschnittstelle: http, (telnet)

kann man beides einbaun. dann ist der begriff "terminal" (unten links) vielleicht etwas unglücklich


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

[Beta-User]

bei Homematic kann ich dir nicht ganz folgen bzw. kann ich mit dem begriff (BilCos) nix anfangen

Der Begriff heißt BidCoS; das ist die Bezeichnung für das "alte" HomeMatic-Funkprotokoll (der Leser muß damit auch nicht direkt was verbinden, es geht eher darum, dass er sieht, dass HomeMatic mehrdeutig ist). Das gehört zu HMUARTLGW/CUL und zur CCU3 (ist doof, dass man da das aktuelle Modell nennen muß, aber CCUx wird vermutlich mit VCCU verwechselt, und dann wird es schräg). Die CCU3 kann jedenfalls (u.A.) alle HomeMatic-Protokoll-Varianten, also BidCoS, HM-IP und HM-wired.
Da es für letzteres (HM-wired) dann aber wieder auch ein separates Hardware-IO-Modul gibt (mWn), wird es noch komplizierter, wenn wir das auch noch aufführen. Also lassen wir es (auf der Grafik) bitte überall weg. Gibt ja schließlich noch anderes wie eQ3-Material, so weit verbreitet ist das nicht und zu guter Letzt wird derjenige, der ein verkabeltes System sucht, da schon ohne die Grafik draufkommen ...

- und bei Eib oder Eibd?

Der Dienst heißt wohl "eibd" (?).

[DasQ]

AKTUELLERSTAND:
bitte nochmals alle drüberschauen.

punkte die mich jetzt noch stören:
A. es steht zu oft komponenten in der sektion "komponenten", könnte man da vielleicht einfach gehaltene beispiele zu lacrosse, 1-wire, knx und zwave nennen, lockert die sache etwas auf. (oder einfach überall weglassen wo "nur komponenten" steht (steht ja schonmal drüber)
B. visualisierung die pfeile/wolken ... sind denn wirklich alle wolken ohne kabel? oder spielt es keine rolle das das logisch nicht stimmt? war der meinung das z.b. bei homematic auch per kabel geht.

ToDo:
1. Pfeile zwischen Interface und Komponenten abschliessend anpassen. (das ist in photoshop ein klein wenig achteckig, drum mach ich das es zum schluss)

Sonstiges:- Telnet darf m.E. hier drin bleiben, aber die "überzähligen" FHEMWEB-Instanzen sollten raus;- Ob FLOORPLAN noch promoted werden sollte? Da tut sich wenig, und wenn, dann eher verwirrendes.
- Die Fritte bei den Servern ist auch, ähm, na ja...
- unten bei den "drahtgebundenen" sollte wohl auf KNX als Modul verlinkt werden (statt dem veralteten EIB)

das bezieht sich aber nicht auf mich?


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

[Beta-User]

bitte nochmals alle drüberschauen.

Vorab mal Danke! Kommt m.E. gut ran, auch wenn es in manchen Details vermutlich gar nicht geht, eine vollständig korrekte, aber einfache Lösung zu finden. Dazu unten, erst mal einige Details und Antworten zu konkreten Fragen:

A. es steht zu oft komponenten in der sektion "komponenten", könnte man da vielleicht einfach gehaltene beispiele zu lacrosse, 1-wire, knx und zwave nennen, lockert die sache etwas auf. (oder einfach überall weglassen wo "nur komponenten" steht (steht ja schonmal drüber)

Nennt man konkret kaufbare Hardware, birgt das das Risiko, dass der Änderungsbedarf bei Veränderungen am Markt ständig besteht; richtig zeitlose Komponenten sind leider selten.
Im Prinzip könnte man das ohne die vielen "Komponenten-Worte" machen, aber es sollte dann irgendwo sehr deutlich stehen, dass es sich in der Regel bei einer "Komponente" um ein reales Stück Hardware handelt (meistens, s.u....)

B. visualisierung die pfeile/wolken ... sind denn wirklich alle wolken ohne kabel? oder spielt es keine rolle das das logisch nicht stimmt? war der meinung das z.b. bei homematic auch per kabel geht.

Es gibt auch HM-Wired, aber das haben wir hier bewußt rausgelassen (s.o. im Thread). M.E. darf der Teil so bleiben (oder es muß noch komplizierter werden...). Was @HM-Familien noch angepaßt werden könnte: CCU3 (bitte zusammen schreiben, kein Leerzeichen) könnte schraffiert sein in den BidCoS und HM-IP-Farben, wobei dann HM-IP noch ein anderes grün bekäme. Ansonsten bitte die CCU3 in der sonstigen HM-Farbe, nicht "anders").

Was die Funk/Kabel-Frage angeht, paßt es m.E. soweit, außer:
(- Funkpfeile, "zum Schluß" wie angekündigt)
- zigbee ist Funk;
- MQTT ist "irgendwie anders" => Oval mit Punktrahmen?

Sonstige Kleinigkeiten:
- TableUI => TabletUI
- Eibd => knxd (bitte widersprechen, wenn es jemand besser weiß! Afaik ist eibd veraltet und Kleinschreibung korrekt)
- Bei der Tasmota-Schreibweise bin ich unsicher. Das wiki ist da uneinheitlich, das Logo deutet auf konsequente Großschreibung hin (würde das so "as is" lassen, wenn nicht jemand interveniert.
- Bei Zigbee (Komponente) würde ich jetzt Bulb/Sensor in die Klammer schreiben, dann ist im "Komponenten"-Bereich wirklich alles ohne konkreten Bezug zu einem FHEM-Modul-Namen. Das hat aber einen Nachteil:
- Zigbee2mqtt würde ich bei MQTT rauslassen, denn sonst bräuchten wir eigentlich auch den Kommunikationspfeil zu Bulb/Sensor...
- shelly => Shelly, aber:
Es gibt hier auch einen alternativen Weg....
=> würde vorschlagen, bei "Zigbee (Bulb/Sensor...)" einen Stern anzufügen und bei Shelly, und unten einen Hinweis anzubringen: "* Alternative Options for integration in FHEM are available" (für ZigBee z.B. noch die Xiaomi- oder Tradfri-Bridges, Shelly via eigenem Modul...) Sonst würde ich Shelly und Zigbee2Mqtt ggf. ganz rausnehmen. Dann bleibt aber wenig in der MQTT-Box... (wäre für mich ok, verengt aber den Blick auf Tasmota, was m.E. auch wieder mehrfach suboptimal ist).

Generelle Fragen (s.o.):
- Die Überlappung/Wechselwirkung zwischen "Interface" und "Server" überzeugt mich insgesamt noch nicht vollständig:
Eigentlich müßte der "Module"-Bereich dann auch mit in die Überlappung. Dann müßte man aber ggf. die vollständigen Modulnamen passend sortieren, also z.B. "00_CUL.pm" in den Überlappungsbreich von "Native..." und "Module" (nicht aber "10_ZWave.pm")... => Bin unschlüssig
- Was "Terminal" angeht:
-- telnet läuft eigentlich auch über ein eigenes Modul... => der Pfeil dürfte eigentlich nicht direkt zu fhem.pl gehen, sondern entweder erst durch den "Modul"-Bereich, oder einfach an der Serverbox enden (finde ich spontan akzeptabel)
-- Ob man da noch irgendwo "Messenger-Service" hinschreiben sollte (gleicher Bereich) und dann ggf. die Pfeile wie oben bei Frontends zusammenlaufen lassen? (würde ich tendenziell weiter weg lassen...)

das bezieht sich aber nicht auf mich?

Nein; das betrifft den Artikel-Inhalt.

(Sorry, das war's erst mal, aber bestimmt fällt mir später nochmal was ein/auf)

[Wernieman]

Ist es eigentlich Wichtig, ob die Verbindung Funk oder Kabel ist?

[Beta-User]

Ist es eigentlich Wichtig, ob die Verbindung Funk oder Kabel ist?

M.E. "an sich" nicht.

Aber: Leute draufzustupsen, dass es auch verkabelte Lösungen gibt, ist eigentlich nie ein Fehler, daher darf Funk gerne "wolkig" sein (auch im Sinne von: es ist eben manchmal nebulös, was da abläuft...). Optisch ist es auch kein Fehler, die Wolken zu verwenden.

Aber wenn die Frage ist, ob es unbedingt andere Pfeile sein müssen: Tatsächlich nicht, mit einer Ausnahme (433MHz)... Hier wäre es eventuell eine Idee, dieses unidirektionale Zeug gestrichelt darzustellen und mit "halben gegenläufigen Pfeilen" (mit "halb gegenläufig" ist gemeint: es gibt diese Pfeilspitzen, die nur in eine Richtung weg von der Schaftlinie gehen, da jeweils einen in jede Richtung...)


@Wernieman:
Deine Meinung "zum Rest" würde mich auch interessieren, v.a., was die Punkte angeht, wo ich selbst unschlüssig bin...



@krikan, ph1959, Markus Bloch:
Dass die beiden erstgenannten im Forum aktiv waren, habe ich gesehen und werte das bisherige Schweigen mal wieder als "mach ruhig"... Wenn mich bis Anfang kommender Woche keiner einbremst, mach ich das auch (was die Grafik angeht, bin ich da guter Hoffnung, das die bis dahin auch soweit fertig ist ).
Wenn also Kritik, dann eher früher wie später, bitte...

[krikan]

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

Das hast Du -was mich betrifft- richtig bewertet. Soweit ich Dich kenne, werden Änderungen gut durchdacht und sind keine hingeworfenen Schnellschüsse. 

[Wernieman]

@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.

[PeMue]

Hallo,

bitte nochmals alle drüberschauen.

ich schlage noch folgende Änderungen vor:
- im oberem mittleren Kasten: FHEM: native IOs ...
- TUL (großgeschrieben)
- bei IT/LaCrosse würde ich den Pfeil nur jeweils mit einer halben Spitze in jede Richtung machen, um zu kennzeichnen, dass die Dinger nur unidirektional sind (Sensoren: Sender, Aktoren: Empfänger)
Ansonsten sehr übersichtlich und durchdacht.

Gruß Peter

[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 ***

[Beta-User]

und noch ein

gefällt mir ganz überwiegend sehr gut!

(Fast) der Reihe nach:
(1) den Umweg durch Modules ((6) - English) braucht es m.E. nicht, denn wenigstens die einfachste Anweisungen (start/stop/restart) gehen wirklich ganz direkt...

(2) Die Pfeile von "Browser" zu "Frontends" bitte verschieben, so dass (3) die Wolke sehr viel größer werden kann. Vielleicht den unteren Abschnitt des Pfeils "durch" die Wolke dann noch etwas in die Wolke ragen lassen, dass optisch eher der "durch"-Eindruck entsteht (im Moment kann man das auch als "dahinter" interpretieren?).

(3) die größere Wolke darf dann gerne eine "Wolke in der Wolke" bekommen mit den bereits genannten diversen Diensten, die man andocken kann (auf die Schnelle: Calendar, Messenger-Service, Remote FHEM (FHEM2FHEM or RFHEM), Weather, ...), das dann mit einem Kommunikationspfeil zu "Server" ((9), muß an der Stelle m.E. nicht genauer werden).

(4) und (10) s.u.

(5) Die Legende (engl.: explanation (?)) ist jetzt sachlich korrekt, was die Pfeile angeht, statt nur Wifi sollte dort RF/WiFi stehen (HM-IP nutzt 868MHz, also nicht Wifi). Ob man es im Schaubild braucht? (Unschlüssig, würde tendenziell sagen: nein...)

(6) Modules statt Module (engl. Mehrzahl)

( 8 ) External statt Externe (engl.; bin unschlüssig, was den Titel an sich angeht, dazu s.u. (10))

(11) FHEMWEB dürfte die "richtigere" Schreibweise sein (=Modulname)

(12) **-Anmerkung zu den IO-Fällen, in denen man nur eine der Optionen benötigt: "Only one of the Interface options per technology is required"

(4)/(10)
Die Anbindung Server<=>Interface gefällt mir immer noch nicht so recht....
Grundsätzlich sollte da um alle Interfaces erst mal ein gemeinsamer Rahmen, und dann würde ich im Moment drei Unterboxen sehen:
- "serial communication" (alle USB/UART-Varianten oben)
- "internal" (MQTT2_SERVER, da würde ich einen separaten Kasten in der blauen "Modules"-Farbe (bzw. dem Verlauf) drumrum sehen, der dann auch über die "Interface"-Box raus direkt an den Server anschließt)
- dann bräuchten wir jeweils noch eine Kommunikations-Visualisierung zwischen
-- den oberen Interfaces und "Modules" sowie
-- den unteren Interfaces und "Modules"
(Den Kreispfeil aus einer der Vorversionen fand ich ganz ok, und würde den oben mit "serial communication" beschriften, unten dann mit "communication via e.g. TCP/IP or script"; damit könnte zumindest oben dann aber die Überschrift ganz entfallen)

Bin noch unschlüssig, aber sowas finde ich eher einleuchtend wie der Vorschlag mit den überlappenden Boxen; sonst wäre ich eher für die schlichte Variante zu haben, den (neuen) Interface-Kasten direkt an den Serverkasten "anzudocken" und das nicht weiter zu erläutern, was es soll und wie die Kommunikation abläuft (aber den MQTT2_SERVER trotzdem blau zu hinterlegen und diese Box im Unterscheid zu den anderen beiden Teilboxen ebenfalls direkt an den "Server" anzudocken). (Muß ggf. die "Rundpfeilvariante" mal gesehen haben, glaube aber im Moment, dass die schlichte Variante (andocken) "weniger ist mehr" ist).

Schiwerig, aber hoffentlich halbwegs verständlich?

[DasQ]

zwischenstand, ist aber noch nicht alles drin, weil ich denk man sollte auf der basis weiter machen.
den dritten kasten bau ich als nächstes bei den interfaces

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

[Beta-User]

Hmmm, bin immer mehr wieder bei dem "andocken"... Das mit den Kreispfeilen (oder ähnlichen Alternativen) ist noch ein Element... => weniger ist mehr...

Vielleicht noch im nächsten step:
- jeweils die sternchen-anmerkungen passende Box mit rein, wobei Actuators dann eben etwas länger würde (*@IT fehlt noch); in die Interface Box müßte dann ein etwas längerer Text, da der Bezug durch die beiden Sterne nur bei Interface verloren gegangen ist (könnte man auch oben weglassen, wenn in der Box (oder besser: der Explanation) steht: "More than one option for data exchange? Choose one." (Kurz und exakt: Schwierig...)
- Mehr Platz drumrum: m.E. besser vermeiden => die Wolke darf ruhig oben drüber, und die beiden Teilpfeile "durch" sollten optisch "eine Linienführung" sein (kein Knick oder so), einer darf ruhig direkt an der Kante enden, nur der andere nicht (m.E.).

[DasQ]

andocken der interface kasten? weil wenn ich da jetzt alle drei kästen dranmach, erkennt man den in der mitte nur schwer

[Beta-User]

andocken der interface kasten? weil wenn ich da jetzt alle drei kästen dranmach, erkennt man den in der mitte nur schwer

Ja, so war's gemeint.

Dass der in der Mitte vergleichsweise klein wird, ist klar. Hoffte darauf, dass der blaue "Modul-Hintergrund" das etwas hervorheben würde? (sonst evtl. etwas größer, aber eigentlich: Das eher ungern, möglichst moderat...)

[DasQ]

 

die datenaustauschstriche passen noch nicht

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

[Beta-User]

Hmm, aber optisch finde ich das so der Spur nach gar nicht übel...

Würde aber die Gesamt-Interface-Box andocken und dann die "native"-Box etwas nach links einrücken, so dass diese eine tatsächlich direkt andockt, und dann die Gesamt-Interface-Box noch mit einem etwas anderen Hintergrund vom allgemeinen Hintergrund abheben?

Rest dann später...

[DasQ]

wir befinden uns auf der zielgeraden ....

kurze zwischenfrage, in wie weit performance (schnelles laden da kleine datei), gegenüber perfekte skalierbarkeit wichtig ist. weil wenn ich das jetzt als PNG so speicher wären wir schon in einem erträglichen mass der dateigrösse.
weil ich muss mich erstmal wieder in illustrator reinfuchsen damit da brauchbar kleine vektorgrafiken mit allem schnickschnack (farbverläufe) realisierbar ist. das kann aber noch ein ganzes weilchen dauern, bis ich da wieder fit bin.

ohne schnickschnack die SVG datei im anhang (fehlende übergänge u. ebenenmasken)
in illustrator ist das gleiche file fast 10x grösser. ... das ist natürlich käse


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

[Beta-User]

 
Zielgerade trifft es ganz gut.

Was Dateigrößen usw. angeht: Nicht eben mein Spezialgebiet...

Scan anbei (leider beim Drucken auf 2 Seiten...), Anmerkungen dazu:

- Links so viel leerer Raum? Müßte sich durch diverse Verschiebe-Aktionen eigentlich vermeiden lassen: V.a. Webbrowser mehr nach rechts, dafür die Wolke etwas runter?

- Wolke:
-- Den oberen der "durch-Pfeile" immer noch ganz hinter die Wolke bringen? Aber die Linienführung ist prinzipiell gut (wäre aber nach Verschieben wieder anzupassen), und auch der "fade-out-Effekt" ist sehr passend (könnte sogar noch ausgeprägter sein, aber das ist Jammern oberhalb des Zielniveaus...).
-- Wolke in Wolke nun etwas klarer? Die Anordnung der Elemente in der Wolke wäre dann eben noch anzupassen, und die Liste, die ich da reingepinselt habe, ist nicht vollständig...

- Bei Interfaces: Die Box hinter der Server-Box ist auch eine gute Lösung. Allerdings sollten die native- und Extenal-Boxen wirklich angrenzen, da sind jetzt noch kleine Spalten sichtbar.
So wie es jetzt ist mit der Box hinter der Serverbox könnte m.E. auch die "native" Box insgesamt so nach links verschoben werden, dass sie direkt an die "Modules"-Box andockt?

- Der Stern bei IT-Lacrosse sollte analog zu Shelly+Zigbee() rechts oben stehen, und der alte Text war korrekt, da hatte ich wohl was mißverständlich formuliert, denn:

- Der alte *-Text könnte (mit dem Stern) direkt unter die Actuators...-Box in den normal hinterlegten Bereich (da ist der sachliche Bezug), und

- das "More..." könnte in den anders hinterlegten "data exchange" bereich unter/zur "explanation".
Und da das (jetzt) optisch integriert ist, kann eigentlich die Überschrift "explanation..." sogar raus, vor allem, wenn der eigentliche Erklärtext und die Linien nach links rutschen würden? Die Schrift kann an der Stelle auch kleiner werden, solange man es überhaupt entziffern kann . (Ist eigentich selbsterklärend bzw. muß im Text sowieso aufgegriffen werden).

Sonstige Feinheiten (wenn du noch Lust hast ):
- WiFi schreibt man afaik international eher mit großem F, oder?
- Was die Ausrichtung der Elemente in den (meisten) Boxen angeht, fände ich insgsamt eine mittig:mittig-orientierte Grundstruktur passend, also:
-- Im "Server" "Frontends" und "FHEM" horizontal mittig, "SlowRF", "ZWave", "HomeMatic" usw. h/v mittig, einschl. der "MQTT-Briefmarke"

[DasQ]

 

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

[Beta-User]

Wieso  ?

Zum Grundlayout:
- Mehr Platz braucht es an sich nicht, das wäre grundsätzlich ok, oder?
- Die Inter/Intranet-Wolke&Umfeld:
Der "durch-Pfeil" hat nichts zu tun mit den genannten Anwendungen, der kommt und geht vom und zum Browser (nur eben nicht immer via localhost = rechter Pfeil), sondern ggf. durch die "allgemeine Wolke"
=> der "durch"-Pfeil kann auch direkt neben dem anderen ("localhost") eher rechts "durchgehen"
=> Wir brauchen eine Art Abgrenzung der benannten Anwendungen vom "Rest des Internet". Das ist mit "Wolke in Wolke gemeint". Da gehören dann die aufgezählten Dinge alle zusammen rein, und es braucht einen weiteren Pfeil (weil typischerweise nicht "Browser", sondern eben Calendar, HTTPMOD...), der diesen Teil "anders" mit dem "Server" verbindet.

- Was nicht ganz optimal ist, ist dass das "Drumrum" optisch sehr viel größer ist als die ganze Server-Box...
Vielleicht sollten wir die insgesamt etwas nach unten rutschen? Solange die Verbindung zwischen "USB/UART" und der Box da ist, wäre das m.E. kein Problem? (Der Pfeil unten muß nicht so geschwungen bleiben). Und/Oder noch irgendwie anders etwas mehr in den optischen Vordergrund bringen?

- Links/rechts-Mittig paßt jetzt soweit, bei "Frontends" und "FHEM" darf dieser Text jeweils oben in der Box bleiben, in MQTT darf auch noch alles vertikal mittig werden.

- Die einzelnen *: Da verstehe ich nicht, warum die jetzt alle vorne stehen. M.E. gehören sie hinter den jeweiligen Bezugspunkt. Die dazu passende Anmerkung "* Alternative options for integration ..." könnte auch in der Actuator-Box am rechten Rand entlang laufen?

- Die ** können einschl. des Erläuterungstexts unten raus (das wurde ersetzt durch "More than...").

- Die Überschrift "FHEM System Overview" kann (ohne den Bindestrich) irgendwie mittiger in dem Freiraum oben platziert werden, oder?

- Die Boxenränder Server IO's sind noch nicht optimal:
-- Bei "native" darf die Begrenzung überschritten werden, der "Modules"-Rahmen darf also unter der (jetzt) roten Umrandung verschwinden. Btw: die Warnfarbe muß da auch nicht sein, eigentlich wäre dieselbe Farbe wie der Rahmen um "Server" passend.
(evtl. kann der Rahmen auf der linken Seite gestrichelt sein (nice to have!))
-- Bei den anderen beiden bitte nicht, da sollen die Rahmen sich nur berühren, aber jeder für sich stehen. Wenn das zu fummelig umzusetzen ist: die Rahmen der IO's soweit in den Hintergrund bringen, dass der Server-Rahmen darüber liegt, nicht umgekehrt.

[DasQ]

Ja eben mit der Wolke  ... die gefällt mir so auch nicht. Aber weil sie jetzt fast kreisrund ist. Wolken sind aber flach und gedrungen
Ja Wolke in Wolke haste du ja auch schonmal gesagt, ich überleg mir was. Wobei mir eine Wolke besser gefällt. Hab schon bemerkt das der Strich wende wo er jetzt ist, mit dem Text Assoziiert wird.
Hatte zuerst das intra/Internet unten und eben in blau. Den optionaltext in der Wolke rechts oben drüber, und einmal rechtausgerichteter text. Aber dann geht, die aufzählungsoptik verlohren.
Es ist schwierig, optisch da kein Chaos zu basteln.

Dann zu den Sternchen: die wenn im Text stehen (und nicht wie in der Erklärung drunter vorangestellt) dann gehen sie gelinde gesagt unter.
Man liest den Text mit vorangestelltem Stern und weis sofort, da ist was. Weist wie ich mein?
Wo und wie man die Erklärung platziert ist dann die zweite Sache.
Allerdings sind die Texte so lang, das ich wieder platzverschwenden würde, wenn ich wie du sagt das eine direkt unter die Sensoren und Autoren setz. Gut mit Zeilenumbrüche bekomm ich das auch drunter.

Für mein Geschmack ist jetzt schon das absolute Maximum an Input in der Grafik erreicht.
Du und ich sehn sofort, wo sich was geändert hat, der Laie braucht da etwas bis er kapiert, was der künstler sich dabei gedacht hat.

Ich würd vorschlagen, die andern sollen mal sich nochmals dazu äußern, vielleicht sehn die was, was wir nicht mehr sehn.

Vorschlag ich mach da jetzt erstmal ein zwei Tage Pause bis sich ggf. Noch jemand rührt.
Wenn nicht gewünscht, setz ich deine letzten Änderung einfach um.

[Beta-User]

Kurze Pause (und ein gewisser Abstand) und evtl. Rückmeldung abwarten ist für mich völlig ok.

- Was die * angeht: Dass der Text ruhig mini werden kann, hatte ich ja schon gesagt, und m.E. dürfen auch die Sterne selber unauffällig in den Hintergrund. Das ist ein Nebenaspekt, der eben mal die Schwelle dazu überschritten hat, dass man ihn überhaupt erwähnt, aber betonen muß man das (an der Stelle noch) nicht extra, dass bei FHEM viele Wege nach Rom führen können ...

- Wolke und flach: stimmt irgendwie... spontane Idee: zwei Wolken hintereinander, durch die teilweise überdeckte rechts den Teil-Pfeilzweig für Browser? Die Überschrift muß dann nur "zu den Wolken" gehören, aber nicht (vollständig) rein? (Und eine gewisse Stapelung von unten (vorne) nach oben (=hinten) wäre dann auch zu verschmerzen...

Aber grundsätzlich: Da steckt wirklich viel drin .

[Beta-User]

Für die Zwischenzeit wäre es noch nett, wenn jemand was zu folgende Teilaspekten im Artikel selbst sagen könnte:

pgm2/FHEMWEB:
Nach meinem Verständnis implementiert nicht pgm2 den Webserver (und das ist auch kein Modul), sondern das Modul FHEMWEB. Dieses nutzt dann aber wieder - je nach eingestelltem style - diverse js-Dateien aus dem Verzeichnis web/pgm2 bzw. liefert die einfach an den Browser aus.
Von daher würde ich zwischenzeitlich eher dazu tendieren, nur noch FHEMWEB zu erwähnen und den Hinweis hinzuzufügen, dass über die Auswahl des style und diverser Farbschemata das Erscheinungsbild im Browser beeinflußt werden kann. Der FHEMWEB-Artikel ist - jedenfalls auf den ersten Blick - in der Hinsicht übrigens auch nicht auf dem allerletzten Stand (darf gerne jemand anderes...)

FLOORPLAN:
Stört mich irgendwie, gehört für mich tendenziell raus. Bin da aber evtl. auch vorbelastet. Meine Erfahrungen waren eher: Nett, aber sehr statisch, was unterschiedliche Bildschirmgrößen angeht, und zuletzt iVm. f18 praktisch unbenutzbar (mindestens: zu große Icons), was letztlich dazu führte, dass ich diesen - sowieso praktisch nie genutzten Teil - vor einigen Monaten aus der config geworfen habe, zugunsten einer etwas intensiveren Beschäftigung mit FHEMWEB.
Andere scheinen den FTUI/FUIP-Weg gegangen zu sein, wieder andere nutzen MQTT, um darüber eine andere Visualisierungslösung (openHAB u.a.) zu füllen.
In dem Forumsbereich ist seit längerem auch sehr wenig los...
Meinungen?

HM ist mir tendenziell unten zu häufig erwähnt, ich würde wenigstens die nicht mehr erhältliche Hardware (LAN Konfigurator, CUNO) da rauswerfen, wenn sonst jemand Ideen hat, wie man das straffen kann: Her damit...

Die Tabellen:
Das steht seit langem "Muß noch ergänzt werden..." drunter. Ist zwar klar, dass das ein laufender Prozess ist, aber entweder es sind (die wichtigsten) Beispiele, oder es "müßte sich jemand kümmern"... (Was ich kenne o. glaube zu kennen, ist bereits ergänzt).
Würde sonst das "Muß" rauswerfen und "Auswahl" in den Text drüber schreiben?

So weit erst mal,

Beta-User

[Hollo]

Ich habe mit gerade mal die Übersichts-Grafik angeschaut und bin über die "Überschriften" gestolpert.
Nach genauerem Lesen habe ich zwar die Intention dahinter verstanden, finde sie aber irgendwie trotzdem unglücklich.

Das betrifft hauptsächlich die Inhalte in der Spalte Interfaces...
Ist z.B. ein ZWave-Dongle keine "External Hardware" ?

In der Konsequenz finde ich Software unter der Sensor-/Aktor-Schiene ebenfalls etwas schwierig.
Die letzte Spalte beschreibt ja eher das Protokoll als die möglichen Devices wie Temperatursensoren, Lampen, Thermostate etc.

Ich würde das eher über Protokolle und erforderliche/mögliche Gateways definieren...
also z.B.

                           devices eq3:
                           USB-Konfigurationsadapter hm-config-usb
                           LAN-Konfigurationsadapter hm-config-lan
                           LAN-Gateway
                           ....
Homematic
                           devices other
                           CUL/CUN
                           ...
-------------------------------------------------------------
                           FHEM internal:
                           MQTT2
MQTT
                           additional software:                           
                           Mosquitto
                           myBroker


Begriffe muss man natürlich überlegen.
Darauf aufbauend könnte man dann die passenden Wiki-Artikel verlinken und/oder eine filterbare Cross-Referenz erstellen.

Bzgl. Protokolle/Interface fällt mir gerade noch Modbus ein.

Bei Inter-/Intranet würde ich in die Richtung tendieren...
- Kopplung mehrerer FHEM-Instanzen (z.B. FHEM2FHEM ...)
- Anbindung interner/externer Dienste über spezielle FHEM-Module (z.B. Weather, Messenger...)
- Anbindung interner/externer Geräte/Dienste über generische Module (z.B. HTTPMOD ...)

Das nur mal so als kurze Gedanken in der Mittagspause... 

[Beta-User]

Hmm, in der Tat ist es schwierig, die teilweise fließenden Übergänge "richtig" zuzuordnen...

Denn jede Art der Datenübertragung braucht ein Stück Hardware.

Wie also abgrenzen:
So wie es jetzt ist, hat FHEM die unmittelbare "Treibersoftware" für die oberen IO-Devices, die alle auch eine firmware haben, die "selbständig irgendwas macht", also in diesem Sinn "extern" sind. Andere Dienste usw. haben keinen direkten Zugriff mehr, das gerät wird exklusiv von FHEM verwaltet.

Für MQTT2_SERVER gilt das umso mehr, der ist ja "nur Software".

Man könnte also beide Boxen vereinen und irgendwas von "exclusively managed" drüber schreiben? (m.E. eher nicht)

Was m.E. aber Sinn macht: das "native" weg und stattdessen die Anbindung USB/UART hervorheben (also aus der Klammer nach oben)?
Das paßt dann zwar (nach wie vor) nur bedingt, weil auch ser2net möglich ist, aber diese Unsauberkeit kann man m.E. vernachlässigen.

Bei den "externen" ist das anders. Die kann man auch von woanders her steuern. Vielleicht sollte man da reinschreiben: "Other (no exclucive FHEM control)"?


Was die Nennung von Software rechts unter MQTT angeht: "Weniger ist mehr" (kann m.E. raus).

Ich würde das eher über Protokolle und erforderliche/mögliche Gateways definieren...

Den Punkt verstehe ich nicht so ganz. Wäre das eine ganz andere Grafik? Oder bezieht sich das auf die Tabelle im Artikel? Die geht jedenfalls in diese Richtung, oder? Nur eben im Moment statisch, aber mit einigen Links.

Bzgl. Protokolle/Interface fällt mir gerade noch Modbus ein.

Wenn du mir die zu der Tabelle passenden Stichworte zurufst, versuche ich das gerne einzupflegen! Ist m.E. ein wichtiges Stichwort (ein (!) gutes Beispiel im Wiki wäre auch nicht schlecht, dann könnten wir die PI-GPIO-Fraktion einfacher auf diese Variante verweisen...).
EDIT: Zeile dazu in die Tabelle eingefügt, bitte ggf. weitere Links mitteilen.

Bei Inter-/Intranet würde ich in die Richtung tendieren...

Das ist im groben der Gedanke hinter "Wolke in Wolke" aka "Wolke vor Wolke", oder meinst du was anderes?
(Fehlt im Text/Artikel noch).

[Hollo]

Hmm, in der Tat ist es schwierig, die teilweise fließenden Übergänge "richtig" zuzuordnen...

Denn jede Art der Datenübertragung braucht ein Stück Hardware.
Wie also abgrenzen:

Vielleicht reisse ich das etwas aus dem Zusammenhang bzw. der ursprünglichen Intention; was soll der Systemüberblick darstellen?

Ich würde mir sowas wünschen wie... WAS kann FHEM WIE WOMIT?

Ich hatte die Sichtweise des "Interessierten", der FHEM noch nicht (umfänglich) kennt.
Der sagt sich m.E. "ich habe ein Device X (oder möchte es mir kaufen), kann ich das mit FHEM steuern!?

Dazu muss ich zunächst gucken... "kann FHEM das benötigte Protokoll?"
Anschliessend gucke ich... "welches Gateway benötige ich dafür?"
Und das am Besten noch unterteilt nach Anschluss (W)LAN, USB, Steckmodul, ?

So wie es jetzt ist, hat FHEM die unmittelbare "Treibersoftware" für die oberen IO-Devices, die alle auch eine firmware haben, die "selbständig irgendwas macht", also in diesem Sinn "extern" sind. Andere Dienste usw. haben keinen direkten Zugriff mehr, das gerät wird exklusiv von FHEM verwaltet.

Okay, das ist ein Argument.
Für einen HM-CFG-USB brauche ich ja im Zweifel auch noch etwas hmland oder wie das hiess; stände das unten?

Für MQTT2_SERVER gilt das umso mehr, der ist ja "nur Software".
Man könnte also beide Boxen vereinen und irgendwas von "exclusively managed" drüber schreiben? (m.E. eher nicht)

Hmm, oder bei betreffenden Devices ein Sternchen für "additional software required" oder so!?

Was m.E. aber Sinn macht: das "native" weg und stattdessen die Anbindung USB/UART hervorheben (also aus der Klammer nach oben)?
Das paßt dann zwar (nach wie vor) nur bedingt, weil auch ser2net möglich ist, aber diese Unsauberkeit kann man m.E. vernachlässigen.

Was ist dann mit (W)LAN?

Um die Grafik nicht total aufzublähen...
wie wäre es mit einem einfachen Kästchen für das jeweilige Protokoll, in dem dann kleine "Icons" für die verfügbaren "Anschlussarten" sind?
Dann könnte man die einzelnen Devices mit den zusätzlichen Angaben wie
- genaue Bezeichnung
- Verfügbarkeit (Serie, abgekündigt, nur noch Ersatz-/Gebraucht)
- Anschlusstyp
- direkte Unterstützung oder zusätzliche Software erforderlich
- Vor-/Nachteile
- ...
- erhältliche Sensoren/Aktoren?

in einer separaten (leichter zu aktualisierenden) Tabelle pflegen.

  EDIT: auf Basis der bisherigen Protokolle-Tabelle im Wiki

Bei den "externen" ist das anders. Die kann man auch von woanders her steuern. Vielleicht sollte man da reinschreiben: "Other (no exclucive FHEM control)"?

Das ginge dann auch in der Tabelle und müsste nicht in der Grafik differenziert werden.

Was die Nennung von Software rechts unter MQTT angeht: "Weniger ist mehr" (kann m.E. raus).

Genau, nur das Protokoll mit dem erforderlichen Gateway. 

Das ist im groben der Gedanke hinter "Wolke in Wolke" aka "Wolke vor Wolke", oder meinst du was anderes?
(Fehlt im Text/Artikel noch).

Mit Wolke verbinde ich immer gleich "Cloud". 

Ich würde beim "Server-Kasten" den Web-Browser einfach als "Frontend" darstellen;
da soll der Nutzer definieren, ob er denn von extern erreichbar macht oder nicht.

In dem Fall könnte man "den Weg" ebenfalls als Gateway darstellen...
dann gibt es halt die Protokolle HTTP(S) , HTTPMOD, ICAL oder so zur Verbindung mit anderen internen oder auch externen Diensten/Geräten.

Sind alles nur so Gedanken, daher bitte nicht falsch verstehen.
Ich befürchte nur, dass im aktuellen Stand eigentlich zu viel in der Grafik steht, und sie daher ständig angepasst werden müsste.
Die Unterstützung eines neuen Protokolls dagegen ist evtl. einfacher als neuer Kasten hinzufügbar.

[DasQ]

Is für dich vielleicht aus dem Zusammenhang gerissen, aber das Thema protokoll hatten wir im ursprungsthread schon angeschnitten und für 2much befunden. (Kann man ja gern auf eine weitere grafik auslager, wie ich schon sagt mehr in Richtung eigenwerbung)

BTW. Hier im Thread

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

Und der mehrfach genannte Wunsch ,,weniger ist mehr"

[Wernieman]

Also wenn juemand Wissen will, ob SEIN Produkt mit Fhem läuft, sollte er nicht in der Grafik, sondern im Text (Wiki, Forum etc.) nachsehen. Deshalb war ja auch mein Vorschlag, einen Block für "Alles was hier nicht drin ist" einzufügen. Nur um zu sagen, Fhem ist Größer als diese Grafik .....

Wenn man wirklich alles in die Grafik aufnehnen würde:
- Würde Sie sehr Groß
- Würde Sie sehr Unübersichtlich
- Würde Sie sehr Umfangreich
- ....
- Würde sie keiner Nutzen

Meine Erfahrungen aus Präsentationen: Keep it Simple ... und der Rest kommt in den Text / Begleitliteratur

[Hollo]

Also wenn juemand Wissen will, ob SEIN Produkt mit Fhem läuft, sollte er nicht in der Grafik, sondern im Text (Wiki, Forum etc.) nachsehen. Deshalb war ja auch mein Vorschlag, einen Block für "Alles was hier nicht drin ist" einzufügen. Nur um zu sagen, Fhem ist Größer als diese Grafik .....

Das sehe ich anders...
eine kleine Grafik mit FHEM kann diese "Protokolle" und zusätzlichen Texten, Tabellen mittels * (Sternchen mit den Anmerkungen) wird eher genutzt und ist m.E. wesentlich einfacher/informativer als lange Artikel/Threads etc.
Das eine als Einstieg "geht das evtl./überhaupt", das andere dann ausführlicher zum wie und unter welchen Bedingungen etc.

Wenn man wirklich alles in die Grafik aufnehnen würde:
- Würde Sie sehr Groß
- Würde Sie sehr Unübersichtlich
- Würde Sie sehr Umfangreich
- ....
- Würde sie keiner Nutzen

Meine Erfahrungen aus Präsentationen: Keep it Simple ... und der Rest kommt in den Text / Begleitliteratur

Sehe ich ja auch so...

...Ich befürchte nur, dass im aktuellen Stand eigentlich zu viel in der Grafik steht, und sie daher ständig angepasst werden müsste.
Die Unterstützung eines neuen Protokolls dagegen ist evtl. einfacher als neuer Kasten hinzufügbar.

[Beta-User]

"Alles" in der Grafik abzudecken, hatten wir ja schon diskutiert: M.E. ein "Ding der Unmöglichkeit".

Die Grafik soll "wenigstens" die "Grundzüge" erläuterbar machen, mehr bitte nicht. (Dafür ist es jetzt schon sehr komplex! Im Prinzip Ende Gelände, auch wenn es hier etwas anders ist als in einer Präsentation: Hier kann man weder direkt mehrere Grafiken hintereinander einblenden und die Dinge "im Fluß" erläutern (und auf Fragen unmittelbar eingehen), sondern kann dann nur _einen_ Text liefern, um das Gesamtgebilde zu erläutern...)

Was das

Block für "Alles was hier nicht drin ist" einzufügen.

angeht: Zusätzliche Elemente (eigene Stränge) von links nach rechts finde ich nach wie vor "too much", aber: ZWDongle/ZWave ist eigentlich als Prototyp für vieles andere zu verstehen (auf die Schnelle insbes. noch: EnOcean, MySensors). Wäre es eine Idee, zum einen "gestapelt" weitere Boxen jeweils dahinter (zum größten Teil verdeckt zu platzieren und diese Box mit "e.g. ZWDongle*" (bzw. "e.g. ZWave*") zu beschriften? Dazu die Anmerkung "*ZWDongle/ZWave: showcase for other bidirectional systems"?


Zum "Wo finde ich was?":
Der Wunsch, sowas zu haben, wurde schon häufiger geäußert. Fachlich liegt das in größerem Umfang außerhalb meiner persönlichen Kompetenz, aber es ist insbesondere keiner gehindert, die Tabelle(n) weiter zu füllen oder den Input dafür zu liefern...
Was ggf. zu überdenken wäre: Einen Abschnitt einzufügen, der erläutert, wie man (in der Regel) effektiv sucht?


Den Punkt mit "von woanders steuerbar" (oder eigene selbstdefinierte Logik auf dem Gerät möglich =>CCU2/3) würde ich ggf. auch gesondert aufgreifen; das ist aber eigentlich und v.a. eine Frage des debugging ("Warum zum T. schaltet mein Gerät ein/aus?!?...Was macht FHEM da?!?!?!?").


Zu den übrigen Punkten (bitte fragen, wenn was fehlen sollte):
- HM-Cfg-USB: kenne ich nicht in der Praxis, aber afaik wird hmland über einen Netzwerkport angesprochen und sollte daher theoretisch auch mehrere Clients bedienen können. Es gibt aber nur in FHEM Software (ein Modul), die das kann... Aber eigentlich gehörte es damit m.E. "nach unten". (Aber da nicht mehr käuflich (?): hat nichts mehr in der Grafik verloren...)
- "Wolke"/"Cloud"
Der Cloud-Begriff erscheint mir an sich schon unpräzise, von daher paßt das ganz gut. Die "Wolke" war halt schon immer eine, und m.E. darf die das gerne bleiben (bzw. dürfen es mehrere werden)...

Allgemein noch:
Wer keine umfangreiche Doku lesen mag, ist bei FHEM einfach falsch (my2ct)... Wir können versuchen, eine Art Wegweiser für die Prinzipien zu liefern, aber dann endet die Reise auch irgendwann.

[Hollo]

Is für dich vielleicht aus dem Zusammenhang gerissen, aber das Thema protokoll hatten wir im ursprungsthread schon angeschnitten und für 2much befunden. ...

...Und der mehrfach genannte Wunsch ,,weniger ist mehr"

Ich denke wir vier (Du, Beta-User, Wernieman und ich) sind da durchaus 1 Meinung!

In der Standard-Systemübersicht WENIGER darstellen...
was zum FHEM-Server an sich gehört und welche Schnittstellen/Protokolle es gibt.

Das Schaubild V4.1 hat doch m.E. schon zuviel.
Ich sehe halt die Spalten Interface und Sensoren/Aktoren eigentlich als 1 Protokoll-Spalte.
Wenn in beiden 1-Wire steht, brauche ich das nicht doppelt bzw. aktuell sogar 3x .
Wenn ich das einsetzen will, muss ich natürlich mehr lesen und gucken; das ist klar und kann auch nicht ersetzt werden.

[Beta-User]

Hmmm, wenn ich das richtig verstehe, würdest du den Schwerpunkt verlagern wollen, weg von einer Denke in konkreten "Hardware-Bausteinen" hin zu "Protokoll"?
Und dann rechts einfach eine Art (vollständiger...?) Protokollliste aufführen unter einer Überschrift ("Protocols & HA Hardware Systems")?

Ist zwar denkbar, hat aber ein paar Haken, die mich für den Moment davon abhalten, in diese Richtung weiter zu denken:
- M.E. müßte dann die Protokollliste vollständig sein, was ständigen Updatebedarf generiert. Fakt ist: FHEM "kann" alles (es muß nur ggf. noch ein Modul dafür geschrieben/angepaßt werden )... Daher hätte ich eher die Tendenz, genau diese Aussage im Text unten aufzuführen/zu erläutern. (Das fehlt da, oder?)

- Wenn ich mal versuche, mich in die Lage eines interessierten Laien zu versetzen und dann "unbedarft" irgendwie die Brücke zwischen einem bestimmten (vorhandenen/zu kaufenden) Stück Hardware und der Grafik zu finden, _darf_ m.E. das Bild gar nicht zu sehr vereinfacht sein. Es gibt eben oft nicht den eindeutigen Weg von einem bestimmten Sensor o. Aktor zu FHEM; z.B. für DS18x20, (was viele mit 1-wire verwechseln,) komme ich alleine auf die Schnelle auf 5 Varianten, bei zigbee sind es - je nach Zählweise 2-4...
Den "Unbedarften" genau (auch) auf dieses "Problem" zu leiten, wenn er mit einem konkreten Stück Hardware kommt, ist Absicht. Das darf m.E. so bleiben, denn es ist ein "Grundproblem".
(Wie oft muß man manchmal nach der Art der Einbindung fragen, weil das nicht präsent ist?!?)

Anders gewendet: Auch für erfahrenere User, die ggf. dann mal wieder auf das Schaubild sehen, ist es evtl. hilfreich, sich die Unterscheidungen nochmal zu vergegenwärtigen. Für die ist es dann aber hoffentlich nicht mehr so verwirrend vieldeutig wie für Neulinge .

- Schließlich: Das Schaubild ist Grundlage für den nachfolgenden Text. Wenn zu wenig unterscheidbares zu erkennen ist, kann man das auch nicht gut erläutern. Oder es braucht weitere Schaubilder, was ggf. auch eine Lösung für das Dilemma darstellen könnte.

Aber bitte: das ist eine spontane Einschätzung...

[DasQ]

Kurze Pause (und ein gewisser Abstand) und evtl. Rückmeldung abwarten ist für mich völlig ok.

- Was die * angeht: Dass der Text ruhig mini werden kann, hatte ich ja schon gesagt, und m.E. dürfen auch die Sterne selber unauffällig in den Hintergrund. Das ist ein Nebenaspekt, der eben mal die Schwelle dazu überschritten hat, dass man ihn überhaupt erwähnt, aber betonen muß man das (an der Stelle noch) nicht extra, dass bei FHEM viele Wege nach Rom führen können ...

- Wolke und flach: stimmt irgendwie... spontane Idee: zwei Wolken hintereinander, durch die teilweise überdeckte rechts den Teil-Pfeilzweig für Browser? Die Überschrift muß dann nur "zu den Wolken" gehören, aber nicht (vollständig) rein? (Und eine gewisse Stapelung von unten (vorne) nach oben (=hinten) wäre dann auch zu verschmerzen...

Aber grundsätzlich: Da steckt wirklich viel drin .

na dann schaun wir mal, wo ich überall fehler übersehn hab.
(sorry das länger gedauert hat, aber hier war arbeitstechnisch kurzzeitig landunter)



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

[Beta-User]

Vorab kurz:

Bei den Ausbuchtungen bei "Modules" weiß ich nocht nicht so recht, was ich davon halten soll, irgendwie läge mir immer noch ein schlichtes "sich-Berühren" zwischen der Server-Box und den IO-Boxen näher. Aber wenn man das so wie auf der Version von So. macht, müßte es unten bei "extern" auch dieselbe Art Ausbuchtung geben. 
(Wenn die Server-Box und die inneren IO-Boxen sich berühren, wäre es evtl. noch eine Verbesserung, den rechten Rand der "Module"-Box und den linken Rand der "Interface"-Box in eine optische Linie zu bringen?)

Die **-Anmerkung kann in jedem Fall raus samt den bezogenen **.

Die Wolken finde ich gut, würde aber die Überschrift so anbringen, dass sie in beide Wolkenteilen mind. teilweise drinsteht.

Schraffur in MQTT2_SERVER: an sich eine gute Idee, aber als konkrete Umsetzung würde mir eine feinere Schraffur als in CCU2 (soll ruhig vom Stil her anders sein) von links unten nach rechts oben eher zusagen. Die Farbgebung in dem Bereich würde ich bis auf den MQTT-grün-Anteil so halten wie die "Server"-Box (angefangen von der Umrandung; das ist schlicht ein Teil des "Server" mit einer "speziellen Funktion).

Mehr: später, vermutlich erst morgen...

Dann haben auch andere nochmal Gelegenheit, was dazu zu sagen .

[DasQ]

also mein hintergedanke war erst die art der verbindung, aber ich habe da schon eine idee wie des noch plastischer rüberkommt.

also nativ fhem wird ja irgenwie angestöpselt.
fhem intern ist eins mit mqtt2_server
und extern ist zwar ein interface, aber die verbindung zu fhem ist "unklar" (simpler datenaustausch?)

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

[Beta-User]

  Die Idee ist nett, und auch das mit den Doppelpfeilen kann man m.E. so bei den "externen Software-" Interfaces so machen (evtl. etwas nach unten damit, damit klarer ist, dass sich das nicht auf 00_CUL.pm bezieht).

Letztlich bringen wir damit eine optische Unterscheidung rein, die fast ein wenig "too much" ist, weil die Grenzen eben irgendwie auch fließend sind (siehe das HM-CFG-USB-Beispiel von Hollo), und was "simpler" Datenaustausch ist (und was "anderer als simpler"), darüber können wir wohl länger diskutieren .

Ich gehe daher mit beiden Varianten (einfaches Angrenzen der Boxen as described oder der "plug"-Variante von heute 09:03 Uhr). Da würde mich allerdings interessieren, wie andere das jeweils finden.

Auf der Basis von 09:03 hätte ich noch folgende Änderungswünsche:

- "IoT, " in der Wolke weg, und auch die Überschrift (3rd Party...) kann weg oder sollte wenn, dann eher in die Richtung "external data, e.g. ..." gehen (tendiere zu "weniger ist mehr"=>weglassen);
- Der Pfeil zur "allgemeinen" Wolke geht nur bis zum "Server", nicht zu "Frontends".
- Mit den "FHEM:..."-Überschriften bei IO's bin ich noch nicht glücklich, würde eher dazu tendieren
-- oben nur "USB/UART" drüber zu schreiben,
-- beim MQTT2_SERVER den vollen Modulnamen hinzuschreiben, und alles andere wegzulassen (also 00_MQTT2_SERVER.pm; evtl. auch beides (also den 00...) drunter in die Box zu schreiben (nein, vermutlich doch eher nicht, aber bitte die Überschrift einfach komplett rauslassen)).
- "External Soft-/Hardware" darf gerne insgesamt gleich groß geschrieben sein und etwas kleiner als "External";
- Die geklammerten Angaben im Server-Bereich sollten in einer etwas kleineren Schrift ausgeführt werden; das sind m.E. nur Erläuterungen/Anknüpfungspunkte für Erläuterungen im nachfolgenden Text.
- zu den *-Anmerkungen:
-- Der Erläuterungstext ist m.E. Fließtext, "options" und "integration" gehören daher klein geschrieben
-- Bei IT/LaCrosse...* sitzt der Stern an der richtigen Stelle, bei MQTT gehört er aber direkt an Shelly, und bei Zigbee direkt an die Überschrift "Zigbee*" (da geht es um die Übertragungstechnik an sich, die anders eingebunden wird, nicht die einzelne Hardware)
- Bei MQTT würde ich Hollos Anregung gerne aufgreifen und nur Hardware-Gadgets erwähnen; vollst. Details dann eher in der MQTT-Grafik im angrenzenden Post... Das ergibt dann "MQTT \n (e.g. TASMOTA or Shelly* devices)"

(Ich will zwar kurz erwähnen, dass MQTT2_SERVER in der Box nur ein Vertreter eines bestimmten Typs des Datenaustauschs ist, und die Grenzen noch mehr fließen, als oben schon angedeutet. Das näher zu erläutern, bringt uns aber m.E. nicht weiter, und wir sollten das auch nicht mehr auf der Grafik unterbringen wollen, weil mehr - jedenfalls nicht ohne größere Anpassungen - nicht auf die Grafik passt, und auch der Aussagegehalt der Grafik an sich dabei nicht "besser" würde).

[DasQ]

 

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

[Beta-User]

Paßt m.E. soweit!

Das gilt aber weiterhin:

Ich gehe daher mit beiden Varianten (einfaches Angrenzen der Boxen as described oder der "plug"-Variante von heute 09:03 Uhr). Da würde mich allerdings interessieren, wie andere das jeweils finden.

Ein paar Kleinigkeiten in jedem Fall bitte noch:

- "Integration" => "integration"
- Der * bei Zigbee darf in derselben Schriftgröße sein wie der vorangegangene Text (oder durch sonstige Maßnahmen weiter nach oben rücken, dann sollte aber alle oberen Sterne, also v.a. auch der bei IT/LaCrosse, dieselbe Größe bekommen...)
- das "internal" würde ich tendenziell auch noch ganz weglassen. Die Gestaltung der Box etc. ist m.E. jetzt so, dass es klar ist, dass es einfach ein "Module" ist, und alle Fragen bekommen wir via Grafik eh' nicht geklärt, sondern werfen dadurch eher wieder welche auf, die wir dann entweder beantworten müssen oder offen lassen; der Gegensatz zu "External Hard-/Software" (bitte noch ohne den Punkt ) hilft an der Stelle m.E. auch nur bedingt

[DasQ]

- "Integration" => "integration"

da hat mich adobe aber ganz gewaltig verarscht. das war/ist ein kompressionsfehler 

[Beta-User]

  ... die Qual der Wahl...

Das etwas größere "(fhem.pl)"@4_5 finde ich besser, das hebt die Sonderstellung dieser Datei mehr raus.

Auf die Schnelle sind mir jetzt noch 2 Kleinigkeiten aufgefallen:

- "Sensor or Actuators" => (einheitlich Ein- oder Mehrzahl) => "Sensors or Actuators" (man wird ja in der Regel mehrere haben...); da es Mischformen gibt, würde ich im Moment sogar dazu tendieren, entweder einen Querstrich statt or zu setzen, oder ein einfaches "&".... So machen wir es: "Sensors & Actuators".
- Die (Text-) Ausrichtung von HUEBridge und MQTT2_SERVER ist (@IO) jeweils nicht ganz mittig in der Box (ok, ist in 4_5 schon/noch ziemlich gefixt, sehe ich grade...)

[DasQ]

wenn wir hier fertig werden, soll ich die ganzen entwürfe hier im thread löschen?

[Beta-User]

Hmm, weiß nicht...
Damit verlieren halt die ganzen Anmerkungen ihren Bezugspunkt, aber eigentlich finde ich das nicht weiter schlimm. Andererseits kursiert dann auch nichts "falsches" mehr => tendenziell ja, löschen.

Lädst du die 4_7 ins wiki? (als neue Version am alten Ort, bitte)
Dann paß' ich bei Gelegenheit den Text weiter an...

[DasQ]

DONE

über grösse und plazierung könnte man nochmals drüberschaun.

[Beta-User]

Thx!

Das mit Größe und Platz ist gar nicht so easy... Ohne thumb bekommt man es nicht so toll vergrößert, mit muß es mittig sein, sonst gibt es einen Umlauf...

Hat da jemand eine Idee? (Gallery?)

Ansonsten bin ich mal "auf dei Schnelle" über den Artikel drüber und habe das eine oder andere angepaßt. Wer mag, darf kritisieren, aber an sich will ich auch erst nochmal in Ruhe den Thread hier durchgehen, was da schon alles angerissen war und das dann möglichst auch abarbeiten, bevor ihr richtig loslegen dürft . Bisher bin ich auch der Versuchung widerstanden, manches in Fußnoten zu verbannen (HM-CFG-USB, z.B., und manches andere rund um Homematic). Aber eigentlich fände ich das an der einen oder anderen Stelle nicht ganz verkehrt...

Bevor ich das vergesse: Ideen/Anregungen wg. des FLOORPLAN-Themas???

[Beta-User]

Hallo zusammen,

meine aktuelle Stichwortliste:

Wolke: Sprachsteuerung, weitere Erläuterung...
FLOORPLAN: wie damit umgehen?
ZWDongle/ZWave als Prototyp/"*ZWDongle/ZWave: showcase for other bidirectional systems"
Wo finde ich was? WAS kann FHEM WIE WOMIT... ("FHEM kann alles")
pgm2 - zu technisch/veraltet?
Homebrew... Nanocul usw ,Bastelecke

In dem Zusammenhang:
- Sprachsteuerung (m.E. als Teil der Wolke) taucht bisher gar nicht auf. Tendiere dazu, das (als Stichwort "voice control" in die Wolke aufzunehmen)?
- Irgendwie ist uns das prototypische bei ZWave verloren gegangen. Wenn wir die Grafik nochmal anfassen, sollten wir in den beiden Boxen m.e. das "e.g. " ergänzen...

Wer gerne noch was auf der Stichwortliste hätte: Bitte melden...

Aus aktuellem Anlaß habe ich auch einige Technologien (MAX! war der Anlaß) als "** evtl. nur noch gebraucht erhältlich" gekennzeichnet. Wer da noch Kandidaten hat: s.o.

[Beta-User]

Mal wieder ein Zwischenstand, nachdem ich etwas an dem Artikel weitergebastelt habe...

Eingang hat jetzt gefunden:
- Wolke: Sprachsteuerung, weitere Erläuterung... als neuer Abschnitt zu "Intra-/Internet"
- Den Abschnitt "Interfaces" habe ich in Richtung "ZWDongle/ZWave als Prototyp..." umgebaut, das ist jetzt auch etwas weniger HM-lastig und eher in Richtung "Viele Wege führen..." geworden. (Die Grafik könnte man trotzdem mit einem "e.g." versehen und bei der Gelegenheit noch "voice control" in die Wolke schreiben)
- Eine Hinweisbox zu "FHEM kann alles" ist dazugekommen

Im Moment finde ich diese Teile eigentlich schon ganz ok, der Artikel sollte m.E. weiter einigermaßen kurz bleiben, daher würde ich "Wo finde ich was? WAS kann FHEM WIE WOMIT..." eher nicht weiter vertiefen?

Offen wäre damit noch:
- pgm2 - zu technisch/veraltet?
- FLOORPLAN: wie damit umgehen?
- Homebrew... Nanocul usw ,Bastelecke

Zum letzten Punkt habe ich momentan keine rechte Idee, wie das in den Artikel passen könnte und neige zum Weglassen, bei den anderen beiden wäre ich weiter für Meinungen dankbar, wie das "allgemein" gesehen wird...

Grüße, Beta-User

[PeMue]

Hallo Beta-User,

Mal wieder ein Zwischenstand, nachdem ich etwas an dem Artikel weitergebastelt habe...

ich habe mir den Artikel mal durchgesehen, ist m.E. sehr gut verständlich. Ich habe noch ein paar Hinweise/Fragen:
- LAN fehlt in der Grafik komplett, d.h. man könnte z.B. eine HM-MOD-RPI-PCB über einen USR-K an das LAN hängen (Spezialfall)?
  Oder ist das der Doppelpfeil bei External Soft-/Hardware?
- Grafik: die CCU3 kann HM bzw, HM-IP, daher die beiden verschiedenen grünen Farben?
- Grafik: das MySensors Gateway fehlt, mit aufnehmen?
- Im Text: der JeeLink kann m.E. nur 868 MHz, 433 MHz Protokolle (die sich von den 868 MHz Protokollen unterscheiden) sind nicht implementiert.

Im Moment finde ich diese Teile eigentlich schon ganz ok, der Artikel sollte m.E. weiter einigermaßen kurz bleiben, daher würde ich "Wo finde ich was? WAS kann FHEM WIE WOMIT ..." eher nicht weiter vertiefen?
Offen wäre damit noch:
- Homebrew ... Nanocul usw., Bastelecke

Zum letzten Punkt habe ich momentan keine rechte Idee, wie das in den Artikel passen könnte und neige zum Weglassen, bei den anderen beiden wäre ich weiter für Meinungen dankbar, wie das "allgemein" gesehen wird...

Da würde ich keine eigene Kategorie im Bild spendieren. Homebrew ist halt Homematic im Eigenbau (ggf. mit erweiterten Funktionen, Big-Fixen, (noch) nicht implementieren ePaper Displays, usw.).
Ggf. könnte man im Text unter Interfaces beim JeeLink das LacrosseGateWay noch als Interface mit aufnehmen (gibt es auch nur hier  .
Dito für den immer populärer werdenden mapleCUx (Stichwort "eierlegende Wollmiilchsau"  ).
Wenn Du magst, mache ich die Korrekturen inkl. Verlinkung. Dito für die diversen Modulationsarten, die noch offen sind. Bei Protokollen würde ich die EC3000 mit aufnehmen.

... daher würde ich "Wo finde ich was? WAS kann FHEM WIE WOMIT ..." eher nicht weiter vertiefen?

Beim zweiten Lesen meiner Antwort, ist mir noch ein Gedanke gekommen. Aus Anwendersicht ist die Systemstruktur ggf. gar nicht so wichtig. Er will vielmehr wissen, was brauche ich, wenn ich z.B.
- die Heizung im Zimmer (inkl. Fenster) überwachen/steuern will
- die Solaranlage/Heizung/... überwachen will (inkl. Urlaubsassistent)
- die Lichter steuern will (mit Sprachsteuerung, Anwesenheitserkennung, etc.)
- usw.
Wäre das nicht ein Ansatz, die verschiedenen HowTos mittels übergeordneter Kategorien zu sortieren/strukturieren? Es kann aber sein, dass ich gerade über das Ziel hinausschieße, dann bremst mich bitte


Gruß Peter

[Beta-User]

Hi Peter,

Danke für deine (überwiegend positiven) Anmerkungen, ich versuch's mal in der Reihenfolge zu beantworten:

- LAN fehlt in der Grafik komplett, d.h. man könnte z.B. eine HM-MOD-RPI-PCB über einen USR-K an das LAN hängen (Spezialfall)?
Oder ist das der Doppelpfeil bei External Soft-/Hardware?

(Vorab: auf der Grafik ist eigentlich schon too much... Erweiterungen daher bitte nur, wenn das "zwingend" ist .)

Ansonsten ist "LAN" zwar ein Stichwort, mit dem der geneigte Leser (in dem Fall gedanklich...) irgendwas verbindet, aber die Frage ist, auf was wir die Gedanken dann leiten wollen? Im Fall des USR-K ist bedauerlich, dass den so wenige kennen, aber für die Darstellung auf der Grafik reicht das m.E. nicht als Argument - genausowenig wie die viel bekannteren Varianten HM-MOD-RPI-PCB+(MapleCUN|ESP8266) was auf der Grafik zu suchen haben (mMn.)...
Vielleicht wäre es eine Idee, im Text unten bei dem Modul den Hinweis anzubringen, dass man das nicht nur an den PI-GPIO betreiben kann? (Der Rest steht m.E. hier und sollte dort (bzw. den weiteren Links dort) ggf. verbessert werden: https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Verwendung_mit_anderer_Hardware.

Da es eigentlich eine mit einem "dummen" Netzwerkgerät verlängerte serielle Verbindung ist, ist das in den Kategorien, die wir irgendwann in der Vergangenheit hier mal diskutiert hatten keine "External"-Sache, sondern eher ein "dummes" Ersatz-Interface statt USB/GPIO-seriell .

- Grafik: die CCU3 kann HM bzw, HM-IP, daher die beiden verschiedenen grünen Farben?

Yup! (Scheint einleuchtend zu sein... )

- Grafik: das MySensors Gateway fehlt, mit aufnehmen?

Eher den ZWave-Teil mit "e.g." belabeln, MySensors ist "nur" - wie EnOcean, das auch (mit Absicht, s.o.) fehlt - ein weiterer Vertreter eines "2-stufigen Moduls".

- Im Text: der JeeLink kann m.E. nur 868 MHz, 433 MHz Protokolle (die sich von den 868 MHz Protokollen unterscheiden) sind nicht implementiert.
Da würde ich keine eigene Kategorie im Bild spendieren. Homebrew ist halt Homematic im Eigenbau (ggf. mit erweiterten Funktionen, Big-Fixen, (noch) nicht implementieren ePaper Displays, usw.).
Ggf. könnte man im Text unter Interfaces beim JeeLink das LacrosseGateWay noch als Interface mit aufnehmen (gibt es auch nur hier .
Dito für den immer populärer werdenden mapleCUx (Stichwort "eierlegende Wollmiilchsau"  ).
Wenn Du magst, mache ich die Korrekturen inkl. Verlinkung. Dito für die diversen Modulationsarten, die noch offen sind. Bei Protokollen würde ich die EC3000 mit aufnehmen.

Entsprechende Klarstellungen und Ergänzungen im Text von Leuten, die wissen, was sie schreiben, sind jederzeit willkommen . Ich habe immer "Bauchschmerzen", wenn ich - zwangsläufig - über Dinge schreibe, die ich nicht (wirklich) kenne...
Homebrew könnte z.B. zumindest in die Bemerkungen bei HomeMatic rein?

(dto. für die Wired-Variante, und wo ich das lese: gab es nicht auch die simple (und bessere...!) Option, einen "ganz einfachen" RS485-USB-Stick als IO dafür zu verwenden...?!?)

Beim zweiten Lesen meiner Antwort, ist mir noch ein Gedanke gekommen. Aus Anwendersicht ist die Systemstruktur ggf. gar nicht so wichtig. Er will vielmehr wissen, was brauche ich, wenn ich z.B.
- die Heizung im Zimmer (inkl. Fenster) überwachen/steuern will
- die Solaranlage/Heizung/... überwachen will (inkl. Urlaubsassistent)
- die Lichter steuern will (mit Sprachsteuerung, Anwesenheitserkennung, etc.)
- usw.
Wäre das nicht ein Ansatz, die verschiedenen HowTos mittels übergeordneter Kategorien zu sortieren/strukturieren? Es kann aber sein, dass ich gerade über das Ziel hinausschieße, dann bremst mich bitte

Uhhh, noch eine Baustelle...
Grundsätzlich gebe ich dir in zwei Punkten recht:
- Zum einen ist sowas wie dieser Artikel eher was Leute wie mich, die erst mal ein bisschen Theorie - hier eben Begriffskategorien - bzw. einen systematischen Überblick brauchen, bevor sie was kapieren.
- Leute, die eher den praktischen Angang haben und sich Theorie nebenher beim Nachvollziehen von Lösungen aneignen, wäre eine redaktionelle Aufarbeitung dieser doch schon ziemlich langen Liste hilfreich.

K.A., ob das allgemein bekannt ist, ich bin jedenfalls neulich darüber gestolpert, dass man die Einordnung der Artikel in die Kategorienseite beeinflussen kann, indem man das Schlagwort mit angibt, unter dem etwas einzusortieren ist. Hier das Beispiel, wie das in https://wiki.fhem.de/wiki/MQTT gelöst ist. Damit wird der Artikel auf der Kategorienseite ganz am Anfang und dann unter "E" wie "MQTT Einführung" angezeigt (auch noch kursiv...):
[[Kategorie:MQTT|Einführung]]
[[Kategorie:MQTT| ]]

Dann sollte man sich aber ggf. vorab ein paar Gedanken machen, wie die Struktur da aussehen sollte, der Rest wäre Fleißarbeit (und gesonder zu diskutieren?)...

[Prof. Dr. Peter Henning]

Kleiner Korrekturwunsch: Viele haben ihre Zigbee-Geräte über den deConz-Server und die Interfaces von Dresden Elektronik angeschlossen. Das bewegt sich dann auf demselben Niveau wie die Huebridge. Im Kasten sollte also (wie bei HomeMatic) stehen ZigBee und darunter in Klammern (Huebridge, RaspBee).

LG

pah

[Beta-User]

Mit "Kasten" meinst du die Grafik ganz oben?

Wenn ja: Inhaltlich ist das auch bei deCONZ das HUEBridge-Modul, das paßt eigentlich, zumal ja auch rechts dann der Hinweis steht, dass des weitere Optionen gibt. "An sich" könnte man da noch ein paar weitere reinpacken (tradfri-Bridge, und von/für Xiaomi gibt es auch was (?)). Was dann aber nicht mehr recht in das Schema paßt, ist zigbee2mqtt, hmmm...?
Neige dazu, das (bei der Grafik) so zu lassen, aber wenn noch mehrere der Ansicht sind, das wäre sinnvoll, ist das auch iO. (vorausgesetzt, @DasQ hat Lust, das umzusetzen).

Allerdings finde ich die Anregung völlig berechtigt, ZigBee an anderen Stellen im Artikel etwas mehr zu promoten. Das hat sich in den letzten Monaten dank IKEA, Aldi &Xiaomi von einer teuren Lösung weniger Hersteller hin zur echten Massenware entwickelt. In der Protokolle-Tabelle habe ich da schon etwas gebastelt und bin am überlegen, ob und ggf. wie das Thema bei Interfaces einen guten Platz haben könnte.
Der reinen Lehre nach wäre das aber dann wieder eine konkrete Hardware...? Dann den ConBee II vorneweg noch vor CUL?!? Dahinter dann den Hinweis auf Hardware-Alternativen?

Muß ich mal sacken lassen, vielleicht hast du oder sonst jemand eine Idee?

[Prof. Dr. Peter Henning]

Meine neues FHEM-Grundlagenbuch erscheint in 2 Wochen - da habe ich den Hardware-Teil bewusst kurz gehalten. Ein wichtiger Beitrag darin sind aber die Shelly-Aktoren, weil sie eben ohne Zusatzhardware auskommen, einfach im WLAN eingebunden sind, und auch nicht nur über MQTT funktionieren.

Dieser Pfad - IP-basierte Devices mit dezidierten Modulen ebenso wie HTTPMOD - fehlen in dem Diagramm komplett.

LG

pah

[Beta-User]

Dieser Pfad - IP-basierte Devices mit dezidierten Modulen ebenso wie HTTPMOD - fehlen in dem Diagramm komplett.

Hmm, der Hinweis ist berechtigt (betr. auf die Schnelle z.B. auch ESPEasy) .

Damit stehen wir wieder vor der Frage, ob "noch was" auf die Grafik muß.

Bin geneigt, das doch zu machen, weil auch noch ein paar andere Kleinigkeiten offen sind.

Würde dann die Ausbuchtung, in der heute nur der MQTT2_SERVER steht etwas vergrößern wollen, da "IP-based" drüberschreiben und dann darunter noch eine Box mit "native IP based \ (e.g. HTTPMOD, Shelly, ESPEasy)" einfügen, dazu korrespondierend auf der "Sensors&Actuators"-Schiene noch einen "Box-Stapel" mit "Shelly, ESPEasy,..."?

@DasQ: Ginge das, ohne dass du komplett von vorne anfangen müßtest? Oder gibt es andere Lösungen, bei denen z.B. nicht alles gleich sichtbar wäre (ich habe dazu noch keine konkrete Idee...).

[Wernieman]

Selly/ESP8266 etc. finde ich eigentlich auch sehr wichtig.

Aber genau aus den Gründen hatte ich am Anfang gesagt, das ersichtlich sein muß, das noch vieiel mehr geht. Im Diagramm sollten wirklich "nur" die Wichtigsten Sein. Sonst wird es unübersichtlich

[Beta-User]

Na ja, mMn. ist es ziemlich viel, was zu "den Wichtigsten" zählt, das macht es schwierig, wenn man konkret wird.

Die Alternative wäre, die Grafik ganz radikal zu vereinfachen, und nur noch dazu zu nutzen, erst mal Begrifflichkeiten zu klären....

Vielleicht als eine Art "Schalenmodell" (also eine Kugel mit mehreren Schichten drumrum)?- Im Kern fhem.pl, darum die "Configuration", die dann "Modules" enthält, die eben mehr oder weniger nah am Kern sind, oben "drumrum" eine Wolke, untendrunter "Sensors&Actuators", dabei aber gar keine spezifische Verbindungen zwischen einzelnen Elmenten, sondern nur noch "pauschale Pfeile"?

(Müßte man evtl. mal austesten, vielleicht hat auch jemand noch eine andere Idee)?

Würde dann dazu führen, dass man manches an Detailgrafiken erläutern müßte, aber z.B. auch den Homematic-Kram schlicht in den Homematik-Artikel "verbannen" könnte... (Mit Verlaub, aber CUL_HM gehört mMn. mittelfristig vermutlich in die Kiste "nicht mehr so wichtig").
Aber den "WLAN-Kram" ( seht mir die Begrifflichkeit bitte nach...) nach vorne zu schieben, ohne das "Warnschild: Infrastruktur muß passen" aufzustellen ist auch suboptimal...

[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 .