Logik - R&S FlipFlop

[sleepless]

mein ehrlicher Rat? Du solltest entweder beim SPSen bleiben oder dich unvoreingenommen mit KNX auseinandersetzen. Du scheinst zu wissen ws NICHT geht und was du NICHT willst - das ist meiner Meinung der falsche Lösungsansatz buw die falsche Herangehensweise.

Danke für dein Feedback. Ich bin sehr wohl unvoreingenommen an KNX herangegangen, gerade weil ich aus der SPS-Welt komme. Dort kenne ich saubere, deterministische Möglichkeiten – z. B. Flip-Flops, klare Signalflüsse, deterministische Programmierung.

Bei KNX fallen einem diese Schwächen sofort auf: fehlende einfache RS-Flipflops, mögliche Race-Conditions, Workarounds anstelle sauberer Lösungen. Das Problem liegt nicht in der Idee von KNX, sondern im grundlegenden Design, das Programmierer ständig zu improvisierten Lösungen zwingt. Für einen Programmierer, der sauberen Code gewohnt ist, ist das schlicht Pfusch. Ohne eine zusätzliche detaillierte und aufwendige Dokumentation ist da kein Durchblick für dritte mehr möglich.

Mir geht es nicht darum, KNX abzulehnen, sondern zu verstehen, wie man solche einfachen Mechanismen wie eine Verriegelungen sauber, nachvollziehbar und ohne fragwürdige Tricks umsetzen kann. Ich möchte lernen, wie man innerhalb dieser Grenzen elegante Lösungen schafft, statt nur herumzudoktern.

Ich werde mir später das OpenKNX Logikmodul genauerer ansehen. Gerne kann man hierfür einmal ein "First Setup" Guide etc. aufzeigen, sofern vorhanden.

[coko]

letour 4Zoll Smart Touch

Das liest sich eher wie ein Exot, für den Du Dich möglicherweise auf YouTube hast begeistern lassen? Wenn es Dir wirklich um Stabilität geht, dann würde ich das kritisch hinterfragen...

wenn du auf OpenKNX anspielst. Ich weiß kaum, was dahinter steckt, aber der kurze überblick über das Logikmodul ließ auf eine Softwarelösung schließen.
Ich hatte das nicht deutlich genug erwähnt, aber im Prinzip ist's dann so wie iobroker in Verbindung mit Homematic, welches für mich aus Latenz & Zuverlässigkeit Günden aus dem rennen ist. Ich möchte nicht wieder im Durchschnitt 1000ms "Lag" im System haben oder "geht gar nicht, weil ein OS Update alles kaputt gemacht hat oder ein Service sich auf die Nase legte". Für gewisse Anwendungen werde ich weiterhin iobroker nutzen, da es einfach nur unendliche Möglichkeiten bietet - aber ich möchte keine Software (auf OS Basis) mehr für kritische Funktionen haben. Mein Licht muss auch angehen, wenn der "Server" aus ist 😉

Wie kommst Du darauf, dass das OpenKNX-Logikmodul eine "Softwarelösung" sein soll? Software steckt natürlich in allen KNX-Geräten drin; bei OpenKNX setzten wir konsequent die Funktionen in einer Mikrocontroller-Firmware um die i.d.R. über KNX-TP kommuniziert. Latenz wird da durch den TP-Bus bestimmt. Konfiguration erfolgt in der ETS und entsprechend könntest Du im Fall eines Hardware-Defekte genauso einfach austauschen wie bei kommerziellen KNX-Geräten...

[coko]

weil ich aus der SPS-Welt komme. Dort kenne ich saubere, deterministische Möglichkeiten – z. B. Flip-Flops, klare Signalflüsse, deterministische Programmierung.

Bei KNX fallen einem diese Schwächen sofort auf: fehlende einfache RS-Flipflops, mögliche Race-Conditions, Workarounds anstelle sauberer Lösungen. Das Problem liegt nicht in der Idee von KNX, sondern im grundlegenden Design, das Programmierer ständig zu improvisierten Lösungen zwingt. Für einen Programmierer, der sauberen Code gewohnt ist, ist das schlicht Pfusch. Ohne eine zusätzliche detaillierte und aufwendige Dokumentation ist da kein Durchblick für dritte mehr möglich.

