OpenKNX-RaumController release - oder: Aus dem Sensormodul wird ein RaumController

[baba2k]

Erste Erkenntnis: Licht ist gerade an und geht nicht mehr aus, aber Sperre ist scheinbar nicht aktiv
image.pngLG baba

[willisurf]

Ok, schon mal gut. Im Status fällt auf, das der PM intern ausgeschaltet hat oder ist (N0). Daher schaltet er nicht nochmal aus.
Gleichzeitig fällt auf, das der Bus recht gut mit der Entfernung ausgelastet wird. Einfach mal probeweise die GA von dem KO Entfernung lösen. Und weiter den Status des PM auch in Bezug auf Ein (N1) bzw. Aus (N0) beobachten.

[baba2k]

Noch eine Erkenntnis: Der PM-Kanal hat das Licht heute morgen einfach eingeschaltet, obwohl die 14 Stunden Rückfallzeit noch nicht erreicht waren und hat es dann nie wieder ausgeschaltet.

image.png

//EDIT: Die Entfernung habe ich jetzt mal raus genommen. Ich hoffe aber nicht, dass das schon zu viel für den Bus ist

[baba2k]

Jetzt hat er wieder das Licht nicht ausgeschaltet und antwortet auch nicht auf meine Diagnose Anfrage
image.png

LG baba

[willisurf]

Noch eine Erkenntnis

Ich vermute mal, das wir die Ursache bei Dir sehr gut mit dem regelmäßigen Auslesen des Diagnosestatus einkreisen können. Am besten bei unerwarteten Zuständen immer auslesen. Dann bekommen wir die Ursache sicher raus.

Bei der Entwicklung und den Tests des VPM habe ich das direkt mit einem iPad gemacht. EasyKNX als App ist da genial, geht aber natürlich auch mit dem Gruppenmonitor. Allerdings hat man den nicht immer gleich zur Hand, wenn etwas auffällt, auch wenn bei mir der Rechner mit Gruppenmonitor manchmal tagelang gelaufen ist (mit der ETS 5 ging das noch, SCNR).

[willisurf]

antwortet auch nicht auf meine Diagnose Anfrage

Da ist etwas sehr ungewöhnlich. Entweder hohe Buslast (immer noch?!) oder das Gerät hat ein Problem.
Gib bitte mal den Diagnosebefehl „watchdog“ ein, wenn er wieder ansprechbar ist.

[baba2k]

Die Buslast ist extrem niedrig, ich habe eben alle zyklischen Telegramme und die Entfernung im HF ausgestellt. Er ist jetzt garnicht mehr ansprechbar und lässt sich auch nicht mehr Programmieren (ich wollte auf 5s Nachlaufzeit gehen) oder Neustarten, das hatte ich so noch nie.

Wie gehe ich jetzt am besten vor? Auf den Diagnosebefehl watchdog reagiert er auch nicht.

image.png
LG baba

[mumpf]

Hab das hier gerade gesehen... Wenn der Melder über den Bus nicht erreichbar ist, dann musst Du ihn leider stromlos machen (also vom Bus trennen) oder die Reset-Taste drücken. Hast Du unter OpenKNX->Erweitert den Watchdog aktiviert? Der macht das nämlich von sich aus, wenn das Gerät hängt, automatisch. Allerdings betreibe ich die PM bei mir ohne Watchdog und hatte schon ewig keinen Hänger.

Gruß, Waldemar

[baba2k]

Danke mumpf, das ist tatsächlich bei mir auch das allererste mal, dass sowas passiert. Ich habe jetzt den ganzen Bus stromlos gemacht, ich komme da nicht so gut dran. Der Watchdog war aktiviert, da es in den Standardeinstellungen so konfiguriert ist

//EDIT: Ich habe jetzt die Nachlaufzeit von Kanal 2 auf 5 Sekunden gesetzt

[mumpf]

Dann hast Du eine Situation gehabt, die ich noch nie hatte... Der Watchdog hat bisher alle "Hänger" durch einen Neustart gelöst. Gerät nicht erreichbar mit eingeschaltetem Watchdog verstehe ich derzeit nicht.
Ich sehe derzeit 2 wesentliche Probleme bei Dir:

1. Die nicht korrekt funktionierende Sperre, das wird sich lösen lassen (wenn auch erst nach meinem Urlaub, außer willisurf findet vorher was)
2. Hänger, die der Watchdog nicht lösen kann - da hab ich im Augenblick keine Idee... aber derzeit auch nicht den Kopf dafür.

Gruß, Waldemar

[baba2k]

Nach dem Neustart war die Sperre aktiv, dann habe ich das Licht über den Glastaster eingeschaltet, aber die Sperre ist aktiv geblieben und das Licht bleibt dauerhaft an. Das Hochstellen der Nachlaufzeit auf 5s hat also nicht geholfen
image.png

[willisurf]

Ich schaue mir heute Abend mal die Sperre an, wenn die Polarität so eingestellt ist, wie bei Dir.

[baba2k]

