Überarbeitung "Systemübersicht"

Beta-User · 01 Juli 2019, 12:06:13

Zitat von: DasQ am 01 Juli 2019, 10:08:41
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 · 01 Juli 2019, 14:39:25

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 · 01 Juli 2019, 15:07:53

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 · 01 Juli 2019, 15:41:38

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

Beta-User · 01 Juli 2019, 15:47:50

Zitat von: DasQ am 01 Juli 2019, 15:41:38
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 · 01 Juli 2019, 16:20:05

die datenaustauschstriche passen noch nicht

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

Beta-User · 01 Juli 2019, 16:26:31

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 · 02 Juli 2019, 11:53:08

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 · 02 Juli 2019, 12:45:01

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 · 02 Juli 2019, 15:50:25

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

Beta-User · 02 Juli 2019, 16:33:08

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 · 02 Juli 2019, 16:52:40

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 · 02 Juli 2019, 17:11:35

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 · 03 Juli 2019, 12:09:20

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 · 03 Juli 2019, 12:57:04

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