Diskussion zu "Alltagsprobleme und deren Lösungen mit dem OpenKNX-Logikmodul"

[Sisamiwe]

Hallo,

ich habe ein Frage zum Logikmodul: Ist es möglich, das Treppenlicht was in einem Logikkanal 1 definiert ist, durch eine weiteren Logikkanal verlängern zu lassen (oder abzubrechen)?

Ich habe einen Logikkanal1 definiert, der:
- bei bei Schaltaktor aus
UND
- einem Trigger
den Schaltaktor per Treppenlicht für eine gewisse Zeit einschaltet
UND
zeitverzögert das Triggersignal an eine weiter Logik 2 weitergibt.

Nun suche ich eine Möglichkeit, das Treppenlicht zu verlängern, wenn der Trigger erneut gesendet wird. (Dabei soll der Trigger direkt, also ohne Zeitverzögerung an die Logik 2 weitergegeben werden.)

Habt ihr eine Idee?

Danke!

[mumpf]

Hi Michael,

zu folgendem kann ich spontan was sagen:

Ich habe einen Logikkanal1 definiert, der:
- bei bei Schaltaktor aus
UND
- einem Trigger
den Schaltaktor per Treppenlicht für eine gewisse Zeit einschaltet

verbunden mit

Nun suche ich eine Möglichkeit, das Treppenlicht zu verlängern, wenn der Trigger erneut gesendet wird.

heißt ja:

• Trigger soll Treppenlicht auslösen, wenn Schaltaktor AUS ist
• Trigger soll Treppenlicht auslösen, wenn Schaltaktor EIN ist

daraus folgt: Das UND ist überflüssig, für das Treppenlicht ich der Zustand vom Schaltaktor nicht relevant. Treppenlicht einfach nachtriggerbar machen (Treppenlicht kann verlängert werden) und dann sollte das klappen.

UND
zeitverzögert das Triggersignal an eine weiter Logik 2 weitergibt.

Hier fehlt mir die Info, wie Du das realisiert hast.

Gruß, Waldemar

[Sisamiwe]

Hier fehlt mir die Info, wie Du das realisiert hast.

Waldemar, danke für Deine Antwort.

Meine Anwendung: Ich habe relativ alte Garagentorantriebe mit sehr hohem Standbyverbrauch. Meine Idee ist diese nun nur bei Bedarf einzuschalten. Den Trigger für Torfahrt habe ich im KNX verfügbar. Der Torantrieb selbst ist an einem Schaltaktor. Es gibt nur einen Trigger und dieser schaltet den Antrieb auf AUF, STOP, AB, STOP.
Wir der Torantrieb mit Spannung versorgt, braucht er ca 1s bis er auf den Fahrtrigger reagiert.

Aktuell habe ich folgende 3 Logiken dafür:
1) Logik 1 (in der ETS ist das Logik 10): Tortrigger gesetzt und Torarantrieb ausgeschaltet: Ist Schaltaktor AUS UND Trigger an, dann schalte den Garagentorantrieb mit Treppenlicht ein

OpenKNX,cv1,0xA012:0x42/LOG:0x35/10
f~Name=Torfahrt%20links%20mit%20Antrieb%20aus%3A%20Netz%20an
f~Logic=1
f~Calculate=1
f~OInternalOff=0
f~Trigger=1
f~TriggerE1=1
f~NameInput1=Trigger%20links
f~E1=1
f~NameInput2=Aktorstatus%20links
f~E2=2
f~E2Default=1
f~NameOutput=Netz%20schalten%20links
f~OStairtimeBase=1
f~OStairtimeTime=1
f~OStair=1
f~OStairOff=0
f~OOutputFilter=3
;OpenKNX​

2) Logik 1 triggert Logik2 (in der ETS ist das Logik 11) (interne Verknüpfung): Diese verzögert per Einschaltverzögerung die Weitergabe des Triggers

OpenKNX,cv1,0xA012:0x42/LOG:0x35/11
f~Name=Torfahrt%20links%20mit%20Antrieb%20aus%3A%20Trigger
f~Logic=2
f~OInternalOff=0
f~I1Name=Netz%20an
f~I1=1
f~I1Function=10
f~NameOutput=Trigger%20links%20ausl%C3%B6sen
f~ODelayOnTime=12
f~ODelay=1
f~ODelayOnReset=0
f~OOff=0
f~OOffAll=0
;OpenKNX​

