eibd(war bcusdk) Fork -> knxd

[Maniac]

KNXD_OPTS="-t 65535 -e=0.0.2 -D -T -R -S -i --GroupCache -b ipt:192.168.6.33"

und

/usr/lib/knxd/groupcachereadsync ip:localhost 1/0/21

Also das lokale Socket wird angelegt, der knxd lauscht auf Port 6720. Und wie gesagt, der Busmonitor zeigt ja auch den Traffic auf dem Bus an. Genauso funktioniert ein

groupreadresponse ip:localhost 1/0/21

Nur der GroupCache scheint nicht zu funktionieren... hast Du eine Idee oder einen Ansatz, woran das liegen kann?

[l0wside]

Ich nochmal... kann mir noch jemand bzgl. groupcacheread helfen? Offensichtlich funktioniert soweit alles wenn der knxd läuft, sogar die ETS funktioniert darüber und zeigt im Gruppenmonitor die Telegramme an.

Wie rufst du groupcacheread auf, und welche Parameter hat der knxd bei dir (lässt sich ggf. über ps ax herausfinden)?
Vermutlich wird das Socket nicht angelegt oder gefunden.

Max

[michaeldamm2]

Gibs für den raspberry pie schon fertige pakete? würde gern den eibd geben den knxd tauschen?

[Maniac]

Ich nochmal... kann mir noch jemand bzgl. groupcacheread helfen? Offensichtlich funktioniert soweit alles wenn der knxd läuft, sogar die ETS funktioniert darüber und zeigt im Gruppenmonitor die Telegramme an.

Allerdings kann ich auf dem Server selbst offenbar kein cacheread nutzen. Die Meldung ist immer

Read failed: No such file or directory

Fehlt evtl. noch irgendwo eine Berechtigung? Wie / wo schreibt er den Cache? Oder fehlt mir noch ein Parameter? Ich habe knxd mit --GroupCache gestartet, ändert aber nichts.

Hier mal ein Auszug aus dem Log. Wenn ich das richtig sehe, wird die Read-Anfrage auf den Bus gesendet und wird auch (von 1.1.4) beantwortet. Trotzdem tritt dann ein Timeout auf...

