eibd(war bcusdk) Fork -> knxd

[tofele]

Ja, ich hatte das Problem erstmals im Oktober 2012, als ich das WG als Router verwenden wollte. Hier ist der damalige Thread.

Patrik hat das Ganze aber in der Zwischenzeit hervorragend reproduziert und dokumentiert (sowohl bei mir zu Hause mit meiner HW als auch völlig unabhängig) und ich würde mich eher an seine Fakten halten als an den alten Thread. Dieser soll nur als Hintergrundinfo dienen und enthält vermutlich irreführende Fakten und fehlerhafte Schlussfolgerungen.

Tom

[swiss]

@mjoe: cool Das Problem besteht schon länger und scheinbar sind Tomas Felner und ich bis jetzt die einzigen die dieses Problem haben oder festgestellt haben. Ich habe dazu damals eine kleine Testdoku verfasst um möglicht viele Fremdeinflüsse die das KNX Net/IP Routing Multicast beeinflussen. Wenn du die Sache mal untersuchen möchtest kann ich dir das PDF mal zukommen lassen.

[hronny]

Wie ist es eigentlich mit Fehlern die im Moment auftreten? Das Projekt steckt ja noch in den Kinderschuhen und hier wird sicher noch kräftig dran gearbeitet.
Soll man nun Fehler hier im Forum posten, oder alles in Englisch als "issues" auf der GIT Seite hinterlegen?
Zum Beispiel kann man den Code nicht so auf einem frischen Debian Wheezy compilieren. Weder mittels bootstrap noch über den debuild Befehl (wenn man den notwendigen Ordner verschiebt).

configure.ac:47: error: possibly undefined macro: AC_COMPILER_OPTION
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

Der Fehler (?) ist seit 2010 bekannt und kann nur damit korrigiert werden, in dem man:

aclocal --force

gegen das ersetzt:

aclocal -I m4 --force

bzw das ganze gleich weglässt und nur

autoreconf -i

benutzt (damalige hilfreichste Antwort von Herrn Kögler).

Ich kann bei mir ohne Probleme, dass mit mehreren virtuellen Maschinen nachstellen. Zudem habe ich ABB USB und Siemens IP Schnittstellen zum Testen hier.

[mjoe]

Wird es dann in absehbarer Zeit auch einen Fix für das Telegrammverdoppelungsproblem bei KNX IP Routing geben?

Kannst Du noch etwas mehr Details liefern, lässt sich das Problem reproduzieren, falls ja wie genau?

@makki, kannst mir den Issue sonst mal zuteilen.

[makki]

Wird es dann in absehbarer Zeit auch einen Fix für das Telegrammverdoppelungsproblem bei KNX IP Routing geben? Würde mir sehr am herzen liegen da erst durch dessen Behebung aus knxd im gegensatz zu eibd ein halbwegs vernünftiger KNX IP Router würde...

Patrik, erstmal ja.
Das Thema (von dir excellent analysierte!) steht durchaus auf dem "Radar", besteht jedoch in einer sehr speziellen Konstellation, wo ich mir bis heute nicht sicher bin, ob es ein Topologie- KNX- oder knxd-Problem ist.
Ich kann es so nicht direkt reproduzieren, jedoch durchaus verstehen.
Ein Haupt-problem sind die vielen anderen involvierten Komponenten;
KNXnet/IP Routing verwendet Multicast - und IP Multicast ist eben immernoch eine seltene "Freakshow"
(Eine kleine Episode dazu: ich habe 9/11 versucht, mit zwei Cisco Catalyst 5000 den 150 MA nen Livestream zu geben - gescheitert - letztlich gelang es mit OSS und Unicast)
-> Ich mache dafür aber mal einen Bug auf:
https://github.com/Makki1/knxd/issues/16

Für den Eigengebrauch hat es in den letzten paar Jahren gereicht. Ich hätte nun Lust mich bei OpenWrt als Maintainer für knxd zu bewerben. Oder möchtest du das lieber selbst machen?

Definitiv NEIN, ich will und wollte noch nichtmal den "Project-Lead" für diese ganze Aktion..
Aber irgendwer musste es ja machen..

Ich sehe mich selbst bei dieser Sache nur als Moderator.

Also, ich wäre brutal dankbar wenn sich jemand darum kümmert und die "Show-stopper" meldet (bzw. fixed) - nicht per Patch sondern lieber im source..