3) Logik3 (in der ETS ist das Logik 9): Wenn Schaltaktor AN und Trigger gesetzt, dann Fahre das Tor (diese Logik wird auch von Logik 2 ausgelöst) Der Fahrtrigger wird ohne Zeitverzögerung umsetzt

OpenKNX,cv1,0xA012:0x42/LOG:0x35/9
f~Name=Torfahrt%20links%20mit%20Antrieb%20an
f~Logic=1
f~Trigger=1
f~TriggerE1=1
f~NameInput1=Trigger%20links
f~E1=1
f~E1Default=2
f~NameInput2=Aktorstatus%20links
f~E2=1
f~E2Default=1
f~NameOutput=Torfahrt%20links
f~OStairtimeBase=3
f~OStairtimeTime=2
f~OStair=1
f~ORetrigger=0
f~OStairOff=0
f~OOutputFilter=1
;OpenKNX​

image.png

Das UND ist überflüssig, für das Treppenlicht ich der Zustand vom Schaltaktor nicht relevant. Treppenlicht einfach nachtriggerbar

Ja, dass kann ich so machen. Allerdings muss ich ja unterscheiden, ob der Schaltaktor schon mehr als 1s an ist und ggf. den Fahrtrigger verzögern, bis der Torantrieb den Trigger auch "verarbeiten kann". Oder eben, ob der Schaltaktor beim Trigger AUS war.
Dafür fehlt mir die Idee.

[mumpf]

Bin zur Zeit unterwegs und kann die Logiken nicht in die ETS importieren, aber ich glaube ich hab das Problem verstanden. Anmerkung für die Zukunft: Bitte NICHT die "menschenlesbare Form" hier verwenden. Die kann keiner lesen, auch ich nicht. Und ich muss das dann immer in das andere Format umsetzen. Bei der maschinenlesbaren Form kann ich die gleich verwenden
(coko: Wenn Du mich fragst, fliegt dieses Format aus dem ConfigTransfer raus, es macht nur zusätzliche Arbeit, weil die Leute denken, das kann irgendjemand lesen).

Sisamiwe: Um das nochmal mit meinen Worten zu formulieren:

1. Bei einem Triggersignal willst Du eine Zeit lang Deinen Torantrieb unter Strom setzen (Treppenlicht)
2. Das selbe Triggersignal soll auch das Tor fahren (was auch immer als nächstes dran ist: AUF/STOP/AB/STOP)
3. Das Problem ist, dass das erste Triggersignal erst 1 Sekunde nach dem PowerOn vom Torantrieb empfangen werden kann. Also soll nur das erste Signal verzögert werden, die weiteren nicht.

Ich sehe folgende Lösung:

1. Logik: Empfängt Triggersignal am E1 und schaltet Torantrieb über ein nachtriggerbares Treppenlicht ein (und nach einiger Zeit wieder aus).
2. Logik: Empfängt den Status des Torantriebs (Ausgang vom Kanal 1) und sendet diesen mit einer Einschaltverzögerung von 1s auf den Ausgang (keine Ausschaltverzögerung). Ein erneutes EIN verlängert nicht die Einschaltverzögerung.
3. Logik: TOR - am E1 liegt das Triggersignal an, am E2 der Ausgang von Logik 2. TOR ist so eingestellt, dass es beim öffnen den Wert von E1 sendet. Der Ausgang triggert dann den eigentlichen Torantrieb.

Was passiert (Antrieb ist stromlos):

• Das erste Triggersignal triggert Logik 1 und macht die Stromversorgung an. Ferner liegt es am Eingang vom TOR, das aber geschlossen ist.
• Das Einschalten der Stromversorgung triggert Kanal 2, der macht nach einer Sekunde das TOR auf
• Das öffnen vom TOR schaltet das Triggersignal auf den Ausgang, der Antrieb ist bereits 1s an und empfängt jetzt das Trigersignal (z.B. auf)
• Ein weiteres Triggersignal wird direkt durch das offene TOR durchgelassen und stoppt den Antrieb. Nebenbei triggert es das Treppenlicht vom Kanal 1 nach
• Irgendwann läuft das Treppenlicht ab und schaltet die Stromversorgung vom Antrieb wieder ab, dabei geht das TOR zu