Mich überrascht es etwas, warum FlipFlops für Dich so wichtig sind: Ich kann ich mich gerade nicht dran erinnern, wann ich die mal gebrauch hätte in KNX (liegt vielleicht aber auch daran, dass ich meinen Zustandsautomaten eine deutlich mächtigere Möglichkeit habe). Für Race-Conditions gib uns doch bitte einfach mal ein Beispiel, dass nicht durch die Eigenschaft von KNX als verteiltes System entsteht. Saubere Lösungen ergeben sich häufig schon alleine durch ein Studium der Hersteller-Dokumentation(und Geräten die einen gewisse Bandbreite an typischen Anwendungsfällen von Haus aus mitbringen. Dann sind da auch Randfälle mit abgedeckt die Du bei eigenem basteln leicht vergisst. Die Verwendung des Programmierer-Begriffs ist unpassend, weil eine reine Parametrierung der vorhandenen Implementierung des Herstellers erfolgt.

Ich werde mir später das OpenKNX Logikmodul genauerer ansehen. Gerne kann man hierfür einmal ein "First Setup" Guide etc. aufzeigen, sofern vorhanden.

Zur StateEngine bzw. den Zustandsautomaten hatte ich Dir schon Links mitgegeben. Fürs LogikModul findest Du ebenso reichlich Informationen hier im Forum, u.A. Anwendungsbeispiele, sowie auch in der Applikationsbeschreibung auf GitHub. Für den schnellen Überblick sind ggf. auch die Videos von Torben Ledermann ganz nützlich: Das können Open-Source KNX Geräte! - OpenKNX Logikmodul (noch mit älterem Setup-Weg) und So hast du Logiken noch nie programmiert! – OpenKNX StateEngine erklärt.

[Fidelis]

Bei KNX fallen einem diese Schwächen sofort auf: fehlende einfache RS-Flipflops, mögliche Race-Conditions, Workarounds anstelle sauberer Lösungen. Das Problem liegt nicht in der Idee von KNX, sondern im grundlegenden Design, das Programmierer ständig zu improvisierten Lösungen zwingt. Für einen Programmierer, der sauberen Code gewohnt ist, ist das schlicht Pfusch. Ohne eine zusätzliche detaillierte und aufwendige Dokumentation ist da kein Durchblick für dritte mehr möglich.

Sorry, das liest sich alles nach "ich will KNX nicht mögen, weil es nicht SPS ist" und hat mit der Praxis wenig bis gar nichts zu tun.

• Race Conditions? In KNX passiert nichts zeitkritisches, nichts in Echtzeit. Oder meinst du wenn du in exakt der gleichen Millisekunde einen Taster drückst während eine Automation getriggert wurde? So what?!
• Workarounds und improvisierte Lösungen? Ja, wenn man unpassende Produkte gekauft hat oder KNX für Dinge einsetzen möchte, für die es eigentlich nicht gedacht ist, mag das nötig sein.
• Pfusch? Das ist als Anwender mehr oder weniger ausgeschlossen. Ja, unsaubere oder für andere schwer nachvollziehbare Wege, sind möglich, aber das ist überall der Fall, was nicht komplett Plug&Play ist.
• Zusätzliche und aufwände Dokumentation? Nein, eben gerade nicht, weil die Doku vollständig in der ETS vorliegt.
• Durchblick für Dritte? Ja, immer, sofern das Projekt in der ETS sauber gepflegt ist. Dann liegt dort alles zentral und transparent ab.

[knxPaul]

Bei KNX fallen einem diese Schwächen sofort auf: fehlende einfache RS-Flipflops, mögliche Race-Conditions, Workarounds anstelle sauberer Lösungen. Das Problem liegt nicht in der Idee von KNX, sondern im grundlegenden Design, das Programmierer ständig zu improvisierten Lösungen zwingt. Für einen Programmierer, der sauberen Code gewohnt ist, ist das schlicht Pfusch. Ohne eine zusätzliche detaillierte und aufwendige Dokumentation ist da kein Durchblick für dritte mehr möglich.

KNX hat einen völlig anderen Ansatz: Der Anwender soll gar nicht programmieren, weil das die Hersteller der Geräte ihm abnehmen. Wie beim Einsatz von Low-Code Systemen muss der Anwender "nur" die richtigen Geräte = Bausteine wählen und dann (mit GAs) verschalten. Die KNX-Geräte enthalten den sauber implementierten, gründlich getesteten und aufwändig dokumentierten Programmcode. Wenn sich die gewünschte Funktionalität mit einer Geräte-Kombination nicht einfach realisieren lässt, muss das Gerät ausgetauscht werden, ohne mit einem Logik-Modul einen Workaround dazuzubasteln..

[GLT]

bisher habe ich in KNX Installationen im Business noch nie eine SPS gesehen

Also hast Du noch nicht wirklich viele gewerbliche Installationen gesehen - KNX in Verbindung mit SPS oder DDC ist business as usual.
Je nach Aufgabenstellung in verschiedensten Konstellationen - privat hingegen ist das eher ungewöhnlich; hier greift man dann auf HS/FS,X1, HASS, NR usw. zurück.

Ohne eine zusätzliche detaillierte und aufwendige Dokumentation ist da kein Durchblick für dritte mehr möglich.

Wer sein Projekt sauber führt, hat alles in einem Paket - ist wie bei der SPS auch - wenn da rumgepfuscht ist, braucht man auch Zeit, sich die Spaghetti zu sortieren.

KNX-Anlagen "programmieren" bedeutet halt auch, die passenden Bibliotheken (Komponenten) auszuwählen u. nicht den Schrott aus eBay zusammen zu würfeln. Klar - es gibt immer wieder Situationen, bei der man mal mehr Hirnschmalz verbraucht und/oder eine zusätzliche Komponente mit rein nehmen muss. Ggfs. dreht man den Spieß auch mal um, nimmt eine SPS als Haupthirn u. KNX als intelligenten Sensorbus - ist aber eher weniger die Regel, denn die Ausnahme.

Man wählt das System, dass zur Aufgabe passt u. reduziert nicht alles auf einen Nagel, damit der Hammer das Werkzeug der Wahl wird.

[waldecker01]

Hast du die Logo Ausgänge benutzt?

Sowohl als auch.
Habe einige Steuerungen gebaut wo die Logo alles übernommen hat. und diverse Meldungen auf den Bus gebracht, oder Befehle übernommen hat.
War ehr die Zeit wo es wenig Logik Bausteine von KNX gab.
Wenn Platz in der Logo ist (hab noch 3 Stück am laufen) werden die auch für externe Logiken genutzt.
Blöd ist halt das die Anzahl der Ein und Ausgänge begrenzt ist (Logo 4, 5, 6, 7).
Heute ist ein KNX Logik Modul sicher angebrachter.
Für mich macht es auch Sinn einige Geräte unabhängig vom Bus zu betreiben, wie z.B. Zisterne, Torsteuerung.
Fällt der Bus aus, können diese Anlagen weiter genutzt werden.

[tsb2001]

Für einen Programmierer, der sauberen Code gewohnt ist, ist das schlicht Pfusch.

Das liegt an der Konzeption von KNX.
In einer SPS gibt’s eine CPU, die aus digitalen Ein- und Ausgängen, Feldgeräten über Profibus, Profinet, ASi oder sonstige Systeme alle Daten einliest, verarbeitet und ausgibt. Da liegt die Logik an einer Stelle. Alle Eingänge lassen sich an einer zentralen Stelle verarbeiten und wieder ausgeben; und das wird genau dort an einer Stelle (CPU) frei programmiert.

Bei KNX hast du dutzende, mitunter hunderte CPUs, nämlich in jedem einzelnen Sensor, Aktor, Taster und was auch immer. Es gibt keine „zentrale“ Intelligenz wie in einer CPU einer SPS. Daher parametrierst du vorgefertigte Systeme, die lediglich über die eingeschränkten Konfigurationsmöglichkeiten einer jeden Firmware eines einzelnen KNX-Geräts dem Anwender zur Verfügung gestellt werden. Es bleibt lediglich die Möglichkeit, über die passende Applikation das richtige KNX-Gerät für seinen Anwendungsfall auszuwählen.

Das ist der Vorteil von KNX: es gibt im vergleich zur SPS keine zentrale Komponente, die als Single-Point-Of-Failure ausfallen kann (allerhöchstens die Spannungsversorgung, die aber auch redundant ausgeführt werden kann). Du kannst jedes Gerät abstöpseln, der Rest läuft einfach weiter. Ist die CPU einer SPS aus, funktioniert gar nichts mehr.
Es ist allerdings kein freiprogrammierbares System.

Das mach natürlich das Konfigurieren schwierig, da lediglich vorgefertigte Ausgänge bestimmte Funktionen erfüllen, die durch vorgefertigte Eingänge eines anderen (oder des selben Geräts) getriggert werden. Alles aus verteilter Intelligenz einer jeden - für den Anwender - unveränderbaren Firmware eines KNX-Teilnehmers.

KNX ist folglich nicht mit einer SPS und deren Funktion vergleichbar.

[Beleuchtfix]

Als einfaches Logik Modul schau dir das Logik Modul von MDT an, nicht so mächtig wie das Open KNX, dafür lizensiert von einem Bekannten KNX Hersteller.
Gruß Florian

[sleepless]

Wie kommst Du darauf, dass das OpenKNX-Logikmodul eine "Softwarelösung" sein soll?

Ein gut gepflegtes Github-Repo.

Zur StateEngine bzw. den Zustandsautomaten hatte ich Dir schon Links mitgegeben. Fürs LogikModul findest Du ebenso reichlich Informationen hier im Forum, u.A. Anwendungsbeispiele, sowie auch in der Applikationsbeschreibung auf GitHub. Für den schnellen Überblick sind ggf. auch die Videos von Torben Ledermann ganz nützlich: Das können Open-Source KNX Geräte! - OpenKNX Logikmodul (noch mit älterem Setup-Weg) und So hast du Logiken noch nie programmiert! – OpenKNX StateEngine erklärt.

Danke. Im Prinzip ist's das Gerät, was ich vom können her 100Pro haben will.

Die Hardware und der Zugang dazu werfen aber einige Fragen auf. Ist es wirklich notwendig, Löten zu müssen, um ein funktionierendes Gerät zu erhalten? Der Preis von 40€ erscheint in diesem Zusammenhang fraglich. Wenn die Produktion irgendwann endet, könnte es problematisch werden, Ersatzteile oder Hardware-"Updates" zu bekommen?
Insgesamt hätte ich mir von der Hardware mehr erwartet, als ein Projekt, das möglicherweise stark von einer einzelnen Person abhängt.
Dieser Fakt bringt mich ins nachdenken, ob mir dieses Risiko es Wert ist oder ich doch lieber ins maßlos überteuerte Siemens Regal greife.
Das muss ich aber für mich klären.

Aber eins noch:
"Anwenderfreundlich" ist ein notwendiges Studium von schnell mal 30 Seiten Parametern je Gerät absolut nicht.
Das wäre ein "auspacken, im System einpflegen und die Parameter ohne Handbuch verstehen".

Abschließend zum Thema SPS vs KNX:

Warum Flipflops?
Nun, weil sie sich Zustände merken und erneute "ein" Befehle ignorieren. Super easy.

SPS: Klemm einfach 100 Taster an einem einzigen Eingang auf einem FlipFlop, welches du aus eine Bibliothek ziehst oder in alter Schreibweise mit einem "S" und "R" hast, an. Egal, welchen Taster du drückst, das Licht wird nur einmal eingeschaltet.
KNX: Klemm einfach auf den Aktor 100 Taster. Jeder Taster schaltet den Eingang von bereits ein -> aus -> ein, wenn irgendwo ein anderer auch noch drauf rumdrückt oder evtl. eine Automatik eines Sensor greift. Wenn du das nicht willst, brauchst du gefühlt 60 Logiken und 40 Gruppenadressen, in denen du dir deine Flipflops erst einmal "zusammen" mit XOR bauen musst.

Was ist nun eleganter und schneller? "S" und "R" in einer Anweisung zu schreiben oder die komplexe KNX Variante?
Ich denke, das Thema SPS vs. KNX werde ich nicht weiter vertiefen. Wer Erfahrung in der SPS-Programmierung hat, wird den Unterschied verstehen, während andere das Thema vielleicht nur aus allgemeinem Wissen kennen. Ich kenne ihn und mir bringt es auch nichts, darüber weiter zu diskutieren.

[GLT]

Was ist nun eleganter und schneller? "S" und "R" in einer Anweisung zu schreiben oder die komplexe KNX Variante?

Bei deinem 100Taster "nur Ein" Beispiel definitiv die KNX-Variante mit Logik "Filter/Begrenzer" - da kann ich bequem auch umschalten, ob alle nur Ein oder auch Ein/Aus dürfen - ohne die Logik mal umprogrammieren zu müssen.

Irgendwie dünkt mir, Du willst gar kein KNX u. suchst die abstrusesten Gründe, um deine Entscheidung für Dich selbst zu rechtfertigen.

Ich denke, das Thema SPS vs. KNX werde ich nicht weiter vertiefen.

Deine Entscheidung - wir sind nicht dafür da, dich überzeugen zu müssen.

Wer Erfahrung in der SPS-Programmierung hat,...Ich kenne ihn und mir bringt es auch nichts, darüber weiter zu diskutieren.

SPS/DDC seit Berufseinstieg u. Instabus/EIB/KNX >30 Jahren inzwischen - und nun?
Es hat seine Gründe, dass ausgerechnet Siemens (als quasi DER SPS-Industriestandard) von Anfang an dabei war - denn nicht das Eine oder Andere ist perse besser - jedes hat seine Aufgabenbereiche/Fähigkeiten/Vorzüge je nach Anforderung u. können sich auch gut ergänzen. Und bei "Überschneidungen" gilt es halt abzuwägen.

[tsb2001]

Wer Erfahrung in der SPS-Programmierung hat, wird den Unterschied verstehen, während andere das Thema vielleicht nur aus allgemeinem Wissen kennen.

Ich verstehe den Unterschied, denn ich habe Jahrelang mit Siemens, Wago und Beckhoff einiges an SPS-Projekten umgesetzt. Ich habe aber auch jahrelang KNX-Prokekte umgesetzt.

Da ich KNX „verstanden“ habe, sind das für mich hinsichtlich der Konzeption zwei völlig unterschiedliche Welten. Hinsichtlich der Ausfallsicherheit und des absolut dezentralen Konzepts mit lediglich 2 Adern an jeden Sensor/Aktor ist KNX das Mittel der Wahl für eine Gebäudeinstallation. Eine SPS würde ich nicht dazu verwenden wollen.
Warum nicht: analoge Sensoren (Feuchtigkeit, Temperatur) bedürfen schon alleine wegen der Störeinstrahlung besonderer Aufmerksamkeit und müssten alle quer durchs Haus zu den Analogeingängen geführt werden; oder zumindest zur dezentralen Peripherie, wenn man es etagenweise verteilt. Und davon gibt es im Haus alleine schon für Raumtemperaturregelungen unwahrscheinlich viele.
Im KNX baue ich einen Taster an die Tür und habe darin alle Sensoren vereint. Keine Abschirmung, kein garnichts.

Und dein Flipflop in der SPS funktioniert nur mit 2 Tasten. Eine davon triggert das Set, das andere den Reset.
Geht mit KNX ganz genauso. Eine Taste sendet ein „Ein“ und triggert damit das „Set“; egal wie viele Taster darauf wirken.
Wenn die zweite Taste mit „Aus“ konfiguriert ist, macht die ein „Reset“. Und auch da ist die Anzahl an Tasten komplett egal.
Und dafür braucht es keine Logik, sondern einfach nur zwei Tastenpaare. Genau wie bei der SPS…

[Beleuchtfix]

Die Lösung ist ganz einfach, verwende eine SPS, du kennst sie gut, KNX ist anders, erfordert ein anderes Denken.

Und die OpenKNX Module sind auch nichts für dich, zu teuer, Bastelware, kann alles was du möchtest, aber man muss sich einlesen (ich bin immer froh, wenn der Hersteller halbwegs vernünftige Beschreibungen liefert). Immerhin konnten wir dir helfen, dass du innerhalb nur einer Woche genügend Gründe gegen KNX gefunden hast.

Viel Spaß mit der Logo.
Florian

[mumpf]

Ich will Dich keinesfalls zu DIY überreden, das muss wirklich jeder selber entscheiden, aber ein paar Sachen klarstellen:

Ist es wirklich notwendig, Löten zu müssen, um ein funktionierendes Gerät zu erhalten?

Ja, wir machen Open Source und Open Hardware, alles Schaltpläne und Platinen sind veröffentlicht, so dass Du sie auch selber aufbauen kannst. Ob derjenige, der die Hardware entwickelt hat, auch Bausätze verkauft, die es einem einfacher machen, an die HW zu kommen, ohne alles einzeln bestellen zu müssen, bleibt demjenigen überlassen. Aber auch das sind Bausätze, keine fertigen Produkte. Normalerweise sind alle SMD-Bauteile fertig gelötet und der Lötaufwand für den Rest hält sich in Grenzen.

Wenn die Produktion irgendwann endet, könnte es problematisch werden, Ersatzteile oder Hardware-"Updates" zu bekommen?

Nein, denn es ist alles dokumentiert und Du kannst es selber nachbestellen oder gar reparieren. Genau das ist die Idee von OpenKNX - nicht von einem Hersteller abhängig zu sein.

"Anwenderfreundlich" ist ein notwendiges Studium von schnell mal 30 Seiten Parametern je Gerät absolut nicht.
Das wäre ein "auspacken, im System einpflegen und die Parameter ohne Handbuch verstehen".

Ich kenne die Logo gar nicht, insofern muss ich mal rückfragen: Das ist eine komplexe Logikengine, mit der man komplexe Systeme aufbauen kann, ohne ein Handbuch zu lesen? Dann hat Siemens einen besseren Job gemacht als wir, aber das ist auch ok, da stecken bestimmt auch mehr Leute dahinter als die paar, die wir hier sind.

Naja, und Dein Beispiel mit den Tastern zeigt, dass Du KNX noch nicht ganz durchdrungen hast bzw. Dir vorschnell eine Meinung gebildet hat. In KNX ist jedes Kommunikationsobjekt so eine Art Flip-Flop, wie Du es beschreibst. Du kannst beliebig viele EIN-Telegramme an ein KO senden, es bleibt EIN, wenn Du den Wert liest. Wenn Du ein AUS schickst, geht es natürlich auf AUS und bleibt dabei. Wenn Du einen Taster also so parametrisiert hast, dass er EIN->AUS->EIN sendet, dann wird sich auf der Empfangsseite das KO natürlich auch so verhalten. Aber ich kann mir nicht vorstellen, dass das bei der Logo anders ist?
Auf jeden Fall kann ich ohne Probleme in KNX 100 Taster mit einem einzigen Eingang verbinden und ohne jegliche Logik so schalten, wie ich will. Und die Taster können sogar beliebig gemischt aus 1-Tasten- oder 2-Tasten-Bedienung bestehen.

Gruß, Waldemar

[coko]

KNX: Klemm einfach auf den Aktor 100 Taster. Jeder Taster schaltet den Eingang von bereits ein -> aus -> ein, wenn irgendwo ein anderer auch noch drauf rumdrückt oder evtl. eine Automatik eines Sensor greift. Wenn du das nicht willst, brauchst du gefühlt 60 Logiken und 40 Gruppenadressen, in denen du dir deine Flipflops erst einmal "zusammen" mit XOR bauen musst.

1. Wechselndes Senden von Ein/Aus passiert nur dann wenn Du einen Taster als Umschalter konfigurierst
2. Wenn Du z.B. einen BWM oder PM nutzt, dann kannst Du diesem die Steuerung des Aktors auf Basis der internen Sensorwerte und manuellen Bedienungen (dafür haben die i.d.R. einen Eingang) überlassen

Dann brauchst Du für Standardfälle überhaupt keine einzige zusätzliche Logik und kommst kannst das schon mit 3 GAs (Schalten, Status-Rückmeldung, Manuelle Bedienung) abbilden.

Warum Flipflops?
Nun, weil sie sich Zustände merken und erneute "ein" Befehle ignorieren. Super easy.

Es ging mir nicht darum was ein FlipFlop ist, sondern ob Du dieses als zusätzliche Komponente benötigst. Und hier konstruierst du so soweit erkennbar einen Anwendungsfall in dem die Nutzung nur unnötigen Komplexitätserhöhrung führt. Das Lösungskonzept muss zum Problem und der Umgebung passen. Dafür muss man sich mit den vorhandenen Möglichkeiten einer, ggf. auch abstrakteren, Umgebung auseinandersetzen.

Was ist nun eleganter und schneller? "S" und "R" in einer Anweisung zu schreiben oder die komplexe KNX Variante?

An den Konzepten von KNX und den Möglichkeiten der genutzten KNX-Geräte vorbei zu arbeiten wird sicher nicht zu eleganten und schnellen Lösungen führen, sondern zu

Workarounds anstelle sauberer Lösungen.