Search the Community

Hallo Leute, zuerstmal sorry für die lange Wartezeit. Die letzten Wochen waren bei mir beruflich sehr stressig wodurch die Motiviation und Energie für alle anderen Projekte leider entsprechend gelitten hat. Zusätzlich muss ich sagen das die Umsetzung der CDL doch etwas komplexer war als erhofft, aber alles der Reihe nach: Die Implementierung Wie der Titel schon sagt steht Version 0.2 der CDL, wobei ich immer schlecht in Versionsnummern bin. Eigentlich stehts kurz vor Version 1.0 . Von den Funktionen her ist jetzt alles drin was in den vorigen Beiträgen beschrieben wurde. Umgesetzt hab ichs auch ziemlich genau wie geplant. Da es in MT scheinbar keine Möglichkeit gibt ein Teilarray als Parameter zu übergeben (also zB array[2] von einem 2-dimensionalen Array) wars teils etwas komplizierter zu schreiben, aber mei. Es geht ja erstmal nur um einen Proof-of-Concept. noch ein paar technische Details: Um die Lesbarkeit ein wenig aufrecht zu erhalten, hab ich die Lib inzwischen in mehrere mqh aufgeteilt die jedoch nur zusammen funktionieren. Aber dadurch erspart man sich das ewige Suchen und Scrollen im großen File. Es gibt derzeit 3 mqh und die lib selbst, jedes File ca 300 Zeilen. Also für ein "richtiges" Softwareprojekt nicht erwähnenswert. (Ich frag mich grad wieso ich solang dafür gebraucht hab ) Funktionsweise und Testablauf Die Grundfunktionalität ist wie gesagt ziemlich genau wie geplant. Zusätzlich hab ich noch speichern der Patterns in Files hinzugefügt: Jedes Pattern erhält sein eigenes File. Der Dateiname setzt sich aus der Trefferquote des Patterns und der ID zusammen. Die Trefferquote hab ich dazugetan damit man schnell die guten Patterns analysieren kann. Zusätzlich gibts ein File mit einer Liste der derzeit aktiven Patterns (inkl. Trefferquote damit man eindeutig das File findet). Im Moment wird die Dateistruktur aber nur zur manuellen Analyse verwendet. Ursprünglich wollte ich ja mit einer Menge von "klassischen" Chartpattern starten und diese Evolutionieren lassen, aber aus Faulheit geh ich derzeit her und erzeuge einfach zufällig 50 Patterns als Start. Pro Generation werden alle mit einer Trefferquote in den oberen 20% zur "Fortpflanzung" verwendet. Außerdem werden (im Gegensatz zum Plan) 30% der alten guten (also obere 20%) Patterns wiederverwendet. Aus dem einfachen Grund weil sonst gute Patterns in der Evolution verloren gehen könnten (und auch wirklich verloren gingen). Wenn die beste Trefferquote erste Ergebnisse Gehts rein nach den Werten bin ich jetzt natürlich schon lange reich Gestern Abend hab ich die ersten Evolutionen laufen lassen und bereits nach ein paar Generationen ist die Trefferquote von 0 auf 99% gestiegen. (bei 5000 Bars im Test) und das unabhängig vom TF. Meine anfängliche Skepsis war leider berechtigt: Bei der Entwicklung haben sich ein paar "Denkfehler" eingeschlichen. Es sind einfach nicht alle Targetfunktionen sinnvoll, hier eine Liste der bisher erkannten Denkfehler: Breakout/Breakthrough: Die minimale Bewegung nach dem Durchbruch darf natürlich nicht negativ sein. Das Target "Wenn das High > 10 ist, dann muss auch High > 10-2=8 sein" ist zwar immer erfüllt, bringt aber in der Tradingpraxis nicht sehr viel Die Schwelle beim Breakout/Breakthrough darf erst inbar durchschritten werden, sprich im Longfall muss gelten Open Low[0] => High[-1] > Low[0]+X" sehr häufig stimmt... Ein Breakout-Target bringt halt nur was, wenn man auch an der Schwelle einsteigen kann... Die minimale Bewegung muss größer als der Spread sein. Es bring nichts wenn ein Breakout passiert und der Kurs mindestens 1 Pip weiterläuft. Das Target ist zwar meist erfüllt, aber im Tradingalltag nicht profitabel Relative Bewegungen sind mit Vorsicht zu genießen. Gleiche Begründung wie beim Spread. Im M1 Chart hilft dir eine Bewegung von 5% vom Vorbar nicht wirklich was, das sind dann immer noch nur ein paar Pips. Um diese Situationen zu verhindern, hab ich Targetconstraints eingeführt. Nach Mutation und Paarung werden die Patterns auf diese Constraints zurechtgestutzt. also zB wird das "isRelative" Flag bei TF 0 gestutzt etc. Zusätzlich hab ich in der Targetauswertung den Spread miteinkalkuliert. Mit diesen Verbesserungen läuft jetzt eine neue Simulation. Im Daily sind wir bereits nach 30 Generationen auf > 90% Trefferquote, H1 auf 52%, M1 steht nach 200 Generationen immer noch bei 6 % und M15 hat erst 3 Generationen durch ;) Noch was technisches zu den Simulationen: Da ich hier keine Backtests mache sondern rein die Generationen in einem Skript laufen lasse, kann ich in einer MT Instanz das Skript auf mehreren Charts/TFs laufen lassen wodurch ich brav alle Kerne belasten kann :D Soweit mal der Zwischenbericht. Mal sehen wieviele Denkfehler und Stolpersteine ich heute noch finde... Freu mich wie immer auf Kommentare und Anregungen. Thx for reading

