OpenKNX-VirtualPresence release (VPM)

[Sisamiwe]

Den Aktorstatus zu verknüpfen ist eine gute Idee in dem von Waldemar geschildertem Fall, das extern geschaltet wird.

Das Verhalten ist mit und ohne Verknüpfung des Aktorstatus gleich.
Ich konnte das Verhalten, dass es manchmal beim zweiten Betreten zu keiner Aktion kommt, noch nicht weiter einschränken. Hat es vielleicht was mit dem Tag / Nacht Objekt zu tun?
Ich beobachte und teste mal weiter.

Aber schon mal Danke an willisurf und mumpf

[willisurf]

Aber der Vorschlag von Bernhard willisurf , den Aktorstatus zu verknüpfen, ist auf jeden Fall gut, unabhängig von dem Problemfall.

Das war tatsächlich ausnahmsweise anders gemeint. Den Aktorstatus zu verknüpfen ist eine gute Idee in dem von Waldemar geschildertem Fall, das extern geschaltet wird. Als Nebeneffekt führt er aber unter gewissen Umständen zu dieser Verzögerung bei erneuten Einschalten, direkt nach dem Ausschalten. Daher sollte er hier im Sinne Fehlereingrenzung nicht auf ModeAuto liegen.

[Susanne007]

Ja nur keinen Stress, ist erst wieder am 1 Nov. wichtig

Auf der Seite "Allgemein" habe ich nichts eingestellt, ist alles im Originalzustand. Der 3 Oktober ist aber angekreuzt.

Funktioniert das ev. nur nach einem vollständigen Programmieren? Habe das in der Zeitschaltuhr vor ca. 3 Tagen so eingetragen und nur "partiell programmiert".

[mumpf]

Das tut mir leid, dass ihr heute früh geweckt wurdet...

Nur zur Vollständigkeit: Auf der Seite "Allgemein" ist der 3. Oktober auch als Feiertag angekreuzt?

Ansonsten gilt das selbe wie für Sisamiwe: Ich schau mir das gerne morgen nochmal an, heute bin ich leider den ganzen Tag unterwegs.

Gruß, Waldemar

[Susanne007]

Hallo zusammen,
ich habe hier den VPM 3.1 in Betrieb und habe eigentlich in der Logik/Zeitschaltuhr eingestellt, dass Feiertage wie Sonntage behandelt werden.
Leider gingen heute um 7:30 alle Rollladen hoch. Datum / Uhrzeit ist richtig verknüpft und wird mir überall z.B. an den GT2 richtig angezeigt.
Wo kann ich noch den Fehler suchen?
Aktuell gibt es nur diese eine GA zum hochfahren und ist auch nur mit dieser einen Zeitschaltuhr verknüpft. (alles erst neu angelegt, keine "Altleichen" irgendwo vorhanden)
Breitengrad/Längengrad ist richtig eingetragen.

[mumpf]

Guten Morgen,

ich schau mir das gerne an (vor allem bei einem so toll vorbereiteten Beispiel, mit ConfigTransfer - großes Lob, so stelle ich mir Supportanfragen vor ), aber ich bin heute den ganzen Tag unterwegs und komme erst morgen dazu.

Aber der Vorschlag von Bernhard willisurf , den Aktorstatus zu verknüpfen, ist auf jeden Fall gut, unabhängig von dem Problemfall. Das ist zwingend notwendig, falls der Aktor auch von wo anders als vom VPM geschaltet wird (Du sprachst von Szenen und von weiteren Logiken). Falls wirklich nur der VPM den Aktor schaltet, wird es nicht helfen, aber es schadet auch nicht . Und ich muss gestehen, dass ich in meinen ganzen Tests nie ohne Aktorstatus-Assoziazion teste (weil immer noch was anders schalten kann). Somit könnte da auch noch ein unerwartetes Verhalten drin sein.

Gruß, Waldemar

[Sisamiwe]

GA Zuordnung wäre auch noch hilfreich.

Im Beitrag oben ergänzt

Liegt ggf. der Aktorstatus auf dem ModeAuto Eingang?

Den Aktoreingang habe ich bislang nicht verknüpft. Das probiere ich mal.

[willisurf]

Nur eine Idee, ich bin unterwegs und kann die Konfiguration nicht anschauen, GA Zuordnung wäre auch noch hilfreich.
Liegt ggf. der Aktorstatus auf dem ModeAuto Eingang?

[Sisamiwe]

Guten Morgen,

ich brauche mal Expertenhilfe!

Mein Szenario: Im Bad habe ich an der Wand neben der Tür einen MDT PM und an der Decken einen RealPresence von Masifi auf dem auch die Firmware läuft.
Ausgewertet und "Verbunden" sind die beiden PMs über den VPM.
Meinst funktioniert es wie es soll: Beim Betreten des Raumes wird das Licht eingeschaltet und wird ca. 1min nachdem man den Raum verlassen hat abgeschaltet (die 1 min ist die Zeit, bis der verwendete Sensor im RealPresence die Päsenz deaktiviert).
Nun gibt es den Fall (vor allem morgens), dass das Licht (nachdem es bereits einmal eingeschaltet wurde und nach Ende der Präsenz wieder ausging) bei einem zweiten Betreten des Raumes nicht wieder eingeschaltet wird. Diesem "Phänomen" komme ich einfach nicht auf die Spur.

