Wie verhindere ich eine Schleife?

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

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

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.

[mumpf]

Hi Hendrik,

2 Welten zu koppeln birgt immer Herausforderungen, wie man auch hier lesen kann. Vielleicht kann ich helfen... Erstmal das, was ich bisher verstanden habe:

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

Wenn ich das bisher beschriebene verstanden habe, dann bewegen wir uns semantisch im selben Bereich wie jede Lampe oder schaltbare Steckdose:

• Es gibt ein KO (in dem Fall Item), dass das Schloss schaltet (also Dein Action_out)
• Es gibt ein weiteres KO (wieder ein Item), dass den Status ausgibt (Dein geschlossen)

Für die Visu würde ich persönlich ein weiteres Item machen, das würde ich dann auf den Status hören lassen (also auf die 8/1/1, gerne auch noch auf weitere externe Taster wie die 4/1/30 bei Dir). Das hast Du ja auch mit Lock: gemacht.

Bis dahin alles prima:

• 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

Im Gegensatz zu einem Licht (wo der von dir vorgeschlagene Weg funktioniert), funktioniert das Schloss ja nicht immer zuverlässig (wenn die Tür offen steht) so dass der zuletzt gesendete Wert nicht immer dem Status entspricht.

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.

Ganz allgemein betrachtet adressierst Du hier ein Problem, dass man immer hat, wenn ein Befehl nicht ausgeführt wird oder durch hohe Latenzen lange dauert: Du siehst einen falschen Zustand. Damit man in der Visu den echten Zustand sieht, bräuchte man eine Art Schalter mit 3 Zuständen "Aus - unbekannt - Ein". Jeder Schaltvorgang wird ausgeführt, der Schalter geht aber auf unbekannt. Auf den neuen Zustand geht er erst, wenn er die Statusinfo bekommt. Nach einer (einstellbaren) Wartezeit geht er wieder auf den vorherigen Zustand, weil dann der Schaltvorgang nicht geklappt hat.

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

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.

Gruß, Waldemar

[Morg]

So, nochmal, ich verstehe in deinen Ausführungen nur Widersprüche. Vielleicht auch aufgrund von unklarer Ausdrucksweise...

Du hast eine Schaltmöglichkeit (MQTT), um den Schlossriegel auf- oder zuzumachen ("abschließen").

Du hast einen Taster (reed), der dir zurückgibt, ob das Schloss verriegelt ist oder nicht (KNX). --> jetzt erklär bitte nochmal GENAU, was der Taster/Reed/wasauchimmer misst: ist der Schlossriegel geschlossen, oder ist das Türblatt geschlossen? Du hast oben beides verneint...

Wenn der Taster zurückgibt, ob der Riegel verschlossen ist, dann geht es mit dem Item von oben, aber ggf. musst du mit eval die "Schleifenaktion" abfangen. Das geht.

Wenn der Taster zurückgibt, ob das Türblatt geschlossen ist, dann kannst du mit einem eval im Item sicherstellen, dass das Schloss nur betätigt wird, wenn das Türblatt geschlossen ist.

Im ersten Fall würde ich den Status in das Item einkoppelt, und wie geschrieben ggf. eine Schleife per eval abfangen. Im zweiten Fall würde ich zwei Items nehmen. Dann kommt der Status aus dem Schaltitem selbst (sh.py muss sich den Status merken).

[henfri]

Hallo,

Ich denke, der Reedkontakt gibt dir an, ob die Tür auf oder zu ist? Oder woher kommt der Reed?

Der ist einfach in meiner Struktur der Items ein Reed-Kontakt. Ist aber ein Microschalter im Türrahmen der prüft ob die Tür abgeschlossen ist.

Ansonsten wäre das ggf. die sinnvollste Änderung: eine Reed-Kontakt, der dir ein Signal gibt, wenn das Türblatt geschlossen ist. Den Binäreingang hast du doch eh schon vor Ort, hat der noch einen zweiten Eingang frei?

