Logik - R&S FlipFlop

[sleepless]

Hallo,

ich bin neu im KNX Thema, habe aber Fachkenntnisse in einem Ähnlichen Bereich (Elektriker).

Ich bin es gewohnt, bei Automatisationstechnik eine ausgereifte Logik vorhanden zu haben. Dies ist bei KNX leider nicht der Fall. Oft ist es abhängig vom gekauften Gerät und wenn dann nur Basic-Logik - also UND/ODER/XODER.
Mit solchen Bausteinen kommt man selten sauber ans Ziel.

Gibt's hier eine Möglichkeit, sich mit den vorhandenen Mitteln (also OHNE Logikmodul) ein R&S Flipflop zusammen zu basteln? Also ein vorgehen, welches Grundlegend funktioniert und man nur entsprechend auf seine Umgebung anpassen muss?

z.B. als ein Aktor nutze ich den Theben RM 16 S, als Schalter den MDT Smart Glastaster und ein True Presence von Steinel.
Alle stellen mir Logiken zur Verfügung und haben Sperrmöglichkeiten. Aber keine "Merker" oder FlipFlops etc.

[EPIX]

"Merker" sind bei KNX eher unüblich - KNX ist "eventgetrieben", also wer zuletzt etwas sendet, das "gilt"...
Das erfordert ein Umdenken von der SPS -Welt

[sleepless]

Ja, das habe ich bereits gemerkt. Das macht alles irgendwie super schwierig und nicht besser. Es fehlt eine "entscheidungsschicht", was aber auch positiv sein kann, insbesondere, was die stabilität angeht.
Aber dennoch: Sowas wie Zustandsabhänige "verriegelungen" sollten schon möglich werden. Und aus Sicherheitsgründen sollte diese Weiche beim Aktor liegen, nicht beim "sendenden" Teil.

