Wie verhindere ich eine Schleife?

[henfri]

Hallo,

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

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

Jetzt habe ich aber oft das Problem, dass ich den Knopf in der Visu (SmartVisu) zweimal drücken muss.

{{quad.stateswitch('Schuppentuer','eg.Schuppen.Ree d.Aussentuer.geschlossen','midi','', ['fts_door_open','fts_door_locked'],'',['icon1','icon0'],'blink','','','','','','Schuppentür','','','','', '','','',['Haustechnik.Schuppen.Schloss.Lock'],'','','',['switch','locks'])}}

Das ist ja der Klassiker bei einem Taster in KNX.
Aber wenn ich jetzt den Status mit dem "Lock" Befehl verknüpfe, baue ich mir doch eine Schleife und das Schloss wird immer wieder schalten.

Wie mache ich das am Besten?

Gruß,
Hendrik

[Morg]

Kannst du in deinen Items - wenn es per KNX ist - nicht den Reed auf knx_cache legen, als Status quasi? Dann weiß das Item immer, ob es "auf" oder "zu" ist, und mit der entsprechenden Anzeige in der Visu kommt dann auch beim ersten Mal gleich die richtige Aktion.

[henfri]

Hallo,

ja, knx_cache ist es schon. Aber ich habe ja ein unterschiedliche Items für den Status und die Aktion.

Wenn ich jetzt ein Item daraus machen würde und manuell geschlosen würde, würde dies eine Aktion beim Schloss verursachen (oder?)

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.

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

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,

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]

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,

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

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

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]

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

[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