Überarbeitung "Systemübersicht"

[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