Aug 24 22:34:16 t-server knxd[21089]: Layer 8(025CEB70,55DB7FC8) New Connection
Aug 24 22:34:16 t-server knxd[21089]: Layer 8(026042A0,55DB7FC8) ClientConnection Init
Aug 24 22:34:16 t-server knxd[21089]: Layer 8(026042A0,55DB7FC8) RecvMessage(006): 00 74 08 15 00 00
Aug 24 22:34:16 t-server knxd[21089]: Layer 4(025DF220,55DB7FC8) GroupCacheRead 1/0/21 1 0
Aug 24 22:34:16 t-server knxd[21089]: Layer 3(0259D150,55DB7FC8) Enqueue L_Data low from 0.0.0 to 1/0/21 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Aug 24 22:34:16 t-server knxd[21089]: Layer 3(0259D150,55DB7FC8) RecvData L_Data low from 0.0.0 to 1/0/21 hops: 06 T_DATA_XXX_REQ A_GroupValue_Read
Aug 24 22:34:16 t-server knxd[21089]: Layer 8(025AD8E0,55DB7FC8) Send_Route L_Data low from 1.9.0 to 1/0/21 hops: 06 T_DATA_XXX_REQ A_GroupValue_Read
Aug 24 22:34:16 t-server knxd[21089]: Layer 1(025ADE20,55DB7FC8) Send(011): 29 00 BC E0 19 00 08 15 01 00 00
Aug 24 22:34:16 t-server knxd[21089]: Layer 0(025ADE20,55DB7FC8) Send(017): 06 10 05 30 00 11 29 00 BC E0 19 00 08 15 01 00 00
Aug 24 22:34:16 t-server knxd[21089]: Layer 2(025DF540,55DB7FC8) Send L_Data low from 1.9.0 to 1/0/21 hops: 06 T_DATA_XXX_REQ A_GroupValue_Read
Aug 24 22:34:16 t-server knxd[21089]: Layer 8(025AD8E0,55DB7FC8) TunnelSend 1
Aug 24 22:34:16 t-server knxd[21089]: Layer 1(025ADE20,55DB7FC8) Send(015): 04 01 06 00 29 00 BC E0 19 00 08 15 01 00 00
Aug 24 22:34:16 t-server knxd[21089]: Layer 1(025DF540,55DB7FC8) SendTunnel(015): 04 43 00 00 11 00 BC E0 19 00 08 15 01 00 00
Aug 24 22:34:16 t-server knxd[21089]: Layer 1(025DF680,55DB7FC8) Send(015): 04 43 00 00 11 00 BC E0 19 00 08 15 01 00 00
Aug 24 22:34:16 t-server knxd[21089]: Layer 0(025ADE20,55DB7FC8) Send(021): 06 10 04 20 00 15 04 01 06 00 29 00 BC E0 19 00 08 15 01 00 00
Aug 24 22:34:16 t-server knxd[21089]: Layer 0(025DF680,55DB7FC8) Send(021): 06 10 04 20 00 15 04 43 00 00 11 00 BC E0 19 00 08 15 01 00 00
Aug 24 22:34:16 t-server knxd[21089]: Layer 0(025DF680,55DB7FC8) Recv(010): 06 10 04 21 00 0A 04 43 00 00
Aug 24 22:34:16 t-server knxd[21089]: Layer 1(025DF680,55DB7FC8) Recv(004): 04 43 00 00
Aug 24 22:34:16 t-server knxd[21089]: Layer 0(025ADE20,55DB7FC8) Recv(010): 06 10 04 21 00 0A 04 01 06 00
Aug 24 22:34:16 t-server knxd[21089]: Layer 1(025ADE20,55DB7FC8) Recv(004): 04 01 06 00
Aug 24 22:34:16 t-server knxd[21089]: Layer 8(025AD8E0,55DB7FC8) TUNNEL_ACK
Aug 24 22:34:16 t-server knxd[21089]: Layer 0(025DF680,55DB7FC8) Recv(021): 06 10 04 20 00 15 04 43 06 00 2E 00 BC E0 19 00 08 15 01 00 00
Aug 24 22:34:24 t-server knxd[21089]: Layer 1(025DF680,55DB7FC8) Recv(015): 04 43 06 00 2E 00 BC E0 19 00 08 15 01 00 00
Aug 24 22:34:24 t-server knxd[21089]: Layer 1(025DF680,55DB7FC8) Send(004): 04 43 06 00
Aug 24 22:34:24 t-server knxd[21089]: Layer 0(025DF680,55DB7FC8) Send(010): 06 10 04 21 00 0A 04 43 06 00
Aug 24 22:34:24 t-server knxd[21089]: Layer 0(025DF680,55DB7FC8) Recv(021): 06 10 04 20 00 15 04 43 07 00 29 00 BC E0 11 04 08 15 01 00 40
Aug 24 22:34:24 t-server knxd[21089]: Layer 1(025DF680,55DB7FC8) Recv(015): 04 43 07 00 29 00 BC E0 11 04 08 15 01 00 40
Aug 24 22:34:24 t-server knxd[21089]: Layer 1(025DF680,55DB7FC8) Send(004): 04 43 07 00
Aug 24 22:34:24 t-server knxd[21089]: Layer 0(025DF680,55DB7FC8) Send(010): 06 10 04 21 00 0A 04 43 07 00
Aug 24 22:34:24 t-server knxd[21089]: Layer 1(025DF540,55DB7FC8) Recv L_Data low from 1.1.4 to 1/0/21 hops: 06 T_DATA_XXX_REQ A_GroupValue_Response (small) 00
Aug 24 22:34:24 t-server knxd[21089]: Layer 3(0259D150,55DB7FC8) Enqueue L_Data low from 1.1.4 to 1/0/21 hops: 06 T_DATA_XXX_REQ A_GroupValue_Response (small) 00
Aug 24 22:34:24 t-server knxd[21089]: Layer 3(0259D150,55DB7FC8) RecvData L_Data low from 1.1.4 to 1/0/21 hops: 05 T_DATA_XXX_REQ A_GroupValue_Response (small) 00
Aug 24 22:34:24 t-server knxd[21089]: Layer 8(025AD8E0,55DB7FC8) Send_Route L_Data low from 1.1.4 to 1/0/21 hops: 05 T_DATA_XXX_REQ A_GroupValue_Response (small) 00
Aug 24 22:34:24 t-server knxd[21089]: Layer 1(025ADE20,55DB7FC8) Send(011): 29 00 BC D0 11 04 08 15 01 00 40
Aug 24 22:34:24 t-server knxd[21089]: Layer 0(025ADE20,55DB7FC8) Send(017): 06 10 05 30 00 11 29 00 BC D0 11 04 08 15 01 00 40
Aug 24 22:34:24 t-server knxd[21089]: Layer 8(025AD8E0,55DB7FC8) TunnelSend 1
Aug 24 22:34:24 t-server knxd[21089]: Layer 1(025ADE20,55DB7FC8) Send(015): 04 01 07 00 29 00 BC D0 11 04 08 15 01 00 40
Aug 24 22:34:24 t-server knxd[21089]: Layer 0(025ADE20,55DB7FC8) Send(021): 06 10 04 20 00 15 04 01 07 00 29 00 BC D0 11 04 08 15 01 00 40
Aug 24 22:34:24 t-server knxd[21089]: Layer 0(025ADE20,55DB7FC8) Recv(010): 06 10 04 21 00 0A 04 01 07 00
Aug 24 22:34:24 t-server knxd[21089]: Layer 1(025ADE20,55DB7FC8) Recv(004): 04 01 07 00
Aug 24 22:34:24 t-server knxd[21089]: Layer 8(025AD8E0,55DB7FC8) TUNNEL_ACK
Aug 24 22:34:24 t-server knxd[21089]: Layer 4(025DF220,55DB7FC9) GroupCache timeout
Aug 24 22:34:24 t-server knxd[21089]: Layer 8(026042A0,55DB7FC9) SendMessage(006): 00 74 00 00 08 15
Aug 24 22:34:24 t-server knxd[21089]: Layer 8(026042A0,55DB7FC9) ClientConnection closed

