OpenKNX-VirtualPresence release (VPM)

[willisurf]

Szenensteuerung scheint nicht zu wirken (lt. Diagnose auch nicht im M Modus)

Durch das Einschalten wechselt der Aktorstatus seinen Zustand. Dadurch schaltet der VPM vom Manuellen Modus in den Automatikmodus.
Habe ich eben nochmal nachvollzogen.

Das ist Sollverhalten und so iO. D.h. Du müsstest Deine Steuerung ändern.

[willisurf]

wie filterst du, dass die Ambiente Szene aktiviert ist. Ich arbeiten nur mit EINER Szenen GA. Bedeutet, dass ja durch Szenen in anderen Zimmern es immer wieder eine neue Szenen Nummer gibt.

Erstmal kurz die schnelle Antwort, die Szenen welche zu Lichtumschaltungen im Raum führen sind bei mir raumselektiv.
Es gibt auch noch Zonen oder Gesamtübergreifende Szenen, die dann als weitere hörende Adressen auf die Aktoren gelegt sind. Ist hier aber unwichtig.
Daher kann ich problemlos für den Raum eine Szene senden, die das Ambientelicht aktiviert.

Sehr grob vereinfacht schaltet der VPM bei (ich könnte den ConfigString posten, aber das ist eigentlich in diesem Fall unübersichtlicher):
Tagesphase Normal: Ein z.B. mit Szene2 (Grundbeleuchtung) AUS z.B. mit Szene1 alles Aus
Tageshase Ambiente: Ein wieder z.B. mit Szene2 (Grundbeleuchtung) AUS z.B. mit Szene8 Ambientelicht

Wichtig ist dann noch wie gesagt die Auswertung des Aktorstatus (wenn dieser auf den VPM geführt ist), sodaß auch bei aktiver Ambientebeleuchtung trotzdem Aus erkannt wird.

Trotzdem hier mal der ConfigString des VPM

OpenKNX,cv1,0xA002:0x31/PM:0x31/1§p~Name=LK1%20WZ§p~PresenceInputs=3§p~PhaseCount=3§p~Output1Type=3§p~Output2Type=1§p~ChannelActive=1§p~LockType=2§p~LockOn=1§p~LockFallback=1§p~PhaseChange=1§p~ManualModeKeyCount=0§p~StartReadLux=1§p~StartReadLock=1§p~StartReadDayPhase=1§p~LeaveRoomModeMove=3§p~ChannelDelayTime=4§p~DowntimeOffTime=1§p~AdaptiveDelayBase=0§p~Phase1Name=Normal§p~Phase2Name=Ambiente§p~Phase3Name=Nacht§p~Phase4Name=Fernsehen§p~Scene0=42§p~SceneAction0=14§p~NumLux:1=50§p~IntPresence1=1§p~NumPresence1:2=855§p~IntPresence2=1§p~NumPresence2:2=853§p~NumSetAuto:1=53§p~NumSetManual:1=54§p~IntActorState=1§p~NumActorState:2=966§p~NumLock:1=56§p~NumReset:1=57§p~NumDayPhase:1=58§p~NumScene:1=62§p~EnableLux=1§p~EnableDayPhase=1§p~LeaveRoom=2§p~LeaveRoomModeChosen=3§p~SignalMove=1§p~SignalPresence=1§p~ExternalSignalMove=1§p~ExternalSignalPresence=1§pA~BrightnessAuto=1§pA~ManualWithPresence=1§pA~BrightnessOffDelayBase=1§pA~BrightnessOffDelayTime=2§pA~ManualFallbackDelayTime=2§pA~BrightnessOn=12§pA~BrightnessDelta:1=10§pB~BrightnessAuto=1§pB~ManualWithPresence=1§pB~BrightnessOffDelayBase=1§pB~BrightnessOffDelayTime=2§pB~ManualFallbackDelayTime=2§pB~BrightnessOn=12§pB~BrightnessDelta:1=15§pB~Output1OffScene=5§pC~ManualWithPresence=1§pC~PresenceDelayBase=0§pC~ManualFallbackDelayTime=2§pC~BrightnessOn=8§pC~Output1OnScene=7§pD~BrightnessAuto=1§pD~ManualWithPresence=1§pD~BrightnessOffDelayBase=1§pD~BrightnessOffDelayTime=2§pD~ManualFallbackDelayTime=2§pD~BrightnessOn=8§pD~BrightnessDelta:1=10§pD~Output1OnScene=3§;OpenKNX

