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

[willisurf]

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?

Ich weiß nicht genau, wie Du das meinst. Das Problem könnte entstehen, wenn Sperren und Schalten im VPM so bearbeitet wird, das zuerst gesperrt wird und dann geschaltet, bzw. beim Ausschalten noch gesperrt geschaltet wird, das Schalten nicht durchkommt und dann erst im nächsten Berechnungsdurchlauf entsperrt wird. Ob das wirklich passieren könnte, kann nur mumpf sagen. Ist aber jetzt vielleicht auch nicht mehr relevant, da ja wahrscheinlich ein Bug vorhanden ist.

Daher mach mal bitte den Test mit dem invertieren über Logik und Umstellen auf Sperren bei 1. Und ja, Nachlaufzeit auf mind. 1s stellen.

[willisurf]

So, jetzt mit frischem Kopf: Der VPM hat einen Bug, wenn die Polarität der Sperre negiert (Sperre aktiv bei"0") wird. Es führt sogar dazu, das das Sperrensignal toggelt und den Bus mit Botschaften flutet. Danke baba2k für die Fehlermeldung und das Issue!

baba2k Workaround daher: Die Polarität der Sperre in jedem Fall auf Defaulteinstellung (Sperre aktiv bei "1") lassen, Sicherheitshalber bei den Nachlaufzeiten wie bereits erwähnt den Wert 0 vermeiden und z.B. 1s einstellen und ggf. auch nochmal mit dem Wert beim Ausschalten aktuellen Zustand senden experimentieren, falls es noch Probleme geben sollte. Wahrscheinlich genügt es aber die Polarität der Sperre zu wechseln.

mumpf wird sich nach seinem Urlaub ab Mitte September das Issue und den Bug anschauen und dann wird es einen Fix geben.image.png

[oyster]

Moin. Wie wäre denn das erwartete Verhalten beim Logikmodul in folgendem Fall (bewusst ein minimales Beispiel):

• Ein Eingang, ein Ausgang (ODER)
• Eingang DPT1.x
• Ausgang DPT1.x
• Signalverarbeitung: Zyklisch senden bei EIN-Telegram alle 10 Sekunden
• Rest ist alles default

Ich wäre jetzt davon ausgegangen, dass ich alles 10 Sekunden das Ergebnis der Logik auf dem Ausgang bekomme UND auch sofort bei einem neu eingehenden Wert. Das Verhalten ist aber so, dass ich lediglich zyklisch (alle 10 Sekunden) das Ergebnis auf dem Ausgang bekomme. Wenn sich der Eingang ändert bekomme ich das neue Ergebnis erst mit dem neuen Zyklus und nicht sofort auf den Ausgang.

Soll das so sein, mache ich etwas falsch oder ist das ein Bug?

[willisurf]

10 Sekunden das Ergebnis der Logik auf dem Ausgang bekomme

bei der Einstellung wird nur das EIN Telegramm zyklisch wiederholt.

Aber zeige bitte mal als Screenshot/Konfigstring die Konfiguration und kurz einen Gruppenmonitorauszug. Textlich ist das häufig schwierig.

Siehe auch

[oyster]

bei der Einstellung wird nur das EIN Telegramm zyklisch wiederholt.

Das ist mir bewusst und auch so gewollt (in meinem realen Use Case verwende ich einen Trigger, ich habe nur versucht das Beispiel so minimal wie möglich zu halten).

Aber zeige bitte mal als Screenshot/Konfigstring die Konfiguration und kurz einen Gruppenmonitorauszug. Textlich ist das häufig schwierig.

Anbei die Screenshots. Was mir dabei noch aufgefallen ist: Da ich auf Eingang 0 keine zyklische Wiederholung habe kommt hier bei jedem Senden auf den Eingang sofort ein Telegramm auf dem Ausgang. Wenn auf den Eingang eine 1 sende kommt bei der Änderung von 0 auf 1 sofort ein Telegram auf den Ausgang, aber nicht, wenn vorher schon eine 1 auf dem Eingang angelegen hat, dann kommt es nur mit der zyklischen Wiederholung. Bei meinem realen Use Case verwende ich einen Trigger (also immer Ein) und andere DPTs plus eine Benutzerformel, daher ist mir das nicht aufgefallen zunächst.

[mumpf]

oyster: Das ist ein guter Punkt. Wenn alle Wiederholungen durchgelassen werden, sollte beim zyklisch senden auch jedes Telegramm durchkommen. Das ist logisch und konsequent.
Wenn man das nicht will, kann man das durch den Wiederholungsfilter unterdrücken.
Ich schau mir das nach meinem Urlaub an und werde das entsprechend anpassen.

Gruß, Waldemar

[willisurf]

Wenn Waldemar das so sagt, stand hier bei mir Quatsch und ja mit dem Wiederholungsfilter ist es dann universell.

[oyster]

Super Sache. Danke euch. Bis dahin lebe ich mit meinem Workaround einer zweiten Logik.

[baba2k]

Hallo willisurf, es scheint so als sind alle Probleme behoben, wenn ich über Logik negiere und die normale Sperre verwende!

Ich habe aber eventuell noch was gefunden: Nach einem Restart vom RaumController schaltet der HF Kanal immer kurze Zeit ein (auch wenn keiner im Raum ist) und dann schaltet auch der HF+PIR Licht PM-Kanal das Licht ein, obwohl der HF Sensor eigentlich garnicht einschalten kann/darf.

