Alltagsprobleme und deren Lösungen mit dem OpenKNX-Logikmodul

[mumpf]

Ich habe schon immer überlegt, wie man gute Beispiele für das OpenKNX-Logikmodul so aufbereiten kann, dass einerseits die vielfältigen Nutzungsmöglichkeiten aufgezeigt werden und andererseits auch nutzbare Logiken daraus werden können. Mir ist nichts gutes eingefallen, weil die Beispiele entweder sehr generisch und damit eher trivial sind oder so komplex, dass keiner sein spezielles Problem darin wiederfindet.

Aber beim Lesen von Problemen im Forum hab ich mir bestimmt schon 100 mal gesagt: "Hätte der mein Logikmodul, wäre das Problem mit einer oder ein paar Logiken erledigt". Und das sind ja genau die Sachen, die ich mit dem Logikmodul adressieren möchte: Wie bringe ich A mit B zusammen, obwohl die Hersteller dafür keine Option in der Applikation anbieten.

Deswegen dieser Thread. Ich werde hier eine Sammlung von real im Forum existierenden Problemen machen, für die ich exemplarisch eine Lösung mit den OpenKNX-Logikmodul beschreibe. Das heißt nicht, dass das reale Problem mit dem Logikmodul gelöst wurde, es soll nur die Möglichkeiten aufzeigen.

Es wird hier also eine langsam ansteigende Sammlung von Beispielen geben, die Alltagsprobleme lösen. In der Hoffnung, es bringt die Logikmodul-User auf Ideen, wie sie ihre eigenen Probleme einfach lösen können.

Die ersten 5 Beispiele sind jetzt da, ich habe jetzt bei jedem Beispiel die besonderen Features des Logikmoduls, die das Beispiel nutzt, zusätzlich aufgeführt.

Ich habe die Anregung von Teilnehmern aufgenommen und Diskussionen zu den Beispielen in den folgenden Thread ausgelagert:

Diskussionen zu "Alltagsprobleme und deren Lösung mit dem OpenKNX-Logikmodul"

Dort dürft ihr auch Fragen oder eigene Probleme reinstellen. Dieser Thread bleibt geschlossen und wird nur vom mir erweitert.

Aus gegebenen Anlass (weil das scheinbar nicht verstanden wird und Rückfragen kommen): Die Beispiele enthalten immer einen (oder mehrere) Konfigurations-Transfer-Strings. Damit könnt ihr die Beispiele direkt in unsere ETS-Applikation übernehmen und habt das Beispiel da, nur noch ein paar GA dran und man kann das ausprobieren.

Zum Konfigurations-Transfer habe ich folgende allgemeine Info schon veröffentlicht: https://knx-user-forum.de/forum/proj...ationstransfer. Auch wie man das im Logikmodul komfortabel verwenden kann: https://knx-user-forum.de/forum/proj...ng#post1968897.


Gruß, Waldemar

[mumpf]

Ab sofort gibt es hier eine Änderungshistorie, damit man überhaupt mitbekommt, was sich in diesem Thread geändert hat. Sonst müsste man ja immer alle Beispiele durchgehen...

28.11.2024 Beispiel 11: Treppenhauslicht mit Wiedereinschaltsperre
26.11.2024 Beispiel 10: Eine "IF-Bedingung" mit Zeit (zeitabhängige Logik)
13.11.2024 Im ersten Beitrag die Infos zum Konfigurations-Transfer ergänzt
10.11.2024 Beispiel 9: Ein Aktor soll seinen Status auch senden, wenn er gesperrt ist und geschaltet wird
05.10.2024 Beispiel 8: Wert bei Stromausfall speichern und nach einem Neustart auf den Bus senden
05.10.2024 Beispiele der Übersichtlichkeit wegen in einzelne Threads verschoben, so kann auch besser darauf verwiesen werden
05.10.2024 Diskussionen ausgelagert in Diskussionen zu "Alltagsprobleme und deren Lösung mit dem OpenKNX-Logikmodul"
31.08.2024 Beispiel 7: Reset eines Busteilnehmers
25.08.2024 Beispiel 6: Nachts soll das Licht immer nur gedimmt angehen
18.08.2024 Beispiel 1b: Wertfilter im Intervall 0-100
17.08.2024 Alle Beispiele ergänzt um "Interessante Features in diesem Beispiel"
17.08.2024 Initiale Erstellung des Threads, mit immerhin schon mal 5 Beispielen

[mumpf]

Frei für zukünftige Ergänzungen...

[mumpf]

Erstes Beispiel: Wertefilter