Einstellung des VPM:

OpenKNX,cv1,0xA002:0x32/PM:0x32/0§VisibleChannels=10§LEDPresence=2§LEDMove=1§HfPresence=2§SendRAW=1§;OpenKNX

Grundsätzlich habe ich 2 VPM Kanäle in Betrieb:
Kanal 1: Wertet Bewegung vom MDT PM und Präsenz vom RPM aus und schaltet das Licht via Szene Tageszeitabhänig

OpenKNX,cv1,0xA002:0x32/PM:0x32/2§p~Name=VPM%20Bad%20OG§p~PresenceInputs=3§p~PhaseBool=1§p~PhaseCount=1§p~Output1Type=4§p~Output2Type=3§p~ChannelActive=1§p~StartReadPresence2=1§p~ExternalSupportsReset=1§p~PresenceKeepAlive=1§p~IntLux=1§p~NumLux:2=855§p~IntPresence1=1§p~NumPresence1:2=21§p~EnableLux=1§p~EnableDayPhase=2§p~LeaveRoom=3§p~SignalMove=1§p~SignalPresence=1§p~ExternalSignalMove=1§p~ExternalSignalPresence=1§pA~Output1Filter=0§pA~PresenceDelayBase=0§pA~PresenceDelayTime=5§pA~ManualFallbackDelayBase=1§pA~BrightnessOn=100§pA~Output2OnScene=41§pA~Output2OffScene=40§pB~Output1Filter=0§pB~PresenceDelayBase=0§pB~PresenceDelayTime=5§pB~Output2OnScene=42§pB~Output2OffScene=40§;OpenKNX

Kanal 2: Wertet Bewegung vom MDT PM und Präsenz vom RPM aus und stellt ein KO für "Bad besetzt" zur Verfügung.

OpenKNX,cv1,0xA002:0x32/PM:0x32/3§p~Name=Bad%20besetzt§p~PresenceInputs=3§p~ChannelActive=1§p~BrightnessIndependent=1§p~StartReadPresence2=1§p~PresenceKeepAlive=1§p~Phase1Name=immer§p~IntPresence1=1§p~NumPresence1:2=21§p~LeaveRoom=2§p~SignalMove=1§p~SignalPresence=1§p~ExternalSignalMove=1§p~ExternalSignalPresence=1§pA~PresenceDelayBase=0§pA~PresenceDelayTime=3§;OpenKNX

Beide Kanäle sind gleich konfiguriert. In dem Fall, wie oben beschrieben, dass das Licht beim zweiten Mal nicht angeht, wird auch vom VPM Kanal keine "An" Telegramm gesendet, wohl aber "Bad besetzt".

Zudem gibt es noch ein Logik, die nach Ende der Präsenz alle Lichter im Bad ausschaltet (auch die die nicht Teil der Szene sind und manuell eingeschaltet wurden)

OpenKNX,cv1,0xA002:0x32/LOG:0x33/1§f~Name=Bad%20Beleuchtung%20aus%2C%20wenn%20Pr%C3%A4senz%20endet§f~Logic=1§f~Calculate=1§f~Disable=1§f~OInternalOn=0§f~OInternalOff=0§f~NameInput1=Pr%C3%A4senz§f~E1=1§f~E1UseOtherKO=1§f~E1OtherKO:2=21§f~E1DefaultExt=2§f~NameOutput=Bad%20Beleuchtung%20aus§f~OOutputFilter=3§f~OOn=0§f~OOnAll=0§;OpenKNX

Und hier noch ein ETS-Mitschnitt von gestern morgen:
image.pngMan sieht, dass

Ende einer Präsenz

203: Bewegung aus
224: Präsenz aus
225: Beleuchtung aus
232: "Bad besetzt" aus

Neue Bewegung und Präsenz:

270: Präsenz an

277: Bewegung an
278: "Bad besetzt" an
aber kein Telegramm für "Licht an" (müsste auf GA 0/4/1 zum Szenenaufruf gehen)

Hier noch die GA Zuordnung:
image.png

Kann hier jemand sachdienliche Hinweise geben?
Danke!

[mumpf]

Der Vorschlag von Bernhard willisurf ist sogar noch besser.

Ansonsten kann der VPM Deinen "morgens"-Fall über den Modus der adaptiven Helligkeitsschwelle abdecken. Zwar geht das Licht an, während der Rolladen auf geht (was auch richtig ist, da es ja noch dunkel ist), aber es geht sehr schnell wieder aus, nachdem der Rolladen oben angekommen ist, da es dann hell genug im Raum ist.

