Ankündigung

Einklappen
Keine Ankündigung bisher.

KNX-Verbindung geht nach Netzwerktrennung verloren

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

    KNX-Verbindung geht nach Netzwerktrennung verloren

    Hallo,
    ich stehe vor dem Problem das sobald meine Netzwerkverbindung einmal unterbrochen wurde (Router neustart, LAN-Kabel gezogen...) das die Verbindung zwischen openHab und KNX nicht wieder aufgebaut werden kann.
    Da ich über die Konsole noch Befehle senden kann z.B. "knxtool groupswrite ip:localhost 0/0/1 0" gehe ich davon aus das das Problem bei openHab liegt?!
    Kennt jemand das Problem, bzw ne möglichkeit was ich hier falsch konfiguriert haben könnte...?

    /var/log/openhab2/openhab.log :
    2018-12-29 18:34:18.478 [WARN ] [nx.internal.connection.KNXConnection] - KNX link has been lost (reason: heartbeat communication failure on object tunneling link link (closed) 192.168.178.$
    2018-12-29 18:34:18.475 [ERROR] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.178.201:3671: send disconnect failed
    java.io.IOException: Invalid argument (sendto failed)
    at java.net.PlainDatagramSocketImpl.send(Native Method) ~[?:?]
    at java.net.DatagramSocket.send(DatagramSocket.java:6 93) [?:?]
    at tuwien.auto.calimero.knxnetip.ConnectionBase.close (ConnectionBase.java:463) [213rg.openhab.binding.knx:1.11.0]
    at tuwien.auto.calimero.knxnetip.ClientConnection$Hea rtbeatMonitor.run(ClientConnection.java:432) [213rg.openhab.binding.knx:1.11.0]
    2018-12-29 18:34:18.508 [ERROR] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.178.201:3671: close connection - heartbeat communication failure
    java.io.IOException: Invalid argument (sendto failed)
    at java.net.PlainDatagramSocketImpl.send(Native Method) ~[?:?]
    at java.net.DatagramSocket.send(DatagramSocket.java:6 93) [?:?]
    at tuwien.auto.calimero.knxnetip.ClientConnection$Hea rtbeatMonitor.run(ClientConnection.java:409) [213rg.openhab.binding.knx:1.11.0]
    2018-12-29 18:34:18.511 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Received detach Event.


    Nach dem Versuch über die Basic UI ein Schalter zu bestätigen kommt noch folgende Meldung in der Log:
    2018-12-29 18:39:41.519 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 192.168.178.201:3671 in mode TUNNEL.


    die event.log schreibt zwar jede ausgeführte Aktion auf, sei sie vom KNX-System gesendet oder über die Basic UI, aber ausgeführt werden die Befehle der Basic UI nicht.

    Ich habe bereits OpenHab 2.2 2.4 und KNX Binding 1.11 und 2.4 ausprobiert, alles ohne erfolg.
    Wäre dankbar für Ratschläge oder Auskunft ob jemand von euch auch das Problem hat.




    #2
    Falls jemand von euch das Problem auch haben sollte,
    Es liegt wirklich an OpenHab.
    Mit der neusten Version 2.5 (Snapshot) habe ich keine Probleme mehr

    Kommentar


      #3
      Update hat doch nicht geholfen, irgendwie schein das nur sporadisch zu sein das Problem, also falls doch noch jemand ne idee hat, würde ich mich freuen....

      Kommentar


        #4
        Wie baust Du die Verbindung zu knx auf?

        Kommentar


          #5
          Ich bin mir nicht sicher was du genau meinst, hier ne kleine Auflistung:
          Openhab mit KNX Binding über KNXD auf einen USB-Modul (TUL TPUART) das an die KNX-Leitung angeschlossen ist

          Kommentar


            #6
            Genau das war mein Begehr
            Da Du schon knxd einsetzt, könntest Du spaßeshalber mal probieren, ob es mit dem ROUTER Mode besser klappt. knxd ist meist ohnehin schon für den Routing-Modus konfiguriert, auf openHAB-Seite reicht es, als Type ROUTER zu setzen, alle anderen Parameter der Bridge werden nicht gesetzt.

            Kommentar


              #7
              Danke erstmal für den Tipp, leider scheint das nicht zu helfen. und ich habe noch zusätzliche Probleme.
              Wenn ich auf Router stelle, kann ich zwar Signale noch empfangen (sehe ich z.B. wenn ich nen Taster drücke und sich der Wert in der Basic UI ändert) aber nicht senden, Über die UI kann ich dann nichts mehr schalten.
              Aber auch wenn ich es als ROUTER starte habe ich das Problem das der Router vor dem Raspberry gestartet sein muss damit ich wenigstens die Signale empfangen kann

              Kommentar


                #8
                Na ja, das ist aber auch klar, knxd muss zuerst laufen und darf auch keinesfalls beendet werden. Wenn nur eine Richtung funktioniert, spricht das dafür, dass Du eine ungeeignete localSourceAddr gesetzt hast. Wie sieht Deine exakte Konfiguration von openHAB KNX aus?

                Kommentar


                  #9
                  Ich habe noch noch mal mit der localSourceAddr rumgespielt aber auch ohne erfolg

                  hier meine Configs:

                  knx.things
                  Code:
                  Bridge knx:ip:BrueckenName [type="ROUTER"]
                  {
                      Thing device Aktorname [ ]
                   {
                          Type switch        : SchalterLichtWohnzimmer        "Licht"      [ ga="0/0/1+<0/0/2" ]
                   }
                  }
                  knx.items (falls interessant)
                  Code:
                  Switch          SchalterLichtWohnzimmer         "Lights 1 [%s]"      <light>         { channel="knx:device:BrueckenName:Aktorname:SchalterLichtWohnzimmer" }
                  knxd.conf (läuft mit systemd)
                  Code:
                  KNXD_OPTS="-e 0.0.1 -E 0.0.2:8 -DTRS -b tpuarts:/dev/knx1"
                  
                  START_KNXD=YES

                  Kommentar


                    #10
                    Und die 0.0.1 ist aus der Linie, an der das TPUART hängt?
                    Die physikalischen Adressen 0.0.2 bis 0.0.10 sind frei?

                    Kommentar


                      #11
                      Zitat von udo1toni Beitrag anzeigen
                      Und die 0.0.1 ist aus der Linie, an der das TPUART hängt?
                      Der TPUART muss auf der gleichen Linie sein wie meine Geräte? Is mir neu bzw ich glaube ich verstehe deine Aussage nicht

                      Aber auch wenn ich e 1.1.10 gebe und E 1.1.11:8 ändert das nix.

                      Meine Geräte sind derzeit nur ein Aktor 1.1.1 und ein Taster 1.1.2, also keine doppelten Adressen

                      Kommentar


                        #12
                        Nein, der TPUART muss nicht auf der gleichen Linie sein, allerdings hat die Hauptlinie 0 und die Mittellinie 0 eine spezielle Funktion, wenn ich mich richtig erinnere.

                        In meiner Testumgebung habe ich für knxd noch zusätzlich -i als Parameter, dann ist der default Port 6720, über den openHAB dann kommunizieren muss. Da ich allerdings ein knx/IP-Gateway besitze, nutze ich knxd nicht, das ist nur mit konfiguriert, falls ich mal was ausprobieren will.

                        Kommentar

                        Lädt...
                        X