Original ist hier. Kurzfassung:

Der Steinel TPM sendet gerne auch mal 102% Luftfeuchtigkeit beim Duschen, worauf ich immer wieder angesprochen worden bin. Also habe ich das nun einmal auf 100% begrenzt.
Formel: if(e1>=100,100,e1)
Also wenn Eingang 1 größer oder gleich 100 ist, gib 100 aus, sonst das, was an Eingang 1 anliegt.

Problemlösung mit dem Logikmodul (ausführliche Antwort ist hier):
Der Eingangskonverter für einen Logikeingang bestimmt, wann der Logikkanal EIN wird. Wenn man also das Wertintervall 0-100 wählt, bekommt man ein EIN für 0-100, AUS sonst. Jetzt muss man nur noch im Ausgangskonverter für EIN den Wert von E1 senden, für AUS konstant 100.
Beispiel als Transfer-String:

OpenKNX,cv1,*/LOG:0x33/*§f~Name=Filter%20Luftfeuchte%20(nicht%20mehr%20als%20100%25)§f~Logic=2§f~NameInput1=Luftfeuchte%20vom%20TP§f~E1=1§f~E1Dpt=7§f~E1HighDpt9:1=100§f~NameOutput=Gefilterte%20Luftfeuchte§f~ODpt=7§f~OOn=2§f~OOnAll=2§f~OOffDpt9=100§;OpenKNX

Gelöst mit nur einem Logikkanal.

Interessante Features in diesem Beispiel:

• Eingangskonverter als Wertintervall
• Ausgang übernimmt den Wert vom Eingang und sendet den weiter

[mumpf]

Beispiel 1b: Wertefilter im Intervall 0-100

Dies ist eine Detailverbesserung von ersten Beispiel. Da Luftfeuche nicht negativ werden kann, wurden dort negative Werte ignoriert. Würde aber fälschlicherweise ein negativer Wert gesendet, würde für diesen auch ein 100 ausgegeben werden. Dieses Beispiel verhindert das und gibt eine 0 für negative Zahlen aus. Man hat also einen Filter, der auf ein Werteintervall filtert.

Das wird erreicht, indem man eine UND-Logik mit 2 Eingängen verwendet, der Eingangskonverter von Eingang 1 alle Werte von "kleinster möglicher Wert" bis 100 durchlässt und Eingang 2 als Eingangskonverter die Konstante 0 definiert.
Der Ausgang sendet jetzt im EIN-Fall das Maximum (E1, E2), also das Maximum von (E1, 0), im AUS-Fall immer noch eine 100.
Für Werte > 100 ist es wie bei Beispiel 1, der Eingangskonverter von E1 geht AUS, die UND-Logik sendet damit ein AUS und der Ausgang sendet die 100.
Kommt ein Wert zwischen 0 und 100, geht E1 auf EIN, die Logik auf EIN und der Ausgang sendet den Wert E1, denn der ist bei der Maximumfunktion größer als 0.
Komm ein negativer Wert, geht E1 immer noch auf EIN, die Logik auch auf EIN, der Ausgang sendet jetzt aber 0, das 0 das Maximum aus 0 und einer negativen Zahl ist.

Beispiel als Transfer-String:

OpenKNX,cv1,*/LOG:0x33/*§f~Name=Filter%20Luftfeuchte%20(nicht%20mehr%20als%20100%25)§f~Logic=1§f~NameInput1=Luftfeuchte%20vom%20TP§f~E1=1§f~E1Dpt=7§f~E1LowDpt9:1=-671088§f~E1HighDpt9:1=100§f~NameInput2=Konstante§f~E2=1§f~E2ConvertFloat=5§f~E2Dpt=7§f~NameOutput=Gefilterte%20Luftfeuchte§f~ODpt=7§f~OOn=8§f~OOnAll=8§f~OOnFunction=7§f~OOffDpt9=100§;OpenKNX

Gelöst mit nur einem Logikkanal.

Interessante Features in diesem Beispiel:

• Eingangskonverter als Wertintervall
• Eingang als Konstante für Formeln
• Ausgang berechnet sein Ergebnis über eine Formel

[mumpf]

Beispiel 2: Umwandlung von m/s auf km/h

Original ist hier. Kurzfassung:

Ich habe eine Elsner Wetterstation und möchte die Windgeschwindigkeit auf meinen Taster MDT II Smart ausgeben. Jetzt würde ich aber gerne anstatt m/s gerne km/h anzeigen lassen.

Problemlösung mit dem Logikmodul:
Man nimmt eine ODER-Logik, bei der Eingang 1 und Eingang 2 auf DPT9 gestellt werden. Der Eingangskonverter von Eingang 2 wird auf Konstante (für Formeln) gestellt und der Wert 3,6 wird vorgegeben.
Den Ausgang stellt man auch auf DPT9, für EIN sendet man das Ergebnis einer Formel und als Formel wählt man A = E1 * E2. Für AUS sendet man nichts.
Beispiel als Transfer-String:

OpenKNX,cv1,*/LOG:0x33/*§f~Name=Umrechnung%20von%20m%2Fs%20auf%20km%2Fh§f~Logic=2§f~NameInput1=Wert%20in%20m%2Fs§f~E1=1§f~E1Dpt=7§f~NameInput2=Konstante%203%2C6§f~E2=1§f~E2ConvertFloat=5§f~E2Dpt=7§f~E2LowDpt9Fix=3.6§f~NameOutput=Wert%20in%20km%2Fh§f~ODpt=7§f~OOn=8§f~OOnAll=8§f~OOnFunction=3§f~OOff=0§f~OOffAll=0§;OpenKNX

Gelöst mit nur einem Logikkanal.

Interessante Features in diesem Beispiel:

• Eingang als Konstante für Formeln
• Ausgang berechnet sein Ergebnis über eine Formel

[mumpf]

Beispiel 3: Weihnachts-Beleuchtungs-Problem

Original ist hier. Kurzfassung:

Sende eine 1 von Totensonntag (Ende November) bis zum 6.Januar.

Das Problem hier ist der Totensonntag als beweglicher Feiertag.

Problemlösung mit dem Logikmodul (Beschreibung der Lösungsidee ist hier):
Unter Allgemein "Feiertage auf dem Bus verfügbar machen" und "Nach Neuberechnung Feiertage auf den Bus senden" aktivieren und sicherstellen, dass Buß- und Bettag (Feiertag 22) und die Hl. Drei Könige (Feiertag 2) aktiviert sind.

Ein Logikkanal als Schlater (Flip-Flop). Eingang 1 und Eingang 2 sind intern mit dem KO 5 (Feiertag heute) verbunden und auf DPT5 gestellt.
Eingang 1 wird auf Einzelwerte gestellt, der Wert 22 vergeben. Eingang 2 auch Einzelwerte, hier der Wert 2.
Beim Ausgang wird die Einschaltverzögerung auf 96 Stunden gestellt.
Beispiel als Transfer-String:
Erstmal die Allgemein-Einstellungen der Logik (hier nur das Delta, alle anderen Einstellungen werden belassen):

OpenKNX,cv1,*/LOG:0x33/0§!merge§HolidayKo=1§HolidaySend=1§DreiKoenige=1§BussBettag=1§;OpenKNX