Makki

[Tru]

knxd auf OpenWrt

Egal, du kennst dich scheinbar damit aus, also bitte ich dich da dranzubleiben.

Für den Eigengebrauch hat es in den letzten paar Jahren gereicht. Ich hätte nun Lust mich bei OpenWrt als Maintainer für knxd zu bewerben. Oder möchtest du das lieber selbst machen? Ich würde mich auch mit der Rolle als Tester begnügen.
Im Prinzip bin ich ja bereits fertig. Es deckt den analogen Stand zu eibd und eibd-tools ab, aber inklusive init-Script und einer kommentierten Beispiel-config-Datei. Die zukünftige Aufgabe würde ich darin sehen die Entwicklung von knxd jeweils nachzuziehen.
Die einzige Schwierigkeit die ich noch habe ist das Cross-Compilieren der Sprach-APIs. Da ist es mir etwas schleierhaft wie das gehen soll, wenn während des Kompilierens ein "gen"-Binary erstellt und ausgeführt wird um Include-Dateien zu erstellen. Ich nehme an, das hat etwas damit zu tun die richtigen Parameter des Host-Systems einzubinden, aber wie das geeignet mit Cross-Compilieren funktionieren soll ist mir schleierhaft. Ich nutze deshalb einen Patch, der die Sprach-APIs raushält.

Gruss, Othmar

[swiss]

Wird es dann in absehbarer Zeit auch einen Fix für das Telegrammverdoppelungsproblem bei KNX IP Routing geben? Würde mir sehr am herzen liegen da erst durch dessen Behebung aus knxd im gegensatz zu eibd ein halbwegs vernünftiger KNX IP Router würde...

[makki]

Eigentlich wollte ich nur melden, dass ich an OpenWrt arbeite. Und das Init-script sollte nur demonstrieren wie ich auf meinem AP knxd einsetze.

Aber um in OpenWRT (sei das nun Up- oder Downstream) richtig reinzukommen, brauchts mehr als eine "Demo", ne ?

Zum Schluss nehme ich auch noch das Init-script in Angriff und ich werde es nicht mehr im Forum posten sondern für mich behalten so wie du .

Schön, ehrlich!
Das ich es für mich behalte, stimmt so aber nicht ganz; ich hatte es mehrfach, bereits vor Jahren, auf openwrt-devel gesendet.. Natürlich erfolglos..
Egal, du kennst dich scheinbar damit aus, also bitte ich dich da dranzubleiben.

Ich bereite das mal bei mir vor; dann kannst du pullen oder nicht. Ansonsten ziehe ich das parallel mit.

Du willst downstream. Upstream ist aus Sicht von Debian z.B. knxd.

Klingt gut, ich nehme das gerne an (sowie jeden Hinweis dazu). Auch direkte Schreibrechte.
Ich stelle nur eine Bedingung zum .deb: Stand heute gehts von Debian Lenny bis Ubuntu 14.10 -> das soll so bleiben!
Also keine unnötigen "neuen" Features, wir brauchen kein quilt oder patch um den Source passend (und maximal freaky+unübersichtlich) zu "verwurschteln"
-> Das soll wenn direkt rein!

Neuen Branch feature/makki-init und gut ist. Kann jeder ansehen wenn er will und wenn nicht dann einfach ignorieren.

Ok, ich checke das morgen mal ein (Stand bcusdk/eibd 0.0.5).. Auch die OpenWRT-Nummer, da hab ich auch schon "extrem-splitting" gemacht.

Ohne sauberen Namespace kommt das Paket niemals durch NEW

Eben, das ist Sonnenklar - deswegen bin ich gedanklich eben noch lange nicht beim Packaging.
Im Automake wurde es von timowi schon gesplittet.

-> Ich denke mittelfristig aber eher daran "knxtool" um die fehlenden Sachen "aufzupeppen", aber das ist eher v1.01 - eins nach dem anderen..
(ein packaging könnte dann immernoch entsprechende symlinks für groupread&co setzen..)