Das ist baulich nicht ohne Staub machbar. Das lasse ich lieber.

Und eine Änderung des Status führt ja nicht zu einer Aktion, das hat doch nichts miteinander zu tun. Sonst würde doch jedesmal beim Licht einschalten die Info "Licht an" nochmal zu einem Schaltvorgang führen...

Das ist klar. Aber der Status ist ja auch normal nicht mit dem Aktor verbunden, sondern nur mit dem Taster.

Sorry, da habe ich vielleicht einen Knoten im Kopf zwischen der KNX Welt (Status und Aktion sind getrennt je eine GA bzw. kommen nur am Taster zusammen) und der Sh.py Welt (ein Item für Status und aktion).

Gruß,
Hendrik

[Morg]

Ich denke, der Reedkontakt gibt dir an, ob die Tür auf oder zu ist? Oder woher kommt der Reed?

Ansonsten wäre das ggf. die sinnvollste Änderung: eine Reed-Kontakt, der dir ein Signal gibt, wenn das Türblatt geschlossen ist. Den Binäreingang hast du doch eh schon vor Ort, hat der noch einen zweiten Eingang frei?

Und eine Änderung des Status führt ja nicht zu einer Aktion, das hat doch nichts miteinander zu tun. Sonst würde doch jedesmal beim Licht einschalten die Info "Licht an" nochmal zu einem Schaltvorgang führen...

[henfri]

Ich würde sowas wie zyklisches Abfragen vermeiden wollen, sondern auf Änderungen reagieren.

Verstehe. Aber dann darf der Befehl nicht zu einer Änderung des Status führen.

Du hast ein "Schloss"-Item, das seinen Status (gesetzt/nicht gesetzt) über den Taster bekommt. Damit weißt du, ob das Schloss auf oder zu ist.

Jetzt könntest du ggf. mit einem eval prüfen, ob die Tür geschlossen ist, und wenn die Tür nicht geschlossen ist, die Schreibänderung auf das Schloss gleich verhindern.

Ich weiß nicht, ob die Tür offen steht, oder nicht. Ich weiß nur, dass sie nicht abgeschlossen ist.

Wenn du das Betätigen des Schlosses mit dem eval blockierst, solange die Tür nicht zu ist, ist der Taster nur ne zusätzliche Sicherung, weil das Schlossitem selbst erst auf true wechseln kann, wenn das Schloss betätigt werden "darf", also würde da auch "fitkiver Status" (ich erwarte nach Betätigung, dass es zu ist) und tatsächlicher Status (Schloss ist verriegelt) immer zusammen passen.

Ja, dazu fehlt mir aber die Information ob die Tür offen steht.
Ich habe nur die Information ob Abgeschlossen oder nicht.

Gruß,
Hendrik

[Morg]

Ich würde sowas wie zyklisches Abfragen vermeiden wollen, sondern auf Änderungen reagieren.

Du hast ein "Schloss"-Item, das seinen Status (gesetzt/nicht gesetzt) über den Taster bekommt. Damit weißt du, ob das Schloss auf oder zu ist.

Jetzt könntest du ggf. mit einem eval prüfen, ob die Tür geschlossen ist, und wenn die Tür nicht geschlossen ist, die Schreibänderung auf das Schloss gleich verhindern.

Dann würde das "Verriegeln" gar nicht erst ausgelöst, wenn die Tür nicht geschlossen ist. Da brauchst du nicht zyklisch abfragen, bei einem Binäreingang bekommst du die Statusmeldung, wenn sie der Wert ändert. Aber das ist dann nur noch "jou, Schloss ist verriegelt", zB für die Statusanzeige.

Wenn du das Betätigen des Schlosses mit dem eval blockierst, solange die Tür nicht zu ist, ist der Taster nur ne zusätzliche Sicherung, weil das Schlossitem selbst erst auf true wechseln kann, wenn das Schloss betätigt werden "darf", also würde da auch "fitkiver Status" (ich erwarte nach Betätigung, dass es zu ist) und tatsächlicher Status (Schloss ist verriegelt) immer zusammen passen.