Und hier noch der Logikkanal:

OpenKNX,cv1,*/LOG:0x33/*§f~Name=Weihanchts-Beleuchtungs-Problem§f~Logic=6§f~Trigger=32§f~NameInput1=Totensonntag%20(Bu%C3%9F-%20und%20Bettag%20%2B%204)§f~E1=1§f~E1ConvertInt=4§f~E1Dpt=2§f~E1UseOtherKO=1§f~E1OtherKO:2=5§f~E1Low0Dpt5In=22§f~NameInput2=6.%20Januar§f~E2=1§f~E2ConvertInt=4§f~E2Dpt=2§f~E2UseOtherKO=1§f~E2OtherKO:2=5§f~E2Low0Dpt5In=2§f~NameOutput=Weihnachtsbeleuchtung%20schalten§f~ODelayOnBase=2§f~ODelayOnTime=96§f~ODelay=1§;OpenKNX

Gelöst mit nur einem Logikkanal.

Interessante Features in diesem Beispiel:

• Logik als Schalter (Flip-Flop)
• Eingang als Filter für Einzelwerte
• Eingang mit interner KO-Verknüpfung
• Ausgang nur mit Einschaltverzögerung, keine Ausschaltverzögerung

[mumpf]

Beispiel 4: Wert negieren

Original ist hier. Kurzfassung:

Ich hätte da auch was und zwar sendet mein Stromzähler des BKW den aktuellen Ertrag als minus Wert auf den Bus und ich muss dies dann nachgelagert korrigieren.

Ist das selbe wie Beispiel 2, nur wird nicht mit 3,6 sondern mit -1 multipliziert. Ich werde zukünftig gleichartige Beispiele nur als Verweise behandeln, ohne Transfer-String. Da es das erste Mal ist, ist das noch eine Ausnahme.

Beispiel als Transfer-String:

OpenKNX,cv1,*/LOG:0x33/*§f~Name=Wert%20negieren§f~Logic=2§f~NameInput1=Eingangswert§f~E1=1§f~E1Dpt=7§f~NameInput2=Konstante%20-1§f~E2=1§f~E2ConvertFloat=5§f~E2Dpt=7§f~E2LowDpt9Fix=-1§f~NameOutput=Ausgangswert§f~ODpt=7§f~OOn=8§f~OOnAll=8§f~OOnFunction=3§f~OOff=0§f~OOffAll=0§;OpenKNX

Gelöst mit nur einem Logikkanal.

Interessante Features in diesem Beispiel:

• Eingang als Konstante für Formeln
• Ausgang berechnet sein Ergebnis über eine Formel

[mumpf]

Beispiel 5: Einen festen (nichtbeweglichen) Feiertag beim Feiertagskalender ergänzen

Original ist hier. Kurzfassung:

könntest du ... den 1. August als Nationalfeiertag (CH) mit aufnehmen?

Problemlösung mit dem Logikmodul (ausführliche Antwort ist hier):
Man nimmt eine Zeitschaltuhr, die am 1.8. morgens einschaltet und abends ausschaltet. Der Ausgang sendet dann an KO 5 (Welcher Feiertag ist heute?) eine Zahl, die den Feiertag repräsentiert. In dem Beispiel wird 65 gesendet, da der bisher höchste Feiertag 32 ist und die Feiertage irgendwann in Zukunft auf bis zu 64 erhöht werden. Abends wird dann eine 0 gesendet. Wenn man auch noch KO 6 (Welcher Feiertag ist morgen?) versorgt haben möchte, macht man das mit einer 2. Zeitschaltuhr, die bereits einen Tag früher (also 31.7.) schaltet. Der Ausgang schreibt dann auf KO 6.

Beispiel als Transfer-String:
Erstmal der Feiertag heute:

OpenKNX,cv1,*/LOG:0x33/*§f~Name=Feiertag%20am%201.8.%20(Nationalfeiertag%20CH)§f~Logic=5§f~TimerName=Schaltet%20am%201.8.§f~Td1DuskDawn=1§f~Td2DuskDawn=1§f~TYearDay=1§f~Td1Value=1§f~Td1HourAbs=0§f~Td1MinuteAbs=0§f~Td2HourAbs=23§f~Td2MinuteAbs=59§f~Ty1Day=1§f~Ty1Month=8§f~Ty2Day=1§f~Ty2Month=8§f~NameOutput=Feiertag%20%C3%BCber%20Feiertagsobjekt%20senden§f~ODpt=2§f~OOnDpt5=65§f~OOnKOSend=1§f~OOnKOSendNumber=5§f~OOffKOSend=1§f~OOffKOSendNumber=5§;OpenKNX

Und dann noch der Feiertag morgen:

OpenKNX,cv1,*/LOG:0x33/*§f~Name=Feiertag%20morgen%20f%C3%BCr%20den%201.8.%20§f~Logic=5§f~TimerName=Schaltet%20am%2031.7.§f~Td1DuskDawn=1§f~Td2DuskDawn=1§f~TYearDay=1§f~Td1Value=1§f~Td1HourAbs=0§f~Td1MinuteAbs=0§f~Td2HourAbs=23§f~Td2MinuteAbs=59§f~Ty1Day=31§f~Ty1Month=7§f~Ty2Day=31§f~Ty2Month=7§f~NameOutput=Feiertag%20an%20Feiertag%20morgen%20senden§f~ODpt=2§f~OOnDpt5=65§f~OOnKOSend=1§f~OOnKOSendNumber=6§f~OOffKOSend=1§f~OOffKOSendNumber=6§;OpenKNX

Gelöst mit zwei Logikkanälen.

Interessante Features in diesem Beispiel:

• Eingang als Zeitschaltuhr
• Ausgang sendet nicht nur auf dem eigenen KO, sondern auch auf einem anderen KO

[mumpf]

Beispiel 6: Nachts soll das Licht immer nur gedimmt angehen

Original ist hier. Kurzfassung:

Ich ... möchte ... realisieren, dass ab einer bestimmten Uhrzeit das Licht nur gedimmt angeht.

Lösung mit dem Logikmodul:
Man nimmt einen Logikkanal als Zeitschaltuhr, der bestimmt wann Nacht ist (im Beispiel 20 Uhr bis 7 Uhr). Ein weiterer Logikkanal wird durch das Einschalten vom Licht getriggert und sendet Nachts einen Dimmwert an das Licht, hier beispielaft 20%. Das Licht wird durch den Schalter normal Ein- und Ausgeschaltet, der Dimmwert kommt so schnell hinterher, dass es Nachts nicht zu merken ist, dass das Einschalten kurzfristig 100% ausgelöst hat. Der Vorteil dieser Lösung ist, dass das Licht auch noch funktioniert, wenn die Logik nicht laufen sollte.

Beispiel als Transfer-String:
Erstmal die Zeitschaltuhr:

OpenKNX,cv1,*/LOG:0x32/*§f~Name=Ist%20Nacht%20von%2020%20-%207%20Uhr§f~Logic=5§f~Td1DuskDawn=1§f~Td2DuskDawn=1§f~TRestoreState=1§f~Td1HourAbs=7§f~Td1MinuteAbs=0§f~Td2Value=1§f~Td2HourAbs=20§f~Td2MinuteAbs=0§f~NameOutput=Ist%20Nacht§;OpenKNX

Und dann die Nachdimm-Logik:

OpenKNX,cv1,*/LOG:0x32/*§f~Name=Nachdimmen§f~Logic=1§f~Calculate=1§f~Trigger=1§f~TriggerE1=1§f~NameInput1=Licht%20schalten§f~E1=1§f~I1=1§f~I1Function=1§f~NameOutput=Licht%20nachdimmen§f~ODpt=3§f~OOnDpt5001=20§f~OOff=0§f~OOffAll=0§>Interner Eingang 3 muss mit der Kanalnummer§>der Zeitschaltuhr verbunden werden!§;OpenKNX

Gelöst mit 2 Logikkanälen.

Beim Import ist darauf zu achten, dass die Nachdimm-Logik von der Zeitschaltuhr abhängt. Beim internen Eingang 3 muss die Kanalnummer der Zeitschaltuhr nachgetragen werden.

Interessante Features in diesem Beispiel:

• Eingang als Zeitschaltuhr
• Interne Verknüpfung von Kanälen
• Logik-Trigger ist nur Eingang 1
• Ausgangs-DPT anders als Eingangs-DPT

[mumpf]

Beispiel 7: Reset eines KNX-Teilnehmers

Original ist hier. Kurzfassung:

Ich habe ein KNX-Teilnehmer ... welches sich rund alles halbe Jahr aufhängt und dann nicht mehr arbeitet.
Wenn ich diesen Teilnehmer dann ... aus der ETS raus neu Starte (Gerät zurück setzen) arbeitet das ... wieder

Hier kann man einen Logikkanal als Überwachungsfunktion parametrieren. In der Annahme, das Gerät schickt regelmäßig alle 5 Minuten eine Temperatur, kann man einen Logikkanal bauen, der durch das Telegramm ein nachtriggerbares Treppenlicht von 16 Minuten setzt. Wenn das Treppenlicht ausgeht, sind 16 Minuten ohne ein Telegramm vergangen, das Gerät hat also 3 Mal nicht gesendet. Dann wird ein "Gerät neu starten" auf den Bus geschickt.

Beispiel als Transfer-String:

OpenKNX,cv1,*/LOG:0x32/*§f~Name=Watchdog%3A%20Ger%C3%A4t%20zur%C3%BCcksetzen§f~Logic=2§f~NameInput1=Temperatur%20(zyklisch)§f~E1=1§f~E1Dpt=7§f~E1LowDpt9:1=-671088§f~NameOutput=Bei%20AUS%20Ger%C3%A4t%20zur%C3%BCcksetzen§f~OStairtimeBase=1§f~OStairtimeTime=16§f~OStair=1§f~OStairOff=0§f~OOn=0§f~OOnAll=0§f~OOff=5§f~OOffAll=5§f~OOffPAArea=15§f~OOffPALine=15§f~OOffPADevice=255§>Eingang anpassen an Telegramm-DPT§>Ausgang Treppenlichtzeit anpassen§>Ausgang PA vom Gerät anpassen§;OpenKNX

Gelöst mit einem Logikkanal.

Nach dem Import sollte man beim Eingang den DPT anpassen, falls man einen anderen DPT als DPT9 überwachen möchte, beim Ausgang die Treppenlichtzeit anpassen, falls die Wiederholintervalle vom Eingang anders sind und natürlich beim Ausgang auch die PA des Zielgerätes angeben. Derzeit steht da 15.15.255, damit nicht versehentlich irgendein Gerät zurückgesetzt wird.

Interessante Features in diesem Beispiel:

• Ausgang mit Treppenlicht
• Ausgang mit "Gerät zurücksetzen"-Funktion

[mumpf]

Beispiel 8: Wert bei Stromausfall speichern und nach Neustart wieder auf den Bus senden

Das Logikmodul kann für alle Eingangs-DPT, die es kennt, die Werte auch bei Stromausfall speichern. Mit einem einfachen Pattern kann man folgendes erreichen:

1. Wert wird bei Busspannungsausfall (also auch Neuprogrammierung) DPT-Gerecht gespeichert
2. Nach einen Neustart steht der Wert sofort für Lesetelegramme zur Verfügung
3. Nach einer frei wählbaren Verzögerung kann der Wert auch aktiv auf den Bus gesendet werden

Beispiel als Transfer-String:

OpenKNX,cv1,0xA011:0x79/LOG:0x34/3§f~Name=Wert%20speichern§f~ChannelDelayTime=5§f~Logic=2§f~Trigger=0§f~NameInput1=Jahresphase§f~E1=1§f~E1Dpt=2§f~E1Default=2§f~E1DefaultEEPROM=1§f~E1LowDpt5:1=0§f~NameOutput=Jahresphase%20Status§f~OOutputFilter=3§f~ODpt=2§f~OOn=2§f~OOnAll=2§f~OOff=0§f~OOffAll=0§;OpenKNX

Das Beispiel zeigt, wie ich die Jahresphasen (Frühling, Sommer, Herbst, Winter, Weihnachten), die das Haus annehmen kann, im Logikmodul speichere.
Der Eingang speichert den Eingangswert beim Busspannungsausfall und sendet diesen über seinen Ausgang. Das ist erstmal nichts besonderes. Der Trick ist, dass die Einschaltverzögerung des Logikkanals dazu genutzt wird, den Wert später auf den Bus zu senden. Das Leseflag wird am Ausgang des Logikkanals gelöscht und am Eingang gesetzt. Dadurch werden Lesetelegramme schon beantwortet, sobald der Eingangswert aus dem Speicher geladen wurde (passiert noch zur Bootzeit, also innerhalb der 1. Sekunde vom Neustart). Außerdem muss die GA vom Ausgang als erste (sendende) GA mit dem Eingang verknüpft werden, damit die Leseanfragen auf dieser GA beantwortet werden können. Die schaltende GA ist somit die 2. GA (hörend). So muss die KO-Liste des Logikkanals aussehen:

KO-GA-Jahresphasen.png
Variationen sind natürlich möglich, mann kann z.B. nur mit einer GA arbeiten, ganz ohne Verzögerung usw. Dieses Pattern ist für den Anlagenstart (wenn alle Geräte neu starten) insofern günstig, als das man bestimmen kann, wann der Status (also der gespeicherte Wert) gesendet wird, um die Telegrammlast beim Analgen-Neustart zu minimieren. Gleichzeitig werden Leseanfragen beantwortet, falls ein anderes Gerät den Status schon früher braucht.

Gelöst mit nur einem Logikkanal.

Interessante Features in diesem Beispiel:

• Eingang mit Speicherfunktion
• Ausgang sendet Wert vom Eingang
• Startverzögerung des Logikkanals
• Änderung von Flags, um das Lesetelegramm vom Eingang beantworten zu lassen

[mumpf]

Beispiel 9: Ein Aktor soll seinen Status auch senden, wenn er gesperrt ist und geschaltet wird

Original ist hier. Kurzfassung:

Die .org oder die Hersteller könnten das schon mit aufnehmen, wenn Ausgang gesperrt und auf dem Schaltbefehl kommt ein Telegramm -> sendet der Status seinen Zustand raus!

Grundidee ist ein Schalter (RS-Flipflop), die Eingänge sind beide als Trigger ausgelegt, das EIN kommt vom Schaltbefehl, das AUS vom Status des Aktors. Beim Ausgang gibt es dann noch eine Einschaltverzögerung von 3/10s, die bei einem vorherigen AUS nicht sendet. Und bei EIN wird ein ReadRequest auf die Status-GA gesendet.

Beispiel als Transfer-String:

OpenKNX,cv1,*/LOG:0x33/*§f~Name=Status%20nachlesen%2C%20falls%20nicht%20gesendet§f~Logic=6§f~Trigger=0§f~NameInput1=Schaltsignal%20des%20Aktors§f~E1=1§f~E1ConvertBool=7§f~NameInput2=Statuswert%20des%20Aktors§f~E2=1§f~E2ConvertBool=7§f~NameOutput=Status%20nachlesen§f~ODelayOnTime=3§f~ODelay=1§f~OOn=4§f~OOnAll=4§f~OOff=0§f~OOffAll=0§;OpenKNX

Die GA-Zuordnung ist wie im Bild unten. Der Status muss an Eingang 2 und an den Ausgang gehen. Zusätzlich sollte beim Ausgang der Logik das L-Flag gelöscht werden.
Forum-Beispiel-9-KO.png

Was passiert: Sobald ein Schalttelegramm kommt (Trigger, egal ob EIN oder AUS), wird das RS-Flipflop eingeschaltet und und die Einschaltverzögerung läuft los. Wenn der Aktor sofort antwortet, schaltet das das RS-Flipflop AUS (egal welches Telegramm, da Trigger). Es passiert nichts.
Wenn kein Telegramm vom Status kommt, wird das RS-Flipflop nicht ausgeschaltet, es sendet nach 3/10s einen ReadRequest, der Aktor antwortet und schaltet das RS-Flipflop auch wieder aus.

Im Gruppenmonitor sieht das dann so aus:
Forum-Beispiel-9-Monitor.png
Die Zeilen 30/31 und 80/81 zeigen das normale Schaltverhalten (Aktor ist hier der Aktor vom Fingerprint, deswegen antwortet immer das selbe Gerät). In Zeile 96 wird die Sperre eingeschaltet. Danach (ab 115) führt jeder Schaltvorgang zu einem GroupValue_Read und der Antwort des Aktors.

Gelöst mit nur einem Logikkanal.

Interessante Features in diesem Beispiel:

• Logik als Schalter
• Eingang als Trigger
• Einschaltverzögerung, aber keine Ausschaltverzögerung
• Statt einem Wert wird ein GroupValue_Read gesendet

[mumpf]

Beispiel 10: Eine "IF-Bedingung" mit Zeit (zeitabhängige Logik)

Diesmal kommt das Beispiel nicht aus dem Forum, sondern aus einem Telefonat, bei dem es um das Logikmodul ging. Da wurde mir "vorgeworfen", dass das Logikmodul sehr eingeschränkt ist, weil man in keiner Logik und auch nicht in den Benutzerformeln eine Bedingung in Abhängigkeit von Tageszeit formulieren kann, aber viele Schaltungen doch genau davon abhängen. Und als ich antwortete, dass das doch schon lange geht, es gibt ja Zeitschaltuhren, war die Antwort: "Ich will ja nicht was per Zeitschaltuhr schalten, ich will z.B. von 22 Uhr bis 7 Uhr meine Klingel stummschalten, also ein

IF "Klingeln" AND Zeit>7 Uhr AND Zeit<22 Uhr THEN "Klingeln"

So was kann man ja nicht formulieren. War seine Meinung. Und weil ich befürchte, dass auch andere Leute dieser Meinung sein könnten, hier also das Beispiel, wie man das Klingelsignal nur von 7 Uhr bis 22 Uhr durchlässt.

Grundidee: Mit einem UND gibt man das Klingelsignal zwischen 7 Uhr und 22 Uhr frei. Der eine UND-Eingang wird von dem Klingelsignal bedient, der zweite UND-Eingang von einer Zeitschaltuhr, die um 7 Uhr einschaltet und um 22 Uhr ausschaltet.

Beispiel als Transfer-Strings:
Erstmal der UND-Kanal:

OpenKNX,cv1,*/LOG:0x32/1§f~Name=Klingeslignal%20freigeben§f~Logic=1§f~Calculate=1§f~NameInput1=Klingelsignal§f~E1=1§f~I1Name=Freigabe%20%C3%BCber%20Zeitschaltuhr§f~I1=1§f~I1Function=2§f~NameOutput=Klingel§;OpenKNX

