Wie verhindere ich eine Schleife?

[Morg]

Das hast du zumindest schöner geschrieben als ich auch wenn ich die Lösung mit zwei Items - für mich - so nicht würde umsetzen wollen, siehe meine Ausführungen oben.

Ich glaube, sein ursprüngliches Problem war die Befürchtung, dass die Status-Rückmeldung - über den Visu-Taster? - wieder einen Schließvorgang auslöst. Das wäre nur über den Visu-Taster wohl nicht der Fall, bei einem kombinierten Item müsste man das (da nicht Aktor und Sensor über KNX angebunden sind) ggf. per eval sperren.

Das andere Thema:
Um eine aktuellen Status zu haben, könnte man auch im Schalt-Item einen "Timer" einbauen (ggf. per Logik), der nach x Sekunden (5?) prüft, ob sich das Status-Item geändert hat, und wenn nicht, wird das Schaltitem zurückgesetzt. Dann wäre der Status ggf. einige Sekunden falsch, aber er würde dann wieder für einen korrekten Status (und Schließzustand) sorgen.

[henfri]

Hallo,

danke für Eure Antworten.

[LIST][*]Du hast ein Schloss, dass bei 1 schließt und bei 0 öffnet (dass es über MQTT angebunden ist, machen wir später)[*]Du hast ein Status, dass Dir angibt, ob die Tür verschlossen ist (1) oder nicht verschlossen (0). Hat nichts mit geöffnet oder geschlossen zu tun (also dem Türblatt), sondern nur mit dem Schloss.

(ich sehe weiter unten, dass du es wohl richtig verstanden hast. Aber nur um es klar zu stellen es gibt drei Dinge, die überwacht werden könnten:

1) Tür (blatt) steht offen --> nicht vorhanden
2) Schloss ist verriegelt (aber keine Aussage ob in der Falle oder bei offenstehender Tür. Nur Riegel ist draußen) --> meldet das Schloss über MQTT
3) Riegel ist in der Falle --> vorhanden über Reed.

• Jemand schaltet (egal ob über Visu oder externen Taster), die Tür geht auf bzw. zu.
• Der Status "bestätigt" den Schaltvorgang nur einige Zeit verzögert.

Jetzt kommt der Fall mit "Tür ist noch offen". Jemand schaltet, die Tür soll zugehen, geht natürlich nicht. Der Status "zu" kommt also nicht. Dich stört, dass es in der Visu so aussieht, als ob es zu wäre. Dein Vergleich mit Licht

passt nicht so ganz. Es würde nur passen, wenn der Lichtaktor gesperrt wäre. Dann würdest Du in der Visu auch sehen, dass Licht an ist, obwohl es nicht angegangen ist.

Genau.

Der einfachere Weg: Zeig den Status der Tür in einem weiteren UI-Element an.

So ähnlich hatte ich das bisher. Nur dass ich ein Item hatte welches den Status angezeigt hatte und einen Schalter für Öffnen und einen für Schließen.

Alternativ (so löse ich es an einigen Stellen, dann braucht man kein zyklisches senden): Löse nach einem Schaltvorgang ein script aus, dass nach einer gewissen Verzögerung einen Read-Request auf die Status-GA sendet. Die Antwort wird dann den korrekten Status enthalten.

Ja, so hatte ich das auch überlegt.

Schuppen_neu:
  Schloss:
    geschlossen:
        type: bool
        knx_dpt: 1
        knx_cache:
              - 8/1/1    # Reed, [B]sendet zyklisch[/B]
              - 4/1/30  # Verbunden mit einem Taster der das Schloss schaltet.
          knx_dpt: 1
          
      Action_out: # Hilfsitem für MQTT.
          type: str
          mqtt_topic_out: SmartlockSchuppen/action  #Äquivalent zu knx_send.
          eval: "'unlock' if sh...geschlossen() ==0 else 'lock'"
          eval_trigger: ..Lock()
          enforce_updates: true

Der MDT pot-freie Eingang kann zyklisch senden.
So sollte das gehen, oder?

Ich glaube, sein ursprüngliches Problem war die Befürchtung, dass die Status-Rückmeldung - über den Visu-Taster?

Nee, einfach vom Reed. Sobald der Reed jetzt ne 1 sendet, wird Action_out doch wieder getriggert, oder?
Das Schloss schließt erneut (meine Sorge war, dass es öffnet. Das wäre dann die Schleife)
Ich könnte envorce_updates beim Action_out weglassen. Aber wenn dann die Tür mal auf steht und ich ein zweites mal schließen muss, sendet Action_out nicht - da es ja schon true ist.

Darüber hinaus:

• Tür ist auf
• Ich setze Schloss.geschlossen(1)
• Item ist jetzt (1) und Actioun_out sendet ein lock.
• Nach der Zyklus-Zeit des pot-freien Eingang wird Schloss.geschlossen auf 0 gesetzt.
• Action_out sendet wieder unlock

letzteres ist ja gar nicht so verkehrt in meinem Fall. Was soll der Riegel draußen bleiben, wenn die Tür offen steht.

Andere Frage:
Durch das zyklische senden wird doch jetzt Schloss.geschlossen regelmäßig auf true gesetzt. Dann wird doch auch das Schloss immer wieder schließen - auch wenn es schon geschlossen ist, oder?

Also muss enforce_updates aus, oder ich darf nicht zyklisch senden, sondern wie von Morg vorgeschlagen nach 3-4s ein read-request senden.

Um eine aktuellen Status zu haben, könnte man auch im Schalt-Item einen "Timer" einbauen (ggf. per Logik), der nach x Sekunden (5?) prüft, ob sich das Status-Item geändert hat, und wenn nicht, wird das Schaltitem zurückgesetzt. Dann wäre der Status ggf. einige Sekunden falsch, aber er würde dann wieder für einen korrekten Status (und Schließzustand) sorgen.

Der falsche Zustand für ein paar Sekunden ist kein Problem.

Ist schon beeindruckend, wie kompliziert so eine einfache Sache ist.

Gruß,
Hendrik

[Morg]

Ich würde das auf zwei Ebenen angehen:

1. die Schleife kannst du verhindern, indem du mit eval und item.last_update_by eine Aktion ausschließt, wenn die Änderung vom Reed kommt.

2. lass eine Logik auf das action_out=1 triggern, die nach 5 Sekunden den reed prüft - wenn reed=0, dann wird action_out auch auf 0 zurück gesetzt, dann bleibt der Riegel nicht offen, sondern schließt bei offenem Türblatt.