Eigentlich wollte ich gerade mit der Implementierung anfangen, da hab ich gemerkt das ich das Bewertungssystem noch gar nicht beschrieben habe. Im letzten Eintrag hab ich gerade noch beschrieben wann ein Chartpattern auf den aktuellen Kursverlauf matcht. Aber für die Evolution dürfen sich ja nur die "erfolgreichsten" fortpflanzen. Also folgender Plan für die "natürliche Auslese" : Jede Generation wird natürlich neu bewertet, es bringt also nix wenn die Eltern erfolgreich waren. Jedes Pattern einer Generation wird auf X (vermutlich 5000) Bars getestet, wenn es matcht und das Target erfüllt bekommt es Bewertung +1. Gleichzeitig wird mitgezählt wie oft es gematcht hat. Die Gesamtbewertung berechnet sich dann folgend: Ist die Anzahl der matches > X/10: Gesamtbewertung = Bewertung/Anzahl. Ist die Anzahl Gesamtbewertung= Bewertung/Anzahl* (Anzahl/(X/10)) = 10*Bewertung/X Sprich wenn es weniger als in 10% der Fälle matcht, wird die relative Bewertung linear reduziert bis 0. So, jetzt kann die Implementierung aber endgültig starten.

Weiter gehts. In Teil 1 hab ich die Grundstruktur und die Targets beschrieben. Jetzt kommen die eigentlichen Regeln der CDL: Ein Chartpattern soll wie gesagt durch eine Anzahl an Regeln beschrieben werden. Für den Anfang werd ich mich auf 2 Typen von Regeln beschränken und mal hoffen damit möglichst viel abzudecken. Die Regeln RULE_BAR_FORM Diese Regel definiert das Aussehen eines bestimmten Bars im Pattern. Damit werden bei Patterns mit nur 1 Bar zB typische Candle-patterns abgedeckt (Hammer etc.). Bei Patterns mit mehreren Bars kann man dann aber auch so Sachen wie die "3 weißen Soldaten" (ich glaub das heißt so) abbilden (einfach 3 dieser Regeln, einen pro Bar). Parameter: # BarOffset: welcher Bar im Pattern gemeint ist 0 ... der aktuellste Bar, 1... einer davor etc. # Direction: > 0 bedeutet C >= O, # isRelativ: wenn > 0 sind die folgenden Werte in Prozent von H-L zu werten (bzw. in Anteilen, vor Abgleich werden sie also normiert das die Summe 100% ergibt). Ansonsten in Pips # sizeCandle: Größe des Kerzenkörpers = ABS(C-O) # upperDocht: = H-MAX(O,C) # lowerDocht: = MIN(O,C)-L RULE_VALUE_RELATION Mit dieser Rule soll alles abgebildet werden können was die Relation zwischen 2 Werten (definiert über PriceID) innerhalb des Patterns definiert. zB "steigende Highs über 3 Bars" kann mit den Regeln "H[2] Parameter: # Price1 - eine PriceID # Price2 - eine PriceID # minDiff - die minimale Differenz zwischen den Werten. Bei negativer Differenz gilt Price1 = Price2 + minDiff # isRelative: wenn > 0 ist die minDiff in Prozent von H-L vom Bar von Price1 Mutation und Kombination Der Mutationsteil ist recht einfach: jeder Parameter hat bei jedem Wert eine "sinnvolle" Bedeutung, somit kann jeder Parameter "beliebig" mutiert und verändert werden. Einzig bei PriceIDs werde ich es so einschränken das nur entweder der BarsBack-Teil oder der Identifier mutiert wird. Außerdem können natürlich zufällig neue Regeln dazukommen. Bei der Kombination werde ich nur die Vermischung von gleichen Regel-typen zulassen. Bei PriceIDs gibt es entweder eine Vermischung der BarsBack Komponente oder einer der zwei Identifier wird gewählt. Alle anderen Parameter werden als zufällig gewichteter Mittelwert der Eltern gewählt. Um das Ganze ein bissl geordnet zu halten, werden die Regeln immer sortiert gespeichert. Zurest RULE_BAR_FORMs und dann RULE_VALUE_RELATIONs. Und hier auch nach Offset bzw. Price1 sortiert. Sprich wenn möglich werden "gleiche" Regeln (zB Barform des 2. Bars) miteinander kombiniert. Gibt es eine Regel nur in einem Elternpattern, wird zufällig entschieden ob sie übernommen wird oder nicht und ggf. mutiert. Die Kombination der Targets ist etwas schwerer. Da jedes Pattern nur ein Target haben kann, wird bei Patterns mit unterschiedlichen Targettypen eines der beiden gewählt. Dieses Eltern-pattern hat dann ein stärkeres Gewicht bei der Regel-kombination (damit die Regeln zum Target passen, bzw. weil sich dessen Gene beim Target auch schon "durchgesetzt" haben ;) Redundanz Auf diese Weise (vor allem durch Mutation) kann es natürlich passieren das es eine Regel mehrfach (oder mehrfach sehr ähnlich) gibt. Das ist durchaus gewollt und ist auch in unserer DNS so gehalten. Wichtige Bausteine sind immer wieder beschrieben, verändert sich eine der vielen Beschreibungen zu sehr, wird sie von einer der anderen einfach überschrieben. In unserem Fall wird nichts überschrieben, aber wenn eine Regel "wichtig ist" / oft vorkommt kann diese damit nicht so ausradiert werden. Bzw. es überlebt jenes Pattern lange, wo diese Regel öfter vorkommt und die damit nicht so anfällig für Mutation der "wichtigen" Regeln ist. Matching eines Patterns Was noch fehlt ist die Entscheidung ob ein Pattern matcht (und damit das Target überprüft werden muss). Zuerst wird jede Regeln einzeln überprüft und eine Übereinstimmungsquote in Prozent berechnet. Bei ValueRelation wird es einen leicht fließenden Übergang beim Schwellwert geben. Bei BarForm gibt es diesen Übergang für jeden Wert wobei die Direction stärker gewichtet ist. Die Quote für ein BarForm ist das gewichtete Mittel von dessen Einzelquoten. Dann wird der Mittelwert aus diesen Quoten berechnet. Ist die resultierende Gesamtquote größer als ein Schwellwert, "matcht" das Pattern. Jo.. damit wär glaub ich mal die Version 1.0 der CDL beschrieben (Beschreibung einer Description... ). Nächster Punkt ist die Implementierung. Bleibt also spannend, noch ist die Hoffnung auf den Gral nicht verloren ;)

