OpenKNX-VirtualPresence - entsperren klappt nicht zuverlässig

[Sven1234]

Hallo zusammen!

Ich hatte das Problem, dass meine VPMs häufig nicht entsperren. Entsperren läuft über einen Szeneneingang.

grafik.png
Die Szene wird beim Verlassen des Hauses durch einen Glastaster gesendet. Das Senden funktioniert auch zuverlässig. Aber die Sperre wird nicht zuverlässig aufgehoben.

Zusätzlich zu den VPMs habe ich auch noch eine Logik, die auf Szene 5 reagiert und dann Szene 64 sendet.

grafik.png

Diese Szene schaltet alle Lichter aus. Die "Lösung" war, dass ich die Logik mit einer Verzögerung senden lasse. Seitdem klappt es einwandfrei, allerdings ist die Verzögerung ärgerlich, da man keine direkte Rückmeldung beim Betätigen des Tasters bekommt (Licht aus).

Außerdem verstehe ich nicht, weshalb das Entsperren nicht funktioniert, da die Szene 5 ja definitiv am Modul ankommt und etwas - d.h. die Logik - auslöst. Weswegen wird also nicht die Sperre für die VPMs zuverlässig deaktiviert? Ist ja auch nicht so, dass die VPMs etwas bei Szene 64 tun.

Was mache ich falsch?

grafik.png

[willisurf]

Was mache ich falsch?

Vielleicht gar nichts, es kann immer noch mal einen Bug geben.
Wir hatten in dem Bereich schon einen Bug
https://knx-user-forum.de/forum/projektforen/openknx/2030505-vpm-szenen-werden-nicht-übernommen?p=2030691#post2030691

Um das besser einsortieren zu können, wäre es schön, wenn Du nochmal kurz die verwendete Hardware und genaue Softwareversion mitteilst (3.6 der Applikation habe ich oben im Bild gesehen).
Und ideal wäre noch ein Screnshot der GA Zuordnung und der Einstellung der Sperre. Vielleicht auch ein (gern gefilterter) Gruppenmonitorauszug, bei dem man sieht das die Szene gesendet wird, aber der Status des VPM gesperrt bleibt.

Parallel versuche ich das schon mal so nachzustellen. Ggf. sind die Zusatzinfos dann gar nicht mehr notwendig.

[willisurf]

In einem ersten Test konnte ich das nicht nachstellen. Ich schaue aber weiter.

[willisurf]

Test mit PresenceModule-Big-3.6.4 auf PiPico, Fehler ist so nicht nachstellbar. Daher bräuchte ich noch mehr Infos.

image.pngimage.pngimage.png
image.png

[Sven1234]

Danke für die Bemühungen!

OpenKNX Reg1 mit 3.6.2 drauf, laut git das aktuelle Release.

GA Zuordnung:
grafik.png
grafik.png
Rest folgt.

[willisurf]

Die GA 0/3/40 wird sowohl vom VPM Ausgang gesendet, als auch zur Steuerung des VPM benutzt. Das kann problematisch sein, wenn man die gesendeten Szenen nicht sauber trennt.

Sende daher bitte auch mal die Ausgangskonfiguration aller Tagesphasen mit.
Der Gruppenmonitor Auszug ist daher auch wichtig, aber das meintest Du wahrscheinlich mit der Rest folgt.

Ggf. mache ich nochmal ein Downdate auf die 3.6.2, das ist kein Problem.

P.S.: Warum wird die gleiche GA (0/3/40] sowohl von Ausgang1 als auch Ausgang2 gesendet?
Das dann bei einer GA mindestens 2x das L-Flag gesetzt ist, ist dann eher ein Schönheitsfehler (sollten ja beide den gleichen Wert senden).

[Sven1234]

Tagesphasen:
grafik.png
grafik.png
grafik.png
Dieselbe GA ist für beide Ausgänge gesetzt, da ich in manchen Räumen zwei Szenen an den Raum senden möchte, z.B. hier:
grafik.png
Gruppenmonitor, wenn es nicht funktioniert:
grafik.png

Gruppenmonitor, wenn es manchmal funktioniert, auch ohne Verzögerung der Logik:

grafik.png

[willisurf]

Danke, von den gesendeten Szenen her über die Tagesphasen ist das sauber entkoppelt.

Wenn ich mir den Gruppenmonitorauszug vom niO Fall ansehe, fällt auf, das auf dem Bus viel los ist und gleichzeitig auf der 0/3/0 direkt nach der Szene 5 als übernächste Botschaft bereits die Szene 64 gesendet wird. Ggf. kommt es zu Zuständen, das die Szene5 noch nicht verarbeitet wurde (wird ja nicht entsperrt) und vor der Verarbeitung bereits von der Szene64 überschrieben wird.

Versuche mal beim Senden der Szene64 eine Verzögerung (100ms sollten genügen) einzubauen. Geht ja mit den Logikkanälen recht einfach.

[mumpf]

Erstmal vielen Dank für Deine Analyse und Hilfe, Bernhard.

