OpenKNX-VirtualPresence release (VPM)

[mumpf]

Thilo: Wenn Du noch eine Tagesphase frei hast, dann könntest Du diese morgens um 6 als Halbautomat aktivieren und erst später die Phase, die Du bisher um 6 Uhr genommen hast. So als möglicher Workaround.
Ansonsten schaue ich mir das heute Abend an und werde es natürlich korrigieren.

Gruß, Waldemar

[thilog]

@mumpf: Leider nein, zumal ich das Problem auch um 0 Uhr habe... Bräuchte also zwei zusätzliche Tagesphasen.

Ich hatte gestern Abend schon mal kurz in den Code geschaut, ein Fix war aber nicht ganz so offensichtlich, da hab' ich heute lieber zum Forenbeitrag gegriffen. ;-) Eilt BTW nicht, wenn der Workaround nicht tut, schalte in den Kanal einfach vorerst auf inaktiv.

[willisurf]

thilog wäre es ggf. eine Alternative zur Sperre, stattdessen Nachts auf eine Tagesphase umzuschalten, in welcher der VPM als Halbautomat konfiguriert ist?
So ist das bei mir konfiguriert.

[thilog]

In der Theorie klingt das gut, ich werde berichten, ob die Praxis das ähnlich sieht. ;-)

traxanos: Der Workaround mit TOR-Gatter funktioniert.

[Amenophis]

Ich habe eine Frage zum VPM in Verbindung mit Tag / Nacht beim Starten. Ich teste aktuell zum ersten mal den VPM.

Zeitschaltuhr:
Ich habe zum Testen eine Logik, welche mittels Zeitschaltuhr von 0 - 6 Uhr eine 0 und von 6 - 0 Uhr eine 1 ausgibt. "Den letzten Schaltzeitpunkt berechnen" ist eingeschaltet. Ich sehe auch, dass nach einem Neustart aktuell eine 1 gesendet wird. Die Schaltuhr startet 1 Sekunde nach Neustart.

VPM:
Ich habe zwei Tagesphasen eingestellt. 0 Ist Nacht (Phase 1) 1 ist Tag (Phase 2). Der VPM startet nach 3 Sekunden. Allerdings startet er immer mit Nacht, obwohl es bereits eine Info über die Zeitschaltuhr gab, dass Tag ist. Auch Lesen Tag / Nacht habe ich bei den Eingänge ausgewählt. Sowohl bei "Neues KO" als auch bei "Absolutes KO" bekomme ich es nicht hin, dass er vor dem Start die aktuelle Phase einliest und dann mit der richtigen startet. VPM Version ist 3.6.
Zum testen habe ich es sowohl mit "Sofort Wechsel der Tagesphase" als auch Wechsel nach Aus probiert. In beiden Fällen das selbe Ergebnis.

Wichtig zu wissen, ich schalte bei Tag / Nacht zwei verschiedene Lichtkreise. Der eine über das 1 KO mit ein / aus, das zweite über das 2. KO mittels Wert. Dürfte darauf aber keinen Einfluss haben.

Muss ich irgendwas noch prüfen oder habe ich was übersehen? Jemand eine Idee?

[willisurf]

Muss ich irgendwas noch prüfen oder habe ich was übersehen? Jemand eine Idee?

Nein, sehr gut beobachtet. Das ist tatsächlich noch ein kleiner Bug, der nur beim Starten des Gerätes auftritt. Die Tagesphase wird nicht übernommen, solange die Startverzögerung im VPM Kanal aktiv ist. mumpf Waldemar kennt das und hat auch bereits die Stelle lokalisiert.

[mumpf]

Ja, gedulde dich bitte noch etwas, ich versuche noch im Februar einen Patch zu machen.

Gruß, Waldemar

[Amenophis]

Ach Waldemar, du kennst mich. Ich hab Zeit und bin froh, wenn ich weiß, dass es nicht an mir liegt. Jetzt kann ich damit umgehen und baue mir ne Logik als Workaround. Wann immer du soweit bist, kommt es rein

