Enelix-EMS/docs/module/Ladestation-Stand-Alone/README.md

Ladestation Stand-Alone

Status: implementiert fuer IP-Symcon 8 und den Enelix-2-Vertrag 4.0.

Das Modul bindet eine einzelne Ladestation direkt an Enelix EMS an. Es liest den Fahrzeug- und Ladezustand ueber die Geraete-API, ermittelt die Phasenzahl aus aktuellen Messwerten und setzt den vom Manager gewaehlten Ladestrom. Es benoetigt keine Gateway-Instanz und hat keine technische Beziehung zum separaten Modul Ladestation Gateway.

Funktionsumfang

• direkte Statusabfrage und Steuerung der unterstuetzten Ladestationen,
• Fahrzeug-, Lade- und Phasenerkennung mit geprueften Geraetedaten,
• Leistungsangebote fuer PV- und Peakbetrieb,
• lokale Freigabe und Umschaltung zwischen Solar- und Normalbetrieb,
• Kommunikation mit dem Enelix Manager ueber den Nachrichtenvertrag 4.0,
• optional sichtbare Diagnosevariablen und schaltbares Debug-Logging,
• automatisierte Tests mit Fake-HTTP-Transport ohne reale Ladestation.

Unterstuetzte Geraete

Geraetetyp	Statusabfrage	Steuerung	Erforderliche Konfiguration
go-e Charger, alte API	GET /mqtt?payload=	alw und amp	IP-Adresse oder Hostname
go-e Charger Gemini / Gemini flex	GET /api/status	frc und amp	IP-Adresse oder Hostname
smart-me Pico	Pico-Charging-API	Load-Management-Current-API	Geraete-ID, Seriennummer, Benutzername und Passwort

Bei go-e wird die lokale HTTP-API verwendet. Die Geraeteadresse wird ohne http://, Pfad oder Parameter eingetragen. Die Pico-Anbindung verwendet HTTPS und HTTP Basic Auth gegen api.smart-me.com. Zugangsdaten werden weder als Variable noch im Debug-Protokoll oder im Diagnosefeld LetzterGeraetebefehl ausgegeben.

Fahrzeug- und Phasenerkennung

Die Leistungsskalen bleiben kompatibel zu Enelix 1; die Fehler- und Ladeendeauswertung ist seit der Korrektur vom 07.10.2026 strenger:

1. Nach erfolgreicher Statusvalidierung gilt das Fahrzeug bei go-e mit car != 1 und bei Pico mit State != 1 als verbunden. Fehler- und Offlinezustaende werden vorher abgewiesen.
2. Die gemessene Leistung wird bei der alten go-e-API mit Faktor 10, bei Gemini direkt in Watt und bei Pico von kW in Watt umgerechnet.
3. go-e und Pico koennen die drei Phasenstroeme einzeln melden. Ab 1 A gilt eine Phase als belastet; mindestens zwei belastete Phasen werden konservativ als drei gerechnet. Frische Dreiphasenmessungen korrigieren gespeicherte Einphasigkeit. Bestaetigte Dreiphasigkeit bleibt konservativ bis zum Ausstecken erhalten, auch wenn zeitweise nur eine Phase belastet wird.
4. Sind beim Anstecken noch keine belastbaren Phasenwerte vorhanden, gibt das Modul [0,4104] W an: 6 A mit dem bestehenden Dreiphasenbudget. Eine zugeordnete Station startet erst nach passender Manager-Vorgabe. Bei Solarladen im Peakbetrieb bleibt das Angebot [0]; es gibt keinen direkten Probebefehl am Manager vorbei. Phasenzahl=0 bleibt bis zur Erkennung erhalten.
5. Nach Phasenerkennungszeit wird die gemessene Leistung relativ zum angeforderten Erkennungsstrom ausgewertet. Dadurch lassen sich eine und drei Phasen bereits bei 6 A unterscheiden. Unter 1265 W bleibt die Anzahl unbekannt, insbesondere bei 0 W. In einer Ladepause bleibt die zuletzt erkannte Anzahl erhalten; neue belastete Phasenmessungen koennen sie korrigieren.
6. Der Ladestrom wird aus der Leistung mit 230 W/A einphasig beziehungsweise 684 W/A dreiphasig berechnet.
7. Nur ein explizites aktuelles Ladeende (go-e car=4) ohne relevante Last (< 1 A und < 100 W) setzt FahrzeugGeladen. Ein einzelner Nullwert und Ladepausen genuegen nicht. Neues Laden oder ein anderer aktueller Status hebt den Wert wieder auf. Die Pico-API hat keinen eindeutigen Voll-Status; dort wird deshalb kein Ladeende aus niedrigem Strom abgeleitet.

