eibd(war bcusdk) Fork -> knxd

[RichiH]

Noch ein Nachtrag: Aus Sicht der Paketierung ist es am Besten wenn alle eventuell vorhandenen Libraries vom System genommen werden wie ja bei libusb schon geschehen. Ansonsten muss man das haendisch rausfrickeln und das Patch-Set mitziehen. Geht schoener...

Zum Thema USB: Verstehe ich das richtig, dass USB Support fuer knxd vielleicht komplett rausfallen soll? Selbst wenn ich nicht mit Full Speed mitschneiden kann ist das Senden von Commands doch immer noch sinnvoll oder nicht?


Richard

[RichiH]

*Hust* Bitte/gerne auch PM oder RichiH auf freenode/OFTC/ircnet/GitHub *hust*

1) ich melde mich dazu (Debian) separat nochmal (es gibt ja schon packerl für den eibd, allerdings schlechte oder ziemlich "individuelle"..),

Offiziell aber eben nix. Und das sollte das Ziel sein.

In dem Kontext auch wichtig: Klare Namespaces. So generische Namen wie "groupwrite" als Binary kommen schlechter durch als "knx-groupwrite" oder gar git-style "knx groupwrite".

2) was genau meinst du mit "Markdown" ? (Beispiel-Projekt o.ä.)

Das ist die Syntax, die zB auch GitHub einsetzt. Siehe auch Daring Fireball: Markdown Syntax Documentation


Richard

[makki]

Zum Thema USB: Dank Forums-Freunden habe ich jetzt ein paar zum testen.

Ehrlich gesagt: Ich werde es nochmal - zum gefühlt fünften mal - mit neuer libusb ausgiebig testen, habe aber wenig Hoffnung, das es dieses mal nicht mit der Entscheidung endet: "unbrauchbar" = rauswerfen.

Mag alles sein, dass USB-Interfaces nicht mehr als 25 tps können. Für ein Einfamilienhaus reicht das aber vielleicht. Wenn es mit den max. 25 tps stabil laufen würde, dann wäre ich schon zufrieden.

Wir liegen real leider weit unter 25 tps..
(welche Workarounds dafür in der ETS alles implementiert wurden.. darf ich nicht weitersagen, kommt aber aus erster Hand..)

Mein Problem dabei:
- Es geht mit der ETS "scheinbar" (zwar schleichend langsam, aber es geht)
- Mitm knxd gehts nicht, weils nicht geht. Ich kann jedoch nichts daran ändern, ausser evtl. künstlich die Handbremse anzuziehen (was sowohl mkoegler als auch ich schon in den vergangenen Jahren mehrfach getan haben!)

Was tun? Weiter die Handbremse anziehen und sich sagen lassen eibd/knxd wären langsam oder instabil -
oder einfach die sehr aufwändige Unterstützung für eine schlecht designte USB-Schnittstelle, die nicht funktionieren kann, fallen lassen?
(ich möchte jetzt nicht ins Detail gehen, aber ich hing schon mit 16-Kanal Logic-Analyzer und Oszi an USB und KNX dafür..es geht so nicht, zumindest kein (i)ACK). Also das wird nie richtig gut werden, höchstens erträglich.

Ist denn ein Telegrammverlust im EFH weniger schlimm, als woanders?
Ich sage nein. Man will um 00:32 den Rolladen runterfahren und das Telegramm kommt nicht an?! Das geht garnicht..

Schwierige Frage, oder?

Makki

[makki]

Zu der lib/language-Diskussion möchte ich mich ehrlichgesagt weitestgehend enthalten und bin ansonsten bei Chris & Timo.
Ich liebe Qt, ich finde Boost auch toll, aber das ist alles keine Option fürn eibd (ausser jemand machts einfach)

Das "pth(sem)-Problem" muss man mittelfristig lösen, klar, aber das ist keine gute Idee für ein stabiles, erstes Release (ausser jemand machts -und testet es komplett auf zehn Plattformen mit fünf Schnittstellen, ..).
-> Wenn, sehe ich mittelfristig eher eine Umstellung auf pthread.

Eigentlich bräuchten wir ein automatisches Testsystem, wo man nach Änderungen sieht ob noch alles funktioniert und ob sich was gebessert hat...

Das wäre genial, die Methoden (z.B. 100.000 Telegramme, zählen ob alle ankommen, ..) hätte ich. Die HW zum testen auch..

Makki

P.S.: Bitte auch die parallel angestoßene Diskussion auf der bcusdk-devel ML beachten: https://sourceforge.net/p/bcusdk/mailman/bcusdk-list/

[timowi]

Ist in der ppa quelle der USB-patch (read-withing-callback) mit drinne?
Oder ist der patch schon generel im code drinne?

Beides nein.

