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.