[Maniac]

Das -R muss vor dem -S stehen.

Danke, das funktioniert soweit scheinbar. Wenn ich den tracelevel auf 65535 stelle, sehe ich im Syslog auch einiges an Aktivität und mit groupswrite kann ich auch schalten.
groupcachereadsync funktioniert dagegen nicht. Ich bekomme immer die Meldung "Read failed: No such file or directory". Auf dem alten System geht es. Ist da jetzt noch ein Kommunikationsproblem oder funktioniert vielleicht nur groupcachereadsync nicht so richtig nach dem Umbau?

Außerdem muss ich unter Ubuntu offenbar noch den Parameter -i mit anhängen, obwohl in der knxd.conf Datei steht, das würde systemd für mich machen. Ich hab mit systemctl enable knxd.service den Service aktiviert und er hat damit auch den Symlink auf die knxd.socket Datei angelegt, trotzdem lauscht der knxd nicht auf Port 6720. Füge ich den -i Parameter in die Parameterliste ein, geht es...
Ich bin in systemd leider auch noch nicht wirklich fit, gibt es da noch ein Problem? Muss ich da noch was konfigurieren?

[Maniac]

Danke, werde ich heute mal testen. Noch was anderes, wo ja schon einige den Code studiert haben: Startet der eibd irgendwie immer wieder automatisch neu? Hab den auf dem alten Server per init.d Skript gestartet. Das stoppen hat jetzt aber nicht funktioniert, auch wenn ich den Prozess mit kill -9 gekillt hat, taucht er mit gleichen Parametern mit neuer ID wieder auf. Konnte ihn erst tot bekommen, nachdem ich das binary umbenannt hatte. Da ich den jetzt seit 3 Jahren nie bewusst stoppen musste, weiß ich nicht, ob das schon immer so war oder der bei mir nur irgendwie amok gelaufen ist...

[Tru]

Wie muss ich denn die Parameter anpassen?

Das -R muss vor dem -S stehen.

[Maniac]

Ok, wo bin ich mit Fragen richtig aufgehoben? Ich versuche es mal hier...