Und dann noch die Zeitschaltuhr:

OpenKNX,cv1,*/LOG:0x32/2§f~Name=Freigabezeit§f~Logic=5§f~TimerName=Freigabezeit%20der%20Klingel§f~Td1DuskDawn=1§f~Td2DuskDawn=1§f~TRestoreState=1§f~Td1Value=1§f~Td1HourAbs=7§f~Td1MinuteAbs=0§f~Td2HourAbs=22§f~Td2MinuteAbs=0§f~NameOutput=Nur%20intern%20genutzt§f~OOn=0§f~OOnAll=0§f~OOff=0§f~OOffAll=0§;OpenKNX

Was passiert: Die Zeitschaltuhr schaltet um 7 Uhr auf logisch EIN und um 22 Uhr auf AUS. Das EIN liegt am zweiten Eingang vom UND an. Wenn jemand klingelt, geht dieses Signal an den ersten Eingang vom UND. Nur wenn beide EIN sind, kann der Ausgang auf EIN gehen und die Klingel klingeln. Somit liegt ab 22 Uhr am zweiten Eingang ein AUS an und die Klingel wird nicht klingeln, bis es am nächsten Morgen wieder EIN wird.

Gelöst mit zwei Logikkanälen.

Interessante Features in diesem Beispiel:

