OpenKNX-VirtualPresence release (VPM)

[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

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

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]

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

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

[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

[ple]

Hallo zusammen,
mal eine kurze frage, wie habt ihr die KO Verknüpfung gemacht mit einem MDT GT2 Taster? Geht ihr mit den Ausgängen vom GT2 erst auf den Melder und dann zum Aktor? Aktuell bin ich da noch unschlüssig wie ich es machen soll, sodass man den Bewegungsmelder übersteuern kann, dieser aber nach einer x Zeit ohne Bewegung wieder zurückfällt in den Automatikmodus.

Gruß und Besten Dank für eure Unterstützung.

Sorry, ich muss hier noch mal nachhaken. Also ich versuche gerade irgendwie den GT2 Taster an den PM zu bringen, sodass dann meine 24V LEDs gedimmt werden beim Langdruck und beim Kurzdruck entweder 100% oder halt 0%. Denke damit sollte dann auch das manuelle Übersteuern starten.
Ich bin davon ausgegangen, dass ich dem PM das Dimmen vom GT2 schicken muss, der das dann weitergibt an den Aktor. Oder ist das so gar nicht gedacht, da es im PM auch Taster gibt? Ist die Idee, die GT2 Taster auf den PM zulegen auf die Tastereingänge? Also in diesem Fall Kurzdruck schalten (100% oder 0%) und Langdruck dimmen?

Hat vielleicht einer eine komplette KO Verknüpfung als Beispiel?

Gruß und Danke

[mumpf]

Ich muss nochmal ergänzen, weil Bernhard willisurf und ich über verschiedene Sachen gesprochen haben (ich hab seine erste Antwort nicht genau genug gelesen):

Ich sprach davon, dass man immer den Status des Aktors (Ausgang), der über den PM-Kanal geschaltet wird, mit dem Eingang Aktorstatus (KO 75 im Bild oben) verbinden sollte. Muss nicht ursächlich für dieses Problem sein, aber ich hatte oben gesehen, dass es nicht erfolgt ist. Würde ich immer machen. Nur dann weiß der PM, welchen Zustand Dein Licht hat.

Bernhard sprach von der Verknüpfung des Status des Aktors mit dem Eingang "Automatik übersteuern" (KO 73 im Bild oben). Das sollte man nicht machen, weil man damit dem Melder mitteilt, dass man nach dem Ausschalten immer so lange ausgeschaltet lassen will, wie die Präsenz + Nachlaufzeit noch anliegt.

Beides ist nicht die Ursache, nur eine generelle Anmerkung.

Ich glaube, ich hab das Problem gefunden (die ConfigTransfer-Strings sind prima, nochmal großes Lob)!

Das Ausschalten im obigen Gruppenmonitor-Log erfolgt nicht über die Szene vom PM-Kanal, sondern über die Logik (hatte mich über die GA 1/1/8 gewundert). Die Logik hast Du direkt mit KO 21 verknüpft, was die Präsenz-Rohdaten von HF-Sensor sind. Der Kanal vom Melder ist noch in Präsenz, vermutlich durch den PIR. Wenn Du wieder rein gehst, ist der noch in Präsenz und schaltet deswegen nicht erneut ein.

Wir können morgen gerne weiter schauen,
Gute Nacht,
Waldemar

[Sisamiwe]

Ich sprach davon, dass man immer den Status des Aktors (Ausgang), der über den PM-Kanal geschaltet wird, mit dem Eingang Aktorstatus (KO 75 im Bild oben) verbinden sollte. Muss nicht ursächlich für dieses Problem sein, aber ich hatte oben gesehen, dass es nicht erfolgt ist. Würde ich immer machen. Nur dann weiß der PM, welchen Zustand Dein Licht hat

Das habe ich nun korrigiert. Diverse Logiken kombiniert um alle Quellen zu erfassen. Das klappt!

Bernhard sprach von der Verknüpfung des Status des Aktors mit dem Eingang "Automatik übersteuern" (KO 73 im Bild oben). Das sollte man nicht machen, weil man damit dem Melder mitteilt, dass man nach dem Ausschalten immer so lange ausgeschaltet lassen will, wie die Präsenz + Nachlaufzeit noch anliegt.

Hier habe ich nun die im der Applikationsbeschreibung beschriebene Zweitastenbedienung umgesetzt.

Beides ist nicht die Ursache, nur eine generelle Anmerkung.

Richtig. Heute früh hat es auch nicht funktioniert.

Das Ausschalten im obigen Gruppenmonitor-Log erfolgt nicht über die Szene vom PM-Kanal, sondern über die Logik (hatte mich über die GA 1/1/8 gewundert). Die Logik hast Du direkt mit KO 21 verknüpft, was die Präsenz-Rohdaten von HF-Sensor sind.

Ich habe den Logik-Kanal nun "zu Testzwecken" deaktiviert. Ich beobachte mal.

Hier die aktuelle GA Zuordnung:
image.png
WIe gesagt, der Logikkanal 1 ist deaktiviert.

Besten Dank!
Michael

[mumpf]

Guten Morgen Michael,

nur zur Info: Ich gehe nicht davon aus, dass das deaktivieren der Logik das Problem löst, ich hoffe nur, dass es weitere Analyse erlaubt. Ich würde jetzt erwarten, dass das Licht länger an bleibt und irgendwann durch den PM-Kanal ausgeschaltet wird. Dann bleibt sicher noch die Frage, warum sich das anders verhält als der Präsenz-Kanal, der ja klar im Gruppenmonitor ein AUS sendet.

Zu den neuen GA:
1/1/1 gibt vermutlich an, ob irgendein Licht im Bad an ist, also das Ergebnis von einem OR aller Lichtstati, oder? Das passt. Was mich aber wundert, ist Dein Test gestern:

Das Verhalten ist mit und ohne Verknüpfung des Aktorstatus gleich.

Hattest Du da auch die 1/1/1 verknüpft? Folgendes hätte ich erwartet (noch mit der akiven Logik):

• PM triggert die Logik über Rohdaten PM AUS.
• Logik schaltet alle Lichtquellen aus
• das OR über alle Lichtquellen geht auf AUS
• das AUS geht zum Aktorstatus-Eingang vom PM-Kanal
• PM-Kanal weiß, dass jetzt alles aus ist
• nächstes EIN auf den Bewegungs-Eingang triggert den PM-Kanal und das Licht geht an

Wenn das oben nicht geklappt hat, würde ich annehmen, dass der PIR noch EIN ist beim nächsten betreten des Raumes - wie sind denn dessen Nachlaufzeiten? Ich hab ja den PIR im Verdacht, aber diese Annahme erklärt nicht, warum "Besetzt" (also der andere PM-Kanal) funktioniert.

6/1/38 führt den Ausgang vom PM auf den Eingang Aktorststus. Das bedeutet, für "Besetzt" hast Du wahrscheinlich nur eine LED und keinen weiteren Status, oder? Wenn sonst keiner die 6/1/38 schaltet, würde ich die Verknüpfung zum Aktorststus wieder wegnehmen. An sich sollte es laufen, ich bin nur jemand, der solche "Ringschlüsse" gerne vermeidet. Zumindest hab ich diesen Fall noch nicht ausprobiert... Du kannst es natürlich mal beobachten und berichten, ob das Seiteneffekte bei "Besetzt" hat.

1/1/189 und 1/1/190 - werden die irgendwie über den PM-Kanal selbst beeinflusst (auch transitiv über Logik) oder sind die einfach nur mit Tasten verknüpft? Auch hier würde ich gerne irgendwelche "Ringschlüsse" vermeiden, zumindest bis wir das andere Problem gelöst haben. Wenn nur Tasten, dann können die bleiben, falls Ringschluss, würde ich die wegnehmen, bis das Originalproblem gelöst ist (Getreu dem Motto: Nicht zu viele Variablen bei der Problemfindung auf einmal ändern).

Gruß, Waldemar

[willisurf]

Lass doch mal den Gruppenmonitor mitlaufen, dann kann man ja sehen ob der PIR noch Präsenz hat, bzw. was sonst so beim Ausschalten passiert.
Ggf. hilft auch das Diagnoseobjekt des VPM.

[Sisamiwe]

willisurf mumpf

Ich glaube, dass ich den Fehler gefunden habe. Der Nachweis steht aber noch aus.

Die Helligkeit wird auch auf den MDT PM neben der Tür bereitgestellt. Damit eine Abschattung durch Vorbeilaufen keine/nur geringe Auswirkung hat, habe ich das mit Hilfe eines Logikkanales und der Glättungsfunktion mit dem Glättungsfaktor 3 geglättet.

Die Helligkeit vom MDT PM wurde zyklisch alle 10min und bei Änderung von 5% gesendet.

Nun wurde morgens das Licht per VPM eingeschaltet, die Helligkeit steigt an und der VPM schaltet. Nachdem das Licht ausgegangen ist, ändert sich die Helligkeit nur einmal stark (Licht aus). Danach nicht mehr, so dass erst nach 10min wieder eine Helligkeit gesendet wird. Auch danach ist die geglättete Helligkeit noch über der Einschaltschwelle. Das würde das Verhalten erklären, dass der VPM immer beim ersten Mal nach längerer Zeit schaltet und danach nicht mehr.

Wie habt ihr die Glättung implementiert ohne das "Gesamtergebnis" zu verschlechtern?

Ich habe nun den Glättungsfaktor mal auf 2 geändert und das zyklische Sender der "Roh"-Helligkeit auf 20s.

Beste Grüße

[mumpf]

Ok, also selber "ausgenockt" . Aber coole Anwendung - und nachvollziehbar. Erklärt auch, warum die Rückführung des Aktorstatus nicht hilft und warum der Präsenzkanal funktioniert.

Du könntest die Glättung überlisten, indem Du für diesen Fall (Licht aus und starke Änderung der Helligkeit) einen weiteren ReadRequest auf den Helligkeitsausgang schickst, vielleicht auch ein paar mal wiederholt, das würde die Glättungskurve schneller flacher werden lassen.

Wie habt ihr die Glättung implementiert ohne das "Gesamtergebnis" zu verschlechtern?

Ich sende de Facto auch wesentlich öfter die Helligkeit, meist so zwischen 7s und 15s, je nach Raum. Erhöht natürlich die Buslast, aber noch reicht es .

Und nach und nach werde ich die klassischen PM durch unseren HF-Sensor ersetzen, da hab ich dann die Helligkeit nativ.

Gruß, Wademar

[willisurf]

Wie habt ihr die Glättung implementiert ohne das "Gesamtergebnis" zu verschlechtern?

Zu einem späteren Zeitpunkt nach dem nächsten Release schreibe ich noch etwas dazu (mit ConfigTransfer Script).

Ich habe für den Anwendungsfall:

Unterdrückung von kurzen Abdunkelungsphasen eines BWM
eine Logik (2 Kanäle), die je Abtastung den Maximalwert aus aktuellem Wert und vorherigem Wert bildet und damit ohne langsame Glättung kurzzeitige Dunkelphasen überbrückt. Zyklische Senderate für die Helligkeit zur Verwendung im VPM ist bei mir alle 60s.

Weil neue Funktionalitäten im nächsten Release dieses Beispiel übersichtlicher machen, werde ich die Logik erst danach beschreiben.
Um nur mit 2 Logikkanälen auszukommen, stecken da schon einige Kniffe drin (Danke an Waldemar für die Hinweise damals, ich hätte die doppelte Anzahl von Logikkanälen benötigt).

[mumpf]

willisurf Bernhard, bist Du sicher? Ich glaube, sein Problem ist, dass die Helligkeit zu lange zu hoch bleibt, da dürfte ein MAX nicht helfen, oder?

Gruß, Waldemar