Der normalisierte Fahrzeugstatus verwendet folgende Werte:

Wert	Bedeutung
0	unbekannt oder noch nicht ermittelt
1	kein Fahrzeug verbunden
2	Fahrzeug verbunden und bereit
3	Fahrzeug laedt
4	Fahrzeug geladen

Leistungsregelung

Ein Leistungsangebot groesser als 0 W wird nur erzeugt, wenn das Modul aktiviert, die Ladefreigabe gesetzt, ein Fahrzeug verbunden und das Fahrzeug noch nicht als geladen erkannt ist. Andernfalls meldet das Modul [0] und stoppt die Ladestation.

Betriebsart	Solarladen	Leistungsangebot
PV	ein	0 W und alle Ladestufen von 6 A bis zum konfigurierten Maximum
PV	aus	ausschliesslich die maximale Ladeleistung
Peak	ein	ausschliesslich [0]; die Ladestation wird gestoppt
Peak	aus	0 W und alle Ladestufen von 6 A bis zum konfigurierten Maximum

Die Leistungsstufen entsprechen Enelix 1: 230 W pro Ampere einphasig und 684 W pro Ampere dreiphasig. Ohne gueltige Manager-Vorgabe faehrt das Modul bei aktivem Solarladen mit 0 A; bei ausgeschaltetem Solarladen verwendet es die maximale angebotene Leistung. Ausnahme: Bei unbekannten Phasen und zugeordnetem Manager gibt es auch ohne Solarladen keinen Start ohne Budget. Ohne Manager kann die eigenstaendige Station im Normalbetrieb mit 6 A pruefen.

Beim Aktivieren oder Umschalten von Solarladen bleibt ein bereits gesetzter Geraetestrom zunaechst unveraendert. Das neue Angebot wird zuerst an den zugeordneten Manager gemeldet; dessen neue Vorgabe wird anschliessend direkt uebernommen. Antwortet kein Manager, greift nach zwei Sekunden das lokale Ersatzverhalten. Sicherheitsabschaltungen wirken weiterhin sofort.

Nach einer Leistungsaenderung wird die aktuelle Stufe fuer ZeitZwischenZustandswechseln gehalten. Waehrend der Mindesteinschaltdauer bleiben positive Leistungsstufen regelbar, 0 W wird jedoch nicht angeboten. Nach dem Abschalten meldet das Modul waehrend der Mindestausschaltdauer ausschliesslich [0]. Sicherheitsabschaltungen durch Deaktivierung, fehlende Ladefreigabe, Ausstecken oder ein erkanntes Ladeende greifen sofort.

Bedienung

Ident	Wirkung
Aktiv	Gemeinsame lokale EMS-Freigabe. false setzt das Angebot auf [0] und stoppt die Ladestation.
Ladefreigabe	Lokale Freigabe fuer das Laden. Diese Variable ist nur mit EinstellungenInVisu=true sichtbar.
Solarladen	Schaltet das oben beschriebene PV-/Peak-Verhalten um. Diese Variable ist nur mit EinstellungenInVisu=true sichtbar.

Die Properties Ladefreigabe und Solarladen definieren die Startwerte. Eine Aenderung der jeweiligen Property wird beim Anwenden der Konfiguration in den lokalen Zustand uebernommen. Eine Bedienung der Variablen verwirft eine noch gueltige Manager-Vorgabe und berechnet das Leistungsangebot sofort neu.

Konfiguration

Gemeinsame EMS-Einstellungen

Property	Typ	Standard	Beschreibung
PrioritaetPV	Integer	0	Prioritaet des Verbrauchers im PV-Betrieb.
PrioritaetPeak	Integer	0	Prioritaet des Verbrauchers im Peakbetrieb.
Meldeintervall	Integer	10 s	Intervall fuer die periodische Vollmeldung an zugeordnete Manager.
VorgabeTimeout	Integer	120 s	Gueltigkeitsdauer einer Manager-Vorgabe ohne Erneuerung.
EinstellungenInVisu	Boolean	false	Blendet Ladefreigabe, Solarladen, Istleistung und Sollleistung ein.
LoggingEin	Boolean	false	Aktiviert das laufende Debug-Protokoll des Moduls.