Dann legen wir mal mit dem 2. Teil des Projektes los: Die Evolution der Pattern-Recognition. (Der Titel ist doch schon mal schön ;) Die Idee dahinter Es wird wie gesagt ein Evolutionsalgorithmus. Entwickelt (Evolutioniert klingt komisch) werden Chartpatterns die eine statistisch signifikante Prognose geben. Hierbei will ich mich gar nicht weiter einschränken was die Chartpatterns angeht. Zu Beginn werden es sicher nur simple Patterns, mit der Zeit soll aber deren Komplexität auch ausgebaut werden (soweit es MQL halt zulässt). Chart-Pattern Description Language Um überhaupt Evolution betreiben zu können, benötigt es eine Definition der "Gene". Bzw. eine Beschreibung welches Gen was bewirkt. Anders gesagt muss es gelingen "beliebige" Chart-Patterns mit einer (möglichst kleinen) Menge an Parametern eindeutig zu beschreiben. Ich nenn diese Beschreibung jetzt einfach mal Chart-Pattern Description Language (kurz CDL). Da ich sowas selber noch nie gemacht habe, kann es leicht sein das die CDL sich im Laufe der Entwicklung noch gravierend ändert, nur als Vorwarnung. Zunächst wird die CDL aus einer (beliebigen) Anzahl an Regeln bestehen. Von den Regeln wird es mehrere Typen geben. zB "Bar X hat folgende Form" oder "Wert von Bar X steht in diesem Verhältnis zu Wert von Bar Y". Über die CDL werde ich noch einen eigenen Eintrag schreiben. Die Bewertungsfunktion Jedes Pattern bekommt eine "Targetfunktion". Sprich es muss nicht jedes Pattern das Close des nächsten Bars vorhersagen. Auch hier wird es wieder unterschiedliche Typen geben. zB "Wenn beim nächsten Bar Preis X überstiegen wird, steigt der Preis um Y weiter", oder eben das klassische "Der nächste Close ist mind. X über dem aktuellen". Weiters gibt es für jede Regel in der CDL eine "Ähnlichkeitsfunktion" die entscheidet wie sehr das aktuelle Chartbild diese Regel erfüllt. Ist die gesamte Ähnlichkeit des Patterns unter dem Schwellwert, so "muss" die Aussage der Targetfunktion zutreffen. Bewertet wird wie oft die Targetfunktion zutrifft relativ zur Anzahl wie oft das Pattern gepasst hat. Matcht das Pattern zu selten (zB Die Evolution Erfolgreiche Patterns werden dann miteinander kombiniert: Sprich es wird eine Teilmenge der Regeln der beiden "Eltern" übernommen. Wenn beide Eltern eine Regel enthalten, so kommt sie "sehr wahrscheinlich" auch ins neue Pattern und die Parameter der Regel werden "kombiniert". Zusätzlich gibt es natürlich Mutationen, sprich es kommen teils zufällig neue Regel dazu. Bzw. Regeln ändern ihre Parameter teils zufällig. Die Implementierung Wenn sich jetzt jemand fragt wie zum Teufel ich das in MQL bauen will, da hab ich ehrlich gesagt selber noch keine Ahnung. Das Projekt schreit ja regelrecht nach Objektorientierung. Aber zumindest in der ersten Version wird sich schon ein Weg finden. Ggf. muss ich halt auf eine C++ dll ausweichen, das will ich aber so gut es geht vermeiden. als dann wiedermal thx for reading ;)