Also, auf meinem alten Server läuft der eibd mit folgenden Parametern:

/usr/bin/eibd -t 1023 -D -T -S -R -d -i --pid-file=/var/run/eibd.pid ipt:192.168.6.33

Starte ich den knxd mit den gleichen Parametern, bekomme ich die Meldung:

Option '-S' starts the multicast server.
-T/-R/-D/-n after or without that option are useless.

Und der Prozess ist wieder beendet. Wie muss ich denn die Parameter anpassen?

Ich bin im aktuellen Stand (von gestern abend) im master Zweig. Meine Hardware ist die IP-Schnittstelle IPS100REG von Jung. Nutzen möchte ich den eibd/knxd sowohl lokal auf dem Server (fhem & groupwrite per php), als auch als Gateway für die ETS4 (was mit dem bisherigen Server und eibd auch alles wunderbar funktioniert). Ich denke also, es muss irgendwie an den Parametern liegen.

[Tru]

Ganz klar ist mir trotzdem noch nicht, wo nun die hauptsächliche Kommunikation statt findet? Ist die alte bcu-Mailingliste noch aktiv? Die letzten Einträge sahen mir eher nach chinesischem Spam aus.
Dann gibt es auch noch die englischsprachige Google Group? Oder ist das auch nicht mehr aktuell? Ich habe noch keinen Zugan dazu beantragt...

In diesem Thread und noch in https://knx-user-forum.de/forum/%C3%B...tester-gesucht diskutieren die Mitglieder des KNX Forum auf Deutsch. Die Google Group wurde angelegt, damit losgelöst von diesem Forum breit diskutiert werden kann, gross aktiv geworden ist die Group aber noch nicht. Die Mitarbeit am Code läuft direkt über http://github.com/knxd/knxd.

[Maniac]

Ich würde mich auch gern mit einklinken... ich habe derzeit auch den eibd auf einem Ubuntu Server laufen. Da ich einen neuen Server aufgesetzt habe, habe ich auch nach einer aktuellen Version vom eibd gesucht und diesen Thread hier gefunden.
Ich bin Software-Entwickler und würde auch gern unterstützen. Allerdings ist meine Zeit derzeit sehr eingeschränkt und "low-level" C/C++ und Unix-Builds sind auch nicht gerade meine Stärke.
Ich könnte ggf. eine kleine Anleitung beisteuern, wie der knxd auf einem Ubuntu-Server (15.04) gebaut wird (man muss ja noch ein wenig zusätzlich installieren). Das habe ich offensichtlich (in meiner VM) erfolgreich hinbekommen, müsste dann zu Hause jetzt mal testen, ob der knxd genauso funktioniert wie der eibd auf meinem alten Server...

Edit:
Ich habe mich nun doch durch den Thread gequält. Ganz klar ist mir trotzdem noch nicht, wo nun die hauptsächliche Kommunikation statt findet? Ist die alte bcu-Mailingliste noch aktiv? Die letzten Einträge sahen mir eher nach chinesischem Spam aus.
Dann gibt es auch noch die englischsprachige Google Group? Oder ist das auch nicht mehr aktuell? Ich habe noch keinen Zugan dazu beantragt...

Da hier ja jetzt schon ganz oft die commits und merges in den master-Branch usw. besprochen wurden, würde ich nochmal git-flow in den Raum werfen. Wundert mich eigentlich, dass das noch niemand vorgeschlagen hat. Bei uns in der Firma ist das mittlerweile standard und eine in meinen Augen sehr saubere Organisation des Code-Stands.
Hier eine Kurzübersicht: http://danielkummer.github.io/git-flow-cheatsheet/ Mit ein bißchen googlen findet man sicher noch mehr dazu, einfache Fragen kann ich sicher auch beantworten...
Die Idee ist im wesentlichen einen develop Branch anzulegen, in dem die Entwicklung stattfindet (quasi der "trunk" bei svn). Neue Features usw. natürlich weiterhin in zusätzlichen Branches. Aber was als "ok / stabil" erachtet wird, wird dann in develop gemergt. In master gibt es dann nur noch die releases, d.h. ab und an schnappt sich jemand den Stand von develop und macht daraus ein Release. Damit sind dann z.B. auch hotfixes einfacher zu integrieren.
Weitere Info dazu: http://nvie.com/posts/a-successful-git-branching-model/