Und hier die Auswertung des Aktorstatus, wegen der relativen Bezüge mit Kanalnummer
Logikkanal 10 stellt abhängig von Ambiente ja/nein einen Vergleichswert 0% oder 8% zur Verfügung, beachte: Die Verzögerung von 2s am Ausgang ist wegen der Abdimmrampe notwendig

OpenKNX,cv1,0xA002:0x31/LOG:0x33/10§f~Name=WZ%20Vergleichswert%20Status%20bei%20Ambiente§f~ChannelDelayTime=2§f~Logic=1§f~Calculate=1§f~Trigger=32§f~NameInput1=WZ%20Ambiente§f~E1=1§f~E1Default=1§f~NameInput2=WZ%20Tagesphase§f~E2=1§f~E2Dpt=9§f~E2Default=1§f~E2Low0Dpt17=2§f~NameOutput=intern%20WZ%20Vergleichswert%20bei%20Ambiente§f~ODelayOffBase=0§f~ODelayOffTime=2§f~ODelay=1§f~ODpt=3§f~OOnDpt5001=8§;OpenKNX

Logikkanal 11 vergleicht Dimmwert mit Vergleichswert

OpenKNX,cv1,0xA002:0x31/LOG:0x33/11§f~Name=WZ%20Lichtstatus%20Stripe_FS§f~ChannelDelayTime=5§f~Logic=2§f~Calculate=1§f~Trigger=32§f~NameInput1=WZ%20Dimmwert%20Stripe_FS§f~E1=1§f~E1ConvertInt=1§f~E1Dpt=3§f~E1Default=1§f~E1LowDelta:1=1§f~E1HighDelta:1=100§f~NameInput2=WZ%20Vergleichswert%20§f~E2Dpt=3§f~E2UseOtherKO=1§f~E2OtherKO:2=879§f~NameOutput=intern%20WZ%20Lichtstatus%20Stripe_FS§;OpenKNX

[willisurf]

Aber die Frage ist doch, warum die 1 vom PM nicht gereicht hat.

Ich denke die GA sind falsch verbunden. Lt. Deiner Beschreibung soll die 5/1/11 vom PM auf den VPM Eingang gehen.
Verbunden ist aber die 5/1/10.
image.png
Da auf der 5/1/10 lt GrpMon kein true gesendet wurde, schaltet der VPM 60s nach dem AUS des Reed ab.
Falls irgendwann vorher auf der GA 5/1/10 mal ein true gesendet wurde, wäre das auch egal, da bei den hörenden Adressen der letzte Wert gewinnt. Bei PM Eingängen ist dieses Konstrukt mit hörenden Adressen selten sinnvoll, eine Logik oder Nutzung des zweiten Eingangs (ist quasi ODER verknüpft) ist meistens besser geeignet.

[henfri]

Danke.
Ich habe den Post oben aktualisiert mit Screenshots und dem Bus-Monitor Auszug mit Status-Objekt, der Logik-Konfiguration und den ETS-Screenshots.

Viele Grüße,
Hendrik

[willisurf]

habt ihr eine Idee zu meinem Problem

auch das kann ich mir anschauen, obwohl im Moment fehlt mir da der Überblick, inwieweit externe Logik beteiligt ist.

Und wenn Du sowieso etwas dazu neu postest, würde ich mir für Konfiguration und -wenn noch möglich- Screenshots der ETS wünschen. Irgendwie ist das lesbarer. CofigStrings zum Import geht natürlich auch, aber manchmal sieht man schon etwas aus den Screenshots.

