PM-Logik mit Abschaltverzögerung

[Alloc]

Hi,

hier mal eine PM/Logik-Kniffelei, insbesondere an die drei, mit denen ich am Mittwoch auf dem Stammtisch schonmal drüber gesprochen hatte ( mumpf , Amenophis , bambam ), aber freue mich natürlich auch über jeden andren Input

OpenKNX-Konfig-Strings am Ende, falls jemand das selbst probieren möchte


Ausgangssituation / Zieldefinition:
Ich habe einen VPM-Kanal und möchte hier eine zweistufige Abschaltung umsetzen, sprich der Dimmer ist z.B. 50% im aktiven Zustand, geht nach Nachlaufzeit erst auf 5% und dann nach 10 Sekunden erst auf 0%. Außerdem soll externes Steuern des Aktors, zum Beispiel über Szenen oder direktes Dimmen aus der Visu, weiterhin möglich sein.


Bisherige Umsetzung:
VPM-Kanal sendet als "Aus"-Wert auf dem Dimmausgang den Zwischenwert (5% im Beispiel), auf dem zweiten Ausgang (Schalten) ein "Aus".
Dazu dann ein Logikkanal, nur ein Eingang, verknüpft mit dem Schaltausgangs-KO des PM. Der Ausgang geht wiederum auf das Dimmausgangs-KO des PM. Dies Logik ist im Ausgang dann so konfiguriert, dass sie nur Werte für "Aus" durchlässt, dabei eine Ausschaltverzögerung von 10 Sekunden hat und eben dann die 0% als Wert setzt.

Ergebnis bis dahin:
Erstmal klappt das wie erwartet. Licht über PM an geht normal, Licht vom PM aus und es wird korrekt erst der geringere Dimmwert gesendet und danach dann von der Logik die 0%.
Problem:Wechselt die Tagesphase des PM oder wird das KO "Automatik Übersteuern" mit "Aus" beschrieben, sendet der PM auch seinen "Aus"-Dimmwert, selbst wenn der PM-Kanal zu der Zeit bereits aus war. Sprich, wechselt man z.B. von der Tages- auf die Nachtphase schaltet der PM nun das Licht auf dem Ausschaltwert für die Nachtphase ein (dann immerhin "nur" 1%) und dann eben über die Logik nach 10 Sekunden erst wieder aus.


Naheliegender Vorschlag vom Mittwoch:
Den Dimmausgang des PM über eine Tor-Logik führen, die über den Schaltausgang des PM gesteuert wird. Dann würde der Aus-Wert des PM nur noch gesendet, wenn er vorher auch eingeschaltet hatte. Außerdem muss das Tor bei Freigabe den letzten Wert des Eingangs senden, damit beim Einschalten nicht zuerst der Dimmwert kommt, dann die Torfreigabe und somit der Aktor den Dimmwert nicht erhält.
Problem:
Wenn man den Aktor am PM vorbei steuert (Szenen, Dimmen über Visu), würde der PM-Kanal zwar in seine Nachlaufzeit gehen um später theoretisch abzuschalten. Er würde aber nie das Tor freigeben, da der Schaltausgang des PM logischerweise dann auch kein "Ein" sendet.

Logische Konsequenz:
Grundsätzlich dieses Vorgehen mit dem Tor beibehalten, aber als Steuereingang nicht nur den Schaltausgang des PM nehmen, sondern vorher zusätzlich mit dem Aktorstatus ODER-verknüpfen.
Erstmal funktioniert das auch immer noch, automatisches Licht geht einwandfrei.
Problem:
Wenn man nun den Aktor am PM vorbei einschaltet, sendet dieser Aktorstatus=Ein, gibt damit das Tor frei und das Tor sendet folglich den letzten Wert seines Eingangs. Das ist dann aber immer 5%, weil der PM ja immer mit 5% abschaltet und das somit immer der letzte Wert des Tor-Eingangs ist.
Somit kann ich nun nicht mehr direkt den Aktor von 0% auf einen beliebigen Wert dimmen, da dies immer erstmal von der Tor-Logik überschrieben wird.


