OpenKNX-VirtualPresence release (VPM)

[mumpf]

Die einzige Schwierigkeit ist, das bei Senden nach Änderung auch das Maxwertfilter verkürzt wird und damit ggf. ausgehebelt wird.

Aber natürlich, das ist ja das Ziel . Im AUS-Fall will ich ja nicht den MAX-Wert (der ja noch sagt, es ist hell) haben, sondern den aktuellen Wert. Deswegen ja mein Vorschlag mit einem Read zu arbeiten. Der Triggert dann erneut die MAX-Wert-Bildung als MAX(dunkel, dunkel) = dunkel. Und das ist genau das, was wir in dem Fall wollen, oder?

Gruß, Waldemar

[willisurf]

Ja genau Waldemar. Die einzige Schwierigkeit ist, das bei Senden nach Änderung auch das Maxwertfilter verkürzt wird und damit ggf. ausgehebelt wird. Wir müssten irgendwie noch einen Weg finden, das Abschalten des VPM Kanals mit in die Helligkeitsauswertung einzubinden (dieses Signal macht ja den Unterschied der Szenarien).
Oder den Maxwertfilter auf eine feste zeitliche Taktung umzustellen, aktuell ist er ja über die gesendete Helligkeit getaktet.

[mumpf]

Ahh, Bernhard, jetzt verstehe ich: Du plädierst dafür, die Glättung bei Michael komplett durch Deine MAX-Funktion zu ersetzen. Und auch minütlich die Helligkeit senden lassen. Für Michaels fall würde das bedeuten, dass das Licht aus bleibt, falls das Bad innerhalb einer Minute erneut betreten wird.
Das würde auf jeden Fall helfen, denke ich.
Und Du kannst im AUS-Fall ja immer noch über eine Logik ein Read auf die Helligkeit schicken und bekommst den aktuelle Wert, solange Du senden bei 5% auch drin lässt.

Gruß, Waldemar

[willisurf]

Dann hier schon mal ein Sneak Preview, wie das wirkt.
Grün Helligkeit vom BWM55, orange nach dem Maxwertbildner, rot gekennzeichnet ein Abdunkeln durch Vorbeigehen.
IMG_9698.jpg

[c4orbi]

Ich bin auf die genauere Beschreibung schon gespannt , denn diese Anwendungsfälle hab ich auch öfter hier im Haus.

[willisurf]

Wird vermutlich durch das zu langsame Filtern erzeugt, sodaß die Helligkeit der Raumlichtquelle noch zu lange nachwirkt.
Nur alle 10min die Helligkeit zu senden ist sehr langsam für den Filter, auch wenn man bei Änderung zusätzlich sendet (wirkt ja wie beschrieben wahrscheinlich nur einmalig).
Bei mir wird die Helligkeit zyklisch alle 60s gesendet und dann braucht man schon diesen Maxwertbildner, damit das Licht nicht bei Helligkeit angeschaltet wird, nur weil man in einem ungünstigen Moment (kurz vor dem Senden) am BWM vorbeigelaufen ist. Mit diesem Filter wird 1min zuverlässig überbrückt.

[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

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

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

[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

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

[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

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

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

[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