[Alloc]

Die Variante mit dem Logikkanal finde ich aber top. Da muss man erstmal drauf kommen, aber eigentlich ist es dann ja simpel. Wie so oft braucht es nur den richtigen Impuls

Nur nochmal um abzuklären, ob das alles so passt: Das wäre nun meine Umsetzung auf der Logikseite:

OpenKNX,cv1,0xA002:0x36/LOG:0x35/1
f~Logic=2
f~E1=1
f~E1Dpt=2
f~E1OtherKO:2=63
f~E1DefaultExt=2
f~E1UseOtherKO=1
f~E1LowDpt5:1=1
f~ODelayOffBase=0
f~ODelayOffTime=15
f~ODelay=1
f~ODpt=2
f~OOn=0
f~OOnAll=0
f~OOffKOSend=1
f~OOffKOSendNumber=63
;OpenKNX​

Hi zusammen,

ich kam heute endlich mal dazu mit dem PM zu spielen (bisher ja nur die Sensorik genutzt/evaluiert) und das auch direkt mal so umgesetzt. Das funktioniert an sich auch wunderbar, allerdings erzeugt es auch ein "Problem": Beim Wechsel der Tagesphase wird immer der Wert für "Aus" gesendet. Das bedeutet nun, dass beim Wechsel von Tag auf Nacht 1% an die Lichter gesendet wird und dann erst nach der Logik-Nachlaufzeit wieder das Licht auf 0% geht. Beim Wechsel von Nacht auf Tag dann sogar auf 5% und dann wieder nach 10 Sekunden aus.
Kann man irgendwie verhindern, dass der PM beim Wechsel der Tagesphase den Aus-Wert sendet?

Schönen sonnigen Sonntag noch allerseits
Chris


PS: Bus-Log:
image.png

[Alloc]

Eigener Post weil unabhängiges Thema
Beim VPM auf nicht-Sensor-HW (z.B. REG1) kann man ja bei jedem PM-Kanal zwei externe PM-Eingänge nutzen und dann für jeden einstellen, dass er nicht Einschalten sondern nur verlängern können soll.
Beim PM-Abschnitt im Sensor-Modul scheint dann quasi Eingang 1 immer der interne Sensor zu sein. Den kann man zwar nutzen oder nicht, aber ich finde nicht die Option, diesen nur zur Verlängerung der Präsenz zu nutzen. Beim externen zweiten Eingang gibt es die Option wie erwartet.
Übersehe ich hier noch was oder gibt es die Möglichkeit beim internen HF-Sensor wirklich nicht?

Hintergrund:
Wir haben hier viel Trockenbau. Ich hab zwar in ersten Tests schon gemerkt. dass das auch ganz gut blockt aber eben nicht 100%. Von Türen etc mal abgesehen die logischerweise gar nicht blocken. Daher würde ich den HF-Sensor eben (wie zuvor an manchen Stellen beim TPM) gerne so nutzen, dass er nur verlängern kann wenn ein Kanal eh schon an ist.

[mumpf]

Hi, zum ersten Post (Aus bei Tagesphasenwechsel): Bin im Urlaub und muss das nach dem Urlaub (kommendes Wochenende) mal ausprobieren, bevor ich qualifiziert antworten kann.

Zum 2. Post: Die integrierten Sensoren können nicht nur halten, das gibt die Implementierung nicht her. Ich weiß, dass die generische Oberfläche das impliziert, aber unter der Haube ist das nicht immer so einfach wie am UI. Ich bekomme das nicht zeitnah hin und es gibt einfach spannendere Projekte .

Aber Du bekommst es trotzdem hin, ohne dass ich was machen muss : Nimm einfach einen 2. Kanal als VPM, dem Du den Ausgang vom 1. Kanal, der den HF nutzt, als Eingang spendierst.

Gruß, Waldemar

[Alloc]

