Die Commandref zu DOIF soll umgeschrieben werden

[Damian]

Es fällt mir immer wieder auf, dass FHEM-Anwender recht komplexe Steuerungen mit Hilfe des DOIF-Moduls definieren. Meine ursprüngliche Idee bei der Entwicklung des Moduls war: das DOIF-Modul für weniger komplexe Aufgaben zu nutzen, die mit wenigen DOIF-Zweigen auskommen.

Stattdessen werden oft bei steigenden Anforderung an die Automatisierung sehr viele DOELSEIF-Zweige mit wiederholenden Angaben definiert, ohne eine Hierarchie bzw. Strukturierung vorzunehmen. Das führt dazu, dass man schnell die Übersicht verliert und das Verhalten des Moduls nicht mehr nachvollziehen kann.

Der neue Perl-Modus bringt im Gegensatz zum FHEM-Modus die Voraussetzungen mit, sein Vorhaben strukturiert zu definieren/programmieren.

Dazu gehören folgende Eigenschaften:

-Definition mehrerer unabhängiger Ausführungsblöcke in einem Device
-Auslagerung von Anweisungen in eigene Routinen innerhalb des Devices
-Einfache Verschachtelung von if-Abfragen
-mehrere unabhängige Timer, die sich abfragen und löschen lassen

Meine Intention ist es daher den Perl-Modus zu präferieren. Dazu möchte ich die Commandref so umschreiben, dass die vielen Beispiele und Erklärungen zu Ereignis- und Zeitsteuerung nicht mehr im FHEM-Modus, sondern in erster Linie im Perl-Modus dargestellt werden und nur noch spezifischen Eigenschaften des FHEM-Modus insb. die Attribute, wie do always, wait, usw. in der Syntax des FHEM-Modus erklärt werden.

Auf diese Weise sollen insb. Anfänger oder auch Umsteiger vom FHEM-Modus einfachen Zugang zum neuen Perl-Modus bekommen, um bei steigenden Anforderungen ihre Definitionen strukturiert definieren bzw. programmieren zu können.

[the ratman]

ich bin ja einer deiner größten fans - grade wegen doif, deinen (euren) noobfreundlichen hilfen im fhem selber und auch im forum - dafür ewigen und 3 tage dank!
und weil ichs doif im gegensatz zu perl irgendwie besser verstehe und mit viel weniger fragezeichen und sehr viel weniger dummen fragen im forum an meine hausautomatisation komm.

jetzt frag ich mich grade, obs nicht grad einsteigern und perl-noobs (wie mir) weh tut was sich da abzeichnet mit deinem beitrag - weg von dem, was ich (und wohl auch andere) so lieben, hin zum üblichen perl, mit dem ich auch in 1000 jahren nix anfangen werd können. aber gut, vielleicht bin ich mit diesen gedanken auch alleine auf weiter flur ...
(gehofft (aber nie erwartet/gefordert *g*) hat der geneigte noob ja mehr auf sowas wie z.b. ne oberfläche ala babble, um das leben des noobs noch einfacher zu machen)

only my 2 cents

[Invers]

Ich stimme meinem Vorredner zu. Bessere Idee wäre vielleicht, die Commandref bezüglich Perlmodus um einen extra Bereich zu erweitern. Der DOIF-Modus ist ja bereits hervorragend dokumentiert und würde ja keine Arbeit mehr machen.
Ich bin ein begeisterter Nutzer und Befürworter des DOIF seit "der ersten Stunde". Jetzt scheint aber der Weg verlassen zu werden, den so viele Nutzer begeistert beschritten haben.
Aber vielleicht habe ich das alles ja nur falsch verstanden.

[Damian]

Ich denke der Perlprogrammierer muss mehr lernen, um DOIF im Perl-Modus zu nutzen, als der eingefleischte DOIF-User des FHEM-Modus.