[willisurf]

ich hoffe das war es was du meintest

Ja genau, ich schau mir das heute Abend an

[mumpf]

Was ich zu Debug-Zwecken mache: Ich entferne die GA von Aktorstatus und gucke, ob es dann läuft. Wenn ja, weiß ich, woran es liegt.

Gruß, Waldemar

P.S.: Wenn wirklich alle Schaltvorgänge vom PM vorgenommen werden, müsst ihr den Aktorstatus auch nicht verbinden...

[henfri]

Danke Waldemar,

wie gesagt: Keine Eile. Aber ich werde deinen Hinweis mal prüfen.

[mumpf]

henfri und shortyle: Ich lese hier mit, aber ich mach derzeit ein Release fertig und neue Bugfixes kommen dann auch erst ins nächste Release (was dann auch nur ein Firmware-Update ohne ETS und entsprechend auch schneller kommen kann und wird). Deswegen auch keine direkte Hilfe von mir, erst nachdem das raus ist.

Danke an willisurf, dass er hier mithilft. Vielleicht findet ihr ja vorher schon was.

Allgemeine Aussage zu beiden Fällen: Der Aktorstatus (Eingang im PM) ist immer wichtig bei solchen Betrachtungen, denn: Immer wenn der Aktorstatus einen anderen Wert bekommt als der aktuelle Zustand des PM, geht er davon aus, dass von außen geschaltet wurde und logischerweise der aktuelle Modus (egal welcher) nicht mehr gilt. Ein Aktorstatus AUS wird einen Melder, der in M1 ist, auf jeden Fall in N0 bringen. Ein Aktorstatus EIN umgekehrt.
Ein Aktorstatus, der gleich dem internen Zustand ist, macht gar nichts: Melder in M1, Aktorstatus EIN stört nicht.

Ich analysieren gerne kommende Woche mit euch eure Probleme, nur jetzt ist nicht die richtige Zeit dafür, sorry. shortyle: Ich finde Dein Szenario spannend und sehe mir das dann gerne an.

Gruß, Waldemar

[henfri]

Hallo,

mumpf, willisurf habt ihr eine Idee zu meinem Problem aus https://knx-user-forum.de/forum/proj...78#post1996778 ?
(Eilt nicht).

Gruß,
Hendrik

[shortyle]

hier die Übersicht vom Kanal, ich hoffe das war es was du meintest.

Bildschirmfoto 2024-11-23 um 11.59.18.png

Dank dir schon mal für deine Mühen.

[willisurf]

Welche GA Verknüpfungen soll ich zeigen, sind ja doch ein paar

Nur die vom betroffenen VPM Kanal, achso und sicherheitshalber auch noch die VPM Version.

Rest mache ich später am Rechner

[shortyle]

Hier mal ein Ausschnitt (gefiltert mit den betroffenen Geräten) vom GrpMon

Dargestellt wurde Szenario 2 von oben

Blau ist folgender Ablauf.

Ich schalte die Szene 39 (Ambiente) und betrete danach die Küche.
was passiert?

1. Szene 39 aktiviert
2. X1 + X3 gehen an (mit Werten der Szene)
3. Ich betrete die Küche
4. X2 wird dazugeschaltet (an X1 + X3 ändert sich nichts -> soweit ok für mich)
5. ich verlasse die Küche
6. nach Ablauf NLZ X1+X2 werden ausgeschaltet -> Szenensteuerung scheint nicht zu wirken (lt. Diagnose auch nicht im M Modus)


Grün ist folgender Ablauf.

Ich betrete zuerst die Küche und schalte während der NLZ die Szene 39.
was passiert?