Danke, Waldemar. Kein Stress deswegen, ich hab Zeit. Genieß erstmal den Urlaub

Natürlich hab ich das beim Einstellen übersehen, dass es hier zusätzlich zum internen Sensor eben auch wie beim Sensor-losen VPM noch die Möglichkeit gibt, *zwei* externe Signale anzubinden. Dann geht das natürlich indirekt doch wieder, top

[Alloc]

Gibt es eigentlich eine Möglichkeit einzustellen, in welcher Tagesphase der VPM nach Neustart startet? Ich habe drei Phasen und er startet bei mir scheinbar immer in Phase 3. Bei Neustart des Gerätes meldet "vpm chXX state" immer "D31".

Außerdem glaube ich, dass dort ein Bug ist: Laut dem Status müsste er ja spätestens nach einmal an+aus automatisch zu Phase 1 wechseln. Dies passiert aber nicht. Sende ich dann die Szene für Phase 1 steht bei "vpm chXX state" immer noch "D31", aber nach dem er dann aus geht ist er wirklich in Phase 1 und meldet dann auch "D11".


Und noch eine Frage zum Thema/KO Aktorstatus: Ich hatte das so verstanden, dass die Rückmeldung vom Aktor den Zustand des PM-Kanal übersteuert. Also:
- Kanal aus und Aktorstatus bekommt eine 1 (wird also extern am PM vorbei aktiviert): PM tut so als ob er einmalig getriggert wurde (wechselt also intern zum aktiven Zustand und lässt die Nachlaufzeit ablaufen). Das funktioniert soweit auch bisher super.
- Kanal an und Aktorstatus bekommt eine 0 (wird am PM vorbei abgeschaltet): PM tut so als ob die Nachlaufzeit abgelaufen wäre, wechselt intern zum inaktiven Zustand und ist bereit neu einzuschalten. Hier hab ich aber zur Zeit das Problem, dass der PM dann immer *sofort* wieder den Einschaltwert sendet.

Zuerst dachte ich, er würde immer noch aktive Präsenz erkennen - weil ich den externen PM-Eingang als Schaltend eingestellt hatte und somit vor dem eintreffenden "Aus" der Präsenz diese als vorhanden gelten könnte. Aber zum Einen hab ich das mal testweise auf Triggernd umgestellt und zum Anderen passiert das sogar, wenn ich das Licht eben nur am PM vorbei einschalte (oben Variante 1, PM wechselt also wohl in den Kanal aktiv Zustand) und danach wieder genauso am PM vorbei ausschalte. Es gab also in dem Szenario nie echte Präsenz, er schaltet aber dennoch sofort wieder ein.

image.png/EDIT:
Das passiert natürlich auch mit dem Problem aus dem Post oben bzgl. des Sendens des Abschaltwertes beim Wechsel der Tagesphase: Kanal ist aus, Tagesphase wird gewechselt. Er sendet den Abschaltwert für die neue Phase - welcher bei mir wegen der Abschaltwarnung dann 5%/1% ist. Also geht der Aktor an, meldet Status=aktiv, der PM-Kanal geht in den Aktiven Zustand. Kurz darauf schaltet die Verzögerungslogik den Aktor ab, Aktor meldet brav Stats=inaktiv, der PM-Kanal hört das und sendet wieder seinen Einschaltwert.



PS: Das Debug-KO ist SUPER. Aber wäre es noch denkbar, dass man bei aktivem Debug KO in den Modulen noch automatische Ausgaben aktivieren könnte? Also z.B. im VPM global und/oder in einzelnen VPM-Kanälen, so dass dann entsprechend bei jeder Statusänderung automatisch das Ergebnis von z.B. dem "chXX state" Befehl gesendet wird? Klar, will man nicht dauerhaft auf dem Bus haben, aber beim Testen könnte das schon hilfreich sein - insbesondere, da die ETS ja keine Historie der gesendeten Werte bietet


