OpenKNX-VirtualPresence release (VPM)

[mumpf]

Sind eigentlich Meldungen generell lieber direkt als Tickets erwünscht oder lieber immer erstmal hier ansprechen?

Lieber hier, häufig kann man das klären und andere bekommen die Probleme auch mit und können manchmal davon lernen. Und wenn es dann wirklich ein Bug ist, dann ist ein issue gut, dann vergisst man es nicht.

Und ja, OFM-PM ist gut. Grundsätzlich sind die Module gut (OFM), die hängen ja in mehreren Applikationen (OAM). Und das Problem ist hier ja beim Modul. In OAM gehören solche Issues wie "auf der Hardware kann ich das nicht installieren" oder "warum kann ich 6 Binäreingänge auswählen, obwohl meine Hardware nur 2 BI hat".

Wenn irgendwas unklar ist oder so einfach melden

Wenn ich nicht klarkomme, machen wir mal ne Session und besprechen das online. Aber lass es mich erstmal so versuchen.

Gruß, Waldemar

[Alloc]

Alloc: Danke für Dein Beispiel, ich gucke mir das gleich heute Abend an.

Gerne. Wenn irgendwas unklar ist oder so einfach melden

Ich gehe nochmal in mich, aber es wird keine kurzfristige Änderung, ich mach das erst in einem Feature-Release, nicht in einem Bugfix-Release.

Klar, das ergibt Sinn. Habe dir mal ein Ticket aufgemacht (mit VPM meintest du die OFM-PM, nicht OAM, korrekt?).

Sind eigentlich Meldungen generell lieber direkt als Tickets erwünscht oder lieber immer erstmal hier ansprechen?

[mumpf]

Alloc: Danke für Dein Beispiel, ich gucke mir das gleich heute Abend an. Ich will ein Bugfix-Release fürs Sensormodul rausbringen, da passt das dann.

Zum anderen Thema:

Es wird wohl bei jedem Phasenwechsel der Wert für Aus gesendet.

Wie willisurf schon sagte, das ist Absicht. Bei Szenen ist recht offensichtlich, dass man so etwas haben möchte, da einzelne Szenen unterschiedliche Lichtkreise betreffen können. Und bei den anderen Schaltobjekten (bool, dim) stört es nicht, wenn ein AUS gefolgt von einem EIN kommt. Das ist der Stand der Implementierung.

Allerdings stimme ich Dir zu, dass man über eine Auswahl an der Stelle diskutieren kann. Denn einerseits braucht man bei normalen Schaltobjekten das AUS nicht wirklich (ich hab da noch so einen Fall, in den eine Logik noch speziell darauf reagiert, aber das ist eher historisch) und andererseits kann man sich auch eine Szene vorstellen, die selber so agiert, dass sie die nicht benötigten Objekte abschaltet und die benötigten einschaltet. Ich hab einfach das Problem, dass mein DALI-Gateway nur 16 Szenen kann und ich somit versuche, möglichst wenige zu "verbrauchen".

Ich gehe nochmal in mich, aber es wird keine kurzfristige Änderung, ich mach das erst in einem Feature-Release, nicht in einem Bugfix-Release.

Gruß, Waldemar

P.S.: Du kannst aber gerne immer wieder nachfragen, das schadet nichts, das wieder in Erinnerung zu bringen. Noch besser: Issue beim VPM auf github.

[willisurf]

Oder sogar generell beim Phasenwechsel den Aus-Zustand nicht nochmal sende

Das beim Wechsel der Tagesphase auch Aus nochmal gesendet wird, ist eine bewusst eingebaute Funktion.
Beispiel:
Normale Tagesphase mit Szene Aus und Ein
Ambientelicht Tagesphase mit Szene z.B. 8% bei VPM aus und ebenfalls Ein

Beim Wechsel der Tagesphase auf Ambiente (oder auch auf Normal) soll auch ohne Präsenz die abweichende Ansteuerung für VPM aus gesendet werden. Das läuft bei mir schon fast 2 Jahre so.

Parallel gibt es ja auch immer noch die Möglichkeit die Tagesphase nicht sofort, sondern erst bei nächster Präsenz umzuschalten.

[Alloc]

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.