Wie versprochen Version 0.1 der CDL aka "Was ich mir grad vorm Fernseher zusammengereimt habe" Anforderungen Die CDL soll wie gesagt die Möglichkeit liefern ein Chartpattern möglichst genau zu beschreiben und dabei einem möglichst allgemeinem Muster folgen. Jede Pattern-Beschreibung soll aus ein Reihe eigenständiger Definition/Regeln bestehen, die beliebig kombiniert und ersetzt werden können. Es sollte möglich sein Regeln miteinander zu vergleichen um "ähnliche" Regeln zu vermischen Jede Regel muss eine Möglichkeit der Kombination mit "ähnlichen" Regeln haben, sowie Möglichkeiten der "Mutation" (zufällige Veränderung der Regel sodass sie (meistens) sinnvoll bleibt). Zugegeben, diese Anforderungen sind bereits mit einer Idee für die CDL geschrieben. Trotzdem spiegeln sie glaub ich die Grundanforderungen recht gut wider. Grundaufbau der CDL Jedes Chartpattern wird beschrieben von einer Reihe von Regeln und einem Target. Repräsentiert werden diese Regeln und das Target je als ein Array. Dadurch ist sogar eine "effiziente" Verwaltung in MT möglich. Der Einfachheitshalber besteht jedes Pattern aus maximal 50 Regeln und jede Regel wird mit maximal 10 (muss ggf. erweitert werden) Werten definiert. Das Target wird ebenfalls mit maximal 10 Werten definiert. Es gibt verschiedene Typen von Regeln und Targets. Der erste definierende Wert jeder Regel/Target bestimmt dessen Typ und entsprechend werden die darauffolgenden Werte interpretiert. Ein Chartpattern ist also mit einem 2D-Array nach folgendem Muster definiert: In Zeile 1 sind "technische" Werte des Patterns gespeichert (Anzahl der verwendeten Regeln, maxBarsBack etc), also Werte die nicht zu den Genen des Patterns zählen sondern für die konkrete Implementierung notwendig sind, eine Art "Header". pattern[1][0-9] enthält das Target. pattern[1][0] ist der Typ des Targets, die restlichen Werte in dieser Zeile sind vom Typ des Targets abhängig. pattern[2][0-9] enthält die erste Regel des Patterns. Wiederum enthält pattern[2][0] den Typ, der Rest ist abhängig vom Typ. pattern[3][0-9] enthält die zweite Regel und so weiter PriceID Da innerhalb der Regeln immer wieder auf verschiedene Preise referenziert wird, müssen diese codiert werden. Dies erfolgt mit den PriceIDs nach dieser Form: X wobei X aus 0-9 ist und angibt welcher Wert des entsprechenden Bars verwendet wird. 0 - Open, 1-High, 2-Low, 3-Close, 4-(H+L)/2, 5- (H+L+C)/3, 6- HighestHigh im Pattern, 7-LowestLow im Pattern wird also auf das High des aktuellen Bars referenziert ist die PriceID 1, High des letzten Bars: 11, Close des vorletzten Bars: 23, Open des 10. letzten Bars: 100 etc. Die Targets Zu Beginn gibt es mal 3 Typen von Targets: TARGET_PREDICTION Bedeutet eine Vorhersage des Close des nächsten Bars, jedoch nicht punktgenau sondern nur die Richtung und minimale Bewegung. Parameter: # Richtung +1 für rauf, -1 für runter # min Bewegung # isRelative: minimale Bewegung ist absolute oder % des aktuellen Bars Das Target ist erfüllt wenn der Close des nächsten Bars die entsprechende Entfernung in der gegeben Richtung überschreitet. (Oder sollte man hier besser High/Low nehmen, also die maximale Bewegung im nächsten Bar?) TARGET_BREAKOUT_MOVE Dieses Target ist gedacht für Patterns wie Keile. Wenn die obere Schwelle durchbrochen wird, muss eine starke Bewegung nach oben folgen, wird die untere durchbrochen eine Bewegung nach unten. Parameter: # Schwelle Long - eine PriceID # Schwelle Short - eine PriceID # min Bewegung bei Durchbruch # isRelative (wie oben) Das Target ist erfüllt wenn der Bar nach dem Pattern eine (genau eine?) Schwelle durchbricht und die mindestens die min Bewegung weiterläuft oder keine der beiden Schwellen durchbricht (dann zählt das Pattern als nicht gematcht, aber nicht als nicht erfüllt). TARGET_BREAKTHROUGH_MOVE Der klassische Durchbruch durch einen Widerstand. Erkannt wird eine Schwelle bei dessen Durchbruch der Kurs deutlich weiter in diese Richtung marschiert. Parameter: # Richtung +1 oder -1 # Schwelle - eine PriceID # min Bewegung bei Durchbruch # isRelative (wie oben) Das Target ist erfüllt wenn der Bar nach dem Pattern die Schwelle durchbricht und mindestens die min Bewegung weiterläuft oder die Schwelle nicht durchbricht (dann zählt das Pattern als nicht gematcht, aber nicht als nicht erfüllt). Da das schon ein recht langer Eintrag ist, mach ich hier mal Pause. Weiter gehts die nächsten Tage in Teil 2.