Sven1234: Ich möchte ergänzend zu Bernhards Analyse nur noch sagen, dass ich keine Möglichkeit sehe, Dir hier durch Änderungen der Firmware zu helfen. Du sagst ja selber - mal geht es und mal nicht. Und wenn Du die Szene 64 um 5 Sekunden verzögerst, dann geht es. Damit hast Du ein Timing-Problem. Du sendest die Telegramme zu schnell auf den Bus.
Ich habe nicht umsonst im Logikmodul die Möglichkeit geschaffen, Telegramme in 1/10s Schritten zu verzögern. Denn eine kurzzeitige Telegrammflut (ich nenne das Telegramm-Burst) kann den Bus überfordern, selbst wenn man sonst eine geringe Buslast hat.
Auch die Annahme, dass man 2 Szenen direkt hintereinander auf einer GA senden kann und beide was bewirken (Dein Beispiel mit 2 verschiedenen Szenen auf 2 Ausgängen), wird (vermutlich) nur zuverlässig funktionieren, wenn die beiden Szenen von 2 unterschiedlichen Geräten ausgewertet werden.
Meiner Meinung nach hast Du schon die korrekte Lösung gefunden (Verzögerung der Szene 64), nur muss das nicht um 5 Sekunden geschehen, es kann eventuell schon eine 1/2 Sekunde reichen. Das musst Du allerdings ausprobieren, wie weit Du runtergehen kannst.

Gruß, Waldemar

[willisurf]

Auch die Annahme, dass man 2 Szenen direkt hintereinander auf einer GA senden kann und beide was bewirken (Dein Beispiel mit 2 verschiedenen Szenen auf 2 Ausgängen), wird (vermutlich) nur zuverlässig funktionieren, wenn die beiden Szenen von 2 unterschiedlichen Geräten ausgewertet werden.

Und selbst dann ist das unschön und könnte abhängig von der Firmwareimplementierung immer noch schief gehen (wenn die Reihenfolge getauscht wird). Das ist keine gute Parametrierung.

[Sven1234]

Danke für die Erklärungen. Dass das eine Funktion statt eines Fehlers sein soll, bzw. so arbeitet wie entworfen, fällt mir schwer zu verstehen.

Ein Gerät empfängt eine Szene und statt sie bis zu Ende abzuarbeiten, bricht es die Bearbeitung ab, da es eine andere Szene empfängt? Verstehe ich ggf. wenn die Szene auf dieselbe Komponente (nicht Gerät) wirkt, also wenn der VPM sowohl auf 5 als auch auf die 64 reagieren müsste. Dann könnte man argumentieren, dass die neue Szene die Abarbeitung der ersten abbrechen sollte. Dem ist aber nicht so.

Logik-Geräte müssen doch in der Lage sein viele Szenen auswerten zu können, ohne mittdendrin abzubrechen, nur weil die nächste Szene kommt. An diesen Geräten laufen doch per Definition viele relevante Szenen/Infos zusammen.

[traxanos]

Das Problem ist, dass das Empfangen eines Werte nicht gleich ausführen bedeutet. Es bedeutet das der laufende KNX Stack den Wert in eine Variable und diesen auch unabhängig der eigentlichen Firmwarelogik wieder auf dem Busgeben könnte (wenn ein Read rein kommt und die Flags passen).

Die Firmware schaut dann in regelmäßigen Abständen wie der aktuelle Wert ist. Wenn jetzt 2 Werte so schnell rein kommen, kann es sein das die Firmware keine Chance hatte den ersten Wert zu lesen. Das ist nicht nur bei uns so der Fall, sondern hab ich auch schon bei anderen Geräten beobachtet.

[Sven1234]

Wenn man mit Verzögerungen arbeiten muss, dann wäre es doch hilfreich, wenn man auch bei den VPM-Ausgängen eine Verzögerung einstellen könnte, zumindest zwischen Ausgang 1 und 2. Oder übersehe ich diese Möglichkeit in der 3.6.2?

[Sven1234]

Die Firmware schaut dann in regelmäßigen Abständen wie der aktuelle Wert ist. Wenn jetzt 2 Werte so schnell rein kommen, kann es sein das die Firmware keine Chance hatte den ersten Wert zu lesen. Das ist nicht nur bei uns so der Fall, sondern hab ich auch schon bei anderen Geräten beobachtet.

Ja, aber in diesem Fall wird die 5 ja vom Gerät "akzeptiert", denn es passiert etwas, die Logik löst aus. Damit ist die Info nicht mehr nur an einem Ort, an dem regelmäßig nachgeschaut wird, sondern bereits intern und in Verarbeitung.

Wenn die 5 gar nicht bearbeitet werden würde, da die 64 zu schnell käme, könnte ich der Logik folgen, aber genau das habe ich ja dadurch ausgeschlossen, dass dasselbe Gerät die Logik sendet. Es muss also erst die 5 ankommen, da es sonst keine 64 gibt.

[willisurf]

Wenn man mit Verzögerungen arbeiten muss, dann wäre es doch hilfreich, wenn man auch bei den VPM-Ausgängen eine Verzögerung einstellen könnte, zumindest zwischen Ausgang 1 und 2.

Das ist schon ein sehr spezieller Sonderfall. Dafür sind ja bewusst die 99 Logikkanäle mit integriert, um so etwas abzudecken.

Würde man alle Spezialfälle mit in die Firmware integrieren, wäre sie nochmals größer, alle hätten deswegen längere Programmierzeiten und vor allem würde es sehr unübersichtlich werden. Daher achtet Waldemar zurecht darauf nur generische und grundlegende Funktionalitäten zu integrieren. Und auch das ist ja bei den Modulen schon mehr als reichlich…
Es muss eben auch performant und beherrschbar bleiben, eine übersichtliche Applikation ist ein hohes Gut.