/EDIT (20:10): Hatte wie im andren Thread geschrieben vorhin das Update auf die neue Version gemacht. Eventuell ist damit das ein oder andre behoben? Zumindest startet er jetzt mit "D11". Ich schau mir morgen noch mal alle Punkte an

[mumpf]

in welcher Tagesphase der VPM nach Neustart startet?

Nein, an sich startet er immer in der Tagesphase 1. Du kannst aber einen ReadRequest auf die Tagesphase schicken lassen und so den Anfangszustand bestimmen. Allerdings funktioniert das erst seit dem aktuellen Release 4.2.5 erst richtig, vorher wurden Tagesphasen am Eingang erst ausgewertet, wenn der Kanal aktiv ist. Aber die Phase 3 macht keinen Sinn, hab ich noch nie gesehen. Hier würde ich wirklich zu Versuchen mit der neusten Version raten.

Es gab also in dem Szenario nie echte Präsenz, er schaltet aber dennoch sofort wieder ein.

Das ergibt keinen Sinn - kann ich überhaupt nicht verstehen. So würde ich keine Firmware ausliefern. Ich bin nur am überlegen, wie wir das analysieren können. Ich schlaf nochmal drüber. Aber Du solltest mir die Parametrisierung und die KO-Zuordnungen schicken, vielleicht sehe ich ja was.

Aber wäre es noch denkbar, dass man bei aktivem Debug KO in den Modulen noch automatische Ausgaben aktivieren könnte?

Nein, das gibt die Infrastruktur nicht her. Beim Debug-Kommando werden die passenden Werte berechnet und dann verschickt. Die Debug-Ausgaben dauernd zu berechnen würde die Performance killen. Und es würde immer passieren, auch wenn keine Debug-Ausgaben erfolgen, das ist tödlich, da es hier immer nur 14 Byte-KO geht. Sorry, aber das werde ich nicht machen.

ch schau mir morgen noch mal alle Punkte an

Gruß, Waldemar

[Alloc]

Danke schonmal für die Infos, Waldemar.

Erstes Testergebnis: Scheinbar startet der PM jetzt mit 4.2.5 (ohne Änderung der Konfig) wirklich immer wie erwartet in D11 . Unterscheidung zwischen Neustart bei Tagmodus vs Nachtmodus fehlt dann noch, aber das kann man ja lösen:

Du kannst aber einen ReadRequest auf die Tagesphase schicken lassen

Die Idee das wieder über Logik beim Start oder ähnliches zu realisieren hatte ich im Bett auch noch. Aber was meinst du mit ReadRequest auf die Tagesphase? Das läuft ja über Szenen, und da kann man üblicherweise nicht lesen.
In meinem speziellen Fall kann ich es aber über ein Read auf meine GA für Tag/Nacht lösen, denn wenn dort der Wert gesendet wird wird auch die passende Szene aus einer Logik gesendet. Und die dritte Phase ("Putzen") ist kein "regulärer" Zustand, ist daher beim Start des PM irrelevant


Das Problem mit dem automatischen Anschalten wenn der Aktor extern abschaltet besteht weiterhin. Ich will auch absolut nicht ausschließen, dass da etwas bei mir selber an der Konfiguration hakt
Ich pack gleich mal alles relevante in ein Projekt und zusätzlich nochmal die relevanten Daten unabhängig von der ETS. Was ist dir da eigentlich grundsätzlich lieber? Screenshots der Einstellungen, Konfigurationsstrings, Screenshots vom Buslog, Buslog als XML, (minimales) ETS Projekt mit passendem Buslog?
ZIP mit Buslog XML und passendem Minimalprojekt

Buslog:
image.png

PM KOs:
image.png
Präsenz extern lag natürlich definitiv nicht an, war auch länger nicht im Raum vor dem Test.

PM-Konfig:

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

Gerne jederzeit melden, wenn ich noch was beisteuern kann. Für direkte Kommunikation (Telefon, Discord, TeamViewer ...) stehe ich auch gerne bereit.