Und an dem Punkt hänge ich dann etwas.
Das einzige was ich gerade noch als Gedanken hatte:
Den Dimmausgang des PM minimal verzögern, bevor er an den Tor-Eingang geht. Somit kann ich garantieren, dass beim aktivieren des Ausgangs des PM immer erst der Schaltausgang an dem Steuereingang des Tores ankommt und somit der Dimmwert dann auch immer korrekt durchkommt. Dann bräuchte ich das Tor nicht so zu konfigurieren, dass es den letzten Eingangswert sendet, wenn das Tor freigegeben wird. Nachteil (neben der vierten Logik für einen einzelnen Dimmkanal ): Das Einschalten des Lichts wird damit pauschal um 0,1 Sekunde (minimale Einstellung in der Logik) verzögert. Das wäre daher für mich eher eine Notlösung als die elegante Variante.

Habt ihr da noch Ideen?

LG,
Chris


Konfig-Strings:
PM-Kanal:

OpenKNX,cv1,0xA012:0x42/PM:0x36/3§p~Name=Hauptlicht§p~PresenceInputs=4§p~PhaseCount=2§p~Output1Type=4§p~Output2Type=1§p~ChannelActive=1§p~BrightnessIntern=1§p~MoveKeepAlive=1§p~Phase3Name=Putzen§p~Phase1Scene=20§p~Phase2Scene=21§p~Phase3Scene=1§p~Scene0=2§p~SceneAction0=16§p~IntPresence2=1§p~NumPresence2:2=133§p~EnableDayPhase=1§p~SignalPresence=1§p~ExternalSignalPresence=1§pA~PresenceDelayBase=0§pA~PresenceDelayTime=90§pA~BrightnessOn=35§pA~Output1OnDim=50§pA~Output1OffDim=5§pB~PresenceDelayBase=0§pB~PresenceDelayTime=60§pB~BrightnessOn=10§pB~Output1OnDim=6§pB~Output1OffDim=1§pC~PresenceDelayTime=3§pC~BrightnessOn=5000§;OpenKNX

Logik-Kanal Ausschaltverzögerung:

OpenKNX,cv1,0xA012:0x42/LOG:0x35/3§f~Name=Ausschaltverz%C3%B6gerung%20Hauptlicht§f~Logic=2§f~E1=1§f~E1OtherKO:2=174§f~E1DefaultExt=2§f~E1UseOtherKO=1§f~NameOutput=(Intern%3A%20Ausschaltverz%C3%B6gerung)§f~ODelayOffBase=0§f~ODelayOffTime=10§f~ODelay=1§f~ODpt=3§f~OOn=0§f~OOnAll=0§f~OOffKOSend=1§f~OOffKOSendNumber=949§;OpenKNX

OR-Logik PM-Status/Aktorstatus:

OpenKNX,cv1,0xA012:0x42/LOG:0x35/9§f~Name=HL%20Schalt%2FAktorstatus§f~Logic=2§f~NameInput1=Aktorstatus§f~E1=1§f~E1OtherKO:2=165§f~E1UseOtherKO=1§f~NameInput2=PM-Status§f~E2=1§f~E2OtherKO:2=174§f~E2UseOtherKO=1§f~NameOutput=(Intern%3A%20HL%20Schalt%2FAktorstatus)§f~ODelayOffTime=1§f~ODelay=1§f~OSendOnChange=1§;OpenKNX

Tor-Logik Dimmausgang:

OpenKNX,cv1,0xA012:0x42/LOG:0x35/10§f~Name=HL%20Ausgangstor§f~Logic=4§f~TriggerGateOpen=3§f~NameInput1=PM-Dimmwert§f~E1=1§f~E1Dpt=3§f~E1OtherKO:2=173§f~E1UseOtherKO=1§f~NameInput2=Tor-Eingang§f~E2=1§f~E2OtherKORel=-2§f~E2UseOtherKO=2§f~NameOutput=HL%20Dimmwert§f~ODpt=3§f~OOn=2§f~OOnAll=2§f~OOff=2§f~OOffAll=2§;OpenKNX

[gbglace]

Diese Abstufung Aus-Signal = 5% und 10s später 0% gilt nur für eine bestimmte Tagesphase?
Und es gilt das der PM das Licht so ausschaltet, egal warum und wie eingeschalten wurde und wer zuletzt den Dimmwert wohin bewegt hat?

Für mich wäre das gedanklich eine Logik, die ein UND aus negiertem Befehl PM sagt AUS + true Status Tagesphase x/y als Eingang kennt und nur bei true der Logik diese Sequenz 5% gefolgt von 0% nach 10s ausgibt.

Spannend bleiben Änderungen im PM Zustand und manueller Beeinflussungen innerhalb dieser 10s, da muss diese Sequenz ohne Ausgang abgebrochen werden. Hierzu könnte dann der Status des PM-Kanals herangezogen werden, denn für den PM war mit dem Senden seines AUS ja schon AUS. Sprich kommt da ein Status EIN, dann wäre das ein Abbruch dieser 10s Wartezeit ohne ein Senden eines weiteren Befehls.

[Alloc]

Nein, die Abstufung gibt es bei allen Phasen, nur natürlich dann mit andren Werten. Da die Logik aber nur den finalen Aus-Wert von 0% sendet ist diese glücklicherweise unabhängig von den Phasen und nur im VPM-Kanal müssen die Sachen konfiguriert werden
Und ja, wann immer der PM sich um das ausschalten kümmert (also Abschalten durch Nachlaufzeit) macht er das dann so. Nur wenn man am PM vorbei abschaltet geht das dann natürlich direkt.

Auch das mit PM sendet 5% und vor Ablauf der 10 Sekunden sendet er wieder Ein, weil wieder Präsenz erkannt wird, funktioniert. Die Logik für die 0% kann man ja hier so einstellen, dass sie bei Empfang eines neuen Wertes einfach die bisherige Verzögerung abbricht.


Das klappt wie gesagt bis dahin auch alles wunderbar. Nur eben mit den Problemen die ich oben beschrieben habe, primär: Der PM sendet beim Phasenwechsel eben die 5% für Aus, und das Licht geht daher beim Wechsel immer an.

Und da wirds dann halt wie beschrieben aufwendiger und leider mit meinem aktuellen Workaround auch nur lösbar mit einer zusätzlichen Einschaltverzögerung (immerhin nur 0,1 Sekunden, aber schöner wäre halt ohne ).

[mumpf]

Hi Chris,

hab zwar (noch) keine Lösung für Dich, aber eine Anregung: Falls Logiken zu komplex werden, kann es auch helfen, ein Teilproblem (oder das gesamte Problem) über einen Zustandsautomaten zu lösen.

Gruß, Waldemar

P.S.: Ich schau mir das nochmal an, bin derzeit nur komplett vom Sensormodul in Beschlag genommen...

[coko]

Ich bin mir nicht sicher ob ich alle Anforderungen vollständig erfasst habe, habe aber bisher das Gefühl dass man das Problem womöglich auf auf Basis der Zustandsautomaten lösen könnte. (Wenn auch bislang nicht in einem Gerät.)

Wenn ich das richtig verstehe, dann hast Du die 9 (oder ggf. auch nur 8 wg Aus-Zuständen für Putzen) automatischen Beleuchtungszustände:

	EIN	Vor-Aus (für 10s)	AUS
Phase 1: Tag	50%	5%	0%
Phase 2: Nacht	6%	1%	0%
Phase 3: Putzen	100%	0%	0%