Allerdings wird jetzt eine neuere libusb verwende. Vorher war es eine sehr alte und angeblich stark modifizierte Version. Es war lange Zeit ein Bug in libusb der genau das Problematisch Interface mit libusb_handle_events/libusb_handle_events_timeout und ziemlich auf die Beschreibung zum pathc passt. Der Bug ist glaub ich seit 2009 bekannt gewesen und wurde bis Version 1.0.9 (von 2012-04-20) nicht behoben.

Dannach gab es etwas Probleme mit libusb. Kein Release mehr nach 1.0.9 vom ursprünglichen Projekt. Dann ein Fork (libusbx). Seit 2014 wieder zusammengeführt unter libusb mit neuen Release (neuste Version 1.0.19). Die neue Homepage ist libusb Google findel leider immer noch als erstes die alte, mit 1.0.9 als letztes Release und ohne hinweis auf die neue...

Also erstmal testen, wie es mit der neuen Version läuft. Und falls es noch Probleme gibt, auf die neue Version anpassen. Ich habe leider keine Möglichkeiten zum testen. Eigentlich bräuchten wir ein automatisches Testsystem, wo man nach Änderungen sieht ob noch alles funktioniert und ob sich was gebessert hat...

[Chris M.]

nee, sieh dir mal den code an. eibd/knx ist in C++ geschrieben.

Hätte ich mal besser in den Code schauen sollen... Dann ist meine Präferenz klar beim C++ zu bleiben

boost oder C++11
Das wichtigste ist in C++11 übernommen worden. Setzt aber einen sehr neuen compiler vorraus. Boost ist aber auch nicht immer so einfach installieren...

Nö, das schließt sich nicht aus.
Aber ich denke auch, dass das was wir brauchen schon in der STL (ja, darf man so nicht nennen - macht aber trotzdem jeder...) drinnen ist. Boost sollten wir nur brauchen, wenn wir anders nicht mehr leicht weiter kommen.

[Qt:]
Mindestens das selbe Problem wie boost: nicht immer ganz einfach zu installlieren... Aber noch viel mehr oversized.

Ich nutze Qt seit 6 Jahren für embedded Entwicklungen unter Linux und halte da wirklich eine ganze Menge von. Für ein Projekt wie den knxd würde ich diese Abhängigkeit aber nicht unbedingt erzeugen wollen.

Ich hätte in diesem Fall auch nicht zu Qt gegriffen - aber ich wollte ja auch nur ausloten, was geplant ist

[larsrosen]

Ist in der ppa quelle der USB-patch (read-withing-callback) mit drinne?
Oder ist der patch schon generel im code drinne?

[Jockel]

Schreibe doch eine etwas ausführlichere BUILDING.mac-os Die kann dann ins doc/ Verzeichnis

Das mache ich gerne sobald ich etwas Zeit habe, vor Weihnachten wohl leider nicht mehr. Dazu sollte ich auch erst mal die Abhängigkeiten klären, ich bin mir nicht sicher welche ich da "zufällig" erfüllt habe, da schon installiert. Hatte auch noch keine Zeit mich um das pthsem Test problem zu kümmern...

QT ist schönes klassisches C++ mit hoher Portabilität auf den üblichen Systemen. D.h. für so ein Projekt erst mal eine gute Basis.

Ich nutze Qt seit 6 Jahren für embedded Entwicklungen unter Linux und halte da wirklich eine ganze Menge von. Für ein Projekt wie den knxd würde ich diese Abhängigkeit aber nicht unbedingt erzeugen wollen.

[timowi]

Bei dem Eindruck empfehle ich den Tellerrand mal wieder zu besuchen und Ausguck zu halten...

ja, da hab ich mal lieber nix zu geschrieben

C dürfte die Sprache der Wahl sein

nee, sieh dir mal den code an. eibd/knx ist in C++ geschrieben.

C++ dagegen bei einer Neuentwicklung - dank STL und BOOST, gepaart mit C++11

boost oder C++11
Das wichtigste ist in C++11 übernommen worden. Setzt aber einen sehr neuen compiler vorraus. Boost ist aber auch nicht immer so einfach installieren...