Der Perl-Kenner muss nämlich die DOIF-Syntax für Ereignis- und Time-Trigger [ erst lernen.

Der FHEM-Modus User braucht nur seine bisherige Definition eins zu eins übertragen:

Auszug aus der aktuellen Commandref (Perl-Modus)

Definitionen im FHEM-Modus mit do-Attribut der Form:

 

Code Auswählen Erweitern

DOIF (<Bedingung mit Trigger>) (<FHEM-Befehle>) DOELSE (<FHEM-Befehle>)

lassen sich wie folgt in Perl-Modus übertragen:

 

Code Auswählen Erweitern

DOIF {if (<Bedingung mit Trigger>) {fhem"<FHEM-Befehle>"} else {fhem"<FHEM-Befehle>"}}[/quote]

Die Bedingungen des FHEM-Modus können ohne Änderungen in Perl-Modus übernommen werden.

Natürlich gibt es feine Unterschiede, da der Status des Perl-Moduls nicht vom Modul verwaltet wird, die Verzögerungen von Anweisungen nicht über ein Attribut definiert werden usw.

Insb. würde ich die ersten Punkte überarbeiten:

Lesbarkeit der Definitionen
Ereignissteuerung
Teilausdrücke abfragen
Ereignissteuerung über Auswertung von Events
Angaben im Ausführungsteil
Filtern nach Ausdrücken mit Ausgabeformatierung
Aggregieren von Werten
Zeitsteuerung
Relative Zeitangaben
Zeitangaben nach Zeitraster ausgerichtet
Relative Zeitangaben nach Zeitraster ausgerichtet
Zeitangaben nach Zeitraster ausgerichtet alle X Stunden
Wochentagsteuerung
Zeitsteuerung mit Zeitintervallen
Indirekten Zeitangaben
Zeitsteuerung mit Zeitberechnung
Intervall-Timer
Kombination von Ereignis- und Zeitsteuerung mit logischen Abfragen
Zeitintervalle, Readings und Status ohne Trigger
Ersatzwert für nicht existierende Readings oder Status
Readingauswertung bei jedem Event des Devices
Erzeugen berechneter Readings
uiTable, das User Interface
Deaktivieren des Moduls

Die restlichen sind FHEM-Modus-spezifisch, daher müssen sie so bleiben wie sie sind:

Nutzung von Readings, Status oder Internals im Ausführungsteil
Berechnungen im Ausführungsteil
Verzögerungen
Verzögerungen von Timern
Zurücksetzen des Waittimers für das gleiche Kommando
Wiederholung von Befehlsausführung
Zwangspause für das Ausführen eines Kommandos seit der letzten Zustandsänderung
Begrenzung von Wiederholungen eines Kommandos
Ausführung eines Kommandos nach einer Wiederholung einer Bedingung
Löschen des Waittimers nach einer Wiederholung einer Bedingung
Eindeutige Statuserkennung
Triggerung durch selbst ausgelöste Events
Setzen der Timer mit Event
Zeitspanne eines Readings seit der letzten Änderung
Darstellungselement mit Eingabemöglichkeit im Frontend und Schaltfunktion
Status des Moduls
Reine Statusanzeige ohne Ausführung von Befehlen
Anpassung des Status mit Hilfe des Attributes state
Vorbelegung des Status mit Initialisierung nach dem Neustart mit dem Attribut initialize
Bedingungslose Ausführen von Befehlszweigen
Initialisieren des Moduls

Alles was zum Nachschlagen für den bisherigen FHEM-Modus-User wichtig ist, insb. die Beschreibung von DOIF-Attributen, wird bleiben.

Der Perl-Modus kommt ja weitgehend ohne Attribute aus, das ist ebenfalls ein großer Vorteil des Perl-Modus, weil man da erst gar nichts nachschlagen muss.

Jeder DOIF-User kann ja jetzt schon mal schauen, ob er mit der aktuellen Beschreibung zum Perl-Modus klar kommt: https://fhem.de/commandref_DE.html#DOIF_Perl_Modus

Ich denke nicht, dass man über besondere Perlkenntnisse verfügen muss, um es zu verstehen.

Falls jemand etwas nicht versteht, dann kann er sich hier melden und dann wird die Commandref so ergänzt, dass sie auch ein Perl-Noob versteht

Wer mich kennt, der weiß, dass ich bisher keinen vor den Kopf gestoßen habe, der etwas nicht verstanden hat - auch nicht, wenn er Fragen zu Perl hat.

[the ratman]

Der Perl-Modus kommt ja weitgehend ohne Attribute aus, das ist ebenfalls ein großer Vorteil des Perl-Modus, weil man da erst gar nichts nachschlagen muss.

ich muß ja trotzdem was nachschlagen, weil die befehle sind dann nicht nur andere, sondern auch noch an anderer stelle.
im falle "perl-modus" geh ich mal fest davon aus, dass die attribute durch perlspezifische befehle ersetzt werden. für leute wie mich also um ecken schwerer und vor allem umständlicher, weil ich das zeug in 2 jahren nicht kapiert hab und wohl nie kapieren werd. wenn ich was in sachen regex les krieg ich sowieso schon die kretze und werf das zeug lieber weg, bevor ich mich wieder mit sowieso nie funzenden eigenen deffinitionen rumärger oder dann ein konstrukt hab, das ich mir im forum umständlich erfragen muß und dann nicht mal verstehe. das ist dann immer lustig beim fehlersuchen - oder besser fehler schätzen und raten.

sagen wirs mal so:
wäre ich beim einstieg in fhem nicht über dein doif gestolpert - so ganz ohne perl - wäre ich warscheinlich nie bei fhem geblieben. ich hab ja echt nix gegen einen perl-modus. aber bitte, bitte, lass uns auch das richtige doif, sonst kann ich fhem am müll werfen. würds nach mir gehen, würd ich das am liebsten getrennt sehen - 2 doif-module - wie wärs mit doif-lite und doif-pro? - und jeder is glücklich.

[Damian]

ich muß ja trotzdem was nachschlagen, weil die befehle sind dann nicht nur andere, sondern auch noch an anderer stelle.
im falle "perl-modus" geh ich mal fest davon aus, dass die attribute durch perlspezifische befehle ersetzt werden. für leute wie mich also um ecken schwerer und vor allem umständlicher, weil ich das zeug in 2 jahren nicht kapiert hab und wohl nie kapieren werd. wenn ich was in sachen regex les krieg ich sowieso schon die kretze und werf das zeug lieber weg, bevor ich mich wieder mit sowieso nie funzenden eigenen deffinitionen rumärger oder dann ein konstrukt hab, das ich mir im forum umständlich erfragen muß und dann nicht mal verstehe. das ist dann immer lustig beim fehlersuchen - oder besser fehler schätzen und raten.

sagen wirs mal so:
wäre ich beim einstieg in fhem nicht über dein doif gestolpert - so ganz ohne perl - wäre ich warscheinlich nie bei fhem geblieben. ich hab ja echt nix gegen einen perl-modus. aber bitte, bitte, lass uns auch das richtige doif, sonst kann ich fhem am müll werfen. würds nach mir gehen, würd ich das am liebsten getrennt sehen - 2 doif-module - wie wärs mit doif-lite und doif-pro? - und jeder is glücklich.

Keine Sorge, es sind zu viele User, die ich verärgern würde, wenn ich wichtige Sachen aus der Commandref entfernen würde.

Ich möchte allerdings neue DOIF-User direkt zum Perl-Modus führen, damit sie später nicht umdenken müssen. Z. Zt. ist die Commandref zum Perl-Modus dafür zu dürftig und steht an zweiter Stelle. Wichtige Erklärungen zur Ereignis- und Zeitsteuerung stehen im FHEM-Modus.

Auf der anderen Seite glaube ich nicht, dass ich einem DOIF-FHEM-Modus-User (welche Wortschöpfung) noch ausführlich erklären muss, wie man im FHEM-Modus eine Lampe schaltet, wenn man auf eine Taste drückt.

Ich kann hier mal einen Vorschlag zur neuen Commandref posten, dann kann jeder DOIF-User selbst beurteilen, ob er damit leben kann oder nicht.

[Prof. Dr. Peter Henning]

Ich schlage vor. statt der gigantisch großen CommandRef zu DOIF lieber ein gut dokumentiertes Wiki zu haben, auf das in der CommandRef nur verwiesen wird. Da kann man auch mit Bildern (Flussdiagrammen etwa) arbeiten.

LG

pah

[the ratman]

zuerst:
dem herrn prof. recht gebe - doif is sicher das am besten und geilste dokumentierte projekt. da fallt mir grad noch winconnect ein mit einer ähnlich guten noob-freundlichen doku. aber gut, das ding ist winzig, gegen doif. bei der doif-doku schlackern dir die ohren, wennst das alles lesen willst. suchen nach beispielen war übrigens anfangs auch irgendwie einfacher. ich hab schon eine brille mit lesen der doif-hilfe verschlissen *g*.

Auf der anderen Seite glaube ich nicht, dass ich einem DOIF-FHEM-Modus-User (welche Wortschöpfung) noch ausführlich erklären muss, wie man im FHEM-Modus eine Lampe schaltet, wenn man auf eine Taste drückt.

nö, dass mußt du tatsächlich nicht mal mehr mir verklickern (ja, auch ich bin bedingt lernfähig *g*). ich staune übrigens immer wieder, was sogar ich an projekten mit doif hinbekomme - mittlerweile sogar, ohne viel fragen zu müssen.
mein genereller trugschluss bei doif war offensichtlich, dass du quasi mal die nicht-programmierer mit doif unterstützen willst. die pros haben ja ihr at und notify und die dummen dummys, myutls und was weiß ich was für ein gschisti-gschasti um alles umständlich machen zu können, was der noob im doif in 2 zeilen macht.
langsam wird für mich das ganze allerdings irgendwie zu "professionell" und ich ärger mich, dass ich z.b. schon deine uitables nicht nutze, obwohl sie sicher mehr kann als ne olle readingsgroup. aber irgendwie ist das modul an sich schon "zu viel" und gehört meines erachtens nach "irgendwie" strukturiert oder besser kartellmäßig zerschlagen - gutes bspl.: doif-tools - stell dir vor, das wäre auch noch direkt im doif drinnen. man hat ja immer den "overhead" aller teile, auch jener, die man nicht braucht, was durchaus mal verwirrend sein kann.

Ich möchte allerdings neue DOIF-User direkt zum Perl-Modus führen, damit sie später nicht umdenken müssen.

das sind die sätze, die mir angst machen ... das schmeckt so richtig nach "später (irgendwann mal) gibt's nur perl-mod - friß, oder stirb". jaja, ich weiß schon, aber das gefühl steckt tief im bauch.

[Damian]

Ich schlage vor. statt der gigantisch großen CommandRef zu DOIF lieber ein gut dokumentiertes Wiki zu haben, auf das in der CommandRef nur verwiesen wird. Da kann man auch mit Bildern (Flussdiagrammen etwa) arbeiten.

LG

pah

Ja, es gibt ja bereits Wiki mit Flussdiagrammen zu DOIF. Es gibt sogar einen Verweise darauf in der Commandref zu DOIF.

Ich kann die bisherige Commandref zum FHEM-Modus ins Wiki verbannen und eine kürzere zum Perl-Modus in der Commmandref verfassen. Aufgrund der wenigen Attribute wird sie wesentlich kürzer ausfallen.

Ich glaube aber, dass jetzt viele DOIF-Nutzen aufschreien werden.

[Damian]

das sind die sätze, die mir angst machen ... das schmeckt so richtig nach "später (irgendwann mal) gibt's nur perl-mod - friß, oder stirb". jaja, ich weiß schon, aber das gefühl steckt tief im bauch.

Eins steht fest: es wird immer den FHEM-Modus geben. Das, was jetzt existiert, wird es so lange geben, wie es FHEM geben wird. Allerdings werde ich meine "geistige Kreativität" dem Perl-Modus widmen, weil es meiner Ansicht nach die Zukunft des Moduls ist. Vielleicht war es ein Fehler den neuen Modus Perl-Modus zu nennen, weil jetzt viele das Gefühl haben, sie müssten Perl programmieren können - das ist sicherlich hilfreich, aber nicht notwendig.

Beispiel:

Ob ich dem Perl-Noop ein einfaches Event-Handling so erkläre:

Code Auswählen Erweitern

DOIF ([taster] eq "on")(set lamp on)

PS: do always Attribut nicht vergessen

oder ob ich ihm das so erkläre:

Code Auswählen Erweitern

DOIF {if ([taster] eq "on"){fhem"set lamp on"}}

macht keinen großen Unterschied. Im Gegenteil einem DOIF-Neuling muss ich jetzt schon mal kein do always Attribut erklären.

Er muss zu diesem Zeitpunkt Null Ahnung von Perl haben. Andererseits hat der DOIF-FHEM-Modus-User schon mehr Perl gelernt, als er ahnt, weil die Bedingung des DOIFs auch im FHEM-Modus bis auf die Trigger in eckigen Klammern, nichts anders als Perl-Syntax ist.

[the ratman]

so, einmal quäl ich dich noch, weil ichs letzte wort haben will *lach*. dann dürfen auch mal andere ...

Eins steht fest: es wird immer den FHEM-Modus geben.

ich glaubs dir schon, wenn dein beispiel auch zeigt, dass ich für perl mehr tippen muß - im speziellen z.b. klammern, bei denen mir die virtuelle tastatur meines surface zu macht (frag m$ warum, ich weiß es nicht).

macht keinen großen Unterschied. Im Gegenteil einem DOIF-Neuling muss ich jetzt schon mal kein do always Attribut erklären.

dafür mußt du mir jetzt beibringen, was ich machen muß, wenn ich kein "do always" will ... du kommst mir nicht aus *fg*
aber du könntest ja 3 anleitungen schreiben - eine für doif, eine für perl-doif und eine für umsteiger (sorry, das hab ich jetzt gebraucht).

[Prof. Dr. Peter Henning]

Ich glaube aber, dass jetzt viele DOIF-Nutzen aufschreien werden

Hmmm. Ich denke, dass die extrem komplexe CommandRef eher der Grund dafür ist, dass so viele Fehler gemacht werden. In die Commandref gehören m.E. nur kurze Beschreibungen - längere Beispiele eben ins Wiki.

Also mögen sie aufschreien, aber es ist zu ihrem Besten.

LG

pah

[Damian]

so, einmal quäl ich dich noch, weil ichs letzte wort haben will *lach*. dann dürfen auch mal andere ...ich glaubs dir schon, wenn dein beispiel auch zeigt, dass ich für perl mehr tippen muß - im speziellen z.b. klammern, bei denen mir die virtuelle tastatur meines surface zu macht (frag m$ warum, ich weiß es nicht).dafür mußt du mir jetzt beibringen, was ich machen muß, wenn ich kein "do always" will ... du kommst mir nicht aus *fg*
aber du könntest ja 3 anleitungen schreiben - eine für doif, eine für perl-doif und eine für umsteiger (sorry, das hab ich jetzt gebraucht).

Naja, ich wollte hier die Parallelen in der Definition der beiden Modi aufzeigen.

Die Kurzform sieht dann eher so aus:

Code Auswählen Erweitern

DOIF {["taster:on"];fhem_set"lamp on"}


und dass hier noch nicht mal der FHEM-Parser (set-Befehl) zum Zuge kommt, sei nur am Rande erwähnt

Vielmehr muss man dem DOIF-Neuling erklären, warum beim zweiten Tastendruck die Lampe im FHEM-Modus-Beispiel nicht angehen würde.

Do always bzw. keine Wiederholung des selben Zweiges im Hinblick auf die Abfrage von zyklisch sendenden Sensoren, ist noch aus der Zeit als es keine DOIF_Readings gab.

[Damian]

Do always bzw. keine Wiederholung des selben Zweiges im Hinblick auf die Abfrage von zyklisch sendenden Sensoren, ist noch aus der Zeit als es keine DOIF_Readings gab.

Hier noch mal die Erklärung, warum man ohne do always auskommt bzw. do always nicht immer eine Lösung bietet:

Anforderung: bei Frost und jedes Mal beim Betätigen eines Taster soll die Heizung auf on, sonst off

Code Auswählen Erweitern

DOIF ([outdoor:temperature] < 0 or [taster:"on"]) (set heating on) DOELSE (set heating on)

ohne do always wird die Anforderung "jedes Mal beim Betätigen des Tasters" nicht erfüllt

mit do always wird bei jedem Event von outdoor:temperature heating geschaltet

Lösung mit Hilfe von DOIF_Readings:

Code Auswählen Erweitern

DOIF ([$SELF:frost] or [taster:"on"]) (set heating on) DOELSE (set heating on)
attr DOIF_Readings frost: [outdoor:temperature] < 0
attr do always


Das Reading frost triggert intern das eigene Modul ohne Events nach außen nur bei Änderung (das ist eine Eigenschaft des Attributes DOIF_Readings und lässt sich so mit userReadings ohne Events nicht nachbilden)

Das geht im Perl-Modus sogar einfacher, da man im Perl-Modus ohnehin ohne Zustandsauswertung arbeitet (do always gibt es im Perl-Modus nicht)

Code Auswählen Erweitern

DOIF {if ([$SELF:frost] or [taster:"on"]) {fhem_set"heating on"} else {fhem_set"heating on"}}
attr DOIF_Readings frost: [outdoor:temperature] < 0


Auf diese Weise lässt sich das Problem von zyklisch sendenden Sensoren in logischen Abfragen mit DOIF_Readings immer elegant lösen. Damit kommt man im Perl-Modus ohne das Attribut do always aus.

[Pfriemler]

Ich will mal ratman zur Seite springen: Seine Rede zur Einsteigerfreundlichkeit unterschreib ich völlig.

Code Auswählen Erweitern

DOIF ([taster] eq "on")(set lamp on)
ist das Musterbeispiel an Einfachheit. Man mag über das "eq" noch unglücklich sein, aber dieses Grundwissen an Perl (Unterschied im Vergleich von Zahlen und Texten) benötigt man an anderen Ecken in FHEM früher oder später doch.

Völlig zu recht dürfte eines der größten Missverständnisse sein und bleiben, warum es dieses "do always" braucht. Hier hätte ich mir noch viel früher gewünscht, do always zum default zu erklären - weil es eigentlich viel logischer ist - und nur bei Bedarf auszuschließen.

Code Auswählen Erweitern

DOIF {if ([taster] eq "on"){fhem"set lamp on"}}
Das Modul heißt TUE WENN. Wieso braucht es jetzt noch ein if?
Und wieso muss ich die if-Bedingung in () setzen, und die Zweige insgesamt in {}? Ein Rückschritt zum FHEM-DOIF, finde ich. Natürlich erkennt das Modul daran den Unterschied von FHEM- und perl-DOIF. Aber diese Klammern verursachen mir Augenkrebs. Übersichtlich wird die ganze Klammerei so oder so erst mit einem Code-Editor (über den ich in FHEM übrigens sehr froh bin).

Spätestens

Code Auswählen Erweitern

DOIF {["taster:on"];fhem_set"lamp on"}
hat dann jeden optischen Charme und prinzipielle Anfängerlogik verloren und ist für den noob (!) einem Notify zum Verwechseln ähnlich. Schlimmer noch: Es macht neben dem etablierten notify und dem FHEM-DOIF eine neue Syntaxebene auf, die zu noch mehr Verwechslungen führen kann. Mag sein, dass die "best of both worlds" ist. Mag sein, dass man diesen Kollateralschaden hinnehmen muss.

Ich bin und bleibe wohl ein Freund des FHEM-DOIF. Nicht zuletzt weil meine teilweise recht umfänglichen Skripte (bspw. Befehlsabfolgen mit Wartepausen) auch nach Monaten intuitiv von mir wiederverstanden werden. Jedes unnötige ", $ oder & stört mich optisch. Kann meine Macke sein, aber vielleicht geht es anderen auch so. Auch ein : sagt mir spontan nix, zumal es in FHEM diverse andere Bedeutungen hat.

Für das Verständnis meiner Äußerungen muss man zudem berücksichtigen, dass ich bei ungefähr der Hälfte der per Attribut möglichen Optionen "steckengeblieben" bin und bisher weder DOIF-Readings noch GUI-Hilfen eingesetzt habe - schlicht weil ich es nicht nötig hatte, weil das meiste längst anders gelöst war. Und anders als vom Modulautor offenbar gewollt finde ich gerade die Bündelung aller "was soll geschehen wenn das Ding den und den Zustand hat"-Befehle in einem DOIF viel übersichtlicher als mich wie etwa bei Notifys von einem "Probably associated with" zum nächsten hangeln zu müssen.
Natrülich werde ich dem perl-DOIF trotzdem Chancen geben, mal sehen was das bei mir vereinfacht - oder verkompliziert...

nachtrag: Das soll kein Mecker sein, sondern nur Gedanken eines (fast) Außenstehenden widerspiegeln. DOIF hat mein FHEM-Leben revolutioniert und dramatisch vereinfacht. Trotzdem ahne ich (derzeit: noch) die enormen Möglichkeiten, die die Neuerungen mit der Zeit gebracht haben, und es gibt so etwas wie eine "Umstiegshürde". Dass die dahinter steckende Arbeit von Damian GROSS-AR-TIG ist, will ich an dieser Stelle sicherheitshalber nochmal wiederholen.