Zzgl. ggf. noch einem Zustand der durch manuelle Bedienung Helligkeitssteuerung erreicht wird.

Idee: Diese Beleuchtungszustände durch einen Zustandsautomaten abbilden.
Zunächst hatte ich darüber nachgedacht die Zustände EIN und Vor-Aus über Einen Ausgang vom Type Szene direkt aufzurufen. Das würde aber wohl auch wieder zu den unerwünschten Effekten beim Umschalten führen. Daher als zweite Idee jeweils zustandsspezifische Schaltsignale zu erzeugen (mit 3 LOG-Kanälen individuelle Ausgangswerte für jede Tagesphase erzeugt):

z		A Ph1=1	B Ph1=0	C Ph2=1	D Ph2=0	E Ph3=1	F Ph3=0	G St=1	H St=0	Timeout	T	O1	O2	O3	O4
1	undefiniert	3	4 (?)	7	8 (?)	11	12	-	-			-
2
3	Ph1 Tag: EIN	-	4	7	8	11	12	-	1			50%
4	Ph1 Tag: vor-Aus	3	-	7	8	11	12	-	1	10s	5	5%
5	Ph1 Tag: AUS	3	-	7	9	11	12	1	-			0%
6
7	Ph2 Nacht: EIN	3	4	-	8	11	12	-	1			6%
8	Ph2 Nacht: vor-Aus	3	4	7	-	11	12	-	1	10s	9	1%
9	Ph2 Nacht: AUS	3	5	7	-	11	12	1	-			0%
10
11	Ph2 Putzen: EIN	3	4	7	8	-	12	-	1			100%
12	Ph2 Putzen: AUS	3	5	7	9	11	-	1	-			0%
13
14
15
16

Insbesondere der Wechsel zwischen den (Vor-)Aus-Zuständen lässt sich damit sehr differenziert abbilden im ahängigkeit vom aktuellen Zustand (das ist genau die stelle die mit diremtem Zustandsaufruf nicht möglich ist).

Zur Reaktion auf manuelle Steuerung braucht es noch etwas mehr, insbesondere falls diese in einem der beiden Vor-Aus-Übergangszuständen erfolgt, die dann verlassen werden müssen. Ggf. reicht es hier schon bei Erkennung der manuellen Bedienung auf den undefinierten Zustand zurückzuwechseln, der sendet keine Soll-Helligkeit. In wie weit können unabhängige Änderungen erfolgen? (Beispiel zur Reaktion auf abweichenden Aktor-Status siehe G und H)

Geht das in die Richtung die Dir vorschwebt, oder fehlt da noch was Entscheidendes?

[Alloc]

Danke Waldemar, mach dir keinen Stress deswegen. Ist ja hier nur zur öffentlichen Diskussion

Danke auch Cornelius, das sieht interessant aus. Brauch aber nen paar ruhige Minuten mir das genau anzuschauen. Bin die Woche leider auch etwas im Stress, da wir Freitag nen großen Release haben. Werde also vermutlich erst nächste Woche dazu kommen.

[Alloc]

Danke nochmal, Cornelius. Das sieht schon sehr passend aus. Wollte es aber nun mal in der Praxis ausprobieren, stoße dabei aber auf ein "Problem": Wie generiere ich die Signale P1 bis P3 für die Statemachine? Ich brauche ja 3 (oder wahlweise 6) getrennte KO, für jede Phase eines, dass dann vom PM die Ein/Ausschaltsignale bekommt. Der PM wiederum hat nur ein Ausgabe-KO für alle drei Phasen zusammen und keinen Ausgang für die aktuelle Tagesphase ( mumpf Wäre eventuell eine Anregung für später? ). Also dachte ich ich nehme einmal DPT 5 als PM-Ausgang, lasse ihn dann je nach Phase 1/2, 3/4, oder 5/6 jeweils für Ein/Aus senden. Dann müsste ich aber diese Werte in entsprechende DPT 1 auf drei verschiedenen KO wandeln.

