NEWS
bshb - Rollladensteuerung mit yhka Homekit
-
Hi!
also ich konnte den Hardware Reset am KLF200 jetzt machen und die Velux Nodes funktionieren - so lala. Ich habe die Beobachtung gemacht, dass ich immer nur einen Befehl geben kann, dann warten muss bis sich der Status aktualisiert hat und dann den nächsten Befehl geben kann. Auch das klappt nicht immer und es erscheinen diese Fehler im Log:
Ich habe jetzt nur noch die Hoffnung, die Anzahl der Nodes durch die Verwendung von Szenen für das Target und die All Values Node für die Current Values zu reduzieren.
Kannst du spontan sagen, wie ich so einen Payload zerlege und in Datenpunkt ausgebe?
Wenn das alles nicht hilft, muss ich wohl zurück auf den Adapter gehen und mir mit der Reboot Funktionalität behelfen :-(.
-
- Mit der Catch Node - kannst Du, wenn Du weißt welche Velux Nodes diesen Fehler produzieren (ist das die Statusabfrage) ggf. abfangen. Einfach eine Catch Node rausziehen, dann zu überwachende Nodes auswählen und das msg.error Objekt analysieren.
2. Wenn Du ein Objekt hast, hängt nun davon ab, ob Du wirklich alles in Datenpunkte schreiben willst oder nur einzelne Daten.2.1 Wenn Dich nur eine einzelne Eigenschaft interessiert zum Beispiel velocity - dann setzt Du die msg.payload auf msg.payload.velocity
2.2. Wenn Du jede Eigenschaft als eigene payload haben willst hängst Du eine split Node dran
2.3. Wenn Du das ganze Objekt in einen Datenpunkt schreiben willst, wandelst Du es in einen JSON String um und beim Auslesen wieder in ein Objekt
und so wandelst Du es wieder in ein Objekt zurück:
2.4.
Auch wenn es mit der neuen Adminversion zum Beginn wohl einige Fehlermeldungen(gabs dann doch nicht) - dann nimmst Du meinen Subflow, der hier genau beschrieben ist: https://forum.iobroker.net/topic/43856/json-string-oder-java-object-in-iobroker-strukturDort ist auch die genaue Bedienung beschrieben - hier nur die Kurzfassung:
Im NodeRed Adapter musst Du die Erstellung von Fremdobjekten zulassen:
Das Anlegen macht die iobroker Out Node in dem Du das einstellst:
Wider Erwarten gabs bei mir im Log keine Fehlermeldung:
Mit diesem Flow
erzeugst Du dann automatisch die Objektstruktur als einzelne Datenpunkte im iobroker:
Ergänzung: Die Fehlermeldung im Log gabs wahrscheinlich nicht, weil es direkt nach 0_userdata.0 angelegt wurde.
Du kannst aber erst mal selbst keine Datenpunkte seit dem neuen Admin anlegen, weil NodeRed leider keine Objekte im iobroker anlegen kann.
Du siehst das fehlende Objekt im neuen admin an dem fehlenden Stiftsymbol
Du musst dann auf der Ebene 0_userdata.0 den Punkt velux nochmals manuell anlegen, damit alles regelkonform ist:
Dann kannst auch manuell in diesem "Verzeichnis" wieder neue Datenpunkte anlegen:
Wenn Du auf den Adapter zurückgehst um das Log zu analysieren, dann sag nochmal Bescheid, denn ich hab noch was an der ChangeNode geändert und wie gesagt eine andere Tailnode verwendet.
-
Also, ich habe mal alles auf die All Value Nodes umgebaut - über die Change Variante. Gefühlt hat das schon mal etwas gebracht. Es kommen weniger Fehlermeldung ins Log:
Allerdings habe ich beobachtet, dass wenn ich Fensterpaare ansteuere, dass die Status Nodes kurz offline sind, und erst nach 2-3 Minuten wieder einen Status berichten. Ich vermute stark, dass in diesem Moment die Fehlermeldungen generiert werden. Vermutlich kann das KLF200 wirklich nur 2 Befehle gleichzeitig verarbeiten. Ich bekomme später des KLR200 und versuche dann mal die Target Befehle über Szenen abzubilden. Evtl. reduziert das die Probleme weiter.
Wie ich die Catch Node verwenden kann ist mir aber nicht klar.
Ich habe sie mit ins Flow Fenster kopiert.. Sollte sie das Debug Fenster beladen?
![54766800-8a13-47f2-b9da-90fe02c324a7-image.png]
(/assets/uploads/files/1630158935738-54766800-8a13-47f2-b9da-90fe02c324a7-image.png)
-
@sascho Nein die Catch Node ist dazu da, um Fehler abzufangen oder ggf. darauf zu reagieren.
Wie gesagt ich würde es aber nicht mit allen Nodes machen, sondern dafür ausgewählte Velux Nodes von Dir verwenden.
Ich versuche Dir das für Dein Beispiel, so am Besten wie möglich zu illustrieren. Da ich wie gesagt keine KLF 200 und keine Velux-Fenster habe, behelfe ich mich momentan mit einer Function Node - die in diesem Beispiel zum Beispiel eine Velux API Node sein könnte, um den Status abzufragen oder auch um das Target zu setzen .
Doch zuerst noch mal die Catch Node.
Man kann entweder alle Nodes in einem Flow überwachen oder nur spezielle. Für spezielle kann man die über eine Liste auswählen, da die ziemlich lange ist, kann man das aber auch über die Schaltfläche Nodes auswählen machen, wie ich versucht habe in folgendem Video darzustellen:
Catch Node zur Fehlerbehandlung.mp4
So und hier nun der Flow und was ich mit dieser Catch Node erreichen kann.
Die FunctionNode simuliert eine Velux Node, die ich mit einer Zufallszahl füttere, wenn diese größer als 0,5 ist - spukt die Node einen Fehler aus, wenn die Zufallszahl kleiner 0,5 ist, dann ist alles OK.
Den Fehler, den die Funktion Node ausstößt, ist in etwa der den Du im Log gepostet hast und das sieht im Beipielflow im Log dann so aus:
wenn ich diese nicht mit der Catch Node abfange.
Der Vorteil ist natürlich nicht nur, dass ich den Fehler statt im Log im Debug Fenster habe, sondern dass ich damit nun eigene Flows starten kann, die durch den Fehler in der Velux Node getriggert werden können.
Du siehst wenn Du in der function Node also ein Fehler erzeugt wird (das würde ja Deiner Velux Node entsprechen), dann triggert die Catch Node mit der Error-Objekt
Dieses kann man nun zwar einfach im Debug Fenster ausgeben lassen oder man lässt einen sinnvollen Flow starten. In meinem Beispielflow filtere ich also nur die Fehlermeldung mit dem timeout aus - man kann natürlich generell einfach alles durchlassen, was einen Fehler erzeugt.
Wichtig ist aber, dass ich über die nachfolgende Change Node nun eine Flowvariable "timeout" auf true setzen kann:
Solange dies gesetzt ist - wird oben der Flow blockiert bis die timeout Variable wieder false ist.
Sprich so kann man nur Werte setzen wenn die timeout-Variable false ist.
Arbeit die Velux Node richtig (in dem Beispiel die Function Node und liegt keine Fehlersituation vor), dann wird timeout auf false gesetzt.
Ich geh einfach mal davon aus, dass die Velux Node im Fehlerfall bislang auch nichts mehr ausspukt und nur wenn alles OK ist, wird auch was aus der Node ausgegeben.
Hier mal der Beispielflow zum Import:
Noch was zur Catch Node - falls Du nicht alle Nodes überwachst gibt die Zahl hinter der Node an (wenn Du keinen Namen vergibst) wieviel Nodes von der Catch Node überwacht werden.
In dem msg.error Objekt, das die Catch Node zurückgibt, ist neben der Fehlermeldung die source interessant:
Damit kannst Du anhand des Namens oder auch der ID, die Node identifizieren, welche den Fehler geworfen hat. Dies ist dann wichtig, wenn Du mehrere Nodes mit einer Catch Node überwachst.Wenn Du die ID über die Schaltfläche in die Zwischenablage kopierst:
Dann kannst Du diese Node über diese ID im Info-Fenster einfach suchen:
Mit etwas Programmierung in einer Function Node - könnte man sich damit auch eine Befehlsqueue aufbauen, die nur bei korrektem Fehlerstatus die Velux Nodes mit Befehlen versieht.
-
In Anlehnung an das vorherige Posting könntest Du auch versuchen mit einer Velux Node verschiedene Fenster zu steuern und mal schauen ob das geht.
Ich habe das mal mit dem topic und Inject Nodes versucht - und das kannst ja auch mal probieren, halt mit Deinen IDs
ob Du so Deine verschiedenen Fenster / Rolläden mit einer Velux Node steuern kannst.
-
@sascho So nun habe ich mal so eine Befehlsqueue realisiert:
Wenn Du über die Inject Nodes wie im vorherigen Post Deine Fenster/Jalousien steuern kannst, dann wäre der nächste Schritt so eine Befehlsqueue mittels einer function Node zu realisieren. Man könnte das ggf. auch ohne function Node machen, aber dann wäre der Flow sehr unübersichtlich.
Die blaue Gruppe - in der ich den Fehler der Velux Nodes nur simuliere, kannst Du dann natürlich weglassen. Ich habe in der Simulationsnode - die Fehlerhäufigkeit mal auf 30% eingestellt, so dass 30% einen Fehler erzeugen.
Wenn Du im Flow die function Node "Befehlsqueue" markierst (orange Linie) und dann auf die Kontextdaten gehst und die Daten aktualisierst, dann siehst Du das die Befehlsqueue quasi leer ist.
Nun drücke ich die Inject-Nodes nach der Reihe der IDs (also 1,2,3,4,1,2, ...)
Wenn ein Fehler auftritt, bei mir gleich beim ID 1, dann siehst Du in der trigger Node das 1 Nachricht ansteht und diese nach einer Minute die Befehlsqueue erneut triggert.
In der Queue ist immer noch der eine Befehl - der also wegen des Fehlers noch nicht abgesetzt werden konnte.
Das passiert dann solange - bis die Velux Node (wieder verfügbar ist):
Hier ein Beispiel wo die erste ID funktionierte, ID 2 und 3 jedoch nicht - da Velux Node nicht bereit.
In der Befehlsqueue wurden die beiden zwischengespeichert:Alle Minuten wird nun versucht - die noch voll Queue abzuarbeiten bis die Velux Node verfügbar ist - dann wird die Queue geleert:
Hier wieder mal der View zum Spielen und Lernen.
Der untere Teil der function Node (Befehlsqueue) wird also ausgeführt, wenn die Velux Node im Fehlerzustand ist, ansonsten werden die Befehle nacheinander an die Velux Node über den oberen Ausgang der function Node gesendet.
Du kannst natürlich meine ganzen Debug Nachrichten aus der function Node rauslöschen, so dass der reine Code der function Node nun so aussieht:
var queue = context.get('queue') || []; var isError = false; msg.OK = msg.OK || false; if (msg.payload !== undefined) queue.push(msg); if (msg.error !== undefined) isError = true; if (msg.OK) { queue.shift(); isError = false; } context.set('queue',queue); if (queue.length > 0 && !isError ) { return [queue[0],null]; } else if (isError) { return [null,msg]; }
-
Wow! Jetzt bin ich völlig erschlagen. Ich muss mir das erst mal morgen alles in Ruhe ansehen. Tausend Dank schon mal vorweg! Ich glaube, ich muss Dir mal einen Präsentkorb schicken, bei dem ganzen Aufwand, den Du hier für mich betreibst!
Ich habe gerade das KLR200 in Betrieb genommen, und im KLF200 4 Szenen zu einem Fensterpaar angelernt:
Mit der Scene Node und einer Inject Node kann ich die 4 Szenen ansteuern. Es funktioniert sehr gut.
Die Kür wäre jetzt, wenn ich nur eine Velux Scene Node benötigen würde, indem ich den Szenenindex in der Nachricht mitgebe. Laut diesem Node Guide wäre das doch möglich:
Was muss ich denn da im Topic mitgeben? Ich bekomme nur Fehler gerade.Das geht doch in die Richtung, wie Du es oben aufgebaut hast - hinter die Dachfenster Funktionen hängen, die dann die Velux Scene Node anspricht.
Btw. Die Scene Node sendet auch Status Meldungen - einige während die Fenster laufen... Evtl. könnte ich mir da die Current, und Remaining/Run Status Meldungen abfangen und so auf die Velux Nodes komplett verzichten
-
@sascho Also die Szene IDs sind ja eindeutig. Im Prinzip brauchst Du in den Velux Scenes Node gar nichts eintragen.
Du gibst einfach die ID in das topic im Inject Node ein und fütterst damit die Scenes Node:
Die Zahl hinter der ID ist die Szene ID und nicht die Node ID - wie bei der Velux Node Node.
Aber nicht msg msg.topic =msg.velux... , sondern natürlich als String :
Sowas geht nicht:
Ein Objekt kann keine Doppelpunkte enthalten und Du hast ja in Deiner Inject kein msg.velux Objekt definiert. - Also einfach die Velux Node mit einem msg.topic als normalen String füttern.
Es macht ausserdem in dem unteren Flow keinen Sinn in der Debug Node eine msg.payload abzugreifen, wenn es keine msg.payload gibt
Dann ist es besser Du stellst die Debug Node auf das gesamte Nachrichten objekt um:
-
Also, irgendwie funktioniert es noch nicht. Ich habe die Inject Node auf String umgestellt und den Scene Index 0 und 1 probiert. Darauf reagiert die Velux Scene Node nicht:
Die Debug Node habe ich auf all Messages umgestellt.
-
@sascho Nun - ich finde leider auch nichts genaues
Wenn die Scene Node noch rot ist - dann muss man da was eingeben. Es darf auf KEINEN Fall noch so ein rotes Warndreieck über der Node zu sehen sein und die rot umrandeten Felder müssen ausgefüllt sein.
So wie ich den Text verstehe:
velux:id:<id> scene id for execute. **The settings are ignored.**
Du musst in der Szene ID trotzdem in die Node eingeben (auch wenn man das wohl mit dem topic überschreibt) - das darf nicht leer oder rot bleiben. Also gib einfach mal eine Zahl als Szene Index ein und schau - ob Du das mit der Inject Node überschreiben kannst.
-
Mit der Variante String geht es leider nicht :-(.
Die ersten zwei Versuche mit den Scene IDs 4 und 5 führen zu keiner Reaktion bei KLF200, der dritte Versuche dann mit Scene ID 5 + Number produziert eine Reaktion allerdings keine Bewegung:Gäbe es evtl. eine Alternative, die Szene über die Velux API + eine Funktion auszulösen? Hier wird das beschrieben (auch wie man die Überlastung des KLF200 verhindern kann):
https://213.136.68.177/topic/14312/adapter-für-velux-klf-200-interface/41?lang=en-GB&page=6
Dies wäre der Code:
Allerdings müsste ich wahrscheinlich die settings.js modifizieren.
-
Ich hab's mit der Function + API Node hinbekommen :-)))!!! Ich kann nun über die Inject Node direkt die Szene aufrufen.
Das Programm zum öffnen von Dateien im Terminal des Docker vom IOBroker nennt sich Nano. Damit konnte ich die settings.js modifizieren. Der Befehl lautet: nano /opt/iobroker/node_modules/iobroker.node-red/settings.js
Ich würde jetzt mal zwei Fenster auf die API Node umbauen. Im nächsten Schritt wäre aber die Frage, ob ich mit einer weiteren API Node auskommen würde, um die Current Position und Remaining/Bewegungsstatus auszulesen :-). Ich bin aber für heute schon mal super Happy!
-
@sascho Kannst Du Code für die Zukunft in CodeTags packen - sonst ist das blöd zum Kopieren.
Punkt 1:
Ehrlich gesagt verstehe ich den functions-code nur halb und halte auch davon überhaupt nichts. Wie gesagt, um Überlastung zu verhindern, habe ich Dir ja gestern ein paar Flows geschickt. Die settings.js müsstest Du modifizieren, aber nur weil du die API in der Function Node verfügbar machen müsstest. Dafür hast Du aber die Velux Nodes und die machen die Arbeit schon, auch wenn wir es halt nicht wissen, warum es nicht geht.
In der Function Node werden Fehler auch nur mit catch abgefangen. Wie gesagt - ich halte nichts davon, über function Nodes so was komplett zu schreiben.
Der Ersteller dieser Function Node macht nichts weiter als die API aufzurufen, das können wir mit der API Node ja auch versuchen.
Im Prinzip fängt der Fehler nur mit der Catch Node ab, macht aber nichts draus.
Was der macht ist nur die API aufzurufen, dass kannst Du aber auch mit den API Nodes:Das gleiche können wir aber auch mit der API Node versuchen:
Im Prinzip hat dieser Ersteller der Function Node nur diese API Funktion aufgerufen:
Wenn Du die Inject Node aufmachst um das Objekt zu bearbeiten, dann mach den visuellen Editor auf, dann kannst da die Zahl für die Szene eingeben.
Eventuell muss man lt. API auch noch die Velocity eingeben.
Du hast auch nicht rückgemeldet, ob die API Nodes zur Ermittlung des Status und der Reboot funktionieren????
Punkt 2:
Probier halt auch ob meine Inject Nodes mit den normalen Nodes funktionieren.
Punkt 3
Ich habe mir gerade den Source Code der Szene Node angeschaut - also es muss in jedem Fall das Topic als String übergeben werden:Ich bin mir aber noch nicht sicher, ob ich das mit den Szenen verstanden habe. Inzwischen kannst ja mal den API Call der Szene probieren und schauen, ob was zurückkommt.
-
@sascho sagte in bshb - Rollladensteuerung mit yhka Homekit:
Ich hab's mit der Function + API Node hinbekommen :-)))!!! Ich kann nun über die Inject Node direkt die Szene aufrufen.
Das Programm zum öffnen von Dateien im Terminal des Docker vom IOBroker nennt sich Nano. Damit konnte ich die settings.js modifizieren. Der Befehl lautet: nano /opt/iobroker/node_modules/iobroker.node-red/settings.js
Ich würde jetzt mal zwei Fenster auf die API Node umbauen. Im nächsten Schritt wäre aber die Frage, ob ich mit einer weiteren API Node auskommen würde, um die Current Position und Remaining/Bewegungsstatus auszulesen :-). Ich bin aber für heute schon mal super Happy!
Ich würde es nicht machen. - Ich hab Dir ja gerade geschickt, wie Du das was die Funktion macht ggf. auhc mit der API Node machen kannst.
Nano ist übrigens ein Linux Editor - dann hat inzwischen jedes neuere Linux System an Board.
Aber wie gesagt mit der Function Node - bin ich aus dem Spiel.
-
Mit der API Node + Funktion hattest Du vollkommen Recht, das war nichts. Die Reaktion der testweise angeschlossenen Fenster war total sporadisch. Ich habe sie erst einmal wieder rausgenommen - total frustierend so etwas.
Stattdessen habe ich gestern die restlichen Szenen im KLF200 angelernt, nachdem es aufgehört hatte zu regnen (ansonsten fahren die Fenster nicht auf).
Ich habe dann mal auf die Schnelle den KLF200 Adapter wieder installiert und an die Szenen gehängt. Bisher läuft der Adapter ohne Absturz und keine Fehlermeldungen im Log.
Evtl. ist ja der Adapter doch die bessere Wahl in Verbindung mit den Szenen + evtl. das Abfangen von Statusmeldungen im Log. Ich habe jetzt einen Smarten Zwischenstecker vor dem KLF200. Wenn eine Fehlermeldung des Adapters im Log auftaucht, könnte man den Zwischenstecker kurz aus und einschalten und dann den Adapter neu starten. Evtl. ist das die beste Lösung?
Mich würde aber schon noch interessieren, ob wir die Nodes zum Laufen bekommen mit Deinen Skripten - mir fehlt gerade nur die Zeit zum ausprobieren :-(.
-
@sascho sagte in bshb - Rollladensteuerung mit yhka Homekit:
Mit der API Node + Funktion hattest Du vollkommen Recht, das war nichts. Die Reaktion der testweise angeschlossenen Fenster war total sporadisch. Ich habe sie erst einmal wieder rausgenommen - total frustierend so etwas.
Na deswegen war ich da auch raus - wenn jemand meint mit einem API Call, dasselbe zu erreichen. Wie gesagt, das hättest Du direkt auch mit der API Node machen können und ich hab Dir ja beschrieben, wie man sowas dann macht. Und wenn man mit der API arbeitet, dann gehört etwas mehr dazu, als nur den Request abzusetzen, das können die API Nodes auch.
Lies mal aus der API Doku ab seite 95
Ich hätte also zumindest erwartet, dass diese Function zurückgibt, ob der Request akzeptiert wurde oder nicht und das hat der alles nicht gemacht. Deswegen war das für mich gleich alles für die Tonne, zudem Du ja die API Node hast, um sowas zu machen.
Aber für Dich ist es wahrscheinlich wirklich besser, Du nimmst den iobroker Adapter wieder in Betrieb und reagierst erst mal auf Fehlersituationen im Log, als Dich mit diesen Problemen rumzuschlagen.
Es wäre was anderes wenn ich auch so KLF Gateway hätte, dann könnte ich Dich hier ganz anders unterstützen, da ich die Dinge ja selbst ausprobieren könnte, aber nach dem nicht der Fall ist, geht das leider nicht. Auch das ich generell den Vorschlag gemacht habe, es mit den Velux Nodes es zu versuchen, war ja nur der Versuch, ob Du damit etwas mehr Stabilität bekommst. Wie Du an dem Flow mit der Befehlsqueue siehst, hat man halt ggf. mehr Möglichkeiten durch direktes Zurückmelden einer Fehlersituation eben schneller zu reagieren, als über den Adapter.
Wie gesagt, nimm den Adapter wieder in Betrieb und installiere Dir die von mir empfohlene Tailnode. Ich habe die jetzt 1-2 Wochen in Betrieb und die kommt nun mit dem Wechsel des iobroker Log Files gut zu Recht.
-
Dieses Schaubbild von Velux hat mich überzeugt, es mal verstärkt mit den Scenes zu versuchen. Ich habe ganz stark die Vermutung, dass das KLF200 gut damit zurecht kommt, aus einem User-Szenenbefehl mehrere Aktuatoren sauber anzusteuern. Nicht gut zurecht kommt es mit Situationen, wo mehrere User-Befehle mit mehreren Aktuatoren verheiratet werden müssen.
Auch mit fast zeitgleich ausgelösten Szenen kommt es gut zurecht. Seit zwei Tagen läuft der Adapter durch und nichts vom Adapter ist im Log aufgetaucht. Das ist doch schon mal super.Und realistischerweise - ich habe hier im Haus noch so viele Sachen zu erledigen - da mache ich mich an das Nodes Thema lieber später noch mal dran. Evtl. hat es ja noch ein paar Vorteile ggü. dem Adapter.
Ich hoffe, dass der Adapter jetzt mal sauber durchläuft - beim ersten Crash baue ich dann noch die Tail-Node ein.
Als nächstes muss aber auf jeden Fall noch die PV Anlage eingebunden werden :-). Du bist aber eine ganz große Hilfe in der Lage! Wirklich noch einmal großen Dank und meine aufrichtige Hochachtung vor Deinen Fähigkeiten! -
@mickym Kurze Frage, ich wollte gerade noch mal den Restart der Instanz einbauen, wenn der Adapter die Verbindung zum KLF200 verliert.
Trigger für den Restart ist, wenn der Connection Datenpunkt auf False springt.
Ich bekomme aber den Trigger für den Instanz-Restart nicht hin. Es kommt immer folgende Fehlermeldung. -
@sascho Hallo - wäre toll wenn Du den Code für den Flow in CodeTags packen würdest.
Ich habe den klf200 Adapter ja leider nicht installiert - aber ich fürchte ich kann Dir nicht helfen. Weil ich hab einfach mal einen anderen Adapter mit Deinem Flow genommen und der funktioniert:
Ich hab mal den Info Adapter neu gestartet.
Schau mal ob Du andere Adapter neu starten kannst - ansonsten hast Du im System ggf. ein Berechtigungsproblem.
Irgendwie als ob Dein NodeRed Adapter unter einer anderen Kennung läuft keine Ahnung.
Eigentlich muss es so funktionieren. Evtl. ist an Deinem System was schief - da müsste ggf. unser Linux Guru helfen => @Thomas-Braun
HIer gabs mal ein ähnliches Problem: https://forum.iobroker.net/topic/40916/docker-container-restart-iobroker-per-script/42?_=1632433048127
Du kannst also mal probieren:
sudo -u iobroker iobroker restart info.0
funktioniert bei mir jedenfalls auch:
-
Ich habs mal mit dem info Adapter probiert. Das funktioniert auch nicht, sieht so aus als wenn ich tatsächlich ein Berechtigungsproblem habe. Soll ich dann mal den Kollegen anklingeln? Die verlinkte Lösung sieht sehr kompliziert aus.