• Verbindung von Zeitschaltuhr und Logik
• Interne Verknüpfung von 2 Logkikanälen
• Das ist ein Beispiel für zeitabhängige Logiken

[mumpf]

Beispiel 11: Treppenhauslicht mit Wiedereinschaltsperre

Original ist hier. Kurzfassung:

• Schalten der Magnetventile für 5 Minuten bei Betreten eines Raumes
• Wiedereinschaltsperre für das jeweilige Magnetventil für 30 Minuten

Realisierung mit 2 hintereinandergeschalteten Treppenlichtern. Grundidee ist ein Schalter (RS-Flipflop) mit Treppenlicht von 30 Minuten, der Setz-Eingang bekommt das Schaltsignal. Der Rücksetzeingang wird vom Treppenlicht ausgeschaltet. Damit wird der Ausgang dieses Logikkanals immer für 30 Minuten EIN, egal was danach mit dem Schaltsignal passiert. Der Ausgang geht an eine 2. Logik, die ein einfaches Treppenlicht von 5 Minuten realisiert. Damit wird die 2. Logik mit der ersten eingeschaltet, schaltet dann schon nach 5 Minuten aus. Da die Logik vorher 30 Minuten lang an bleibt, kann in dieser Zeit nicht erneut eingeschaltet werden.