Danke willisurf! Ich habe es mal von Claude analysieren und ein Issue + PR erstellen lassen, hilft dir das oder ist das quatsch?

Issue: https://github.com/OpenKNX/OFM-PresenceModule/issues/22
PR: https://github.com/OpenKNX/OFM-PresenceModule/pull/23

Liebe Grüße
baba

[willisurf]

Ich habe es mal von Claude analysieren und ein Issue erstellen lassen, hilft dir das was oder ist das quatsch?

Danke für Deine Mühe, aber das ist hier für mich erstmal nicht relevant.
Bei so etwas teste ich dann lieber konventionell.
Ggf. gibt es aber für Waldemar Hinweise nach seinem Urlaub.

Erkenntnisse bis hier: Die Sperre funktioniert auch im invertierten Zustand normal, interessant sicher für mumpf auch die invertierte Sperre ist nach einem Neustart erstmal inaktiv, also erwartungskonform.
Ich habe nochmal weitergetestet, bin mir da jetzt nicht mehr so sicher....ich schaue mal Morgen weiter.

Aber warum es so mit Schalten und Sperren "gleichzeitig" nicht zuverlässig funktionieren kann, ist m.E. trotzdem erklärbar. Die Sperre sperrt das Ausgangssignal des VPM und nach dem Entsperren werden -so ist es eingestellt- keine Schaltungen nachgeholt. Dadurch könnten je nach Verarbeitung Schaltungen (auch AUSschaltungen) "verloren" gehen. Generell halte ich daher das Konstrukt mit einer GA zu Schalten und gleichzeitig zu Sperren nicht für robust. Aber ich mag Sperren ja sowieso nicht.
Du könntest natürlich mal versuchen, beim AUSschalten der Sperre "aktueller Zustand" zu wählen und auch weiter mit der Diagnose beobachten. Und auf jeden Fall beim Nachlauf weiterhin mind. 1s einstellen.

Ansonsten wäre der Umbau auf Halbautomat die bessere Lösung und ich denke damit lassen sich Deine Anforderungen trotzdem umsetzen, wenn man noch die Eingänge "Automatik übersteuern" und "Manuell übersteuern" nutzt. Das müssen wir dann nochmal gemeinsam sehen.

Man sollte nicht zu schnell schreiben. Die Sperre verhält sich invertiert merkwürdig. Ich war verwirrt, weil Diagnose und Reaktion nicht zusammenpassten. Ich muss mir das auf jeden Fall nochmal ansehen. Bitte invertiere mal den Schaltbefehl über einen Logikkanal und stelle die Sperre zu Testzwecken auf die "normale" Logik gesperrt bei "1" um.

[baba2k]

Danke willisurf!

Erkenntnisse bis hier: Die Sperre funktioniert auch im invertierten Zustand normal, interessant sicher für mumpf auch die invertierte Sperre ist nach einem Neustart erstmal inaktiv, also erwartungskonform.
Ich habe nochmal weitergetestet, bin mir da jetzt nicht mehr so sicher....ich schaue mal Morgen weiter.

Laut https://github.com/OpenKNX/OFM-Prese...annel.cpp#L553 wird immer mit 0 initialisiert. Demnach ist bei inventierter Einstellung der PM-Kanal nach dem Neustart gesperrt, das deckt sich auch mit meinen Beobachtungen.

Aber warum es so mit Schalten und Sperren "gleichzeitig" nicht zuverlässig funktionieren kann, ist m.E. trotzdem erklärbar. Die Sperre sperrt das Ausgangssignal des VPM und nach dem Entsperren werden -so ist es eingestellt- keine Schaltungen nachgeholt. Dadurch könnten je nach Verarbeitung Schaltungen (auch AUSschaltungen) "verloren" gehen. Generell halte ich daher das Konstrukt mit einer GA zu Schalten und gleichzeitig zu Sperren nicht für robust. Aber ich mag Sperren ja sowieso nicht.
Du könntest natürlich mal versuchen, beim AUSschalten der Sperre "aktueller Zustand" zu wählen und auch weiter mit der Diagnose beobachten. Und auf jeden Fall beim Nachlauf weiterhin mind. 1s einstellen.

Das Schalten sollte eigentlich der Taster über GA 1/1/1 direkt übernehmen und der PM muss eigentlich nur Sperren/Entsperren oder verstehe ich das falsch?
Muss die Nachlaufzeit auch >= 1s sein, wenn PIR unf HF jeweils 30s Nachlaufzeit haben?

Ansonsten wäre der Umbau auf Halbautomat die bessere Lösung und ich denke damit lassen sich Deine Anforderungen trotzdem umsetzen, wenn man noch die Eingänge "Automatik übersteuern" und "Manuell übersteuern" nutzt. Das müssen wir dann nochmal gemeinsam sehen.

Wie würdest du das umsetzen? Die Nachtphase auf Halbautomat umstellen und dann mit 1/1/1 zwischen Tag und Nacht umschalten? Bei mir ist Tag = 0 und Nacht = 1, das müsste ich dann zumindest für diesen PM-Kanal invertieren.

Liebe Grüße
baba