Es werden also 2 Systeme werden. Da damit aber 2 Techniken verglichen werden sollen, haben beide Systeme die gleiche Basis und damit fangen wir mal an. Für die erfahreneren Handelssystementwickler: Ich will hier mal wirklich von ganz ganz unten anfangen, an dem Punkt der normalerweise unbeachtet bleibt weil er "selbstverständlich" passiert. Aber manchmal ist es gut sich klar zu machen worauf alles aufbaut. Also nicht wundern und ggf. einfach Einträge überspringen ;) Die Grundannahmen Jedes Handelssystem beruht auf (einer oder mehr) Grundannahmen. Ich meine da so Grundannahmen wie "Es gibt Trends an der Börse, und diese können vollautomatisch erkannt und gehandelt werden"... Egal wie die Grundannahme aussieht, sie ist in Stein gemeißelt. Auf dieser Annahme basiert das gesamte System. In meinem Fall sieht die Grundannahme so aus: Der Markt ist auf "längere" Sicht nicht (vollautomatisch) vorraussagbar. Vollautomatische Systeme können demnach nur in sehr kleinen Timeframes mit schnellen Positionen funktionieren. Im Preis (inkl. Volume und ggf. Level X ) sind alle nötigen Informationen für ein erfolgreiches System enthalten. Es gibt Muster und Konstellationen in den vorhandenen Daten, auf die der Markt "meist" ähnlich reagiert. Hat man diese Grundannahme für sich getroffen, kann man sich überlegen wie man darauf basierend ein erfolgreiches System schreibt. Meist ist die Grundrichtung hier offensichtlich. In meinem Fall wird es die Erkennung und Verwertung der Muster sein. Außerdem gibt die Grundannahme vor das es in sehr kleinen Timeframes passieren muss. Wie gesagt werde ich mich also nicht direkt mit Indikatoren etc. beschäftigen sondern versuchen auf die pure PriceAction zurückzugreifen. Da man natürlich zur Mustererkennung die Preise "vorbereiten" muss, werd ich hier teils sicher auf Indikatoren zurückgreifen, aber die Grundidee sind Muster in der Preisaction. Der nächste Schritt ist jetzt die erste Rohfassung für die Systemlogik. Noch bevor die erste Zeile Code geschrieben wird, sollte man eine grobe Vorstellung haben, auf welchen Eckpfeilern das System stehen wird. Dazu mehr im nächsten Eintrag.