Ich hab schon das Gefühl, das ich irgendwie im ein Logikmodul nicht drum komme. Nur sind diese Teile für das, was sie können und was sie kosten, ein lächerlicher Witz zu anderen smarten Lösungen. (Wenn die für 50€ zu haben wären, wär's passend. Aber nicht für 600€ aufwärts...)

[willisurf]

irgendwie im ein Logikmodul nicht drum komme.

Falls DIY in Frage kommt, schau Dir mal OpenKNX an. Da gibt es dann auch Zustandsautomaten….

[GLT]

Ich hab schon das Gefühl, das ich irgendwie im ein Logikmodul nicht drum komme.

Kann durchaus sein - könnte aber auch daran liegen, dass Du in der SPS-Denke ggfs. "falsch" an die Sache rangehst. Das kann aufgrund fehlender Info aktuell aber außer Dir keiner einschätzen.

Es gibt für den gewerblichen Bereich Steuerungen, die u.a. auch mit Node Red arbeiten können - recht viel flexibler wird's nicht.
Privat oder DIY kann man von VM bis RPi sich austoben.

[sleepless]

könnte aber auch daran liegen, dass Du in der SPS-Denke ggfs. "falsch" an die Sache rangehst.

Ja, das wird zu 100 Prozent so sein. Selbst Logikmodule bieten kein RS-FlipFlop oder irgendwas, was sich zustände "merkt". KNX ist da anders aufgebaut, ich muss das anders verarbeiten und hab irgendwie keine Idee, das sauber umzusetzen. Sauber heißt: Auch nach 10 Jahren kann man das gut nachvollziehen. Da sehe ich aktuell schwarz - um Verriegelungen umzusetzen, muss man oft an 20 Stellen etwas "verknüpfen". Sowas ist der Tod für die Übersicht.

Ich nenne mal ein Beispiel: Ein Taster, der je nach Zustand eines Aktors 2 Funktionen hat. Einmal normal einschalten, wenn der Aktor noch nicht aktiv ist. Und einmal den Aktor gegen andere Telegramme "verriegeln" wenn der Aktor bereits beim Tastendruck aktiv ist - als Beispiel, die EIN/AUS Telegramme vom Präsenzsensor ignoriert.
In der SPS Welt super easy - hier scheiter ich.
Ja - es gibt Taster mit einer "Langdruck" Option. Die macht am meisten Sinn und würde sämtliche Logik überflüssig machen. Aber der Kackpunkt: Nicht alle Taster haben solch eine "Langdruck" Funktion. Mähhh

Bin schon mit dem Gedanken am spielen, einfach am KNX eine Siemens LOGO! für solche Aufgaben zu stopfen. Overkill, aber immerhin eine echte Logik und eine Zentrale Übersicht vorhanden. (Auf ioBroker hab ich kein Bock mehr)

Aber wahrscheinlicher ist: Ich bin planlos und versuche mich mit meiner SPS Kenntnis zu retten 🙄 Erst mal werde ich deswegen gar nichts kaufen etc, was eine Logikschicht in meiner Topologie bringt, sondern auf die Tipps von KNX "Profis" warten. Weil bisher habe ich in KNX Installationen im Business noch nie eine SPS gesehen 😏

[EPIX]

Nicht alle Taster haben solch eine "Langdruck" Funktion

..
Jalousiefunktion haben 99% aller Taster - die kann man für solche Dinge verwenden - sofern binäre Signale genügen (0/1)

[coko]

"Merker" sind bei KNX eher unüblich - KNX ist "eventgetrieben", also wer zuletzt etwas sendet, das "gilt"...

Da will ich mal etwas dagegen argumentieren: Bei KNX könnte man womöglich sogar von einer gewissen "Dualität" von Zuständen und Ereignissen sprechen. Die Telegramme auf dem Bus sind natürlich Ereignisse, die dienen aber in vielen Fällen dazu einen verteilten Systemzustand über Gerätegrenzen zu synchronisieren. Je stärker das Gerät einen internen Zustand aufweist, desto schwächer wird diese Interpretation. Bei einem Aktor ohne Sperr-Funktionen u.s.w. kann man direkt von außen den Schalt-Zustand überschreiben. Bei komplexeren Aktoren hab Schalttelegramme einen stärkere Ereignis-Charakter ("Aufforderung zur Zustandsänderung"), der dann abhängig vom internen Zustand einen abweichenden Folgezustand erzeugen kann, der über Status-KOs auf dem Bus verteilt wird. Lesetelegramme fordern dazu auf den momentanen Zustand auf dem Bus bereitzustellen.

Interessanterweise hatte ich zur Vorstellung der OpenKNX-Zustandsautomaten sogar mal einen KNX-Aktor als Automat nachgebaut:
Beispiel zur Einführung der OpenKNX Zustandsautomaten: Virtueller Schaltaktor mit Sperre und Treppenhaus-Funktion
Daran sollte man schön erkennen können, wie viel zustandsbehaftest Verhalten schon von Haus aus in jeder aktuellen KNX-Installation steckt.

um Verriegelungen umzusetzen, muss man oft an 20 Stellen etwas "verknüpfen". Sowas ist der Tod für die Übersicht.

Schau Dir das verlinkte Beispiel an. Mit den bereits von willisurf gennannten Zustandsautomaten lassen sich solche Sachverhalte übersichtlich darstellen. Wenn DIY in Frage kommt, dann am besten mal den Thread von Anfang an lesen.

Selbst Logikmodule bieten kein RS-FlipFlop oder irgendwas, was sich zustände "merkt".

Das OpenKNX-Logikmodul bietet auch RS-FlipFlops, wobei Du die für Deinen genannten Anwendungsfall nicht zwingend benötigst: Da könntest Du auch eine UND-Vernüpfung von Aktor-Status (gelegentlich wird auch empfohlen einen ungebnutzten Aktor-Kanal als Speicher zu verwenden) und Schalt-Signal verwenden um die Sperre zu setzen. Auch TOR kann in solchen Fällen interessant sein. Würde hier aber auch als erstes mal dem Hinweis von EPIX auf die unkonventionelle Taster-Konfiguration folgen, damit hast schon eine sehr einfache und robuste Lösung.

[Chade]

Ich nenne mal ein Beispiel: Ein Taster, der je nach Zustand eines Aktors 2 Funktionen hat. Einmal normal einschalten, wenn der Aktor noch nicht aktiv ist. Und einmal den Aktor gegen andere Telegramme "verriegeln" wenn der Aktor bereits beim Tastendruck aktiv ist - als Beispiel, die EIN/AUS Telegramme vom Präsenzsensor ignoriert.

Hier zeigt sich sehr gut, dass du noch in der Denke von SPS steckst. Viele Funktionen, die du sonst aufwendig in der SPS programmierst, stecken schon von Hause aus in den Applikationsprogrammen von KNX-Geräten - ohne die Nortwendigkeit zu programmieren.

Dein Beispiel anhand eines Präsenzmelders SCN-P360D4.03 von MDT aufgegriffen:
- Der Präsenzmelder schaltet mit seinem Lichtkanal 1 (der o.g. hat derer vier!) einen Aktor.
- Ein externer Taster (irgendein KNX-Taster) schaltet den Kanal auf Handbetrieb (Aktor schaltet ein)
- Handbetrieb bleibt (je nach Gsto = je nach Parametrierung im Präsenzmelder) dauernd ein, bis er ausgeschaltet wird
oder
- Handbetrieb bleibt für Zeit x aktiv, um dann wieder in den Automatikmodus zurückzufallen
oder sogar
- kurzer Tastendruck schaltet ein aber Präsenzfunktion aktiv. Langer Tastendruck schaltet Handbetrieb.

Zusätzliches Gimmik: Kurzer Druck einer anderen Taste schaltet aus und sperrt den Präsenzmelder für n Sek., damit du den Raum verlassen kannst, ohne dass der PM das Licht wieder einschaltet.

Damit habe ich nur an der Oberfläche des Applikationsprogrammes gekratzt.

SPS: Umsetzen von Anforderungen mit den abstrakten Logikbausteinen der SPS
KNX: Umsetzen von Anforderungen anhand der Möglichkeiten der Applikation des KNX-Gerätes.

Nur in wenigen Ausnahmefällen wirst du wirklich eine externe Logik benötigen.

Und: glaube mir, nach 10 Jahren kann ein KNX-Wissender diese Einstellung leichter im ETS nachvollztiehen, statt seitenlange Dokumentationen von Logiken zu studieren.

[sleepless]

Dein Beispiel anhand eines Präsenzmelders SCN-P360D4.03 von MDT aufgegriffen:
- Der Präsenzmelder schaltet mit seinem Lichtkanal 1 (der o.g. hat derer vier!) einen Aktor.
- Ein externer Taster (irgendein KNX-Taster) schaltet den Kanal auf Handbetrieb (Aktor schaltet ein)
- Handbetrieb bleibt (je nach Gsto = je nach Parametrierung im Präsenzmelder) dauernd ein, bis er ausgeschaltet wird
oder
- Handbetrieb bleibt für Zeit x aktiv, um dann wieder in den Automatikmodus zurückzufallen
oder sogar
- kurzer Tastendruck schaltet ein aber Präsenzfunktion aktiv. Langer Tastendruck schaltet Handbetrieb.

Zusätzliches Gimmik: Kurzer Druck einer anderen Taste schaltet aus und sperrt den Präsenzmelder für n Sek., damit du den Raum verlassen kannst, ohne dass der PM das Licht wieder einschaltet.

Ich habe den Präsenzmelder von Steinel im Einsatz. Unabhängig davon fehlt eine Handbetriebsfunktion. Es ist lediglich möglich, den Präsenz-Kanal zu sperren, wodurch keine Aktionen mehr ausgeführt werden.

Der Theben-Aktor bietet eine Sperrfunktion und lässt sich im Verhalten konfigurieren. Eine direkte Handbetriebsfunktion ist jedoch nicht vorhanden. Diese könnte über einen Workaround umgesetzt werden, indem die Sperrfunktion dauerhaft ein „EIN“-Signal auslöst.

Eine zeitlich begrenzte Handfunktion ist nicht verfügbar. Zeitfunktionen existieren nur im Theben-Aktor, sind jedoch ausschließlich absolut nutzbar und nicht bedingt einsetzbar. Das führt dazu, dass der Kanal entweder dauerhaft mit Ein- oder Ausschaltverzögerung arbeitet.

Die Möglichkeiten echter Logikfunktionen werden häufig unterschätzt. Der zusätzliche Aufwand wird gesehen, der Nutzen jedoch nicht. KNX-Funktionalität ist stark abhängig von den im Gerät integrierten Funktionen. Wenn diese nicht vorhanden sind, müssen Workarounds eingesetzt werden, die nicht mehr als saubere Lösung gelten können.

Auch die Nutzung eines Jalousietasters ist nicht vollständig geeignet. Die Visualisierung auf dem Taster zeigt eine Jalousie mit Positionsanzeige, obwohl tatsächlich ein Küchengerät mit Handfunktion gesteuert wird. Das ist natürlich dem Anwender am Ende nicht klar.

Irgendwie bin ich deshalb mit dem Problem nicht wirklich weiter.

[coko]

die Nutzung eines Jalousietasters ist nicht vollständig geeignet. Die Visualisierung auf dem Taster zeigt eine Jalousie mit Positionsanzeige, obwohl tatsächlich ein Küchengerät mit Handfunktion gesteuert wird. Das ist natürlich dem Anwender am Ende nicht klar.

Wenn die Hardware schon eine grafische Anzeige der Funktion bietet, dann wird es wahrscheinlich auch andere Konfigurationsmöglichkeiten geben um zwischen kurzem und langem Druck zu unterscheiden (oder auch die grafische Anzeige anzpassen). Die Konfiguration als Jalusientaster funktioniert halt auch schon mal mit 30 jahre alten Tastern, sonst überhaupt keine weiteren Konfigurationsmöglichkeiten mitbringen...

Btw.: Du hast immer nur auf das unmittelbar letzte Posting geantwortet. Hast Du die anderen Antworten auch wahrgenommen?

[waldecker01]

SPS und KNX sind unterschiedlich. Tue mich da auch oft schwer. SPS ist meiner Meinung nach leichter zu Programmieren und zu verstehen.
Hatte viel mit Siemens Logo gemacht.
Bevor ich KNX Logikbausteine verwendet habe, sind Logo´s mit KNX Modul eingebaut worden. das war einfacher.
Leider waren dort die Ein- und Ausgänge begrenzt.
Du wirst sicher um einen Logik Baustein nicht drum herum kommen.
Nutze jetzt dazu den ABA/S 1.2.1 von ABB.
Leider nicht billig, hab mir den dann bei e---- geschossen.

[sleepless]

Wenn die Hardware schon eine grafische Anzeige der Funktion bietet, dann wird es wahrscheinlich auch andere Konfigurationsmöglichkeiten geben um zwischen kurzem und langem Druck zu unterscheiden

Ja, gibt es bei dem zweiten Taster (letour 4Zoll Smart Touch). Der lange druck ist nur bei "Value" als Art verfügbar. Sprich, er sendet z.B. ein 1bit.
Aber dort kann ich nur auswählen, welchen Zustand von beiden bei einem 1 bit gesendet werden soll. Also z.B. eine "0" wenn gedrückt wird. Es gibt also kein automatisches Umschalten. Wenn also "0" ausgewählt, dann immer eine "0". Gleiches auch für die Langdrück-Funktion.
Im Gegensatz zu dem MDT Glastaster bildet der Letour das nicht korrekt ab. Ich denke schon darüber nach, die Verriegelung einfach nur am MDT möglich zu machen. Dort funktioniert das mit dem Langdruck wenigstens wie erwartet. Am Ende ist dies aber nicht das, was möglich sein sollte, sondern wieder nur ein "Workaround".

Du hast immer nur auf das unmittelbar letzte Posting geantwortet. Hast Du die anderen Antworten auch wahrgenommen?

Ja, habe ich gesehen, 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 😉

Leider waren dort die Ein- und Ausgänge begrenzt.

Das ist mir klar. Hast du die Logo Ausgänge benutzt?
Mein Ziel war eher, das nur die Logik der Logo! genutzt wird, nicht die "Hardware". Sprich, die Logo! dient im KNX System eher für "Freigaben" auf Aktoren. Sie sollte sozusagen der "Wächter" spielen. Also quasi so:
Eingang Taster -> Telegram an Logo -> Logo wertet gemäß Programmierung aus -> Telegram an Aktor.

Ich wollte jetzt nicht mein KNX Aktor nutzlos machen und auf die Logo Ausgänge setzen. Das wäre mir wieder zu "instabil", da ich eine weitere "Schicht" in die Grundlegende Funktion bringe. Wie gesagt: Ich möchte die Stabilität von KNX in der Grundlage aufrechterhalten.

[EPIX]

... 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.
....
wie iobroker in Verbindung mit Homematic

das ist keinen SW-Lösung sondern ein HW-KNX-Gerät, das über den KNX-Bus programmiert wird...
Latenz? Nein!

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.

[willisurf]

Ja, habe ich gesehen, 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.

Nein, wie schon geschrieben sind es KNX native in der ETS abgebildete Geräte ohne single Point of failure wenn man es topologisch richtig macht.