Falls das nicht reicht: Morgen hab ich wieder Zugriff auf die ETS, dann kann ich Dir das auch schicken, aber eigentlich sollte das für einen erfahrenen User wie Dich ausreichend sein . Und falls ich die Aufgabenstellung falsch verstanden habe, melde Dich nochmal.

Gruß, Waldemar

[Sisamiwe]

aber eigentlich sollte das für einen erfahrenen User wie Dich ausreichend sein

Vielen Dank! Es hat gereicht. Das TOR ist noch nicht "mein Freund". Aber es wird.

• Bei einem Triggersignal willst Du eine Zeit lang Deinen Torantrieb unter Strom setzen (Treppenlicht)
• Das selbe Triggersignal soll auch das Tor fahren (was auch immer als nächstes dran ist: AUF/STOP/AB/STOP)
• Das Problem ist, dass das erste Triggersignal erst 1 Sekunde nach dem PowerOn vom Torantrieb empfangen werden kann. Also soll nur das erste Signal verzögert werden, die weiteren nicht.

Exakt, dass ist/war die Aufgabenstellung.

und die Lösung:

Logik 1:

OpenKNX,cv1,0xA012:0x42/LOG:0x35/15§f~Name=Tor%20links%20-%20Netz§f~Logic=2§f~NameInput1=Tortrigger%20links§f~E1=1§f~E1Default=2§f~NameOutput=Tor%20links%20-%20Netz%20schalten§f~OStairtimeBase=1§f~OStairtimeTime=1§f~OStair=1§f~OStairOff=0§;OpenKNX

Logik 2:

OpenKNX,cv1,0xA012:0x42/LOG:0x35/16§f~Name=Tor%20links%20-%20Trigger%20verz%C3%B6gert§f~Logic=2§f~I1Name=Tor%20links%20Netzstatus§f~I1=1§f~I1Kind=2§f~I1FunctionRel=-1§f~NameOutput=Tor%20links%20Trigger%20verz%C3%B6gern§f~ODelayOnTime=12§f~ODelay=1§f~ODelayOnReset=0§;OpenKNX

Logik 3:

OpenKNX,cv1,0xA012:0x42/LOG:0x35/17§f~Name=Tor%20links%20-%20Tor%20fahren%2Fstoppen§f~Logic=4§f~TriggerGateOpen=3§f~NameInput1=Tortrigger%20links§f~E1=1§f~E1OtherKORel=-6§f~E1DefaultExt=2§f~E1UseOtherKO=2§f~I2Name=verz%C3%B6gertes%20Triggersignal§f~I2=1§f~I2Kind=2§f~I2FunctionRel=-1§f~NameOutput=Tor%20links%20fahren%20%2F%20stoppen§f~OStairtimeBase=3§f~OStairtimeTime=2§f~OStair=1§f~ORetrigger=0§f~OStairOff=0§;OpenKNX

Das könnte auch in die Beispielsammlung.

Nochmals vielen Dank!

[mumpf]

So, hab mir nochmal Dein Beispiel in der ETS angesehen. Ich hatte es vorher so verstanden, dass Dein Trigger aus 3 möglichen Werten [AUF, ZU, STOP], also z.B. [1, 2, 3] besteht. Für eine rein binäre Lösung wäre auch statt einem TOR ein UND gegangen, TOR bietet sich vor allem an, wenn man einen beliebigen Eingangswert auf den Ausgang unter bestimmten Bedingungen weiterleiten möchte. Aber natürlich geht es auch mit Bool-Werten.

Ich werde mal heute Abend Dein Beispiel in die Sammlung aufnehmen, danke für das Feedback.

Gruß, Waldemar

[Theees]

Um mehrere Aussagen zu verbinden, musst Du logische Verknüpfungen machen, in diesem Fall wahrscheinlich ein UND. Eine Logikfunktion "verwursten" hab ich nicht https://knx-user-forum.de/core/image...EAAAICRAEAOw==.

Hallo zusammen,

ich bin, Jahreszeitenbedingt, gerade am verwursten

Meine Rolladenautomation hat im Sommer ganz gut funktioniert. Sie bestand aber auch nur aus "Fahre um 07:30 Uhr hoch" und "Fahre bei 3lx herunter".
Jetzt ist es aber um 07:30 Uhr noch dunkel, meine Rollladen fahren rauf, und direkt wieder herunter

