Ü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