Weinzierl KNX BAOS Module 838 kBerry

[mentor2k]

Noch ne kleine Info:

Hier bekomm ich nur den Fehler:

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 ...

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

[Tru]

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.

[Shotte]

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:

   - 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:

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.

[Shotte]

...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):

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

[ginePro]

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 ...)

[tabilia]

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

[lo4dro]

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ß

[soeffi]

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:

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

[soeffi]

Zwei Ergänzungen:

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

Dazu:

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

[tabilia]

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

[MrRum]

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

---

[predi ger many]

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

[FrankP]

Hallo,

mit folgenden Parametern konnte ich über die ETS reproduzierbar Geräte programmieren, nicht jedoch die Weinzierl-Schnittstelle direkt.

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[B] -T -B pace -R -S[/B] -c"

[ebber0]

Hallo,

bei mir funktioniert das eigentlich so wie ich mir das vorstelle mit den Parametern:

KNXD_OPTS="-e 0.0.1 -E 0.0.2:8 -u /tmp/eib -D -T -R -S -b ft12cemi:/dev/ttyAMA0"

Allerdings erst sobald eine Netzwerkverbindung besteht. Davor startet knxd nicht. Funktioniert das ganze auch irgendwie ohne Netzwerkverbindung falls diese mal fehlen sollte?