Ankündigung

Einklappen
Keine Ankündigung bisher.

OpenHAB2: Zugriff via Gateway MDT Interface SCN-IP000.01

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

    OpenHAB2: Zugriff via Gateway MDT Interface SCN-IP000.01

    Moin *,

    ich habe Probleme, von OpenHAB auf den KNX-Bus über ein 'MDT Interface SCN-IP000.01' zuzugreifen.

    OH läuft auf einem CentOS7, Version ist 2.4.0.

    Über PaperUI wurde ein Binding eingerichtet:
    Code:
     This binding supports connecting to a KNX bus
    
    Supported Things
      KNX FT1.2 Interface knx:serial
     KNX/IP Gateway       knx:ip
    KNX Device               knx:device
    Auch ein Thing wurde eingerichtet - hier die Repräsentation im Dateisystem:
    Code:
    # cat /var/lib/openhab2/jsondb/org.eclipse.smarthome.core.thing.Thing.json
    {
      "knx:ip:10ee2bb2": {
        "class": "org.eclipse.smarthome.core.thing.internal.BridgeImpl",
        "value": {
          "label": "KNX/IP Gateway MDT Interface SCN-IP000.01",
          "channels": [],
          "configuration": {
            "properties": {
              "useNAT": false,
              "readRetriesLimit": 3,
              "ipAddress": "172.16.20.10",
              "autoReconnectPeriod": 60,
              "localIp": "172.16.20.9",
              "type": "TUNNEL",
              "localSourceAddr": "1.1.1",
              "readingPause": 50,
              "portNumber": 3671,
              "responseTimeout": 10
            }
          },
          "properties": {},
          "uid": {
            "segments": [
              "knx",
              "ip",
              "10ee2bb2"
            ]
          },
          "thingTypeUID": {
            "segments": [
              "knx",
              "ip"
            ]
          },
          "location": "Schaltschrank Heizungskeller"
        }
      }
    }
    Dieses Element wird in PaperUI als Online angezeigt, in den Logs steht:
    Code:
    2019-09-08 18:46:12.245 [hingStatusInfoChangedEvent] - 'knx:ip:10ee2bb2' changed from UNINITIALIZED to INITIALIZING
    2019-09-08 18:46:12.333 [hingStatusInfoChangedEvent] - 'knx:ip:10ee2bb2' changed from INITIALIZING to UNKNOWN
    2019-09-08 18:46:12.597 [hingStatusInfoChangedEvent] - 'knx:ip:10ee2bb2' changed from UNKNOWN to ONLINE
    Ich gehe daher davon aus, dass das Gateway korrekt initialisert ist.

    Ich hatte jetzt erwartet, die Elemente unter Inbox scannen zu können. Das ist aber nicht der Fall.

    Also wurde eine Definition von Hand erstellt:
    Code:
    # cat /var/lib/openhab2/jsondb/org.eclipse.smarthome.core.thing.Thing.json
    [...]
    ,
      "knx:device:a83cdde8": {
        "class": "org.eclipse.smarthome.core.thing.internal.ThingImpl",
        "value": {
          "label": "Licht Erker",
          "bridgeUID": {
            "segments": [
              "knx",
              "ip",
              "10ee2bb2"
            ]
          },
          "channels": [],
          "configuration": {
            "properties": {
              "pingInterval": 600,
              "address": "1/0/32",
              "readInterval": 0,
              "fetch": false
            }
          },
          "properties": {},
          "uid": {
            "segments": [
              "knx",
              "device",
              "a83cdde8"
            ]
          },
          "thingTypeUID": {
            "segments": [
              "knx",
              "device"
            ]
          },
          "location": "Wohnzimmer"
        }
      }
    }
    Das wird mir aber im UI als 'offline' dargestellt:
    Code:
    2019-09-08 20:09:54.907 [ome.event.ItemUpdatedEvent] - Item 'LichtErket1' has been updated.
    2019-09-08 20:23:34.629 [hingStatusInfoChangedEvent] - 'knx:device:a83cdde8' changed from UNINITIALIZED to INITIALIZING
    2019-09-08 20:23:34.667 [hingStatusInfoChangedEvent] - 'knx:device:a83cdde8' changed from INITIALIZING to UNKNOWN
    2019-09-08 20:23:40.875 [hingStatusInfoChangedEvent] - 'knx:device:a83cdde8' changed from UNKNOWN to OFFLINE
    Hier weiß ich nicht weiter.

    Hinweis: Bei der Initialisierung des Gateways habe ich an fast allen Schrauben und Kombinationen gedreht.

    Dass das Gateway grundsätzlich funktioniert(e) weiß ich, weil ich vor ein oder zwei Jahren mit 'eibd' einen funktionierenden Listener für die Events am Start hatte. Die damaligen Settings waren:
    Code:
    $ eibd -D -S -T -i --eibaddr=1.1.1 --daemon=eibd.log --no-tunnel-client-queuing ipt:knx
    Bin momentan ratlos und wäre ich für weiterführende Hilfe dankbar.
    TNX

    cu, Lyra
    Zuletzt geändert von Lyra; 08.09.2019, 21:02.

    #2
    knx unterstützt kein autoDiscovery, also kann auch openHAB hier leider nicht automatisch auf Entdeckungsreise gehen.

    Was Dein angelegtes Thing betrifft, so hast Du eine GA als address angelegt. In diesem Bereich der Konfiguration ist aber eine physikalische Adresse anzugeben.
    Allerdings kannst Du diesen Teil der Konfiguration komplett weg lassen, es spielt für die Funktion keine Rolle (außer eben die Anzeige, ob das Device mit der physikalischen Adresse x.y.z über den Bus erreichbar ist. Dieser Ping hat aber keine Priorität und geht auch gerne mal verloren. Da er, wie erwähnt, für die Funktion keine Rolle spielt...

    Unterhalb des Things kannst Du Channels anlegen, über das +-Zeichen. Je nach Channeltyp musst Du mindestens eine, aber durchaus auch mehrere GA anlegen, z.B. ein Switch Item benötigt - korrekt verwendet - zwei GA, die erste um den Kanal zu steuern, die zweite, um den aktuellen Status zu erhalten. Eine Ist-Temperatur kommt über eine einzelne GA, die am besten lesbar ist (so wie der Status beim Switch auch), ein Dimmer benötigt drei GA (Ein/Aus sowie Absolutwert schreiben und lesen) und so weiter.

    Bei der Bridge gibst Du besser keine physikalische Adresse an, das macht oftmals Probleme. Wichtig ist die physikalische Adresse der Bridge vor allem, wenn Du den Gruppenmonitor in ETS nutzt und automatisch einen Namen für die physikalische Adresse sehen willst.
    Zuletzt geändert von udo1toni; 08.09.2019, 21:22.

    Kommentar


      #3
      Vielen Dank für die freundliche Antwort. Hatte noch nicht so viel Gelegenheit, da weiter zu machen, wollte aber auch nicht tagelang stumm bleiben...

      Zitat von udo1toni Beitrag anzeigen
      knx unterstützt kein autoDiscovery, also kann auch openHAB hier leider nicht automatisch auf Entdeckungsreise gehen.
      ACK

      Zitat von udo1toni Beitrag anzeigen
      Was Dein angelegtes Thing betrifft, so hast Du eine GA als address angelegt. In diesem Bereich der Konfiguration ist aber eine physikalische Adresse anzugeben.
      Allerdings kannst Du diesen Teil der Konfiguration komplett weg lassen
      Ich rätsel noch über die Bedeutung Deiner Worte. Was ist 'GA'???

      OK, wenn ich die "1/0/32" entferne, dann wechselt der Zustand tatsächlich auf 'Online'. Das könnte ein Fortschritt sein.

      Hoffe, da bald weitermachen zu können.
      TNX

      Kommentar


        #4
        Oh, ich kann plötzlich das Licht schalten. Kaum macht man's richtig, schon funktioniert's. Wer hätte das gedacht?!?

        Tja, muss trotzdem noch mal in Ruhe sortieren, was ich da jetzt veranstaltet habe...

        Kommentar


          #5
          GA -> GruppenAdresse. Schreibweise (Standard) a/b/c, z.B. 14/7/250
          KO -> KommunikationsObjekt (wird in ETS durchnumeriert)
          DPT -> DatenPunkT. Schreibweise a.b (b wird normalerweise dreistellig mit führenden Nullen angeben, z.B. 1.001)

          Neben den Flags sind diese drei Bezeichnungen das A und O im knx Bus. Jedes Device hat verschiedene KO mit bestimmten DPT und Flags, die mittels GA über den knx Bus miteinander kommunizieren können.

          Daneben gibt es noch die physikalische Adresse, die am Bus eindeutig sein muss (jedes Device, bzw. der Busankoppler hat eine), Schreibweise x.y.z, z.B. 1.1.15. Die physikalische Adresse spieltim Zusammenhang der Bustopologie eine Rolle, anonsten aber vor allem beim Programmieren der Devices. Für die Funktion von openHAB ist sie nebensächlich.
          Zuletzt geändert von udo1toni; 09.09.2019, 22:45.

          Kommentar


            #6
            Vielen Dank auch für die weiterführenden Erklärungen. Grundsätzlich ist das bekannt (wenn auch schon wieder etwas angestaubt), war mir aber unsicher wegen der Abkürzung.

            OK, also ist mein Stand schon mal gar nicht so schlecht, denn der grundlegende Aufbau und das Gateway funktioniert für das Beispiel Licht und Rollladen. Dabei möchte ich es in diesem Thread bewenden lassen, hier kann ich mich jetzt selbstständig weitertasten oder bei Problemen notfalls einen weiteren Thread eröffnen.

            Aber zur Einbindung des Gateways hätte ich schon noch eine Frage: Ist die gewählte Config beim Gateway so sinnvoll oder würdet Ihr anders vorgehen? Ich habe den Typ 'Tunnel' letztlich nur gewählt, weil ich vor Jahren mit 'eibd' so Erfolg hatte und ist die erste, die funktioniert. Muß ja nicht die beste Variante sein...

            Herzlichen Dank nochmals!

            Kommentar


              #7
              Dein MDT-Interface kann nur Tunnel...

              Kommentar


                #8
                Ack - tnx

                Kommentar


                  #9
                  Zitat von DiMa Beitrag anzeigen
                  Dein MDT-Interface kann nur Tunnel...
                  Ist zwar schon etwas älter, aber laut Handbuch kann das Interface/Gateway bis zu 5 gleichzeitige Verbindungen

                  Kommentar


                    #10
                    Das ist richtig, aber ich verstehe den Bezug zu meinem Beitrag nicht?!

                    Kommentar


                      #11
                      Zitat von DiMa Beitrag anzeigen
                      Das ist richtig, aber ich verstehe den Bezug zu meinem Beitrag nicht?!
                      Nicht richtig gelesen. Ich hatte irgendwie gelesen: .... kann nur ein Tunnel

                      Kommentar

                      Lädt...
                      X