Nachdem nicht jeder Leser die Historie seit Jahren kennt: eibd (hier jetzt knxd) war Anfangs eher ein "Abfallprodukt" des BCUSDK, die libeibclient eine gute Fleissaufgabe, die "examples" eben Beispiele; es kam jedoch anders: der eibd hat im Bereich OSS EIB/KNX revolutioniert und wird heute von tausenden produktiv verwendet. Auch kommerziell.
Und die "examples" sind keine Beispiele mehr, sondern faktische produktiv Client-Programme für essentielle Anwendungen.
Insofern muss man da etwas umdenken..


Erstmal brauchts ein sauberes Release mit lange überfälligen Bugfixes - aber auch einigen Neuerungen.

Als Beispiel möchte ich nur die diversen "gewachsenen" commandline-Parameter nennen, da muss man dringend aufräumen: (--tpuarts-ack-all-group und --tpuarts-ack-all-individual z.B. ist eigentlich eher default, der Ansatz dazu direkt auf meinem Mist gewachsen - der Parameter geht aber so garnicht; sinnvoller wäre --tpuarts-dont-ack - in Sonderfällen)
Oder das -S bei -R oder -T implizit ist..
Das ist kein Vorwurf, es ist eben gewachsen aber an diesem Punkt hat man noch die Chance etwas aufzuräumen.. Vorher braucht man keine neuen Init-Scripts schreiben.

Love it or hate it, aber das wird auch ein systemd File brauchen.

Meistens liebe ich Debian/Ubuntu, manchmal hasse ich es auch.. So ist das nunmal.
systemd wird da am Ende sicher auch eine sinnvolle Sache! Aber s.o.: bitte nicht ohne Not auf Kosten der Abwärtskompatibilität.
Denn das ist was ich hasse: ohne jegliche Not (leider war/ist es sehr oft so!) Benutzer zum Update des gesamten Systems zwingen..
Nur weil der Entwickler/Maintainer "latest&greatest" bevorzugt, muss das noch lange keinen tieferen Sinn haben.

Makki

P.S.: Meine Debian-Packerl für bcusdk/eibd [mit hässlichen Patches] funktionieren bis heute von Debian Lenny bis Ubuntu 14.10, also kanns ja nicht ganz unmöglich sein.

PPS: ich freue mich aber über jedes Feedback und lasse dies gerne einfließen!

[RichiH]

Da gebe ich dir absolut recht. Momentan ist das (pre-Release 1.0) aber bei mir noch unter-priorisiert, da wir es so (pth vs. pthsem) eh nicht upstream schaffen können.

Ich bereite das mal bei mir vor; dann kannst du pullen oder nicht. Ansonsten ziehe ich das parallel mit.

Du willst downstream. Upstream ist aus Sicht von Debian z.B. knxd.

Mit Branch/Tag (Release X.Y) spricht doch aber nichts gegen native packages, denn da will ich (langfristig!) eigentlich hin..

Nein, native packages willst du nicht; non-native ist besser: https://wiki.debian.org/DebianMentor...ive_package.3F

Ich habe meine "individuelle" Version des Pakets mit Init-script&Co ja bewusst noch nicht ins GIT gestellt..

Neuen Branch feature/makki-init und gut ist. Kann jeder ansehen wenn er will und wenn nicht dann einfach ignorieren.

Und in der Diskussion bisher kamen ja auch schon gute Verbesserungsvorschläge auf (30+ wild benannte examples ohne jeglichen Namespace unter /usr/bin finde ich ja auch wirr!)

Ohne sauberen Namespace kommt das Paket niemals durch NEW

Ein Paket muss für mich ein gescheites Initi-Script haben und nach dem installieren - einfach funktionieren. Punkt.

Love it or hate it, aber das wird auch ein systemd File brauchen.

Richard

[Tru]

knxd auf OpenWrt

mit Verlaub, eine fixe IP-Adresse einer IPT-Schnittstelle im Init-script (das beim nächsten Update überschrieben wird) ist genau was ich an Linux manchmal hasse.

Eigentlich wollte ich nur melden, dass ich an OpenWrt arbeite. Und das Init-script sollte nur demonstrieren wie ich auf meinem AP knxd einsetze.
Bin unterdessen schon weiter, das Makefile holt jetzt die Source direkt aus GIT. Aktuell arbeite ich daran, eine libusb > 1.0.9 auf OpenWrt hinzubekommen.
Zum Schluss nehme ich auch noch das Init-script in Angriff und ich werde es nicht mehr im Forum posten sondern für mich behalten so wie du .

[christianwicke]