Also die Eckpfeiler. Ich möchte das System eigentlich möglichst "einfach" halten. Vor allem zu Beginn und solange noch nicht klar ist was die Ansätze überhaupt können. Die Eckpfeiler bestehen für mich (u.a.) aus diesen Punkten: Welcher Markt/Märkte Welcher Timeframe Einstiegslogik Ausstiegslogik MM/RM Markt: Da die Systeme selbstlernend werden (sollen), werde ich mich auf keinen Markt einschränken, sondern die Systeme dann mit diversen Märkten füttern und schaun was passiert, Schwerpunkt aber FOREX. Timeframe ergibt sich aus der Grundannahme: M1 bzw. ggf. M5. Die Systeme werde ich Timeframe unabhängig bauen damit man auch Test auf höheren Timeframes machen kann, aber der produktive Einsatz ist für kleine TF geplant. Die Ausstiege und MM/RM wird wie gesagt sehr simpel sein, jede Position bekommt TP und SL (abhängig von dem erkannten Muster). Später werde ich sicher auch mit trailing und BreakEven testen, aber derweil reicht TP und SL. Risiko bekommt jeder Trade gleich viel, es soll ja jeder die gleiche Chance haben. Kommt das spannenste hier: die Einstiege. Wie schon gesagt wird alles auf Mustererkennung beruhen. Eigentlich macht das fast jedes Handelssystem, also konkreter: Muster in der PriceAction. Der Knackpunkt ist natürlich "wie" diese Muster erkannt werden und welches Muster wie gehandelt werden soll. Und hier beginnen sich die beiden Systeme zu unterscheiden: klassische KI Der KI Teil, wird ein neuronales Netz bekommen, mit diversen (noch zu definierenden Eingängen) und damit klassifizieren ob der Kurs innerhalb der nächsten 2 Bars nach oben oder nach unten geht. (Details dazu später). Entsprechend dieser Klassifikation wird dann die Position eröffnet. Evolution Beim Evolutionsteil wird es noch etwas leichter sein zu verstehen warum das System etwas macht. Hier versuche ich zuerst einige mögliche Muster zu definieren. Das System wird dann diese Muster in der Vergangenheit testen und analysieren welche "funktionieren" und welche nicht. Die "guten Muster" werden dann einerseits gehandelt, andererseits werden durch Mutation und Vermischung neue "Muster" definiert die bei Erfolg automatisch zum Pool hinzugefügt werden. (Auch hier Details später). Um mir für das ganze rundherum die Arbeit zu erleichtern, werde ich das ganze in das EA-Kitchen Framework einbetten.