Ladestation und Diagnose

Property	Typ	Standard	Beschreibung
Geraetetyp	Integer	0	1 go-e alt, 2 go-e Gemini, 3 smart-me Pico; 0 ist nicht konfiguriert.
Geraeteadresse	String	leer	IP-Adresse oder Hostname fuer beide go-e-Varianten.
GeraeteID	String	leer	Geraete-ID fuer die Pico-Statusabfrage.
Seriennummer	String	leer	Seriennummer fuer die Pico-Stromvorgabe.
Benutzername	String	leer	Benutzername fuer die Pico-API.
Passwort	String	leer	Passwort fuer die Pico-API; im Formular als Passwortfeld dargestellt.
MaximalerLadestrom	Integer	16 A	Obergrenze der angebotenen Ladestufen; zulaessig sind 6 bis 32 A.
Phasenerkennungszeit	Integer	60 s	Dauer der 6-A-Probe vor der leistungsbasierten Phasenerkennung.
FahrzeugstromErkennungszeit	Integer	90 s	Zeit, die eine stabile Stromunterschreitung anliegen muss, bevor die Fahrzeuggrenze mit 2,5 A Reserve uebernommen wird.
ZeitZwischenZustandswechseln	Integer	1 min	Mindestabstand zwischen zwei Leistungsaenderungen.
Mindesteinschaltdauer	Integer	0 min	Mindestdauer nach dem Einschalten, in der kein Abschalten auf 0 W angeboten wird.
Mindestausschaltdauer	Integer	0 min	Mindestpause nach dem Abschalten, in der nur 0 W angeboten werden.
Abfrageintervall	Integer	5 s	Intervall der Geraetestatusabfrage.
Ladefreigabe	Boolean	true	Startwert der lokalen Ladefreigabe.
Solarladen	Boolean	true	Startwert der lokalen Solarlogik.
DiagnosevariablenAnzeigen	Boolean	false	Blendet gemeinsame und ladestationsspezifische Diagnosevariablen ein.

Die internen Properties Testmodus und Testantwort gehoeren ausschliesslich zum automatisierten Symcon-Funktionstest und erscheinen nicht im Konfigurationsformular.

Variablen

Immer sichtbar:

Ident	Typ / Zugriff	Beschreibung
Aktiv	Boolean / bedienbar	Lokale EMS-Freigabe; der Initialwert ist false.
FahrzeugVerbunden	Boolean / Anzeige	Zeigt, ob die API ein verbundenes Fahrzeug meldet.
FahrzeugGeladen	Boolean / Anzeige	Aktuell bestaetigtes Ladeende; bei Pico ohne eindeutiges API-Signal immer false.
Ladestrom	Float / Anzeige	Groesster gemessener Phasenstrom, ersatzweise aus Leistung und bekannter Phasenzahl berechnet.
Phasenzahl	Integer / Anzeige	0 unbekannt, 1 einphasig oder 3 dreiphasig.

Nur mit EinstellungenInVisu=true sichtbar; Ladefreigabe und Solarladen sind bedienbar:

• Ladefreigabe
• Solarladen
• Istleistung
• Sollleistung

Nur mit DiagnosevariablenAnzeigen=true sichtbar:

Ident	Beschreibung
Leistungsquelle	Immer 2 fuer eine gemessene Leistung.
Fahrzeugstatus	Normalisierter Status von 0 bis 4.
SollwertGueltig	Zeigt, ob die Vorgabe noch gueltig und im aktuellen Angebot enthalten ist.
Verfuegbar	Zeigt, ob die Ladestation grundsaetzlich Leistung aufnehmen kann.
AenderungMoeglich	Zeigt, ob das aktuelle Angebot mehr als eine Leistungsstufe enthaelt.
Stoerung	Sammelstatus fuer Konfigurations- und Kommunikationsfehler.
Stoertext	Letzte verstaendliche Fehlerbeschreibung.
Geraetehinweis	Pico-Autorisierung und historisches letztes Ereignis, getrennt vom aktuellen Fehler.
LetzterGeraetebefehl	Letzter Steuerbefehl mit HTTP-Methode und URL ohne Zugangsdaten; Statusabfragen ueberschreiben ihn nicht.
LeistungsangebotDiagnose	Aktuelles Leistungsangebot als JSON-Liste in W.