Erster Gedanke: Einfach ein Tor pro Ziel-KO: Tor-Steuereingang und Daten-Eingang direkt an PM-Ausgang. Beispiel für P2, Steuereingang als Wertintervall (True = 3-4), Dateneingang nur True = 1. D.h. kommt eine 1 wird freigegeben und der Ausgang = 1, kommt eine 2 wird freigegeben und der Ausgang = 0, kommt irgendwas andres wird das Tor gesperrt und somit nichts am Ausgang gesetzt.
Nur: Wenn das Tor vorher gesperrt war, wird nicht gleichzeitig freigegeben und gesendet, sondern wohl erst der Eingangswert gesetzt, *dann* das Tor freigegeben, und somit der erste Wert eben nicht mehr zum Ausgang geleitet.
UND-Logik würde wieder nicht funktionieren, da ich ja zwei unterschiedliche Ausgangswerte brauche, aber auch ermöglichen muss, dass bei bestimmten Eingangswerten (diejenigen, für die der jeweilige Logikkanal nicht zuständig ist) gar nichts am Ausgang passiert.


/EDIT: Dachte auch übers verwenden der Optionen "Senden bei Freigabe" beim Tor nach, aber dann hätte man potenziell wieder das Problem, dass auf dem Dateneingang ja theoretisch auch genauso gut noch der alte Wert liegen könnte - zumindest aus Nutzersicht ist ja nicht klar definiert, in welcher Reihenfolge das verarbeitet wird, wenn mehrere Eingänge das gleiche KNX-Telegramm verarbeiten sollen (oder sogar die Eingänge alle auf das gleiche KO gemappt sind).

/EDIT2: Scheint aber prinzipiell so zu gehen - also "Beim öffnen des Tores"="Eingangswert senden". Frage mich nur, wenn es das bei der Freigabe braucht - sprich scheinbar der Eingangswert erst gesetzt wird, dann das Tor freigegeben - warum erhalte ich dann nicht bei einem anderen Wert noch vom alten Tor ein Telegramm?
Also wenn Logik/Tor 1 freigegeben wird mit z.B. 2, dann setzt er den Ausgang "Aus". Danach wird mit z.B. 3 eigentlich das Tor gesperrt, aber *vorher* müsste doch noch Logik 1 eben den Eingangswert 3 annehmen, der Eingangskonverter müsste sagen "das ist nicht 1, also betrachte ich die 3 als False" und der Ausgangskonverter dann eben den Wert für False -> 0 senden.
Also ich hätte erwartet entweder immer Verarbeitung Eingangswert vor Tor-Zustand (danach sah es ja aus, weil er vorher nichts gesendet hatte, wenn man das Tor nicht vorab freigegeben hatte), dann müsste er noch vor dem Schließen des Tores für den neuen Eingangswert ein Telegramm am Ausgang erzeugen, oder immer Verarbeitung Tor-Zustand vor Eingangswert, dann hätte er aber ja auch schon beim Öffnen des Tores direkt für den neuen Eingangswert ein Telegramm absetzen müssen ... Das verwirrt mich daher

[willisurf]

Ich habe nicht alles genau nachvollzogen, aber falls Du Eingangssignale benötigst, die im einen Zustandswechsel auslösen sollen, aber statisch bereits vor dem Statewechsel aktualisiert worden sind, kannst Du das mit einem Logikkanal lösen, der das (statische) Eingangssignal mit dem/den relevanten States verknüpft und dadurch bei Eintritt in den State das Signal nochmal dynamisch sendet.

[coko]