Beispiel als Transfer-Strings:
Erstmal der Schalter-Kanal:

OpenKNX,cv1,*/LOG:0x34/5§f~Name=Einschaltsperre%20§f~Logic=6§f~Trigger=0§ f~NameInput1=Einschaltsignal%20(wird%20gesperrt)§f ~E1=1§f~NameInput2=Einschaltsperre%20vorzeitig%20a ufheben§f~E2=1§f~I2Name=R%C3%BCcksetzen%20bei%20AU S%20(Selbstverkn%C3%BCpfung)§f~I2=2§f~I2Function=5 §f~NameOutput=Internes%20Schaltsignal%20(Sperrzeit )§f~OStairtimeBase=1§f~OStair=1§f~ORetrigger=0§f~O On=0§f~OOnAll=0§f~OOff=0§f~OOffAll=0§;OpenKNX

Dann das 2. Treppenlicht:

OpenKNX,cv1,*/LOG:0x34/6§f~Name=Einschaltsperre%20Teil%202§f~Logic=2§f~Trigger=0§f~I1Name=Internes%20Schaltsignal§f~I1=1§f~I1Function=5§f~NameOutput=Ausgang%20Einschalsperre§f~OStairtimeBase=1§f~OStairtimeTime=5§f~OStair=1§f~OStairOff=0§f~OSendOnChange=1§;OpenKNX​