1. Ich betrete die Küche
2. X1 + X2 werden eingeschaltet
3. ich verlasse die Küche
4. ich aktiviere Szene 39 -> X3 wird dazu geschaltet und X1 erhält Wert aus Szene
5. nach Ablauf NLZ wird X2 ausgeschaltet (X1 + X3 bleiben unverändert) -> Szenensteuerung klappt. Auch in der Diagnose ist der manuelle Modus aktiviert

Es scheint also die Reihenfolge irgendwie entscheidend zu sein. Zuerst die Szene, die den manuellen Modus im Kanal einschalten soll, zu aktivieren klappt nicht. Umgekehrt klappt es.

Bildschirmfoto 2024-11-23 um 11.05.32.png

Welche GA Verknüpfungen soll ich zeigen, sind ja doch ein paar

Ganz andere Idee zum Ambientelicht. Ich habe das bei mir auch, allerdings habe ich das über Tagesphasen realisiert. Wenn Ambientelicht aktiv ist wird zum Ausschalten nicht die normale Ausschaltszene gesendet, sondern eben Ambiente. Gleichzeitig berücksichtigt auch der Aktorstatus das bei Ambientelicht noch (bei mir) 8% eingeschaltet sind und über einen Logikkanal wird das als AUS signalisiert, damit die ganzen Tasteranzeigen und Umschaltungen klappen.

wie filterst du, dass die Ambiente Szene aktiviert ist. Ich arbeiten nur mit EINER Szenen GA. Bedeutet, dass ja durch Szenen in anderen Zimmern es immer wieder eine neue Szenen Nummer gibt. Kannst du dKonfigtransfer zur Verfügung stellen, da kann ich es vielleicht leichter nachvollziehen.

[willisurf]

Ich habe gerade mal die Szenensteuerung auch für "Manuell aktivieren" mit meinem Stand (Präsenz Version 3.2) geprüft.
Bei mir schaltet er auch bei Manuell aktivieren in den Manuell Modus. Könntest Du bitte mal ein kurzes Stück GrpMon Ausschnitt und Deine GA Verknüpfungen zeigen?

Ganz andere Idee zum Ambientelicht. Ich habe das bei mir auch, allerdings habe ich das über Tagesphasen realisiert. Wenn Ambientelicht aktiv ist wird zum Ausschalten nicht die normale Ausschaltszene gesendet, sondern eben Ambiente. Gleichzeitig berücksichtigt auch der Aktorstatus das bei Ambientelicht noch (bei mir) 8% eingeschaltet sind und über einen Logikkanal wird das als AUS signalisiert, damit die ganzen Tasteranzeigen und Umschaltungen klappen.

[shortyle]

Hallo zusammen ich habe auch mal wieder eine Frage bzw ein Problem.

Sorry schon mal wenn es etwas länger wird, wollte es aber möglichst genau beschreiben.

Es geht mir um die Szenensteuerung. Das Thema Helligkeit lassen wir mal außen vor, die Schwellen sind alle erfüllt, dass die Leuchten angehen.

Aber erstmal von vorne. Wir haben einen offenen Wohn/Koch/Essbereich.
Dort geht es um folgende Geräte.

Beleuchtung (DALI):

- Kochen

- Nischen Beleuchtung --- Ambiente Beleuchtung --- (X1) -> Die Konfiguration vom betroffenen PM Kanal habe ich als Screenshots beigefügt.

- Hauptbeleuchtung (X2)

- Wohnen:

- Lichtvoute --- Ambiente Beleuchtung --- (X3)

BWM:

- Kochen

- normaler BWM welcher im VPM "verarbeitet" wird (B1)

Taster:

- Wohnen

- normaler KNX Taster mit dem Szenen ausgelöst werden (T1)