Wie generiere ich die Signale P1 bis P3 für die Statemachine? Ich brauche ja 3 (oder wahlweise 6) getrennte KO, für jede Phase eines, dass dann vom PM die Ein/Ausschaltsignale bekommt. Der PM wiederum hat nur ein Ausgabe-KO für alle drei Phasen zusammen und keinen Ausgang für die aktuelle Tagesphase [...] Also dachte ich ich nehme einmal DPT 5 als PM-Ausgang, lasse ihn dann je nach Phase 1/2, 3/4, oder 5/6 jeweils für Ein/Aus senden. Dann müsste ich aber diese Werte in entsprechende DPT 1 auf drei verschiedenen KO wandeln.

Nur mal kurz als Lösungsidee (ungetestet und freihand ohne ETS), soweit ich das noch in Erinnerung habe:

• DPT5 Ausgang passt, die Ausgangswerte 1/2, 3/4, oder 5/6 für die Paare auch
  • Wichtig für unten: im niedrigsten Bit haben die Werte 1 für EIN und 0 für AUS
• Ausgangspaare Verwenden. Für jdes Ausgangspaar einen Logikkanal
  • Ph1
  • Ph2
  • Ph3
• Die jeweiligen Logikkanäle wie folgt konfigurieren:
  • als UND
  • Den PM-Ausgang als Eingang verwenden
  • Eingangswert EIN für jeweils genau das der zugehörigen Phase Wertepaar ermitteln (also z.B. 1/2 für Ph1; Wichtig: Die müssen natürlich disjunkt konfiguriert sein)
  • Ausgang als DPT1
    • Senden bei EIN:
      • E1 & 1
        • E2 dafür auf konstant 1 setzen
    • KEIN senden bei AUS

PM-Ausgang	Ph1/E1	Ph2/E1	Ph1/E1	Ph1/A	Ph2/A	Ph3/A
1	EIN	aus	aus	1
2	EIN	aus	aus	0
3	aus	EIN	aus		1
4	aus	EIN	aus		0
5	aus	aus	EIN			1
6	aus	aus	EIN			0
andere	aus	aus	aus

[Alloc]

Ah, stimmt, die "nativen" Ausgangsfunktionen erlauben ja sogar noch bitweise Operationen. Das ist wirklich eine gute Idee! Gleich mal umsetzen

[Alloc]

Der Teil scheint soweit zu laufen, morgen mal weitertesten (bisher war das nur die Statemachine-"Trockenübung" mit manuellen Signalen an den Logikeingängen).
Hatte deinen Vorschlag nochmal etwas angepasst:
image.png

Zusätzlicher Status "Manuell Ein" (Z15).
Z1: Wenn er im Auszustand ist (egal ob manuell/initial) und ein Präsenz-Aus-Signal kommt wechselt er in den Aus-Zustand der Phase, nicht in den Vor-Aus. Bei Aktorstatus Ein (also am PM vorbei) wechselt er zu Manuell Ein (Z15).

Z4/8/12 (Px Vor-Aus / "Warn"): Wenn für die aktuelle Phase nochmal ein Aus vom PM kommt springt er direkt in den richtigen Aus-Zustand (Z5/9/13). Somit kann man über Auto-Übersteuern Taste direkt aus dem Vor-Aus in den richtigen Auszustand springen und den Timeout überspringen.

Z5/9/13 (Px Aus): Wenn Aktorstatus=1 kommt ist dies wieder das Anschalten am PM vorbei, springt daher auch in den Manuell Ein Zustand (Z15).

Z15 (Manuell Ein): Wenn Aktorstatus=0 kommt schaltet man am PM vorbei aus, er geht in Manuell Aus (Z1). Zusätzlich hier noch die Behandlung einer PM-Aus-Meldung. Der PM ist ja zwangsläufig in die Nachlaufzeit gestartet, wenn der Aktorstatus aktiv gemeldet hat, also sollte (wenn nicht manuell abgeschaltet wird) der PM irgendwann Aus senden, dann spring er zurück in den passenden Vor-Aus-Zustand der jeweiligen Tagesphase.