Ankündigung

Einklappen
Keine Ankündigung bisher.

Mehrere Gruppenadressen auf einem Switch-Item mit Mappings

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

    Mehrere Gruppenadressen auf einem Switch-Item mit Mappings

    Hallo zusammen,

    meine Roto-Dachfenster werden über potentialfreie Kontakte gesteuert, welche an einem MDT Schaltaktor hängen.
    Dieser läuft im Impulsmodus (500ms) und ich habe pro Fenster vier Gruppenadressen:

    Dachfenster auf
    Dachfenster zu
    Rolladen auf
    Rolladen zu

    Gerne würde ich diese auf zwei Switch-Items legen und dafür Mapping-Buttons verwenden:

    Dachfenster [ÖFFNEN] [SCHLIESSEN]
    Rolladen [ÖFFNEN] [SCHLIESSEN]

    Nun sehe ich aber keine direkte Möglichkeit, auf den zwei Buttons verschiedene Gruppenadressen zu senden - es handelt sich ja lediglich um die verschiedenen States des Switch-Items - und ein Switch-Item hängt eben nur an einer Gruppenadresse.

    Gibt es eine einfach Möglichkeit, dies umzusetzen? Oder muss ich den Umweg über Dummy-Items und zugehörige Rules gehen?
    Genau genommen hätte ich einfach nur gerne mehrere Buttons nebeneinander, wobei jeder Button auf eine andere Gruppenadresse sendet...


    Viele Grüße

    Nico



    #2
    Wie stellst Du sicher, dass immer nur einer der zwei zusammen gehörenden Schaltkanäle aktiv ist?
    Normalerweise solltest Du dafür lieber einen Rollladenaktor verwenden, der verhindert zuverlässig ein fehlerhaftes Ansteuern, gleichzeitig wird Dein Problem komplett beseitigt.

    Falls es nicht anders geht - nicht jeder Schaltaktor lässt sich als Rollladenaktor programmieren und Aktoren sind nicht billig - musst Du tatsächlich 6 Items verwenden, 2 für die UI und 4 für die vier Schaltkanäle.
    Dabei kannst Du dann in den nötigen Rules auch gleich dafür sorgen, dass niemals auf und zu gleichzeitig aktiv sind.

    Natürlich kannst Du auch mit nur einem ungebundenen Item für die UI arbeiten, dafür nutzt Du dann am besten ein Number Item, damit Du die 6 Knöpfe bequem unterscheiden kannst (Fenster Auf/Stop/Zu, Rollladen Auf/Stop/Zu) - Wie Du die Knöpfe so beschriftest, dass sie gut auseinander zu halten sind, steht dann auf einem anderen Blatt...
    Zuletzt geändert von udo1toni; 13.06.2017, 05:36.

    Kommentar


      #3
      Hi Udo,

      rein technisch ist die gleichzeitige Aktivierung mehrerer Kanäle kein Problem - die Roto-Steuerung führt immer nur die Aktion der zuletzt gebrückten Ader durch.
      Der Schaltaktor gibt wie beschrieben also immer nur einen Impuls ab.
      D.h. z.B. Fenster öffnen starten, Ader 1 kurz schließen. Das Problem ist, um die Fahrt zu stoppen, braucht es den gleichen Impuls nochmal.

      Daher geht es meiner Meinung nach auch nicht mit einem Rolladenaktor - der würde ja die gesamte Fahrtzeit schließen und ein Stoppen wäre für ihn das Öffnen des Kontaktes. Momentan habe ich das einfach auf vier einzelnen Tasten auf einem MDT Smart II.

      Daher mein Wunsch, das in openHAB zu verbessern.

      Der erste Schritt wären jetzt erstmal nur diese vier Buttons, damit hab ich dann erstmal das Gleiche auf dem Smartphone wie auf dem KNX-Taster.
      Nächster Schritt wäre dann eine Logik, welche das ganze wie einen Rolladen bedienbar macht.
      D.h. mit Timern, welche wissen, wann das Fenster / der Rolladen komplett offen/geschlossen ist und den Impuls zum Stoppen dann umkehren.

      Erstes Ziel wäre somit in openHAB ein RollerShutter Item + Rules zu erstellen, so dass sich das von openHAB wie ein normaler Rolladen (Öffnen/Schliessen des Fensters verhält sich ja auch wie ein Rolladen) bedient.

      Final dann so, dass ich es auch auf dem KNX-Taster wie einen Rolladen bedienen kann (mit Eintasten-Bedienung).

      Ich schaue mir jetzt erstmal das Number-Item an - vielen Dank für den Tipp

      Vg
      Nico




      Kommentar


        #4
        Ah, der Aktor gibt nur einen einzelnen Steuerimpuls... das hatte ich nicht so verstanden... Dann ist das natürlich genau so richtig, wie Du das gemacht hast. Dann böte es sich an, ein wenig Aufwand zu treiben...

        Also
        1. ein ungebundenes Item für die UI. Das wäre ein Rollershutter Item.
        2. die einzelnen Items, die den Laden bzw. das Fenster bedienen. Die fasst Du am besten als Gruppe(n) zusammmen.
        3. die Items persistierst Du
        4. ein paar Rules, die aus der Persistence feststellen, welcher Kanal zuletzt betätigt wurde und dann mit dieser Information die Steuerbefehle vom ungebundenen Rolleshutter Item umsetzen (also z.b. beim Stoppkommando auf dem richtigen Kanal triggern) und eventuell sogar eine Rückmeldung über den aktuellen Status liefern (also wie weit der Laden geschlossen ist)

        die ersten drei Punkte sind trivial, die Rules werden da schon ein wenig anspruchsvoller, aber der Aufwand sollte trotzdem überschaubar sein.

        Kommentar


          #5
          Hi Udo,

          danke für den Input!
          Genau so habe ich es vor...

          Evtl. kommt da ja eine fertige copy&paste Lösung bei raus, die ich dann hier mal vorstellen kann.
          Gibt ja doch einige User hier im Forum, welche ebenfalls die gleiche Roto-Fenstersteuerung haben.

          Vg

          Nico

          Kommentar

          Lädt...
          X