image.png
Gibt es ansonsten noch die Möglichkeit, die Sperre nach dem Neustart auf die Rückmeldungs GA vom LED Controller zu setzen? Damit der PM-Kanal gesperrt ist, wenn das Licht aktuell aus ist?

LG baba

[willisurf]

es scheint so als sind alle Probleme behoben, wenn ich über Logik negiere und die normale Sperre verwende!

Sehr gut!

Nach einem Restart vom RaumController schaltet der HF Kanal immer kurze Zeit ein (auch wenn keiner im Raum ist)

Soweit ich mich erinnere ist das normal.

dann schaltet auch der HF+PIR Licht PM-Kanal das Licht ein, obwohl der HF Sensor eigentlich garnicht einschalten kann/darf.

Ist zwar ein seltener Fall, der im normalen Betrieb kaum auftritt (allenfalls beim Programmieren) aber merkwürdig ist, das er einschaltet, obwohl das in der Applikation deaktiviert ist. Schauen wir auch nochmal mit an.

Gibt es ansonsten noch die Möglichkeit, die Sperre nach dem Neustart auf die Rückmeldungs GA vom LED Controller zu setzen? Damit der PM-Kanal gesperrt ist, wenn das Licht aktuell aus ist?

Ich bin überhaupt kein Freund von diesen Sperren und das ist schon irgendwie eine ungewöhnliche Konstellation. Versuch es einfach, wenn Du es so haben möchtest und beobachte das Verhalten im Gruppenmonitor. Du kannst bei den Eingängen auswählen, das der Status der Sperre nach einem Neustart eingelesen wird.

[mumpf]

baba2k: Ich hab gerade etwas Leerlauf, ich versuch mal, ein paar Denkanregungen für Dein Szenario anzubieten. Auch um eine Alternative zu den Sperren zu bieten.

• Frau möchte gerne die Automatik in bestimmten Situationen ausschalten, indem sie das Licht aktiv über einen Taster ausschaltet -> PM soll gesperrt werden
• Frau möchte gerne die Automatik in bestimmten Situationen wieder anschalten, indem sie das Licht aktiv über einen Taster einschaltet -> PM soll entsperrt werden

Das will mir nicht in den Kopf. Natürlich darf Deine Frau das wollen und ich werde zusehen, die Sperren zu reparieren, damit das auch geht. Aber das deckt doch nicht wirklich die Alltagsfälle ab?

• Licht ausschalten, um einen gemütlichen Abend bei Kerzenschein zu haben - prima.
• Licht ausschalten, weil es beim Fernsehen stört - prima.
• ABER: Licht ausschalten, weil es morgens bereits hell genug ist - willst Du dann wirklich abends erstmal einschalten müssen, wenn Du den Raum betrittst?
• ODER: Es ist subjektiv zu dunkel und man schaltet manuell ein, ohne dass es automatisch passiert ist. Automatik ist aktiv und schaltet wieder aus, weil es etwas heller wurde. Das nervt doch, oder?

Für so was gibt es den Eingang "Automatik übersteuern". Hier teilt man dem PM mit, dass man das Licht eingeschaltet hat (auch wenn der PM das nicht machen würde) oder dass man es ausgeschaltet hat (auch wenn der PM das anlassen würde). Von jetzt an passt er auf, ob er Präsenz feststellt und behält den Zustand, solange Präsenz (+Nachlaufzeit) vorhanden sind. Damit hast Du Deine Sperre (den Benutzerwunsch), aber beim verlassen des Raumes wird diese wieder automatisch aufgehoben. Das ist ein Beispiel.

Ich weiß nicht, wie das bei euch mit mehreren Lichtkreisen ist, aber in der Küche, Esszimmer, Wohnzimmer, Badezimmer hab ich min. 4 Lichtkreise. Der PM schaltet immer ein Hauptlicht ein (das ist raumspezifisch, können 1 oder mehrere Lichtkreise sein), ich komme damit auf keinen Fall in einen dunklen Raum. Je nach Stimmung kann ich dann andere Lichtkreise am Taster wählen. Licht AUS über PM bedeutet immer ALLE Lichtkreise aus. Das gleiche, was der PM macht (Hauptlicht EIN, alle Lichter AUS) kann ich per Patch auf dem MDT-Taster machen, das ist aber auf einer eigenen GA - das ist dann ein Benutzerwunsch. Man kann also dem Melder mitteilen, wie der Benutzerwunsch ist.

Dann gibt es noch den Eingang "Manuell übersteuern", der sagt mehr oder minder: Ich will, dass Du in dem Zustand bleibst, in dem Du jetzt bist (alle Automatiken aus). Der hat auch eine Rückfallzeit und kann sogar präsenzabhängig ausgeschaltet werden.

Es gibt eigentlich genug Möglichkeiten, dem Melder den aktuellen Wunsch des Benutzers mitzuteilen.

Dadurch das "Automatik übersteuern" so lange an bleibt, wie Präsenz da ist, erreicht man das gleiche wie mit der Sperre - aber nur so lange, wie man im Raum ist. Danach beginnt das Spiel von neuem. Und man hat nicht das Problem, dass man in einen dunklen Raum kommt, weil der Melder noch gesperrt ist.

Damit Nachts auf keinen Fall das Licht angeht, würde ich in der Nachtphase mit Halbautomat arbeiten. Der hat den Vorteil, dass er das Licht zwar nicht anmacht, aber - falls durch irgendwas Licht angemacht wurde, z.B. durch einen manuellen Wunsch - dieses wieder ausgemacht wird.

Vielleicht bringt Dich das noch zum auf Ideen,
Gruß, Waldemar