Gruß, Waldemar

[mumpf]

Durch die Eintastenbedienung ist es allerdings so, dass man das Licht (falls bereits an) zuerst mit kurzem Tastendruck (Automatik übersteuern) ausschalten muss und dann mit langem Tastendruck (manuelles Übersteuern) das Licht "sperren" + Rollläden sperren+schließen kann. Der WAF schließt das aus...

Du hast beim VPM auch ein mächtiges Logikmodul dabei, das weißt Du schon, oder? Und Du sagst hier direkt, was Du machen musst. Du willst bei langem Tastendruck (manuelles übersteuern):

• zuerst das Licht ausmachen
• dann in den Manuellmodus gehen

Langer Tastendruck geht auf "Automatik übersteuern->aus" + auf einen Logikkanal, der mit 1/10s Verzögerung auch noch auf Manuelles übersteuern geht. Falls Du auf dem Weg noch ein Signal invertieren oder filtern musst, dann brauchst Du noch einen 2. Logikkanal.

Gruß, Waldemar

[willisurf]

Ich würde den langen Tastendruck eine Szene Schlaf senden lassen, die schaltet Licht aus, sperrt den Melder und fährt das Rollo runter. Die Reaktion des VPM auf Szenen kannst Du direkt im VPM einstellen.

Wie dann die Szene beendet werden soll, müsstest Du im Detail mit Deiner Frau klären/ausprobieren. Auch die Frage ob das Einschalten des Lichts bei Hochfahren noch unterdrückt werden soll. Umsetzen kann man das mit VPM und Logikmodul sicher, wenn es klar definiert ist.

[gbglace]

Würde ich vermutlich wenn der Status des Rollos unten ist reagierend auf den Tastendruck vom Taster /Visu kommend eine Verzögerung einbauen und erst dann den VPM antriggern. Aber dann hast das Problem das es noch 20/30 Sekunden dunkel bleibt, bis die Verzögerung rum ist, dann erst der VPM selbst in Automatik geht. Das hilft dann zwar bei dem Szenario es ist hell genug draußen, weil der Lichtsensor dann schon meldet es braucht kein künstliches Licht, aber im Winterhalbjahr hast dann immer die Zeit der Rollollaufzeit sinnlos gewartet bis dann endlich Licht im Raum ist.
Bevor ich da per Hand Licht anschalte würde ich eher damit leben, dass der VPM direkt Licht anmacht und wenn der Rollo dann oben ist und es dann doch hell genug ist macht er es halt wieder aus. Dank Soft AN/AUS muss sich da auch niemand geblitztdingst fühlen.

[bastiaux]

Erstmal ein riesen Lob an alle Beteiligten des OpenKNX Team, mega starkes Projekt, Danke dafür

Sorry, falls es hier OT ist, ich hätte aber mal eine Logikfrage bzw. Best-Practice Frage zum VPM.

Aktuell ist es so, dass bei langer Tastenbetätigung in einem Raum (Schlafzimmer, Kinderzimmer) die PM Automatik "gesperrt" wird (Steinel TP über VPM via manuelles Übersteuern, Eintastenbedienung: kurz=Automatik übersteuern, lang=Manuell übersteuern) und somit das automatische Ein-/Ausschalten des Lichts, sowie gleichzeitig auch der Rollladen "sperrt" und dieser damit auch runterfährt, also quasi eine Szene "Schlafen".

Durch die Eintastenbedienung ist es allerdings so, dass man das Licht (falls bereits an) zuerst mit kurzem Tastendruck (Automatik übersteuern) ausschalten muss und dann mit langem Tastendruck (manuelles Übersteuern) das Licht "sperren" + Rollläden sperren+schließen kann. Der WAF schließt das aus...

Stellt man den VPM Kanal auf Zweitastenbedienung und sendet mit langem Tastendruck nur immer ein AUS-TG, wird zwar beim "Sperren" (Manuell Übersteuern + AUS-TG) das Licht zwar ausgeschalten und der Rollo fährt runter, da man dann aber nur noch mit kurzem Tastendruck und damit Automatik übersteuern aus dem Manuellen Modus raus kommt, schaltet sich das Licht damit sofort an (während die Rollläden gerade Entsperren und noch hoch fahren). Der WAF schließt das ebenfalls aus...

Hat jemand einen Vorschlag, wie man die Funktion ohne diese 2 Problematiken umsetzen könnte, sodass das Licht beim "Entsperren" (momentan Automatik Übersteuern) nicht gleich Einschaltet, sondern entweder noch solange Präsenz+Nachlaufzeit da ist aus bleibt und bei Bedarf manuell angeschalten werden muss oder erst in seinem Automatikbetrieb bei Bedarf einschaltet, wenn der Rolllo ganz oben ist und es draußen evtl. noch zu dunkel ist?

[Lexxs]

Susanne007

Vielen Dank für deine Hilfe.
Ja, dies wurde bereits in der ETS parametriert.

image.png