[maitscha]

Ich würde auch gern auf den knxd wechseln, da dieser wesentlich mehr Infrastruktur (Build-Scripts für Debian-Packages, Daemon-Scripts, usw) mitbringt. Ich möchte den knxd dabei als Router für einen Python-Service (das über Socket mit dem knxd kommuniziert, um Werte zu lesen und zu schreiben) und gelegentlich auch zum Programmieren über die ETS3 verwenden. Ich verwende einen Weinzierl KNX IP Linemaster 760. (bisher hab ich den eibd mittels "--Server --Discovery --GroupCache --listen-tcp --no-tunnel-client-queuing --eibaddr=1.1.2 ipt:192.168.1.2" gestartet).

Wo bekomm ich denn am besten Info mit welchem Layer2 Treiber ich den knxd starten sollte (mal abgesehen von den ganzen anderen Parametern)? Für welchen Anwendungsfall starte ich den knxd als Multicast Server?

[l0wside]

Hört sich sinnvoll an. Matthias, lieferst du noch einen Kommentar? Oder liegst du gerade am Mittelmeer am Strand?

Max

[MGK]

Hier mal meine Meinung als Anwender:

die Kommandozeilen Parameter sollten auf jeden Fall gehen und gleich bleiben, damit man knxd als Ersatz für den eibd einfach so einsetzen kann.

neue Optionen (wie mehrere Schnittstellen) würde ich da aber nicht einbauen, da sollen die Leute sich auf die config Datei umstellen.

und ich würde evt. noch einen Hinweis einbauen: wenn man den mit den Kommandozeilen Parametern startet. "Using command line options is deprecated, please use the config file /etc/knxd.cfg" oder so was.

Gruss und danke für die Arbeit!
Michael

[l0wside]

Ich würde das Ganze etwas elaborierter machen. Schließlich brauchen wir in Zukunft backend-spezifische Optionen zB für das Filtern von Gruppenadressen. Die Idee, aus der .INI-Datei die Argumente zu generieren, halte ich da für wenig zielführend.

Die vorgeschlagene Struktur sieht mir ganz plausibel aus. Ich hatte den bestehenden Code so verstanden, dass die Ergebnisse des Argumente-Parsens in arg landen. Allerdings werden sich so nicht mehrere Interfaces abbilden lassen.

Welche Darreichungsform wäre denn passender? Klassischerweise hätte ich so was gemacht:

• Abstrakte Basisklasse ConnectionDesc
• Davon abgeleitete Klassen ConnectionDescIP, ConnectionDescTPUART, ...
• Als Ergebnis des Parsens ein std::list<ConnectionDesc>

Gegenvorschläge willkommen, Noch ein paar Fragen zum Thema Legacy:

• Muss die Variante via Kommandozeilenparameter hinterher noch funktionieren?
• Wenn ja:
  • Müssen die Kommandozeilenparameter kompatibel zu den jetzigen sein?
  • Muss nur der bestehende Satz an Parametern unterstützt werden, oder sollen auch per Kommandozeile mehrere Interfaces konfiguriert werden können?

Max

[Smurf]

Sven aus Hannover Der eibd heißt jetzt knxd. Programmieren via ETS5 funktioniert, ich setze die Pigator-Schnittstelle und den TUL in meinem Haus mehrfach ein.

Aktuelle Probleme:

* man muss das Programmieren bei "größeren" Geräten teilweise mehrfach probieren (wahrscheinlich Paketverluste; an der Ursache forsche ich noch). Aber irgendwann sagt die ETS "OK" und dann ist das auch so.

* ETS5 kann nur Multicast (in der ETS das Interface auswählen, knxd mit -DRS gestartet); Tunnelmodus (in der ETS den knxd auswählen, knxd mit -DTS gestartet) klemmt, wohl wegen eines falschen Datentyps. Multicast wiederum setzt voraus, dass du nicht über WLAN gehst oder dein Router nicht zu hirntot dafür ist.