Die Regellogik speichert ihren Zustand unabhaengig von der Sichtbarkeit der Diagnosevariablen. Das Ein- oder Ausblenden veraendert daher nicht das Regelverhalten.

Managerkommunikation

Das Modul implementiert VerbraucherSchnittstelle::ManagerdatenEmpfangen() und verwendet ausschliesslich den Nachrichtenvertrag 4.0. Eine separate Manager-ID wird nicht konfiguriert. Das Modul akzeptiert Vorgaben nur von einem Manager, in dessen manueller oder automatischer Verbraucherzuordnung die Ladestation aktiv eingetragen ist.

An den Manager werden neben den gemeinsamen Feldern diese Zustaende gemeldet:

• Sollleistung_W
• FahrzeugVerbunden
• FahrzeugGeladen
• Fahrzeugstatus
• Phasenzahl
• Ladestrom_A
• Ladefreigabe
• Solarladen
• Ladefehler mit Stoertext
• Geraetehinweis

Eine Sollleistung wird nur angenommen, wenn sie im zuletzt berechneten Leistungsangebot enthalten ist. Nach VorgabeTimeout ohne Erneuerung wird sie ungueltig. Statusaenderungen werden kurz verzoegert und zusaetzlich alle Meldeintervall Sekunden an alle zugeordneten Manager gemeldet.

Instanzstatus und Fehlerbehandlung

Status	Bedeutung
102	Konfiguration und letzte Geraetekommunikation sind gueltig.
201	Konfiguration ungueltig, beispielsweise fehlende Adresse oder Pico-Zugangsdaten.
202	Geraetekommunikation oder Antwortauswertung fehlgeschlagen.

Bei einem Fehler meldet das Modul Verfuegbar=false, AenderungMoeglich=false und setzt Stoerung sowie Stoertext. HTTP-Anfragen verwenden 5 Sekunden Verbindungs- und 10 Sekunden Gesamt-Timeout. Antworten ab HTTP-Status 400 sowie unvollstaendige oder ungueltige JSON-Antworten gelten als Kommunikationsfehler.

go-e muss err=0 und einen bekannten car-Wert 1 bis 4 melden. Pico muss einen verwendbaren Zustand 1, 2, 3, 4 oder 6 sowie einen frischen LastSeen (ersatzweise ValueDate) liefern. Bei Ladezustand 4 oder positiver Leistung muss auch ValueDate frisch sein. Die Grenze liegt bei 120 Sekunden; mehr als 15 Sekunden in der Zukunft oder ein Zeitstempel ohne Zeitzone sind ungueltig. Im Leerlauf wird das beobachtete ValueDate=0001-01-01 toleriert, sofern LastSeen aktuell ist und keine Leistung gemeldet wird. CamelCase und PascalCase der Pico-Feldnamen werden unterstuetzt. Nicht-endliche/negative Messwerte werden abgewiesen.

Pico-Zustand 6 wartet auf Autorisierung und bietet [0], ohne allein deshalb einen Kommunikationsfehler zu erzeugen. LastWarningOrError ist ein historisches Ereignis und wird nur als Geraetehinweis ausgegeben, nicht als dauerhaft aktiver Fehler interpretiert. MaxStationCurrent begrenzt die Stationsleistung; dynamische Grenzen von 0 A sind kein Hardwaremaximum.

Der lokale Statuscache gilt fuer drei Abfrageintervalle, mindestens 15 und hoechstens 120 Sekunden, bei Pico hoechstens bis zum Ablauf der API-Zeitstempel. Managerdaten erneuern diesen Cache nicht. Bei Fehler oder Ablauf werden Angebot und Vorgabe auf 0 gesetzt und die Station als nicht verfuegbar gemeldet. Der steuernde Pfad versucht bei zuvor gesetztem Strom eine Nullvorgabe; deren Scheitern wird zusaetzlich gemeldet. Eine API-Annahme ist keine Bestaetigung eines physischen Ladestopps. Erst eine frische gueltige Statusabfrage hebt den Fehler auf. Reine periodische Rueckmeldungen lesen nicht erneut per HTTP.

