Ankündigung

Einklappen
Keine Ankündigung bisher.

Weinzierl KNX BAOS Module 838 kBerry

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

    Noch ne kleine Info:

    Hier bekomm ich nur den Fehler:

    Code:
    knxd /etc/knxd.conf
    E00000084: [ 1:main] There is no KNX addr= in section 'main'.
    F00000109: [ 1:main] Error setting up the KNX router.
    Hier rennt der knxd sofort los und funktioniert auch ...

    Code:
    knxd /etc/knxd.ini
    Layer 4 [ 1:main        0.000] initialized
    I00000131: [ 1:main] 0.14.28:672ca39: knxd /etc/knxd.ini
    Layer 4 [ 1:main        0.000] setting up
    Layer 0 [ 4:log/main    0.000] State setup
    Layer 3 [ 5:server/Server     0.000] registerLink: 5:server
    ich verstehs nur nicht, warum das über die .conf nicht geht

    Kommentar


      Zitat von mentor2k Beitrag anzeigen
      ich verstehs nur nicht, warum das über die .conf nicht geht
      wenn knxd nur ein Argument bekommt, muss es ein INI-File sein. Sonst müssen es all die Parameter sein, welche intern über knxd_args automatisch in ein INI-File umgewandelt werden.

      EIB/KNX, VISU mit knxd + linknx + knxweb, Steuerbefehle via SMS und Email mit postfix + procmail

      Kommentar


        Hallo Weinzerl User,

        auch ich muss mich wegen Problemen bei der Inbetriebnahme des BAOS 838 Moduls melden. Ich will für einen Bekannten den Raspi vorbereiten, da ich mich waghalsig aus dem Fenster gelehnt habe und meinte, dass ich das schnell ausgesetzt bekomme. Nun hänge ich schon 2 Tage daran und weiß leider nicht weiter.

        Ich kann zwar in der Kommandozeile knxd starten, aber leider scheitern bei mir die systemd Aufrufe. Ich habe folgendes gemacht:
        - Raspi3B+ mit Wienzerl BAOS 838 Modul
        - openhabian image installiert und eingerichtet
        - bt und weitere Notwendigkeiten eingerichtet bzw. deaktiviert
        - über openhabian-config die knxd Erweiterung installiert (dauerte lange, da er alles kompiliert hat. Es ist jetzt die Version: knxd 0.14.28:81e6e7b-emipatch )
        - Konfigurationsdatei nun in /etc/default/knxd
        - "knxd -t 0xffff -f 9 -e 1.1.240 -E 1.1.241:4 -i 6720 -D -T -R -S -b ft12cemi:/dev/serial0" in Kommandozeile funktioniert, nur dass ich dann in ETS5 alle Nachrichten 4x sehe
        --> gibt es da ggf. einen Konflikt mit meinem 2. Raspi mit knxd aber mit USB KNX Stick? In der Router Spalte werden für die 4 identischen Nachrichten die Zahlen 0, 2, 4 und 6 gelistet... soll aber hier jetzt nicht gelöst werden
        - die knxd.service Datei erwartet eine konfigurationsdatei bei /etc/default/knxd. Als Parameter habe ich schon alles mögliche probiert:
        Code:
           - KNXD_OPTIONS="-f9 -t1023 -e 1.1.240 -E 1.1.241:4 -DTRS -b ft12cemi:/dev/ttyAMA0"
           - KNXD_OPTIONS="-e 1.1.240 -E 1.1.241:4 -u/tmp/eib -B single -t 1023 -b ft12cemi:/dev/ttyAMA0 -D -TS -c"
           - KNXD_OPTIONS="-f 9 -t 1023 -e 1.1.240 -E 1.1.241:4 -u/tmp/eib -B log -A delay=30 -B pace -b ft12cemi:/dev/ttyAMA0 -D -B log -TRS -i 6720"
           - und noch einiges weiteres
        Das Ergebnis ist überall gleich. Der Aufruf "sudo systemctl restart knxd.service" führt dazu, dass nicht umgehend zurückgesprungen wird, sondern eine ganze Weile vergeht, in der auch fleißig KNX Traffic in /var/log/syslog geloggt wid, aber nach einer Weile ein Abbruch stattfindet mit der folgenden Fehlermeldung:
        Code:
        Jan  9 19:16:33 RaspiHBS knxd[4086]: Layer 0 [12:B.ft12cemi/ft12wrap   88.860] Sequence jump
        Jan  9 19:16:35 RaspiHBS systemd[1]: knxd.service: Start operation timed out. Terminating.
        Jan  9 19:16:35 RaspiHBS knxd[4086]: Layer 4 [ 9:B.ft12cemi/Conn       90.116] Stopping
        Jan  9 19:16:35 RaspiHBS knxd[4086]: Layer 5 [ 9:B.ft12cemi/Conn       90.116] up => >down
        Jan  9 19:16:35 RaspiHBS knxd[4086]: Layer 5 [ 9:B.ft12cemi/Conn       90.116] Stopping
        Jan  9 19:16:35 RaspiHBS knxd[4086]: Layer 0 [17:B.ft12cemi/log        90.116] Stop
        Jan  9 19:16:35 RaspiHBS knxd[4086]: Layer 2 [16:B.ft12cemi/ft12cemi   90.116] CloseL2
        Jan  9 19:16:35 RaspiHBS knxd[4086]: Layer 0 [17:B.ft12cemi/log        90.116] Stopped
        Jan  9 19:16:35 RaspiHBS knxd[4086]: Layer 5 [ 9:B.ft12cemi/Conn       90.116] >down => down
        Jan  9 19:16:35 RaspiHBS knxd[4086]: Layer 4 [ 9:B.ft12cemi/Conn       90.116] down
        Jan  9 19:16:35 RaspiHBS knxd[4086]: Layer 4 [ 9:B.ft12cemi/Conn       90.116] down
        Jan  9 19:16:35 RaspiHBS knxd[4086]: Layer 4 [ 9:B.ft12cemi/Conn       90.117] is down
        Jan  9 19:16:35 RaspiHBS knxd[4086]: Layer 0 [17:B.ft12cemi/log        90.117] Closing
        Jan  9 19:16:35 RaspiHBS knxd[4086]: Layer 0 [13:B.ft12cemi/log        90.117] Closing
        Jan  9 19:16:35 RaspiHBS knxd[4086]: Layer 0 [15:B.ft12cemi/log        90.117] Closing
        Jan  9 19:16:35 RaspiHBS knxd[4086]: Layer 2 [14:B.ft12cemi/FT12_ser   90.117] Close
        Jan  9 19:16:35 RaspiHBS systemd[1]: Failed to start KNX Daemon.
        Jan  9 19:16:35 RaspiHBS systemd[1]: knxd.service: Unit entered failed state.
        Jan  9 19:16:35 RaspiHBS systemd[1]: knxd.service: Failed with result 'timeout'.
        Über hilfreiche Tips würde ich mich unglaublich freuen.
        Zuletzt geändert von Shotte; 09.01.2019, 19:23.

        Kommentar


          ...jetz habe ich es mit viel probieren und weiteren Installationen, Updates und Konfigurations-Parameter hin bekommen:

          - die openhabian-config installation rückgängig gemacht und alles rausgeschmissen
          - den master von git ausgechekct und nach Anweisung compiliert und installiert
          - in der /etc/default/knxd Datei alles auskommentiert
          - in der /etc/knxd.conf Datei die folgenden Parameter benutzt (Router Option habe ich vorübergehend rausgenommen, da ich schon einen Router im System habe):
          Code:
          KNXD_OPTS="-e 1.1.240 -E 1.1.241:4 -u/tmp/eib -B log -A address=15.15.255 -B single -b ft12cemi:/dev/ttyAMA0 -D -B log -TS -c"
          Auf einmal ging es, obwohl ich auch zuvor diese Parameter schon mal ausprobiert hatte. Komisch, aber wenn es jetzt geht, dann will ich mal nicht meckern.

          Vielen Dank für Eure gute Arbeit,
          Shotte

          Kommentar


            Hallo Smurf,

            ich hatte diesen Thread mal mitgelesen.
            Gäbe es das Ganze auch in einer so kurz wie möglichen, aber so ausführlich wie nötigen zusammengefaßten Anleitung für Newbies (Schritt für Schritt nachvollziehbar und überprüfbar), um das Set-up von Raspberry (3 B+) u. kBerry erfolgreich durchzuführen?

            Ich möchte mir die HW anschaffen und damit nach und nach meine KNX-Installation mobil bedienbar machen (und dann auch noch weitere Funktionalitäten hinzufügen, z.B. Homekit (Bridge), Alexa ...)

            Kommentar


              Hallo ginePro,

              hier im Forum gibt es z.B. eine detailierte Anleitung wie man das zum Laufen bekommen kann: https://knx-user-forum.de/forum/proj...berry-am-rpi-1
              Ich kenne dein Hintergrundwissen nicht, aber wenn du kein Bastler/Linux-Poweruser bist würde ich eher ein richtiges IP Interface empfehlen als die Baos Lösung. Damit muss man sich einfach zeitlich intensiver beschäftigen und benötigt mehr Hintergrundwissen.

              Viele Grüße,
              Samuel

              Kommentar


                Hallo ginePro,

                die Erstinstallation ist etwas aufwendig. Seitdem funktioniert der knxd bei mir auf dem RPI sehr gut.
                Openhab mach damit viel weniger Zicken.

                Gruß
                --
                Gruß
                Lothar

                Kommentar


                  Hallo zusammen,

                  ich hänge mich mit meinen Problemchen hier mal an, ich versuche auch gerade das kBerry zum laufen zu bekommen.

                  Was ich bisher gemacht habe:
                  • Hardware: Rapberry Pi 3 mit Raspbian oder Tinkerboard (Pin-kompatibel zu RPi) mit Armbian --> Ergebnis ist bisher gleich für beide
                  • KNX: Eine Spannungsversorgung mit Diagnose und ein MDT Glastaster verbunden. Beide Jungfräulich vom Werk (habe keine andere Schnittstelle zum Programmieren)
                  • Bluetooth deaktiviert, ttyAMA0 mit udev-Regel versorgt
                  • knxd kompiliert und installiert (0.14.29-5)
                  • KNXD_OPTS="-f9 -e 1.1.200 -E 1.1.201:5 -u/tmp/eib -B single -b ft12cemi:/dev/ttyS1 --Name=tinker --Discovery --Tunnelling --Routing --Server --GroupCache
                  • knxd startet und läuft (laut journal)
                  • ETS5 läuft in VirtualBox (arbeite sonst unter Linux), Netzwerkbrücke eingerichtet
                  Wo es klemmt:
                  • Automatische Erkennung der Schnittstelle in der ETS: Hat schonmal geklappt, im Moment kann ich es aber nicht reproduzieren. Ich vermute, dass Multicast ein Problem ist, da ich alles über WLAN verbinde, vielleicht mag die Fritzbox das nicht, oder die Verbindung in die Virtualbox
                  • Alternativ kann ich aber die Schnittstelle manuell konfigurieren, dann steht da in der ETS "OK" und die ETS bekommt eine Adresse aus dem Bereich von -E zugewiesen
                    • Problem 1: Manchmal bekommt die ETS doch keine phys. Adresse, dann steht da nur 0.0.0. ETS neu starten hilft, ist aber sicher keine Dauerlösung
                  • Ich kann auf die Geräte eine physikalische Adresse schreiben (im Programmiermodus).
                    • Aber: Die ETS beschwert sich beim Programmieren über einen Timeout.
                    • Die phys. Adresse scheint aber trotzdem anzukommen, denn ich kann danach mit der ETS prüfen ob das Gerät im Programmiermodus ist oder nicht (ok)
                    • Problem 2: Von den Aktoren kommen nur die KNX Broadcasts an 0/0/0 zurück, mehr nicht, siehe Busmonitor:
                  Code:
                  LPDU: B0 11 CB 11 02 60 80 66 :L_Data system from 1.1.203 to 1.1.2 hops: 06 T_CONNECT_REQ
                  LPDU: B0 11 CB 11 02 61 43 00 A4 :L_Data system from 1.1.203 to 1.1.2 hops: 06 T_DATA_CONNECTED_REQ serno:00 A_DeviceDescriptor_Read Type:00
                  LPDU: B0 11 CB 00 00 E1 01 00 75 :L_Data system from 1.1.203 to 0/0/0 hops: 06 T_DATA_XXX_REQ A_IndividualAddress_Read
                  LPDU: B0 11 02 00 00 E1 01 40 FC :L_Data system from 1.1.2 to 0/0/0 hops: 06 T_DATA_XXX_REQ A_IndividualAddress_Response
                  LPDU: B0 11 CB 11 02 60 81 67 :L_Data system from 1.1.203 to 1.1.2 hops: 06 T_DISCONNECT_REQ
                  LPDU: B0 11 CB 11 02 60 80 66 :L_Data system from 1.1.203 to 1.1.2 hops: 06 T_CONNECT_REQ
                  LPDU: B0 11 CB 11 02 61 43 00 A4 :L_Data system from 1.1.203 to 1.1.2 hops: 06 T_DATA_CONNECTED_REQ serno:00 A_DeviceDescriptor_Read Type:00
                  LPDU: B0 11 CB 11 02 61 43 00 A4 :L_Data system from 1.1.203 to 1.1.2 hops: 06 T_DATA_CONNECTED_REQ serno:00 A_DeviceDescriptor_Read Type:00
                  LPDU: B0 11 CB 11 02 61 43 00 A4 :L_Data system from 1.1.203 to 1.1.2 hops: 06 T_DATA_CONNECTED_REQ serno:00 A_DeviceDescriptor_Read Type:00
                  LPDU: B0 11 CB 11 02 61 43 00 A4 :L_Data system from 1.1.203 to 1.1.2 hops: 06 T_DATA_CONNECTED_REQ serno:00 A_DeviceDescriptor_Read Type:00
                  LPDU: B0 11 CB 11 02 60 81 67 :L_Data system from 1.1.203 to 1.1.2 hops: 06 T_DISCONNECT_REQ
                  LPDU: B0 11 CB 11 02 60 80 66 :L_Data system from 1.1.203 to 1.1.2 hops: 06 T_CONNECT_REQ
                  LPDU: B0 11 CB 11 02 61 43 00 A4 :L_Data system from 1.1.203 to 1.1.2 hops: 06 T_DATA_CONNECTED_REQ serno:00 A_DeviceDescriptor_Read Type:00
                  LPDU: B0 11 C9 11 02 60 81 65 :L_Data system from 1.1.201 to 1.1.2 hops: 06 T_DISCONNECT_REQ
                  In Ermangelung besseren Wissens hänge ich mal noch ein Log mit -t 1022 von dieser Situation an.

                  Prinzipiell: Die ETS sollte doch eigentlich inzwischen mit dem kBerry "normal" benutzbar sein, oder?

                  Ich wäre sehr dankbar wenn jemand einen Hinweis hätte ob ich prinzipiell etwas falsch mache, ob ich woanders noch schauen kann oder insbesondere wenn Smurf die kryptische Log-Datei auseinandernehmen könnte.

                  Vielen Dank!


                  Stefan
                  Angehängte Dateien
                  Zuletzt geändert von soeffi; 27.04.2019, 08:51.

                  Kommentar


                    Zwei Ergänzungen:

                    Vom Raspberry Pi scheint das Multicast jetzt wieder zu funktionieren, damit arbeite ich also mal weiter.

                    Dazu:
                    Zitat von soeffi Beitrag anzeigen
                    Problem 1: Manchmal bekommt die ETS doch keine phys. Adresse, dann steht da nur 0.0.0. ETS neu starten hilft, ist aber sicher keine Dauerlösung
                    habe ich gerade den Wireshark bemüht: Hier versucht die ETS eine Verbindung vom Typ "device_mgmt_connection" aufzubauen, und bekommt nur die 0.0.0 zurück. Ob das nun so gewollt ist oder nicht kann ich nicht beurteilen - scheint aber nicht die Ursache von Problem 2 zu sein.

                    Hat jemand eine Idee zu letzteren - warum der Monitor (knxtools vbusmonitor1 - ist das überhaupt richtig und was ist der unterscheid zu vbusmonitor2, busmonitor* usw.?) keine Pakete als Antwort bekommt?

                    Danke nochmal!
                    Stefan

                    Kommentar


                      Hallo,

                      seit neuem funktioniert bei mir das Programmieren nicht mehr, ständig Timeouts, es sieht so aus als ob die Antworten der Geräte beim Programmieren nicht bei der ETS eintreffen... alles andere (Monitor, Gruppenadressen ansprechen etc. funktioniert bestens).

                      Probleme begannen als ich ein Gira L1 programmieren wollte, ich habe dann den knxd und ETS auf die aktuellsten Versionen geupdatet.
                      Inzwischen kann ich nur noch das BAOS Modul selber aus der ETS programmieren, alles andere geht nicht.
                      Ich habe diverse Startparameter getestet, auch die mit denen es in der etwas älteren knxd-Version mit der ETS 5.5 noch ging klappen nicht mehr.

                      Im github gibt es aktuell ja auch die selbe Fehlerbeschreibung. Ist hier schon etwas bekannt woran das liegt und wie ich mir dabei helfen könnte?
                      Ich kann gerne auch heute Abend ein genaues Log erstellen / posten.

                      VG
                      Samuel



                      Kommentar


                        Ich hab genau das gleiche Problem.... er scheint die Geräte zu programmieren, aber ETS5 meldet immer wieder ein Timeout.... Hat jemand einen Tip? Das MDT Netzteil signalisiert auch immer wieder einen Bus-Error.....

                        Signalisierungen an den Bus gehen, Monitoring auch. Nur leider eben nicht das Programmieren!

                        Anbei die Logfiles:


                        https://drive.google.com/file/d/1Kqz...ew?usp=sharing

                        und


                        https://drive.google.com/file/d/10aE...ew?usp=sharing
                        Zuletzt geändert von MrRum; 31.05.2019, 16:46.

                        Kommentar


                          Smurf


                          Hallo Smurfix,

                          kannst du mal bitte deine Empfehlung für den KNXD_OPTS String und den für die KNXD Command Line String posten?

                          Du hast ja das Modul und hast es auch in KNXD implementiert. Und aus den Threads hier im Forum wird man nicht so recht schlau.

                          Die Verwendung des aktuellen Master-Branches ist glaube ich ok?

                          Viele Grüße
                          Predi

                          Kommentar

                          Lädt...
                          X