PresenceModule mit Steinel TruePresence: Verständnisproblem "Manuell übersteuern"

[nsowen]

Hallo zusammen,

erst einmal großes Lob an das OpenKNX Team, das ist echt ein richtig gutes Projekt. Ich bin relativer Neuling im gesamten Thema und konnte leider auch mit der Suchfunktion nicht wirklich fündig werden. Verzeiht bitte, falls das Thema schon in einem Thread behandelt wurde.

Was ich erreichen will:
Konstantlichteregelung per Steinel TruePresence + OpenKNX PresenceModule mit manuellem Übersteuern und Dimmen bei Bedarf.

Was ich schon hinbekommen habe:
Der Steinel TruePresence liefert Präsenz und Bewegung an OpenKNX REG1, geflashed mit PresenceModule-Big-3.6.2. Von dort steuere ich ein Licht an einem MDT Dimmaktor per Konstantlichtregelung. Das funktioniert prima, d.h. es wird in Abhängigkeit zum Lux-Wert des TruePresence geschaltet.

Ein Gira Tastsensor soll nun per Taster die Übersteuerung einschalten und anschließend den Dimmwert anpassen können, ohne dass die Konstantlichtregelung wieder dazwischenfunkt und dunkler fährt bzw. ausschaltet. Nach der entsprechenden Ablaufzeit von 6 Stunden bzw. beim manuellen Ausschalten des Lichts soll die Konstantlichtregelung wieder aktiv sein.

So ist es nun verdrahtet:

image.png
Auszug aus dem Gruppenprotokoll:

image.png

Schritte:
29. Taster wird kurz betätigt, EIN an 1/1/41
30. PresenceModule quittiert "Status Manuell = 1" an 9/2/0
31. Taster wird lang betätigt, relatives Dimmen auf 100% an 1/3/25
32. Aktor meldet Schaltstatus EIN an 1/4/41 - PresenceModule empfängt Schaltstatus via 1/4/41 an "Aktorstatus", das passiert noch während des Dimmens
33. PresenceModule quittiert plötzlich "Status Manuell = 0" an 9/2/0

Ein wenig schaltet PresenceModule das Licht wieder aus, weil der "Manuelles Übersteuern" wieder ausgeschaltet wurde.

Ich verstehe irgendwie nicht, wieso der Aktorstatus die manuelle Übersteuerung wieder implizit abschaltet. So richtig schlau werde ich aus der Applikationsbeschreibung dahingehend auch nicht.

Vielleicht hat jemand ein Tipp und kann mir meine Fehlkonfiguration erklären, oder eine alternative Herangehensweise aufzeigen!

Besten Dank und "keep up the good work" ;-)

Viele Grüße,

Nils

[willisurf]

Es wundert mich, das sich der Aktorstatus ändert, nur weil Du den Dimmwert veränderst.
Da habe ich etwas in Deiner Topologie oder Bedienung noch nicht verstanden.

Der VPM ändert den Modus von manuell auf Auto zurück, wenn sich der interne Status ändert.
Also vermutet in Deinem Beispiel:
VPM ist intern Aus und auf Manuell geschaltet.
Aktorstatus wechselt auf Ein
VPM schaltet intern von Aus auf Ein, daher durch den Statuswechsel zurück auf Auto.

Zeig bitte nochmal der Vollständigkeit halber, ob Du bei manueller Bedienung den Ein- oder Zweitastenmodus gewählt hast.

Ansonsten wäre ein möglicher Weg die Dimmbotschaft von Taster auszuwerten und dadurch direkt den Manuellmodus zu setzen. Das Logikmodul kann das leider nicht, da DPT2 aktuell nicht wählbar sind. Vielleicht hast Du ja irgendwoanders noch eine Möglichkeit das umzusetzen.
Oder noch besser, wir finden etwas im bestehenden System.

[nsowen]

Vielen Dank für die schnelle Antwort, Bernhard!

Da habe ich etwas in Deiner Topologie oder Bedienung noch nicht verstanden.

