Ankündigung

Einklappen
Keine Ankündigung bisher.

Openhab und KNX

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

    [Codebeispiel] Openhab und KNX

    Guten Abend,
    bin ein Neuling und hab ein bischen Problem mit dem KNX binding.
    könnte mir jemand mal die Funktionen udn die Reihenfolge der GA`s erläutern.Also was mit +,<und , gemeint ist.
    in welcher Reihenfolge müssen die GA´s angelegt werden,wegen hören und senden usw?
    Vielen Dank schonmal.

    Alex

    #2
    Hi,

    eigentlich ist das hier ganz gut erklärt:https://github.com/openhab/openhab/w...d-items-to-knx
    Aber gut: Das < bedeutet, dass ein Lese-Request beim Starten von openHAB an die jeweilige Gruppe gesendet wird.
    Und mit + fügst einfach zusätzliche hörende Adressen hinzu.

    Reihenfolge:
    Code:
     knx="[<][<dptId>:]<mainGA>[[+[<]<listeningGA>]+[<]<listeningGA>..], [<][<dptId>:]<mainGA>[[+[<]<listeningGA>]+[<]<listeningGA>..]"

    Gruß!
    Zuletzt geändert von thoern; 26.02.2016, 22:36.

    Kommentar


      #3
      ok,danke.
      nächste frage:
      ich möchte ein item anlegen das mir nur den status anzeigt von einem Aktorkanal.geht das mit einem string?

      Kommentar


        #4
        Hallo,

        Ein Aktorkanal hat nur zwei Zustände: On bzw. Off. Dafür sind Switch-Items gedacht.
        String-Items sind zur Ausgabe von Textinformationen gedacht.

        gurß

        Kommentar


          #5
          Vielleicht etwas allgemeiner: Welches Item Du nimmst, hängt davon ab, welchen DPT Du daran bindest. Wenn Dein Aktor einen Schaltzustand mit einem Bit signalisiert, ist Switch das richtige Item. Wenn der Aktor z.B. einen Prozentwert rückmeldet, ist ein Number Item angesagt. Wobei ja meist die Aktorrückmeldung im selben Item landen soll, weshalb man z.B. bei einem Dimmer dann GA1+GA2 für die absolute Leistung nimmt. über GA1 wird die Leistung dann gesetzt, wenn der Aktor seine Leistung meldet, tut er das aber über GA2. Genauso kann man den Schaltzustand eines Schaltaktors an ein einziges Item koppeln - analog zu der Programmierung in der ETS, wenn Einzeltaster die korrekte Schaltstellung auch dann rückmelden sollen, wenn der Aktor über eine Szene geschaltet wird.

          Kommentar


            #6
            auch hier für danke.
            ich möchte aber nur den status ,ohne schalt funktion.
            Und noch ein problem:ich habe eine steckdose die gesperrt werden kann.ich habe ein item für die normale funktion,an aus,und ein item für die sperre.
            ist nun die steckdose gesperrt und es wird in openhab oder über knx die GA für schalten angesteuert wird nur in openhab der status der Steckdose geändert.was aber nicht der zustand im KNX ist.kann man das irgendwie lösen?
            GA´s wie folgt:GA schalten 4/1/0
            GA Status 4/1/2
            GA sperren 4/1/4 ohne weiteren Status

            Kommentar


              #7
              Falls Du unter keinen Umständen in der Lage sein willst, die Schaltfunktion auszuführen, kannst Du natürlich auch nur die Status-GA verwenden. Du kannst aber in der UI einfach ein Text Item verwenden, dann gibt's keinen Schalter zum Schalten - Das musst Du ohnehin, wenn Du nur die Status-GA verwendest - openHAB weiß ja nicht, dass das nur ein Status ist - oder Du nutzt das Contact Item - was aber strenggenommen für Kontakte gedacht ist, z.B. Tür offen usw., da könnte dann z.B. die Logik verkehrt sein (hab ich jetzt nicht im Kopf )

              Das Sperrwerk musst Du in openHAB abfangen, also ein Item mit der Sperr-GA anlegen (vermutlich musst Du in diesem Fall den DPT mit angeben - Sperrfunktion ist meist 2-Bit), und dann hast Du zwei Möglichkeiten.
              Ich tendiere in diesem Fall dazu, das Steckdosen-Item in der UI auszublenden: visibility=[SperrItem==OFF] Du könntest auch hier als Ersatz ein Text Item einblenden, das zeigt dann trotzdem den Status der Steckdose an.
              Alternativ könntest Du eine Rule bauen, die, falls der Status der Steckdose auf ON wechselt, nachschaut, ob die Sperre aktiv ist und dann gegebenenfalls den Status wieder auf OFF zurücksetzt. Damit fängst Du auch den Fall ab, dass Du auf anderem Weg die Steckdose schaltest, also z.B. per REST, Console, Jabber, oder, oder, oder...

              Kommentar


                #8
                vielen dank.
                hat mir schonmal weitergeholfen.
                wie muss ich das mit der vibility einfügen.wird dann das steckdosen item nur ausgeblendet wenn die sperre on ist?

                die nächsten probleme werden bestimmt nicht lange brauchen

                Kommentar


                  #9
                  Genau, visibility ist eine Eigenschaft in der Sitemap, die pro Item gesetzt werden kann. Wenn der Term in den eckigen Klammern wahr ist, wird das Item dargestellt, sonst nicht.

                  Kommentar


                    #10
                    Hi,

                    hätte auch mal eine Frage zu dem Thema:

                    Bei der Konfiguration:

                    GA zum schalten: 3/3/1
                    GA Status: 3/3/101

                    ITEM Datei :
                    Switch LichtDecke "Decke" <switch> {knx="3/3/1+<3/3/101"}

                    frägt der Raspberry im ~10 Sekunden Takt die 3/3/102 (den Status) ab. Wo hab ich was vergessen?



                    Und so:
                    ITEM Datei:
                    Switch LichtDecke "Decke" <switch> {knx="3/3/1+3/3/101"}

                    So holt der Raspberry sich den Status nicht über die 3/3/101 sonder über die 3/3/1?

                    Kommentar


                      #11
                      Aaaalso: Es gibt die Möglichkeit, ein Pollintervall zu definieren, in dem dann die Adressen abgefragt werden. Das wird mit dem Binding eingegeben: {knx="3/3/1+<(10)3/3/101"} würde so automatisch alle 10 Sekunden die GA3/3/101 abfragen.
                      Da Deine Konfiguration nicht so aussieht, ist entweder irgendwas oberfaul, oder openHAB bekommt keine Antwort auf seine Anfrage und versucht mehrfach erfolglos, das Item zu lesen. Dafür spricht, dass der Standard Timeout bei 10 Sekunden liegt, nachdem openHAB einen erneuten Leseversuch unternimmt (Parameter knx:timeout in openhab.cfg). Dagegen spricht, dass es eigentlich nur 4 Leseversuche geben sollte (Parameter knx:readRetries in openhab.cfg) und openHAB danach aufgeben müsste.
                      Wenn im Binding kein < angegeben ist, wird openHAB aber niemals versuchen, den Status über den Bus aktiv zu erfragen. openHAB wird auf jeden Fall immer auf jedes Telegramm reagieren, welches im Binding angegeben ist. Wenn also über GA3/3/1 ein ON/OFF reinkommt, weil jemand den Lichtschalter gedrückt hat, wird openHAB dies sofort auswerten, genauso, wenn der Aktor auf GA3/3/101 einen Status ON/OFF schickt. (siehe auch Posting #5)

                      Kommentar


                        #12
                        {knx="3/3/1+<(10)3/3/101"} funktioniert wunderbar, er frägt alle 10 Sekunden jetzt ab.


                        Allerdings funktioniert wenn das Licht über die Zentralfunktion geschaltet wird, folglich die 3/3/101 ihren Wert ändert wird dieses in der Openhab nicht angezeigt. Auf dem Bus lässt sich alles verfolgen.

                        Wenn ich mit dem die IP Schnittstelle als Busmonitor hole werden die Telegram ebenfalls angezeigt.
                        Mit dem
                        <(10) wird der Wert zwar aktualisiert allerdings dies bei allen GA zu machen ist etwas viel :/

                        Kommentar


                          #13
                          Zitat von ADH92 Beitrag anzeigen
                          {knx="3/3/1+<(10)3/3/101"} funktioniert wunderbar, er frägt alle 10 Sekunden jetzt ab.


                          Allerdings funktioniert wenn das Licht über die Zentralfunktion geschaltet wird, folglich die 3/3/101 ihren Wert ändert wird dieses in der Openhab nicht angezeigt. Auf dem Bus lässt sich alles verfolgen.

                          Wenn ich mit dem die IP Schnittstelle als Busmonitor hole werden die Telegram ebenfalls angezeigt.
                          Mit dem
                          <(10) wird der Wert zwar aktualisiert allerdings dies bei allen GA zu machen ist etwas viel :/
                          Was willst du eigentlich erreichen?
                          Wenn du wissen willst, ob die GA 3/3/1 an oder aus ist, dann macht man das so:
                          {knx="<3/3/1"}
                          Lesen-Flag muss natürlich auf diese GA gesetzt sein. Das mit den (10) brauchst du normalerweise gar nicht und deine Status-GA brauchst du auch nicht. Deshalb vielleicht mal genauer beschreiben, was du überhaupt erreichen möchtest.

                          Gruß!

                          Kommentar


                            #14
                            Zitat von thoern Beitrag anzeigen
                            deine Status-GA brauchst du auch nicht.
                            Da muss ich jetzt aber mal widersprechen. Selbstverständlich ist es eine gute Idee, die Status-GA für den Status heranzuziehen, und nicht eine GA, die zum Setzen eines Status verwendet wird.
                            1. Welches Gerät soll sich denn zuständig fühlen, wenn openHAB anfragt? Der Aktor selbst könnte natürlich drauf antworten, aber man kann auch mehrere Aktoren auf eine GA verlinken. Ein Taster sollte es eigentlich auch nicht sein, denn da gibt's potentiell auch mehrere von.
                            2. Was passiert denn, wenn der Aktor über eine andere GA geschaltet wird, oder über eine Szenenfunktion? Dann bleibt das Item bis zum nächsten regulären Schaltereignis auf dem falschen Zustand.

                            Das ist auch einer der Gründe, warum man ausdrücklich mehrere GA an einzelne Item-Eigenschaften binden kann.

                            Kommentar


                              #15
                              Ach so... Ansonsten ist das ständige pollen der Status natürlich nicht notwendig, sofern knx mit der ETS korrekt konfiguriert ist, wird bei jedem Statuswechsel der Status über den Bus gesendet und auch von openHAB empfangen und ausgewertet. Was aber gerne mal passiert, ist, dass der Statuswechsel nicht in der UI angezeigt wird. Man sollte also die events.log im Auge behalten, um zu sehen, ob Status geändert wurden, z.B. mittels tail -f ./logs/events.log

                              Kommentar

                              Lädt...
                              X