Schau mal in der User-Dokumentation bei eval, da sind auch Beispiele; ich meine auch eins, womit du die Änderung des Items (Zuweisung von false -> true) prüfen und blockieren kannst.

[henfri]

Hallo,

Ich hatte das so verstanden, dass der Reed-Kontakt den Status vom Schloss rückmeldet, nicht vom Türblatt.

Ja, das ist leider falsch. Aber ich sehe, dass ich das nicht gut beschrieben habe, sorry.

Und das, was du oben stehen hast (den Taster in knx_cache), geht so nicht, da weißt du ja nie, welchen Wert das Item gerade haben soll.

Ja, im Prinzip ist das ja das Gleiche Problem wie in der Visu. Wobei ich den betreffenden Taster auch so parametrieren kann immer eine 1 zu senden, da ich hier immer nur abschließen will.

Wenn das Schloss nicht über KNX geschaltet wird, weiß ich nicht, wie du die Trennung in einem Item umsetzen kannst.

Ist es denn wichtig, ob es über KNX geschaltet wird? Das Problem ist doch -wie ich es verstehe- ein anderes:
Im Gegensatz zu einem Licht (wo der von dir vorgeschlagene Weg funktioniert), funktioniert das Schloss ja nicht immer zuverlässig (wenn die Tür offen steht) so dass der zuletzt gesendete Wert nicht immer dem Status entspricht.
Aber wo ich das schreibe... eigentlich ist es wie ein Licht mit Treppenlicht-Automat. Da funktioniert ja das Konstrukt, da beim Abschalten durch den Aktor (Treppenlichtfunktion) der Status aktualisiert wird.

Woher bekommst du denn den Status des Schlosses? Gibt es den (zuverlässig)?

Ich habe im Schließblech (da wo der Riegel rein geht) einen kleinen Schalter, der vom Riegel betätigt wird. Der wiederum wird von einem MDT Potentialfreiem Eingang ausgewertet.


Was möglich wäre:
Scenario A) Tür steht offen --> Verriegeln schlägt fehl
Taster schickt 1 --> Lock
Status ist dadurch direkt Locked (nur ein Item)
Potentialfreier Eingang wird zyklisch abgefragt und setzt auf Unlocked

Scenario B) Tür ist geschlossen (nicht abgeschlossen) --> Verriegeln funktioniert
Taster schickt 1 --> Lock
Status ist dadurch direkt Locked (nur ein Item)
Potentialfreier Eingang wird zyklisch abgefragt und setzt auf Locked (d.h. keine Änderung)




Gruß,
Hendrik

[Morg]

Ich hatte das so verstanden, dass der Reed-Kontakt den Status vom Schloss rückmeldet, nicht vom Türblatt.

ich habe ein Motorschloss, dass ich
Haustechnik.Schuppen.Schloss.Lock
Ver/Entriegeln kann (true/false)

eg.Schuppen.Reed.Aussentuer.geschlossen gibt den Status an.

Falsch?

Und das, was du oben stehen hast (den Taster in knx_cache), geht so nicht, da weißt du ja nie, welchen Wert das Item gerade haben soll. Wenn das Schloss nicht über KNX geschaltet wird, weiß ich nicht, wie du die Trennung in einem Item umsetzen kannst.

Woher bekommst du denn den Status des Schlosses? Gibt es den (zuverlässig)?

[henfri]

Hallo,

die 4/1/30 ist der Taster, der das Schloss betätigt.
Das Schloss wird über MQTT angesteuert ("Action_out"). Das Schloss ist nicht über KNX angesteuert.

Eine Änderung von knx_cache bewirkt keinen Schreibvorgang auf den KNX-Bus, das ist ja der Witz dabei.

Da du den aktuellen Status vom Schloss (über knx_cache) ja immer da hast, kann der nächste Schreibvorgang dann auch immer der Wert sein, den du gerade brauchst. item ist false -> send true; item ist true -> send false. Das macht in der Visu jeder einfache Schalter (stateswitch).