Herstellerquellen: go-e API-Schluessel und smart-me OpenAPI, abgeglichen am 07.10.2026.

Migration der Korrektur vom 07.10.2026

Vor Installation laufende Moduldateien und Konfiguration sichern und fremde Anpassungen vergleichen. Beim ersten ApplyChanges mit Erkennungsversion 2 werden alte, moeglicherweise aus 0 W abgeleitete Phasen verworfen. Ein alter Voll-Status wird beim erneuten Lesen nur mit aktuellem explizitem Signal bestaetigt. Freigaben, Solarwahl, Prioritaeten, Objektkennungen und Zugangsdaten bleiben erhalten. Es wird kein Benutzerobjekt geloescht. Neue Phasenerkennung kann auf ausreichendes Managerbudget warten; das ist beabsichtigt.

Veroeffentlichung auf develop/beta aktualisiert die Anlage nicht. Nach einem separat freigegebenen Update frische Statusdaten, Phasen, PV/Peak-Angebote, Ladepause/Wiederanlauf und Abschaltung an echten Geraeten kontrollieren. Fuer einen Rollback die gesicherten Moduldateien und passenden Instanzzustand verwenden; keine fremden Laufzeitaenderungen ueberschreiben.

Installation und Inbetriebnahme

1. Im IP-Symcon Module Control den Testing-Branch develop der Bibliothek https://git.belevo.ch/ENELIX/Enelix-EMS.git installieren oder aktualisieren.
2. Unter Instanz hinzufuegen nach Ladestation Stand-Alone suchen und eine Instanz anlegen.
3. Den Geraetetyp auswaehlen und die dazugehoerigen Verbindungsdaten eintragen: bei go-e nur IP-Adresse oder Hostname, bei Pico Geraete-ID, Seriennummer, Benutzername und Passwort.
4. Den maximal zulaessigen Ladestrom der Installation zwischen 6 und 32 A einstellen. Diese Grenze ersetzt keine elektrische Absicherung.
5. Abfrageintervall, Meldeintervall, VorgabeTimeout sowie die beiden Prioritaeten festlegen.
6. Die gewuenschten Startwerte fuer Ladefreigabe und Solarladen setzen.
7. Fuer die Erstinbetriebnahme EinstellungenInVisu, DiagnosevariablenAnzeigen und bei Bedarf LoggingEin aktivieren.
8. Die Instanz im Manager manuell aktiv zuordnen oder bei automatischer Suche in der gefundenen Liste aktivieren.
9. Zuerst ohne Fahrzeug kontrollieren, ob die Statusabfrage fehlerfrei ist. Danach unter Aufsicht ein Fahrzeug verbinden und Aktiv einschalten.

Fuer go-e muss IP-Symcon das Geraet im lokalen Netz per HTTP erreichen koennen. Fuer Pico ist ausgehender HTTPS-Zugriff auf api.smart-me.com erforderlich. Passwoerter gehoeren ausschliesslich in das dafuer vorgesehene Passwortfeld und niemals in Repository-Dateien, Skripte oder Screenshots.

Abnahmecheckliste

• Die Instanz erreicht Status 102, und Stoerung bleibt false.
• Ohne Fahrzeug sind FahrzeugVerbunden=false, Phasenzahl=0 und das Leistungsangebot [0].
• Nach dem Anstecken wird das Fahrzeug erkannt und bei unbekannten Phasen zunaechst [0,4104] angeboten. Nur mit Freigabe und Managerbudget beginnt die 6-A-Probe; Solar/Peak verhindert sie.
• Nach der Erkennungszeit werden eine oder drei Phasen relativ zum Pruefstrom gespeichert, sofern eine belastbare Leistung gemessen wird. Bei 0 W bleibt die Anzahl unbekannt; einzelne Phasenstroeme koennen die Erkennung vorziehen.
• Die erkannte Phasenzahl bleibt bei einer anschliessenden Ladepause stabil.
• Ein kurzzeitiger Nullwert setzt nicht FahrzeugGeladen; neues Laden bleibt moeglich.
• go-e-Fehler und alte Pico-Zeitstempel sperren positive Angebote bis zur frischen gueltigen Abfrage.
• Die gemessene Leistung wird plausibel in Istleistung und Ladestrom abgebildet.
• Aktiv=false oder Ladefreigabe=false stoppt die Ladestation.
• PV mit Solarladen=true bietet 0 W und die Ladestufen an.
• PV mit Solarladen=false bietet nur die maximale Leistung an.
• Peak mit Solarladen=true stoppt die Ladestation und bietet nur [0] an.
• Peak mit Solarladen=false bietet 0 W und die Ladestufen an.
• Eine Manager-Vorgabe ausserhalb des gemeldeten Angebots wird abgewiesen.
• Leistungswechsel-, Mindest-Ein- und Mindest-Aus-Zeiten werden im gemeldeten Angebot sichtbar und vom Manager eingehalten.
• Nach Ablauf des Vorgabe-Timeouts gilt wieder das lokale Ersatzverhalten.
• Im Debug-Protokoll und in LetzterGeraetebefehl erscheinen keine Zugangsdaten.