Genaueres Szenario: das Licht ist noch aus, weil es gemäß KLR noch hell genug ist. Ich betätige den Taster und setze damit den manuellen Modus. Beim Hochdimmen ausgehend von 0% scheint der MDT AKD-0401.02 standardmäßig ein EIN-Status zu senden. Was ich allerdings noch nicht probiert habe, ist einen Einschaltwert für den Kanal zu konfigurieren. Mal schauen, ob dann auch ein EIN gesendet wird, ich fürchte aber ja.

VPM schaltet intern von Aus auf Ein, daher durch den Statuswechsel zurück auf Auto.

Gerade im Code (PresenceChannel.cpp) in processActorState() nachgeschaut: ja, scheint wohl zu so zu sein: immer wenn ein EIN über das KO kommt, wird der Auto-Modus aktiviert. Das scheint auch dann zu passieren, wenn man die Sperre aktiviert hat. Ggf. wäre es ein Feature Request, das Verhalten "Auf Auto bei Schaltstatus EIN" auch abschaltbar zu machen?

Zeig bitte nochmal der Vollständigkeit halber, ob Du bei manueller Bedienung den Ein- oder Zweitastenmodus gewählt hast.

image.png

Das Logikmodul kann das leider nicht, da DPT2 aktuell nicht wählbar sind.

Es sollte DPT3 (4-bit) sein:

Data fields Description Encoding c Increase or decrease the brightness. See 1.007
0 = Decrease (See EXAMPLE 3)
1 = Increase

StepCode The number of intervals into which the range of 0 % … 100 % is subdivided, or the break indication.
- 001b…111b: Step Number of intervals = 2^(stepcode-1)
- 000b: Break

Gut, man könnte das in Home Assistant basteln, aber vielleicht gibt's doch noch eine elegantere Lösung?

Viele Grüße,

Nils

[willisurf]

Was ich allerdings noch nicht probiert habe, ist einen Einschaltwert für den Kanal zu konfigurieren.

Würde ich nicht machen, das muss anders gehen.

Es sollte DPT3 (4-bit) sein

Ja klar genau, meinte ich auch.

Mir ist ein Workaround eingefallen (gerade ausprobiert), mit dem DPT3 direkt über Logik ein EIN auszulösen.

Kurz zum Workaround (sicher auch für mumpf Waldemar interessant):
Der VPM hat ein KO für DPT3 (eigentlich in Zusammenhang mit Abschaltung über adaptiver Helligkeit), aber das kann man nutzen, um zumindest den rel. Dimmbefehl einzulesen. Dazu am besten einen freien VPM Kanal aktivieren, damit das nicht stört.

Einen Logikkanal mit einem Eingang z.B. als ODER konfigurieren und diesen Eingang als DPT1 direkt auf das KO legen (absolut oder relativ). In der Applikationsbeschreibung steht zwar, das man das nicht tun soll, aber -vorbehaltlich der Zustimmung von Waldemar- in diesem Fall denke ich, ist es in Ordnung, da danach nur der Trigger ausgewertet wird und keine Datenkonvertierung stattfindet.

Beim Eingang "Trigger" (statt "Eingangswert") auswählen.

Als Ergebnis wird am Ausgang der Logik bei jedem relativem Dimmbefehl ein EIN erzeugt, mit dem Du weiter versuchen kannst, den VPM Kanal in den manuellen Modus umzuschalten.
Eintastenmodus sollte dabei richtig sein. Falls es nicht funktioniert, ist jedoch der Zweitastenmodus (der auch direkt den Status mit umschaltet) auch einen Versuch wert. Ggf. hilft es auch die Umschaltung auf Manuell verzögert zu senden.

[mumpf]

-vorbehaltlich der Zustimmung von Waldemar-

Hey Bernhard, coole Idee, auf die kam ich noch gar nicht. Klar, wenn Du das ausprobiert hast und es funktioniert, dann hab ich auch kein Problem damit, dass es genutzt wird.

Ansonsten wird auch im Logikmodul bei einem nächsten größeren Release auch DPT3 Einzug halten, das ist so eines der letzten Features, die noch fehlen. Aber der obige Workaround ist für ein Triggersignal vollkommen ausreichend.

Gruß, Waldemar

[nsowen]

Danke euch beiden, ich werde das am Montag testen und berichten 🙏