Ankündigung

Einklappen
Keine Ankündigung bisher.

OH2 knx binding kann keine Daten mehr senden zu knxd, empfängt aber weiter

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

    OH2 knx binding kann keine Daten mehr senden zu knxd, empfängt aber weiter

    Hallo
    Vielleicht weiss jemand Rat.
    Ich verwende OH2 (2.0.0) mit KNX-Binding 1 auf R-PI3 zusammen mit dem knxd (0.14.16).
    Nach einer Weile (2h bis 1.5 Tage) kann OH2 keine Daten mehr senden, empfängt aber weiterhin Daten korrekt vom knxd.
    Folgende Konfiguration verwende ich:

    Code:
    openhab> config:edit org.openhab.knx
    openhab> config:property-list
    
       autoReconnectPeriod = 30
       busaddr = 0.0.200
       ignorelocalevents = true
       ip = 192.168.1.42
       localIp = 192.168.1.42
       port =
       service.pid = org.openhab.knx
       type = TUNNEL
    Das Problem scheinen wohl noch mehr User zu haben (siehe meinen Post im knxd Forum).

    Das Problem tritt bei mir auch im ROUTER Modus auf, allerdings dort permanent.

    Um jegliche Vorschläge zur Lösung des Problems wäre ich sehr dankbar.

    Grüsse Michael
    Zuletzt geändert von misa; 06.06.2017, 23:45.

    #2
    Meine erste Frage dazu wäre, warum nutzt Du knxd? Welche (physische) Schnittstelle verwendest Du, um auf den knx-Bus zu kommen?

    knxd habe ich noch nicht getestet, verfolge aber (nachlässig) die Entwicklung, soweit ich das mitbekommen habe, läuft knxd nicht unbedingt rund und hat arge Probleme mit ETS 5.
    eibd hatte ich früher im Einsatz, damit ich parallel mit ETS und openHAB auf den Bus zugreifen konnte. Das Problem war, dass dieser parallele Zugriff nur teilweise funktionierte; wenn ich komplexe Busteilnehmer programmieren wollte, musste ich alle anderen Buszugriffe unterbinden.
    Da ich eine IP-Schnittstelle einsetze (Weinzierl 730 knx IP Interface), kann ich ohnehin bis zu 5 Dienste konkurrierend auf den Bus zugreifen lassen (mit der gleichen Einschränkung - beim Programmieren sollte ETS exklusiv zugreifen), also habe ich eibd ersatzlos gestrichen und openHAB nutzt die IP-Schnittstelle direkt.
    USB oder Seriell kann openHAB ebenfalls ohne Hilfe von außen, da gäbe es natürlich in der Tat eine Einschränkung, wenn die Schnittstelle auch für ETS zur Verfügung stellen soll.

    Kommentar


      #3
      Hallo udo1toni, Danke für die Antwort.

      ETS brauche ich nicht. Für mich würde es auch reichen, über OH2 KNX direkt meine physikalische Schnittstelle anzusprechen.

      Ich verwende den TPUART USB Konnektor von busware.de.

      Mir ist allerdings nich klar, wie ich das knx binding in OH2 dafür konfigurieren muss. Ein Konfig Beispiel würde mir helfen. Habe nur Beispiele für ROUTER und TUNNEL gefunden.

      Bezüglich knxd kann ich sagen, dass die Stabilität echte Fortschritte macht.
      Im Zusammenspiel mit dem knx binding kann ich mir vorstellen, dass die wechselnden knx Geräteadressen ggf. mein Problem auslösen.

      Grüsse Michael
      Zuletzt geändert von misa; 08.06.2017, 09:47.

      Kommentar


        #4
        Hallo misa

        Kommentar


          #5
          Sorry, hatte Speichern zu schnell gedrückt. Update siehe oben

          Kommentar


            #6
            Hmm... Anscheinend wird gerade tpuart als Verbindung nicht nativ unterstützt... FT1.2 sollte es sein (das war früher mal der Standard über spezielle Busankoppler mit serieller oder auch USB Schnittstelle.) Also ist vermutlich doch knxd das Mittel der Wahl.

            Bleiben ein paar Knackpunkte, mit denen Dein Problem zusammenhängen könnte. Zum einen natürlich die Konfiguration von knxd, die zwar wohl einfacher funktioniert als früher eibd, trotzdem müssen ja alle Parameter passen, also lokale Schnittstelle, Port, Ethernetport, Betriebsart...
            Gerade der ROUTER Mode soll gerüchteweise besser funktionieren als der TUNNEL Mode, ich kann das bisher nicht beurteilen, meine IP-Schnittstelle unterstützt nur TUNNEL als Betriebsart. Für den ROUTER Mode muss Multicast funktionieren, außerdem bin ich mir nicht sicher, wie das funktioniert, wenn beide Dienste auf der selben Hardware laufen, eventuell muss man das bei der Konfiguration berücksichtigen.
            Ansonsten kann ihc nur empfehlen, auf die unstable Version zu wechseln - keine Angst, der Name lügt Es handelt sich halt um den Entwicklerzweig, das bedeutet, es gibt fast täglich neue Versionen. Aber die Software ist (bis auf Ausreißer) eigentlich immer stabil mit den neuesten Features, und es ist niemand gezwungen, ein Update auch zu installieren. Eventuell gab es, seit im Januar OH2.0 offiziell veröffentlicht wurde schon Verbesserungen bei der Kommunikation mit knxd (unter https://github.com/openhab/openhab könntest Du auf die Suche gehen, ob da jemand was gemerged hat)

            Kommentar


              #7
              Mein TUL kann auch FT1.2, wenn ich ein neues ROM flashen würde. Ich habe allerdings gelesen, dass FT1.2 auch nicht die erste Wahl bezüglich Stabilität ist. Da bleibe ich lieber bei TP-UART.
              knxd ist prima. Bin auf der aktuellsten Version.
              Mit der Konfiguration ist bei mir alles OK. Es läuft ja auch pronzipiell. Ich bin mir mittlerweile recht sicher, das Problem eingekreist zu haben. Seit dem ich knxd so umkonfiguriert habe, dass nur noch ein virtuelles knx gerät unterstützt wird, läuft es problemlos.

              K.a., ob das mit den springenden, physischen knx Adressen zusammenhängt.

              Kommentar


                #8
                Ah, das hatte ich irgendwie überlesen... ja, wenn die knx-Adresse des Adapters sich ändert, könnte das schon zu Problemen führen. Wobei man doch eigentlich davon ausgehen sollte, dass gleiche IP und gleicher Port immer die gleiche Adresse zugewiesen bekommen... Bei mir sind 5 virtuelle Adressen aktiv, das funktioniert einwandfrei (wobei ich zugebe, dass wenn, dann nur ETS zusätzlich zugreift, aber openHAB ist immer die erste Anwendung, die sich auf das Interface verbindet.)

                Kommentar

                Lädt...
                X