In dem Logikkanal wo die Helligkeit abgefragt wird kann ich ja einen zweiten Kanal nicht direkt als Zeitschaltuhr definieren.
Wie ist denn hier der eleganteste Weg?
Nehme ich einfach einen weiteren Logikkanal und definiere den das er z.B. ab 07:30 Uhr "1" und um 10 Uhr zurück auf "0" wechselt?

Dann dürfte der Rollladen ja mit einer "UND" Verknüfpung nur hoch fahren wenn es zwischen 07:30 und 10 Uhr und heller als 3lx ist.

Gruß Thies

[Ing-Dom]

nimm doch einfach https://github.com/OpenKNX/OAM-ShutterController

[Theees]

Danke, ich schaue mir das später mal an!

[willisurf]

oder bau das UND ein und warte noch ein wenig. mumpf hat da etwas vor...

[mumpf]

Theees: Du kannst auch in der Zeitschaltuhr selbst schon "schlauere" Sachen sagen... z.B. "Bei Sonnenaufgang, aber nicht vor 7:30", oder "Bei Sonnenuntergang, wenn die Sonne 6° unter dem Horizont ist".
Ansonsten verknüpft man die Logikkanäle mit UND/ODER/EXOR, je nach Aussage, die man treffen möchte, ja.
Und in ca. 1-2 Wochen kommt was neues von mir .

Gruß, Waldemar

[Theees]

Hi mumpf,

ja diese Optionen in der Zeitschaltuhr hatte ich gesehen. Ich bin aber mit "Sonnenauf-" oder "Untergang" nicht glücklich. Zumindest damals in der Homematic war ich damit nicht glücklich. Denn bei schlechtem Wetter fahren die Rolläden dann evtl. passend herunter, aber bei Sonnenschein fahren sie viel zu früh herunter oder umgekehrt. Daher möchte ich das über definierte Helligkeitswerte (aus dem Sensormodul) steuern.

OK 1-2 Wochen kann ich noch warten Dann bin ich mal gespannt und schaue dann wofür ich mich entscheide.

[mumpf]

Wenn Du über Helligkeit gehen willst, wird Dir meine "Neuerung" nichts bringen. Da wird einfach nur der Shutter mit im Sensormodul integriert, und der geht auch über Sonnenstand und Zeit.

Aber... 7:30 Uhr auf bei draußen dunkel? Willst Du das wirklich? Warum dann nicht auch da Helligkeit verbunden mit Zeit? Also:
"Heller als 3 lux, aber nicht vor 7:30 Uhr"?

Aber ist natürlich Deine Sache, ich wundere mich nur.

Gruß, Waldemar

[Theees]

Nene ich meinte das schon so wie Du

[maba83]

Hi, ich hoffe ich grätsche hier nicht zu sehr dazwischen. Ich bräuchte eine Logik, die Werte auf einer GA liest und diese speichert und auch beantwortet, zyklisch sowie auf Leseanfrage. Bislang hatte ich diese über MDT SCN-LOG gelöst "Zyklisch senden/abfragen"

Ich habe es mit dem Beispiel 8 versucht, aber bekomme es nicht sauber ans laufen.

Ich habe Eingang und Ausgang aus dem Beispiel in eine GA gepackt. Wenn ich dort einen Wert mit der ETS in die GA schreibe und dann das Modul neustarte/neu programmiere, erhalte ich wie beschrieben nach ein paar Sekunden den entsprechenden Wert, den ich gesetzt habe zurück.

to bus 1/2/3 25
(Neustart)
from bus 1/2/3 25

Wenn ich aber einen Wert in die GA schreibe und dann auf der GA lese, dann bekomme ich den vorherigen Wert zurück. Und auch nach dem Neustart ist es der alte Wert (vermutlich, weil ja dann das Logikmodul selbst den alten Wert auf die GA geschrieben hat und dann mit dem weiter arbeitet)

to bus 1/2/3 26
(Leseanforderung)
from bus 1/2/3 25
(Neustart)
from bus 1/2/3 25

Ich hatte mal zyklisches Senden auf dem Aufgang eingeschaltet alle 20 Sekunden. Dort kommt dann der korrekte Wert (solang ich nicht zwischendurch einen Leserequest hatte).

to bus 1/2/3 27
(20 Sekunden)
from bus 1/2/3 27
(20 Sekunden)
from bus 1/2/3 27
(20 Sekunden)
from bus 1/2/3 27
to bus 1/2/3 28
(Leseanforderung)
from bus 1/2/3 27
(20 Sekunden)
from bus 1/2/3 27