-> Ergo: wir brauchen wenn dann gute Langzeit-Tester! Freiwillige vor.
Makki

Ich habe eine Gira USB Schnittstelle und bin auch bereit, die langfristig zu testen.
Ich hatte mit der USB-Schnittstelle noch nicht so viele Probleme bis jetzt, außer dem eibd-Problem, dass nach langer Pause das erste Telegramm verloren ging. Dafür hatte ich einen Patch bereit gestellt. Mich stört eher, dass eibd manchmal nach ein paar Wochen hängt und durchgestartet werden muss. (Ist das evtl. auch ein USB-Problem?)

Damit nicht andere denselben Fehler machen und sich eine USB-SS kaufen: Könnte jemand ein paar Produktempfehlungen machen mit welchen Schnittstellen man günstig und stromsparend einen PC an KNX anschließen kann?

Danke
Christian

[makki]

Ich habe mich aus Interesse mal an der Kompilierung von knxd für OpenWrt versucht und eine lauffähige Version hingekriegt. Ich stelle hier das Makefile gerne zur Weiterentwicklung zur Verfügung. Es erstellt die beiden Pakete knxd und knxd-tools. Dazu gehört noch ein Patchfile, weil sich der Python Client nicht erstellen lässt, und meine Version des Init-Scripts.

Gruss, Othmar

Othmar, mit Verlaub, eine fixe IP-Adresse einer IPT-Schnittstelle im Init-script (das beim nächsten Update überschrieben wird) ist genau was ich an Linux manchmal hasse.
Sorry, das geht garnicht und dieser Parameter hat in keinem SystemV, Linux oder BSD (oder sonstwas) irgendwas hardcoded im Init-script verloren.
Genau damit macht man Linux zur "Freak-Show"

Makki

Edit: nur zur Erläuterung: das macht man unter Debian mit /etc/default/knxd und unter OpenWRT mit /etc/config .. z.B.

[makki]

`contrib/debian` ist eine schlechte Idee. Besser ist es, einen Debian Branch zu machen. Ansonsten wird das _extrem_ schnell ekelhaft. Von native package fang ich jetzt gar nicht an

Da gebe ich dir absolut recht. Momentan ist das (pre-Release 1.0) aber bei mir noch unter-priorisiert, da wir es so (pth vs. pthsem) eh nicht upstream schaffen können.
Mit Branch/Tag (Release X.Y) spricht doch aber nichts gegen native packages, denn da will ich (langfristig!) eigentlich hin..
Ich habe meine "individuelle" Version des Pakets mit Init-script&Co ja bewusst noch nicht ins GIT gestellt..
Und in der Diskussion bisher kamen ja auch schon gute Verbesserungsvorschläge auf (30+ wild benannte examples ohne jeglichen Namespace unter /usr/bin finde ich ja auch wirr!)

-> Dazu dient der Thread auch! Meinungen sammeln.

-->GitHub contrib/openwrt

Wird gerne angenommen (gits auch schon was, aber mit 15 wüsten Patches [root raus, ...], nicht besonders "gesellschaftstauglich")

Ein Paket muss für mich ein gescheites Initi-Script haben und nach dem installieren - einfach funktionieren. Punkt.

Makki

[RichiH]

`contrib/debian` ist eine schlechte Idee. Besser ist es, einen Debian Branch zu machen. Ansonsten wird das _extrem_ schnell ekelhaft. Von native package fang ich jetzt gar nicht an

Siehe z.B. https://github.com/RichiH/vcsh/network - saubere Branches fuer Sid, Backports, eventuell Ubuntu etc. Dazu noch mittelfristig Fedora oder was weiss ich und alles schoen sauber getrennt aber an einem Ort zentral verwaltet.

[RichiH]

-> Ergo: wir brauchen wenn dann gute Langzeit-Tester! Freiwillige vor.

Ich habe im Moment nur den ABB USB 1.1 und wollte mit einem RasPi ein IP Gateway bauen. Wenn ich eh ein IP Gateway brauche kann ich auch grad beides laufen lassen. Am besten waere es dann aber wenn knxd gleich mehrere parallele Inputs koennte und automagisch diffed. Die Statistiken kann ich dann gerne in anonymer Form turnusmaessig weitergeben.

Sollte ich auf ein bestimmtes IP Gateway setzen damit es mit knxd sauber laeuft?