Das obige Beispiel hat noch den Rücksetz-Eingang vom Schalter rausgeführt, darüber kann man die Einschaltsperre auch vorzeitig zurücksetzen.

Was passiert: Der Schalter bekommt ein Schaltsignal EIN, schaltet damit das Treppenlicht vom Ausgang auf EIN für 30 Minuten. Das Treppenlicht ist nicht verlängerbar, aber ausschaltbar, falls man die Einschaltsperre vorzeitig beenden möchte (über ein EIN auf Eingang 2). Das EIN am Ausgang schaltet das Treppenlicht des 2 Logikkanals, das seinerseits den Ausgang auf EIN schaltet.
Nach 5 Minuten schaltet der 2. Logikkanal auf AUS, weil das Treppenlicht abgelaufen ist.
Jegliches Schaltsignal am Eingang war bis hierhin und auch weiterhin wirkungslos, die Wiedereinschaltsperre funktioniert.
Nach weiteren 25 Minuten (also insgesamt nach 30 Minuten) schaltet das erste Treppenlicht AUS und setzt damit den Schalter zurück.
Erst jetzt kann ein erneutes EIN am Schaltsignal erneut einschalten.

Gelöst mit 2 Logikkanälen.

Interessante Features in diesem Beispiel:

• Logik als Schalter (RS-Flipflop)
• Schalter, der sich selbst über Treppenlicht zurücksetzt (Monoflop)
• Interne Kanalverknüpfungen