Fehlersuche

• Status 201: Geraetetyp und Pflichtfelder kontrollieren. Bei go-e darf die Adresse kein Protokoll, keinen Pfad und keine Parameter enthalten. Bei Pico muessen alle vier Zugangsfelder befuellt sein.
• Status 202: Erreichbarkeit, DNS, lokale Firewall und API-Antwort pruefen. Stoertext enthaelt den konkreten Kommunikations- oder JSON-Fehler.
• Fahrzeug wird nicht erkannt: Rohstatus der Geraete-API kontrollieren. Der Adapter erwartet bei go-e err, car und nrg[11], bei Pico State, ActiveChargingPower und die oben beschriebenen Zeitstempel.
• Phasenzahl bleibt laenger auf 0: Waehrend der Erkennungsphase muessen Managerbudget, Freigabe und tatsaechliche Stromaufnahme vorliegen. Nullleistung bleibt unbekannt. Beide Adapter koennen einzelne Phasenstroeme nutzen; ohne diese Werte wird die Leistung nach einer budgetierten 6-A-Probe ausgewertet.
• Manager-Vorgabe wird abgewiesen: aktive Zuordnung im Manager sowie LeistungsangebotDiagnose und die Betriebsart kontrollieren.

Tests

Stand der Korrektur vom 07.10.2026: composer check erfolgreich mit 402 Tests und 1875 Assertions, einschliesslich isolierter Modullaufzeit. Zusaetzlich 92 Assertions der reinen Adapter-/Reglerklassen im Symcon-8.0-Entwicklungskernel mit eigenem Test-Namespace erfolgreich. Der vollstaendige native Modultest unten wurde fuer diese Korrektur angepasst, aber nicht ausgefuehrt. Keine Stellbefehle an reale Hardware, kein Anlagenupdate und keine Feldabnahme.

Die Unit- und Adaptertests verwenden einen injizierten Fake-HTTP-Transport. Damit werden fuer go-e alt, go-e Gemini und smart-me Pico Statusantworten, URL, HTTP-Methode, Authentisierung und Steueraufrufe ohne reale Hardware geprueft.

Isolierte Laufzeittests fuehren zusaetzlich das echte Stand-alone-Modul mit simulierten Symcon-Aufrufen aus: Ladepause, Ladeende/Wiederanlauf, Budgetprobe, Peak-Sperre, Phasenkorrektur, Cacheablauf, Fehlerbeibehaltung und Migration. Diese Fake-IPS-Laufzeit darf niemals im echten Symcon-Kernel geladen werden.

Der Symcon-Funktionstest verwendet den internen Testmodus mit simulierten API-Antworten. Er prueft alle drei Geraetevarianten, die Mindeststrom-Probe beim Anstecken, stabile Phasen waehrend einer Ladepause, die Schaltsperren, Fahrzeugstrom-Erkennung, die Leistungsangebote in PV und Peak sowie die Umschaltung ueber den Solarladen-Button.

PHP-Syntax, Struktur- und Unit-Tests des gesamten Repositorys:

composer check

Funktionstest nur fuer die Ladestation gegen IP-Symcon 8:

tests/Symcon/bin/run-symcon-tests.sh single LadestationStandAlone

Vollstaendiger Symcon-Modultestlauf:

tests/Symcon/bin/run-symcon-tests.sh all

Aufbau, Testvertrag und Ergebnisdateien sind unter docs/testing/README.md beschrieben.