Klar, z.B. könnte man QT als Bibliothek nehmen (das gibt's auch Headless).
QT ist schönes klassisches C++ mit hoher Portabilität auf den üblichen Systemen. D.h. für so ein Projekt erst mal eine gute Basis.

Mindestens das selbe Problem wie boost: nicht immer ganz einfach zu installlieren... Aber noch viel mehr oversized.

... könnte es durchaus Sinn machen sich nur auf POSIX zu limitieren - auch wenn's deutlich anstrengender ist.

definitiv nicht! Dann müsste jede Menge in den code gezogen werden. Für solche Fälle könnte jemand mal einen portablen Stack in C schreiben.
eibd/knxd ist was anderes!

pth funktioniert zur Zeit sehr gut. Dabei wird es wohl auch erstmal bleiben. Ein wechsel ist nicht so einfach wie zuerst gedacht. Ich halte es aber nicht für Sinnvoll das hier zu diskutieren.

[Chris M.]

Zur Programmiersprache: Will ich nicht entscheiden, ich hätte normales C genommen. Mein Eindruck ist, dass C++ sich nie richtig gegenüber C durchgesetzt hat und die zusätzliche Komplexität die Vorteile auffrisst.

Bei dem Eindruck empfehle ich den Tellerrand mal wieder zu besuchen und Ausguck zu halten...

C dürfte die Sprache der Wahl sein, wenn der bestehende Code maßvoll weiterentwickelt werden soll (ich vermute das wird unsere Zielrichtung sein).
C++ dagegen bei einer Neuentwicklung - dank STL und BOOST, gepaart mit C++11, lässt sich dort ein sehr sauberer (= wartbarer!) Code schreiben der dennoch sehr performant ist und klein compiliert. (Man muss - wie immer - schon wissen was man tut, wer beliebig wütet und meint eine gigantische Klassenhierachie bauen zu müssen, möglichst noch mit virtueller und mehrfacher Vererbung, kann natürlich auch die Vorurteile bedienen)

Mit Native oder Bibliothek weiß ich nichts recht anzufangen. Gibt es Bibliotheken, die man statt des normalen select() nehmen kann?

Klar, z.B. könnte man QT als Bibliothek nehmen (das gibt's auch Headless).
QT ist schönes klassisches C++ mit hoher Portabilität auf den üblichen Systemen. D.h. für so ein Projekt erst mal eine gute Basis.
Aber da unser Ziel "klein und minimaler Ressourcen-Verbrauch" ist, evtl. gar Embedded-Systeme (=> möglichst gar kein dynamisches Speichermanagement!), könnte es durchaus Sinn machen sich nur auf POSIX zu limitieren - auch wenn's deutlich anstrengender ist.

[Tru]

Ich habe soeben knxd erfolgreich produktiv in Betrieb genommen.

Läuft auf Ubuntu 14.04.1 LTS i386 zusammen mit einem IP Gateway im Tunnelmodus.

Gruss, Othmar

[christianwicke]

Meine persönliche Meinung: die USB-SS (nicht TP-UART) sind alle unbrauchbar.
(Das hat nichts mit USB zu tun, sondern simplen Dingen, wie 64k Frames, einem falschen Design [HID], das kann nicht gehen..)
Ich drehe den Spiess mal um: beweise mir das Gegenteil bei 25-30 tps

Mag alles sein, dass USB-Interfaces nicht mehr als 25 tps können. Für ein Einfamilienhaus reicht das aber vielleicht. Wenn es mit den max. 25 tps stabil laufen würde, dann wäre ich schon zufrieden.

Christian

[timowi]

Falls es Jemandem hilft: Ich hab mal Ubuntu Packete des aktuellen knxd erstellt:

https://launchpad.net/~timo-wingende...tu/knxd-daily/

[timowi]

1. libtoolize muss separat installiert werden, ich habe es aus den macports genommen. Dann muss in der bootstrap.sh libtoolize durch glibtoolize ersetzt werden (und /opt/local/bin muss im Suchpfad enthalten sein)

Ok, das ist auch eine Besonderheit der Verwendung der git Quellen. In einem release Quellpacket wird schon die configure und die ganzen Makefile.in enthalten sein

Warum der pthsem test fehlschlägt ist mir noch nicht klar, am $LD_LIBRARY_PATH wie vom configure script vorgeschlagen liegt es jedenfalls nicht..

Nach dem fehlgeschlagenen configure die config.log ansehen. Da steht es drin. Oder irgendwo hochladen. (z.B. Pastebin.com - #1 paste tool since 2002!)

Schreibe doch eine etwas ausführlichere BUILDING.mac-os Die kann dann ins doc/ Verzeichnis

[Jockel]

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:

1. libtoolize muss separat installiert werden, ich habe es aus den macports genommen. Dann muss in der bootstrap.sh libtoolize durch glibtoolize ersetzt werden (und /opt/local/bin muss im Suchpfad enthalten sein)

2. Zusätzlich braucht es die Bibliotheken argp-standalone und pthsem aus den macports. Ev. auch noch weitere Abhängigkeiten, die ich schon installiert hatte.

1. Der configure aufruf dann als ./configure --without-pth-test CPPFLAGS='-I/opt/local/include' LDFLAGS="-L/opt/local/lib"

Warum der pthsem test fehlschlägt ist mir noch nicht klar, am $LD_LIBRARY_PATH wie vom configure script vorgeschlagen liegt es jedenfalls nicht..

Damit kann ich die Binaries erzeugen, ob die noch mehr tun als den Hilfetext auszugeben habe ich aber noch nicht getestet. Es gibt auch einige warnings vom Compiler, das scheint auf den ersten Blick aber nichts OSX spezifisches zu sein.