Ankündigung

Einklappen
Keine Ankündigung bisher.

openhab3 KNX binding

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

    #16
    Ich habe jetzt für den IP Gateway als localSourceAddr die physikalische Adresse meines IP-Interface angegeben. Damit wird das als Online angezeigt.
    Bei den Things habe ich jeweils die physikalische Adresse des Aktors angegeben, der die meisten Channels enthält, die ich dahinter definiere. Damit werden nun auch die Things als Online angezeigt.
    Etwas verwirrend finde ich das dennoch, denn eigentlich kann ich ja ein Thing auch völlig losgelöst von einem Aktor definieren. z.B. kann ich mit einem Thing die logische Einheit "Fenster" erstellen und dahinter alle Fensterkontakte hängen. Jetzt können die aber von unterschiedlichen Tasterinterfaces kontrolliert werden. Oder gruppiert Ihr wirklich alles nach dem jeweiligen Aktor?

    Kommentar


      #17
      Zitat von McMaster05 Beitrag anzeigen
      Ich habe jetzt für den IP Gateway als localSourceAddr die physikalische Adresse meines IP-Interface angegeben. Damit wird das als Online angezeigt.
      Bei den Things habe ich jeweils die physikalische Adresse des Aktors angegeben, der die meisten Channels enthält, die ich dahinter definiere. Damit werden nun auch die Things als Online angezeigt.
      Was meinst Du mit "die meisten"? Entweder, Du definierst exakt ein Thing pro Device, dann bekommt das Thing (wahlweise) die physikalische Adresse dieses Device, oder Du definierst in einem Thing nur Teile eines Device oder gar Teile mehrerer Devices innerhalb eines Thing, dann darfst Du keine physikalische Adresse angeben. Entgegen anderslautenden Aussagen hier im Forum ist das auch nicht korrekt, auch wenn es dennoch funktioniert - aber eben nur in Teilen.
      Zitat von McMaster05 Beitrag anzeigen
      Etwas verwirrend finde ich das dennoch, denn eigentlich kann ich ja ein Thing auch völlig losgelöst von einem Aktor definieren. z.B. kann ich mit einem Thing die logische Einheit "Fenster" erstellen und dahinter alle Fensterkontakte hängen. Jetzt können die aber von unterschiedlichen Tasterinterfaces kontrolliert werden. Oder gruppiert Ihr wirklich alles nach dem jeweiligen Aktor?
      Es ist in der Dokumentation von openHAB sehr eindeutig erklärt, dass ein Thing exakt einem Device entspricht. Bei Bussystemen wie z.B. knx gibt es keinen zwingenden Zusammenhang zwischen Thing und Device, weshalb Du auch anders konfigurieren kannst (so wie von Dir beschrieben z.B.), aber das ist nicht so vorgesehen.

      Und ja, bei mir hat jedes REG und jedes verbaute Modul exakt ein Thing als Entsprechung in openHAB.
      Ich sehe für jedes einzelne Device, ob es auf dem Bus erreichbar ist.
      Ziehe ich einen Busankoppler ab, dann wird das entsprechende Thing spätestens nach Ablauf der Ping-Zeit als OFFLINE angezeigt.
      Stecke ich den Busankoppler wieder an, ändert sich die Anzeige spätestens nach Ablauf der Ping-Zeit wieder auf ONLINE.
      Bei bestimmten Devices funktioniert sogar fetch, womit ich in openHAB angezeigt bekomme, wie der Hersteller heißt und welche ROM-Maske geladen ist.
      Beide Funktionen sind eher Spielerei, da für die Funktion von openHAB und knx irrelevant.

      Eine Gruppierung nach Funktion nehme ich auf Itemebene vor, in openHAB3 gibt es dort sogar das semantic Model für exakt diese Aufgabe.

      Es gibt diverse andere Hardware, bei der der Anwender nicht die Wahl hat, Things nach eigenem Gutdünken zu konfigurieren, dort kann man auch nicht einfach Messwerte und Funktionen als getrennte Hardware betrachten.
      Zuletzt geändert von udo1toni; 22.05.2021, 19:29.

      Kommentar


        #18
        Udo meint u.a. mich, wenn er sagt, dass andere Teile im Forum das anders sehen.

        Für mich ist ein Thing ein Thing im Sinne von Software, also etwas, was eine Einheit bildet, man als Ding ansehen kann. Das kann ein Aktor oder Sensor sein, muss aber nicht. Es kann auch ein Gewerk sein.

        Zitat von udo1toni Beitrag anzeigen
        Es ist in der Dokumentation von openHAB sehr eindeutig erklärt, dass ein Thing exakt einem Device entspricht. Bei Bussystemen wie z.B. knx gibt es keinen zwingenden Zusammenhang zwischen Thing und Device, weshalb Du auch anders konfigurieren kannst (so wie von Dir beschrieben z.B.), aber das ist nicht so vorgesehen.
        Wenn das nicht vorgesehen wäre, hätte der Autor des KNX-Binding die physikalische Adresse zwingend gemacht. So hat er genau die Option offengehalten, ein Thing als etwas Virtuelles zu sehen.

        Davon mache ich lebghaften Gebrauch. Meiner Meinung nach kapselt die ETS die Hardware und liefert die GAs als Schnittstelle nach außen. openHAB-Things setzen auf den GAs auf und gruppieren sie. Und bei den meisten dürften GAs anders strukuturiert sein als in Physik, etwa in Gewerke oder Topologie.

        Genau das steht auch in https://www.openhab.org/addons/bindings/knx/: "Things are wrappers around an arbitrary group addresses on the KNX bus."
        openHAB 4.2

        Kommentar


          #19
          Zitat von Tokamak Beitrag anzeigen
          Wenn das nicht vorgesehen wäre, hätte der Autor des KNX-Binding die physikalische Adresse zwingend gemacht.
          Entschuldige bitte, aber das ist Deine Sicht der Dinge. Wie erwähnt gibt es keinen Grund, eine physikalische Adresse zu nutzen. Warum also sollte man die physikalische Adresse zwingend machen?
          Zitat von Tokamak Beitrag anzeigen
          So hat er genau die Option offengehalten, ein Thing als etwas Virtuelles zu sehen.

          Davon mache ich lebghaften Gebrauch. Meiner Meinung nach kapselt die ETS die Hardware und liefert die GAs als Schnittstelle nach außen. openHAB-Things setzen auf den GAs auf und gruppieren sie. Und bei den meisten dürften GAs anders strukuturiert sein als in Physik, etwa in Gewerke oder Topologie.

          Genau das steht auch in https://www.openhab.org/addons/bindings/knx/: "Things are wrappers around an arbitrary group addresses on the KNX bus."
          Ja, aber dann steht halt die Funktionalität physikalische Adresse nicht zur Verfügung. Wenn man keine Hardware abbildet, dann darf man auch keine Hardware Parameter verwenden!

          Ansonsten gilt: https://www.openhab.org/docs/#a-quick-overview
          Things are the first openHAB (software) generated representation of your devices

          Kommentar


            #20
            Ich schließe mich Udo an: Ich bilde ebenfalls die physikalischen Geräte als Things ab. Ansonsten sind ja auch quasi alle Funktionen zur Statusüberwachung der physikalischen Geräte nutzlos. Die logischen Strukturen dann über Items oder Equipment, zumal da jetzt mit den Metadaten aus dem Model noch weitere Möglichkeiten dazu (ge)kommen sind/werden (auch wenn man sie bislang nur spärlich nutzen kann, ich zumindest).

            Kommentar


              #21
              Zitat von zeebee Beitrag anzeigen

              Ich habe mich in openHab übrigens von den Aktoren logisch losgelöst und arbeite mit Bereichen:
              Bildschirmfoto 2021-02-01 um 09.24.03.png
              Was ist denn der Vorteile wenn man mehrere Things anlegt für die Bereiche. Habe es bisher auch so gemacht, bin aber irgendwie kurz davor einfach ein Thing "KNX" anzulegen und da alle Gruppenadressen rein.

              Kommentar


                #22
                Zitat von STSC Beitrag anzeigen
                Was ist denn der Vorteile wenn man mehrere Things anlegt für die Bereiche.
                Für mich, dass die automatisch erstellten Items mit dem Namen vom Thing beginnen. Das hilft bei der Suchmaske in den Items. Außerdem habe ich so viele KNX Channels, dass es so übersichtlicher ist. Aber wenn dir das nicht taugt, mach einfach ein KNX-Thing.

                Kommentar


                  #23
                  OK, dann hast du z.B. ein Thing "KNX_Rolladen" mit einem Channel/Item "Rolladen_Arbeit".
                  Wenn du das dem Semantic Model hinzufügt, dann taucht das unter Properties/Eigenschaften in der UI als "KNX_Rolladen_Rolladen_Arbeit" auf; das schaut doch dann auch blöd aus?

                  Kommentar


                    #24
                    Spätestens wenn Du eine Hardware hast, welche nicht in der Lage ist, Werte bei Änderung oder zyklisch zu senden, die aber durch einen Read Request dazu bewegt werden kann, die Daten preis zu geben, möchtest Du dieses Device getrennt von den anderen konfigurieren, damit Du den Read Interval sinnvoll setzen kannst. Dieser Parameter wird pro Device gesetzt, da ein Device die genannten Funktionen entweder überall oder nirgendwo bietet. Selbstverständlich ist es wesentlich effizienter, bei Wertänderung zu senden als zyklisch abzufragen, aber es gibt halt noch solche Hardware.
                    Ich habe mehrere GA, die nicht eindeutig einem Device zuzuordnen sind (z.B. Uhrzeit/Datum auf dem Bus sowie einige Zentralfunktionen), die habe ich natürlich in einem generic Device angelegt.
                    Meine Devices enthalten im Devicenamen einen Bezug auf die physikalische Adresse sowie die Funktion, also Shutter, Dimmer, Switch usw., weshalb ich immer genau weiß, wo ich das entsprechende Device suchen muss.
                    Ob Du das so haben willst, ist natürlich Deine Sache, niemand zwingt Dich dazu, Things pro Device anzulegen, aber (ich wiederhole mich da gerne) die Entwickler von openHAB haben das explizit so vorgesehen.
                    Genauso folgen meine GA einem (für mich) logischen Schema, Hauptgruppe->Raum, Mittelgruppe->Funktion (z.B. Heizung, Licht, Rollläden usw), Untergruppe->Adressierung ähnlich der KO-Struktur. Es wird Leute geben, die das als total unpraktisch brandmarken werden, es führt aber dazu, dass all meine Devices einer bestimmten Sorte extrem ähnliche GA aufweisen, wesehalb ich die Devices einfach kopieren und anschließend Teile der GA anpassen kann. Das hat sich einfach so ergeben, die GA-Struktur hatte ich schon vor openHAB.

                    Kommentar


                      #25
                      Zitat von STSC Beitrag anzeigen
                      OK, dann hast du z.B. ein Thing "KNX_Rolladen" mit einem Channel/Item "Rolladen_Arbeit".
                      Wenn du das dem Semantic Model hinzufügt, dann taucht das unter Properties/Eigenschaften in der UI als "KNX_Rolladen_Rolladen_Arbeit" auf; das schaut doch dann auch blöd aus?
                      Nein, das Thing heisst "KNX_Rolladen" und der Channel einfach "Büro_Balkon". Dann Wird KNX_Rolladen_Büro_Balkon draus.

                      Kommentar


                        #26
                        Hast du dann auch ein KNX_Licht_Büro_Balkon? Kann es zwei Items mit "Büro_Balkon" geben?

                        Kommentar


                          #27
                          Thing + Channel = Item

                          Ein Item muss eindeutig sein. Das Item wäre also nie nur Büro_Balkon sondern KNX_Licht_Büro_Balkon bzw. KNX_Rolladen_Büro_Balkon. Umlaute gehen auch nicht im technischen Namen, es geht nur um den Aufbau.

                          Kommentar

                          Lädt...
                          X