Szenario 1:
- ich betrete die Küche und über B1 werden die Leuchten X1 und X2 angeschaltet (verarbeitet im VPM mittels zwei PM Kanäle = passt soweit
- ich verlasse die Küche und die beiden Leuchten werden wie gewünscht (Nachlaufzeit vorbei) ausgeschaltet = passt soweit


Szenario 2:
- ich aktiviere mit T1 die Szene 39 welche das Ambiente Licht einschaltet (also X1 + X3) = passt soweit
- ich betrete die Küche, X2 schaltet sich dazu = passt soweit
- ich verlasse die Küche und nach Ablauf der Nachlaufzeit schalten sich X1 und X2 aus = das ist in dem Augenblick nicht gewollt, denn X1 soll aufgrund der Ambientebeleuchtung an bleiben, aber nachvollziehbar, da der Befehl zum Ausschalten eben aufgrund der Nachlaufzeit kommt.

Nun dachte ich mir, ok, beim schalten der Szene 39 wird der PM Kanal von X1, mittels der Szenensteuerung auf manuell gesetzt --- also "Szene 39 -> Manuell aktivieren", das hat aber nicht das gewünschte Ergebnis zum Erfolg, denn wenn ich im Diagnose Objekt für X1 schaue bleibt er im Normalmodus und die Nachlaufzeit beginnt, ohne das ich die Küche betreten habe. Nach Ablauf derer geht X1 aus.

Wenn ich das Ganze nun mit "Szene 39 -> Manuell übersteuern mit EIN" mache, dann klappt es wie gewünscht. bis auf eine Ausnahme. Durch das EIN Signal schaltet sich X1 auf den maximalen Einschaltwert (zeitgesteuert 20%), nicht jedoch auf den Einschaltwert, welcher in der Szene 39 (5%) hinterlegt ist.

Lt. Applikationsbeschreibung ist doch der Unterschied zwischen Manuell aktivieren und Manuell übersteuern mit EIN nur der, dass beim Letztgenannten noch ein EIN Signal gesetzt wird. Bei beiden müsste aber der Kanal in den Manuellen Modus wechseln, oder? Bei mir macht er aber irgendwie nichts anderes, als das er salopp gesagt kurz die Präsenz simuliert, dadurch die Nachlaufzeit auslöst und eben nach Ablauf die Leuchte ausschaltet.

Ziel wäre es also, dass bei Szenario 2 X1 mit dem Wert eingeschaltet wird, der in der Szene definiert wird und nach Verlassen der Küche nicht ausgeht.

Das Verhalten von "Manuell übersteuern mit EIN" kann ich völlig nachvollziehen, bei "Manuell aktivieren" habe ich erwartet, dass der Kanal nur in den manuellen Modus geht, nicht mehr, nicht weniger.

hier noch der Konfigtransfer falls das eher hilft.

OpenKNX,cv1,0xA002:0x32/PM:0x32/2§p~Name=E1_K%C3%BCche_Nische§p~PresenceInputs=2§p~PhaseCount=1§p~ChannelActive=1§p~AutoOffIsLeave=1§p~ManualModeKeyCount=0§p~LeaveRoomModeMove=3§p~DowntimeOffTime=5§p~Phase2Scene=4§p~Scene0=33§p~Scene1=34§p~Scene2=35§p~Scene4=39§p~SceneAction0=2§p~SceneAction1=5§p~SceneAction2=5§p~SceneAction4=24§p~EnableLux=1§p~EnableDayPhase=1§p~LeaveRoom=2§p~LeaveRoomModeChosen=3§p~SignalMove=1§p~ExternalSignalMove=1§pA~BrightnessAuto=2§pA~ManualWithPresence=1§pA~PresenceDelayTime=3§pA~ManualFallbackDelayBase=1§pA~ManualFallbackDelayTime=45§pB~BrightnessAuto=2§pB~ManualWithPresence=1§pB~ManualFallbackDelayBase=1§pB~ManualFallbackDelayTime=45§pB~BrightnessOn=30§;OpenKNX

Allgemeine PM Kanal Einstellungen
Screenshot 2024-11-22 220938.png

Szenensteuerung
Screenshot 2024-11-22 220201.png

Phase1 (ist zum besagten Zeitpunkt aktiv gewesen)
Screenshot 2024-11-22 220242.png