Ankündigung

Einklappen
Keine Ankündigung bisher.

MDT AKU Sperre mit Szene aufheben und neuen Wert für Sperre senden

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    MDT AKU Sperre mit Szene aufheben und neuen Wert für Sperre senden

    Hi,

    ich habe einen MDT AKU, den ich auf einem Kanal auf EIN sperre.
    Wenn ich jetzt nicht die Sperre direkt aufhebe (Sperre=AUS), sondern das über eine Szene mache, dann schaltet der Aktor korrekt und sendet auch einen aktualisierten Status für den Kanal, aber der neue Wert für die (jetzt aufgehobene) Sperre wird nicht gesendet.

    Nachdem die Flags für das Sperr-KO standardmäßig auf KS stehen, ist das auch nachvollziehbar.
    Aber wenn ich das auf KSÜ oder KLSÜ ändere, sollte dann nicht auch eine Aktualisierung des Sperr-KOs gesendet werden?
    Passiert nämlich nicht. Wenn ich einen READ schicke (nachdem ich das L gesetzt habe), kommt der korrekte Status.

    Habe ich einen Denkfehler oder verhält sich der Aktor nicht richtig?

    Danke!

    #2
    Schau mal im technischen Handbuch auf Seite 85 (4.4.2.5 Verhalten bei Sperren / Entsperren). Du musst "Verhalten bei Entsperren" anpassen.

    Kommentar


      #3
      Das Verhalten beim Entsperren ist korrekt.
      Es geht darum, dass das Sperrobjekt seinen geänderten Status nicht sendet, wenn die Sperre über eine Szene aufgehoben wird.
      Dazu habe ich im THB leider nix gefunden.

      Kommentar


        #4
        Achso verstanden. Du hast da keinen Denkfehler. Der Status wird am Sperrobjekt immer nur beim Read-Request übergeben, da ja der Eingang von sich aus keinen Status zurückgibt. Du benötigst etwas, was aktiv abfragt. Bei dem Sperrobjekt muss dann das L und Ü Flag gesetzt sein.

        Laut Handbuch gibts das Status Sperre/Alarme nur bei den Jalousieausgängen aber nicht bei den Schaltausgängen.

        Edit: Nachfrage: Für was benötigst du das genau? So ein Fall kommt ja nur vor wenn man das in einer Visu darstellen will und dieses Request sendet dann normalerweise die Visu auch. Andernfalls könntest du, sofern du das OpenKNX Logikmodul hast, es auch darüber anschubsen, siehe hier: https://knx-user-forum.de/forum/projektforen/openknx/1973478-alltagsprobleme-und-deren-lösungen-mit-dem-openknx-logikmodul?p=1993158#post1993158
        Zuletzt geändert von r4id; 22.04.2026, 15:41.

        Kommentar


          #5
          So wie ich die Flags verstanden hatte, müsste doch das Sperrobjekt seinen neuen Wert senden, wenn sich dieser intern ändert (in meinem Fall getriggert durch Szene) und das Ü-Flag gesetzt ist. Tut es aber nicht. Vielleicht ist das aber auch nicht zwingend so, da kenne ich die Spec zu wenig.

          Wozu brauche ich das: wenn ich die Sperre irgendwo visualisiere (bspw. auf einem Taster) stimmt die Anzeige sonst nicht.

          Workaround über OpenKNX-Logik (WENN Szene=x empfangen, DANN sende Read auf Sperre) funktioniert, hab ich schon getestet. Damit kann man schon auch leben, aber eleganter wäre es natürlich, der Aktor würde das von selbst senden.
          Vielleicht ist das auch eine Frage, die hjk beantworten kann?

          Kommentar


            #6
            Das Sperrobjekt ist ein Eingangsobjekt und sendet keinen Status. Ein Statusobjekt für die Sperre gibt es nicht, da man das in der Regel nicht braucht.
            Würde das Sperrobjekt senden, kann das zu ungewöhnlichen Verhalten führen, wenn mehrere Sperrobjekte mit einer GA verbunden sind.
            Die Abfrage mit einer Logikfunktion ist aber möglich. Ich würde allerdings die Szene in ein Bitobjekt wandeln, dann stimmt auch die Visu immer.

            Kommentar


              #7
              Danke für das Feedback!
              Bitobjekt probiere ich auch mal aus, danke für den Tip!

              Kommentar


                #8
                Ein KO als Ein- und Ausgang uu benutzen, bedingt dann aber auch Sorgfalt bei der Definition der GA und deren Verbindungen an den KOs die jeweilige Status GA muss dann als erste verbunden werden, damit diese zum senden verwendet wird, und je Status nur ein KO welches sendet. Insofern hast man dann ggf die eine GA die die Sperre auslöst und x Geräte/KO darauf reagieren, aber dann eben je Gerät/KO eine eigene Status-GA oder nur eine GA, dann aber zwingend auch nur eines der betroffenen KO als Ein- und Ausgabgs-KO definiert.

                Man könnte es also schon so bauen aber da muss man dann auch gut aufpassen wie man das dann verwendet.
                ----------------------------------------------------------------------------------
                "Der Hauptgrund für Stress ist der tägliche Kontakt mit Idioten."
                Albert Einstein

                Kommentar


                  #9
                  Ist vollkommen richtig, das erfordert schon Sorgfalt. Und ist vielleicht auch unnötig fehleranfällig. Die Diskussion zeigt mir, dass ggf. eine andere Marschrichtung die bessere Wahl wäre.
                  Und ich hab gelernt, dass ich mich mitnichten drauf verlassen kann, interne Statusänderungen durch setzen des Ü-Flags mitgeteilt zu bekommen.

                  Kommentar

                  Lädt...
                  X