Habe das auch gerade nochmal mit dem Minimalaufbau (ohne Logik) überprüft: Es wird wohl bei jedem Phasenwechsel der Wert für Aus gesendet. Im Normalfall (wenn man die Phasen so definiert hat, dass deren Aus-Wert bei Dimmwerten 0% ist) ist das natürlich kein Problem, denn wenn der Aktor aus war und 0% gesendet wird ändert sich nichts. In Kombination mit der Ausschaltverzögerung ist das aber ein Problem, wenn die Phasen so definiert sind, dass sie Dimmwerte > 0% als Aus senden, da jeder Phasenwechsel jetzt eben zu einem (temporären) Einschalten des Lichts führt.

Hier wäre die Frage, ob man das eventuell als Option unterbinden könnte. Oder sogar generell beim Phasenwechsel den Aus-Zustand nicht nochmal sendet. Ich denke zumindest im Kontext von Licht dürfte das keinen Unterschied machen (0% senden wenn das Licht eh aus ist bringt ja nichts), weiß aber nicht, ob da jemand irgendeine komplett "verrückte" Nutzung der Kanäle hat, bei denen man dann wirklich Aus mit Werten ungleich 0/false auf dem Bus braucht (eventuell sogar variierend je nach Phase) und diese somit beim Phasenwechsel gesendet werden müssten.

[Alloc]

Ich wollte gerade mal versuchen das Problem mit dem Abschalten am PM vorbei in einer rein "virtuellen" Umgebung nachzustellen. Also ein PM-Kanal, der nur mit den nötigsten GA verbunden ist und diese auch nur über die ETS füttern, nicht verbunden mit irgendwelchen anderen Geräten.

Aktuell kann ich mit diesem Setup das Problem, dass durch Aktorstatus=off der Ausgang nochmal angeschaltet wird, nachstellen. Allerdings bisher nur auf dem HF-Sensor mit SensorModule-big-4.2.5, noch nicht auf dem VPM im REG1 mit PresenceModule-big-3.6.2. Da muss irgendwas anders sein - oder ich hab irgendwas nicht richtig abgeglichen Hab aber den PM-Kanal über Export+Import rübergezogen.

Das Problem scheint übrigens nur aufzutreten, wenn der PM-Kanal bei Präsenz überhaupt von allein einschalten würde. Sprich Vollautomat (vermutlich auch Auto-Ein) und aktuelle Helligkeit unter der entsprechenden Grenze. Dann reicht aber wirklich auf das KO Aktorstatus 1 (damit der PM-Kanal aktiv ist) gefolgt von 0 zu senden. Danach sendet er wieder den Einschaltwert und läuft dann wieder bis zur Nachlaufzeit. Natürlich geht alternativ auch normale Präsenz auszulösen, so dass der Kanal aktiv ist, und dann Aktorstatus 0 zu senden.


/EDIT: Unter der Annahme, dass es sonst keine Unterschiede zwischen den beiden Geräten gibt die sich da auswirken - und ich beim Testen nichts falsch gemacht habe - würde ich behaupten, das muss funktioniert haben und somit eine Regression aus dem Commit sein. Bin aber noch nicht ganz durchgestiegen, wann wo welche Bits gesetzt werden

/EDIT 2:
Hier nochmal der Konfig-String für den VPM-Kanal, der bei mir als Test ausreicht:

OpenKNX,cv1,0xA012:0x42/PM:0x36/3§p~Name=Test§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~PresenceDelayBase=0§pA~PresenceDelayTime=30§pA~BrightnessOn=10§pA~Output1OnDim=50§pB~PresenceDelayTime=3§pB~Output1OnDim=6§pB~Output1OffDim=1§pC~PresenceDelayTime=5§pC~BrightnessOn=5000§;OpenKNX

Wie gesagt, einfach an das KO Aktorstatus ne GA anhängen und erst 1 und dann 0 senden, dann müsste man das schon sehen (niedrige Helligkeit vorausgesetzt - hätte ich natürlich auch mal hochsetzen können ). Alternativ in aktive Präsenz gehen so dass der PM angeschaltet hat und dann wieder Aktorstatus = 0.

[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.

[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]

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

[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

[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]

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.

[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

[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

[mumpf]

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

Gruß, Waldemar