eibd(war bcusdk) Fork -> knxd

[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

[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!

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

[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

[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

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

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

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

[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

[mjoe]

Wenn du die Sache mal untersuchen möchtest kann ich dir das PDF mal zukommen lassen.

Ja schick mir doch mal das pdf per pn oder an 'dev at mjoe dot org', danke

[makki]

Ich hab es eben mal auf die Schnelle unte OSX probiert die Quellen zu übersetzen. Das funktioniert soweit mit folgenden Ergänzungen zur Anleitung auf GitHUB:

Es wäre toll - damit das nicht untergeht(!!), wenn du das ins Github-Wiki schreiben würdest - oder in ein README.osx o.ä.
Mir einfach den github-Namen mitteilen, wenn das zu unübersichtlich erscheint (was ich durchaus verstehen würde..) bitte kurze Info, dann versuche ich es die Tage einzupflegen.

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.

Patrik hat das sehr detailiert dokumentiert (nicht von WG irritieren lassen, es geht rein um eibd/knx; ich selbst habe auch eibd aufm WG gepflegt..)
Ich habs an den Issue https://github.com/Makki1/knxd/issues/16 angehängt, sachdienliche Hinweise sind gerne willkommen

Makki

[kfed]

Ich hab gerade ein Gentoo Linux ebuild für eibd fertiggestellt als ich auf den thread hier stieß - Jetzt wird daraus wohl ein knxd ebuild , wenn Interesse besteht würde ich das gerne zur Verfügung stellen.

Ich hab eine Gira USB Schnittstelle, d.h. damit könnte ich euch testend zur Seite stehen. Ich hätte zwar vor demnächst auf ein usb-tp-uart oder knx/ip umzustellen, weil auch der gira homeserver ist nicht stabil mit dem usb-hid dings... Aber das heißt ja nicht, dass ich die gira Schnittstelle wegwerfe. Möchte alles auf opensource umstellen, dass mein Haus auch in 20 Jahren noch sicher von aussen Steuerbar ist, d.h. ich werde die nächste Zeit mit coding rund um das Thema verbringen.

Wegen pthsem austauschen (falls das noch der plan ist), würde ich C++11 threading als Ziel nehmen. Mag sein, dass man da jetzt aktuelle compiler für braucht, aber bis der code umgebaut ist sind die compiler auch schon wieder weiter verfügbar. Und die threading libs im C++ standard werden wohl sehr lange überleben bzw. gewartet.

[makki]

Ich hab gerade ein Gentoo Linux ebuild für eibd fertiggestellt als ich auf den thread hier stieß - Jetzt wird daraus wohl ein knxd ebuild , wenn Interesse besteht würde ich das gerne zur Verfügung stellen.

Danke, #17 ist bereits gemerged

Ich hab eine Gira USB Schnittstelle, d.h. damit könnte ich euch testend zur Seite stehen.

Gerne!
Für einen stabilen Betrieb empfehle ich aber weiterhin (USB) TP-UART oder KNXnet/IP..

Wegen pthsem austauschen (falls das noch der plan ist), würde ich C++11 threading als Ziel nehmen. Mag sein, dass man da jetzt aktuelle compiler für braucht, aber bis der code umgebaut ist sind die compiler auch schon wieder weiter verfügbar. Und die threading libs im C++ standard werden wohl sehr lange überleben bzw. gewartet.

Sehe ich im Prinzip zwar genauso (wobei ich eher pthread präferiere) aber wiegesagt: das halte ich eher für ein Ziel einer Version 1.1+ - es sollen "alte" (OpenWRT z.B.) die einfach nen ganz anderen Zyklus haben keinesfalls ausgeschlossen werden.
-> Also wenn vorerst eine parallele Branch.

Zumindest nicht ohne Not, denn es funktioniert mit pthsem ja 24x7x365 (x8 Jahre); ich hasse "Update-Zwang".
"Bezahlen" muss man das damit, das es so nicht in Debian kann, aber damit leben wir jetzt auch schon seit ewig..

Makki

[christianwicke]

Pull Request für USB-Timeout-Problematik

Hallo Michael, ich habe den Patch von damals (BCU SDK with eibd / Mailing Lists) überarbeitet und als Pull-Request bereit gestellt. In dem Original-Patch war eine Variable nicht initialisiert, dass ist nun gefixt.
Mit dem Patch wird der USB-Timeout nun richtig behandelt. Bisher wurde nach 30 Sekunden ohne Telegramm (Timeout) anschließend das erste Telegramm nicht erkannt.
Ich bin noch git-Anfänger. Falls ich den den Pull-Request nicht richtig erstellt habe, melde dich bitte noch mal.

Was anderes: Git es eine Übersicht, welche Threads es in knxd gibt und auf welche Semaphoren sie benutzen und mit wem sie Daten austauschen? Wenn es noch gar gar nichts gibt, mache ich mich bei Gelegenheit mal daran.

Christian

[Tru]

knxd auf OpenWrt

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, ich habe es unterdessen geschafft, dass die Pakete pthsem und knxd (inklusive knxd-tools) auf github.com/openwrt/packages aufgenommen worden sind, ebenso libesmtp und linknx. Diese werden nun jeweils im Trunk automatisch erstellt. Ich bin jetzt am Finetuning und nehme Anregungen gerne entgegen.

knxd muss noch ohne USB-Support gebaut werden, weil OpenWrt bei libusb-1.0 auf Version 1.0.9 steht und der Maintainer keine Veranlassung sieht auf Version 1.0.19 zu gehen. Ich glaube er stört sich an der Abhängigkeit von udev, aber da blicke ich nicht durch.

Gruss, Othmar