Das verstehe ich soweit.

Bei mir wäre das dann:

Schuppen_neu:
  Schloss:
    geschlossen:
        type: bool
        knx_dpt: 1
        knx_cache:
              - 8/1/1   # Reed
              - 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

Aber:
Wenn jetzt Schloss.geschlossen=true über den Taster gesetzt wird und die Tür noch physisch offen steht (!) habe ich den Eindruck, dass die Tür abgeschlossen ist, auch wenn sie nicht abgeschlossen ist. Schloss.geschlossen gibt mir also nur den "Sollwert" nicht den tatsächlichen Wert.

Verstehst du, was ich meine?

Gruß,
Hendrik

[Morg]

Nein. Nur so, wie ich geschrieben habe. Kein knx_listen mehr.

knx_send auf das Schloss - du willst ja eine Aktion auslösen
knx_cache (beinhaltet knx_listen) auf den Reed - du willst ja wissen, was da los ist.

Der aktuelle Status des Schlosses - tatsächlich des Reed-Kontaktes - ist im Item als Wert verfügbar. Damit siehst du, ob das Schloss auf oder zu ist.

Wenn du auf das Item schreibst, geht der Wert zum Schloss und löst (ggf) eine Aktion aus.

Eine Änderung von knx_cache bewirkt keinen Schreibvorgang auf den KNX-Bus, das ist ja der Witz dabei.

Da du den aktuellen Status vom Schloss (über knx_cache) ja immer da hast, kann der nächste Schreibvorgang dann auch immer der Wert sein, den du gerade brauchst. item ist false -> send true; item ist true -> send false. Das macht in der Visu jeder einfache Schalter (stateswitch).

Du brauchst kein Hilfsitem mehr und kein Action_out oder so.

Mit deinen Daten von oben:

Schuppen_neu:
  Schloss:
    type: bool
    knx_dpt: 1
    knx_cache: 8/1/1  #Reed
    database: 'true'          
    knx_send: 4/1/30  # das ist das SChloss? ansonsten KNX-Adresse vom Schloss einsetzen

[henfri]

Hallo,

so ganz krieg ich das noch nicht durchdacht...

  Schuppen_neu:
  Schloss:
    geschlossen:
        type: bool
        knx_dpt: 1
        knx_cache: 8/1/1  #Reed
        database: 'true'          
   

    Lock: #Hilfsitem
          type: bool
          enforce_updates: true
          knx_listen:
              - 4/1/30  #Verbunden mit einem Taster
          knx_dpt: 1
          
      Action_out:
          type: str
          mqtt_topic_out: SmartlockSchuppen/action  #Äquivalent zu knx_send.
          eval: "'unlock' if sh...Lock() ==0 else 'lock'"
          eval_trigger: ..Lock()
          enforce_updates: true

Du schlägst ja vor aus geschlossen und Lock ein Item zu machen, oder?
Dann hätte ich zwei knx_listen - einen für den Taster, einen für den Reed.
Aber dann wäre sobald ich den Taster drücke, der Status auf geschlossen, auch wenn das Schloss nicht funktioniert (z.b. weil die Tür offen steht).

Übersehe ich was?

Gruß,
Hendrik

[Morg]

Nee, du machst quasi ein Item daraus:

eg:
  schuppen:
    tuer:
      type: bool
      knx_dpt: 1
      knx_send: 1/2/3 # die KNX-Adresse vom Schloss
      knx_cache: 1/2/5 # die KNX-Adresse vom Reed
      visu_acl: rw

Wenn mich mein Gedächtnis nicht ganz im Stich lässt, bekommt das Item seinen Wert aus dem Reed (zeigt also immer den aktuellen Status) und du kannst damit mit einfachem Klick das Schloss auf- und zumachen.

In der Visu musst du keine Verrenkungen mehr machen, ein einfacher stateswitch mit an/aus und rot/weiß (oder hell/dunkel oder so) reicht völlig aus.