eibd(war bcusdk) Fork -> knxd

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

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

[larsrosen]

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

[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

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

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

[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

[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

[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

[makki]

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

Natürlich ist das das Ziel.. Ist auch nicht so, das ich es nicht schon vor Jahren diplomatisch versucht hätte
Diesmal steht das Packaging (nicht nur Debian) aber in den Top3 der Prio-Liste!
Ehrlich, was mich - als reiner Anwender - schon immer nervt: ist wenn ein Paket z.B. kein gescheites Init-Script hat, so das es nach einem apt-get install "einfach automatisch funktioniert".
(was mit z.B. USB-TPUART, KNXnet/IP durchaus möglich ist)

Naja, das ist eine blöde, ziemlich lange Geschichte.. (die du vermutlich ja schon kennst)
Das erste Problem ist RSE mit der pth, dann die pthsem von mkoegler, weil die pth lt. RSE ja eh schon perfekt ist..
Wie auch immer, meine Meinung dazu: die pth ist nicht perfekt, die pthsem hat durchaus ihre Berechtigung. Mir fehlt aber ehrlichgesagt das Know-How, um sich in diese müssige Diskussion im Detail einzumischen.

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

Das sehe ich genauso,
timowi hat dazu im Prinzip schon einen Bug aufgemacht: https://github.com/Makki1/knxd/issues/5

Ich kenne ja nun Debian und dessen "Politik" seit Jahren - ein knxtool (stammt von JFMeesen und fasst im Endeffekt die meisten /examples zusammen) wärs glaube ich am ehesten(?)

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

Ok, denke eine Mischung aus doxygen und .md wird uns erstmal weiterbringen..

Makki

[makki]

Zum Thema USB: Verstehe ich das richtig, dass USB Support fuer knxd vielleicht komplett rausfallen soll?

Jein, ich stelle das nur zur Diskussion, weil es einfach eine Menge Aufwand macht. u.a. mir mal wieder einige Stunden, die sinnvoller zu investieren wären, als Schnittstellen zu testen, die eh nicht funktionieren werden

Selbst wenn ich nicht mit Full Speed mitschneiden kann ist das Senden von Commands doch immer noch sinnvoll oder nicht?

Full-Speed mit USB-SS is nich, keine Chance - das geht mitm TP-UART gerade knapp (ohne RTOS - mit kein Problem)

Makki

[RichiH]

Verzicht auf USB ist meiner Meinung nach keine Option. Allein schon die Programmierung ueber Netzwerk bei vorhandener USB Schnittstelle ist zu wertvoll.

Gibt es Richtwerte fuer die maximalen Paketraten? Zur Not kannst du ab Wert X warnen...

[RichiH]

Das sehe ich genauso,
timowi hat dazu im Prinzip schon einen Bug aufgemacht: https://github.com/Makki1/knxd/issues/5
Makki

Das liese sich wirklich am einfachsten mit `knx group write foo` `knx bcu read` etc pp loesen. Wenn was zusaetzlich installiert ist tut es einfach und muellt trotzdem keinem die Tab Completion voll. Wenn es nicht installiert ist sollte `knx` das abfangen und idealerweise Installationspfade nennen.

[makki]

Verzicht auf USB ist meiner Meinung nach keine Option. Allein schon die Programmierung ueber Netzwerk bei vorhandener USB Schnittstelle ist zu wertvoll.

Gibt es Richtwerte fuer die maximalen Paketraten? Zur Not kannst du ab Wert X warnen...

Ich strebe das ja auch nicht an (wenn es nach anderen ginge, würden USB-SS schon seit 4J auf einem gewissen Gerät nicht mehr gehen..)
Aber nachdem die USB-SS hier so gerne&oft empfohlen werden, wollte ich das nochmal loswerden: Finger weg von dem Zeug, besser bitte gleich KNXnet/IP.

Egal was wir da machen (FIFO-Queue, Tail-drop, Warnung beim start): es wird immer wieder zu Rückfragen kommen, warum Telegrammverluste vorkommen.
Und die Antwort ist müssig: "weils so ist"

Die Richtwerte stehen im KNX-Standard (sind - stark vereinfacht ausgedrückt! - je nach Telegramm-Grösse 30-50), die schafft jedoch ohne künstliche Handbremse in der ETS keine.
-> Ergo: wir brauchen wenn dann gute Langzeit-Tester! Freiwillige vor.

Das liese sich wirklich am einfachsten mit `knx group write foo` `knx bcu read` etc pp loesen. Wenn was zusaetzlich installiert ist tut es einfach und muellt trotzdem keinem die Tab Completion voll. Wenn es nicht installiert ist sollte `knx` das abfangen und idealerweise Installationspfade nennen.

Jep, an sowas in der Art dachte ich:

- Optional symlink "groupread" -> knxtool (so funktioniert es im Moment, abwärtskompatibel - aber nicht im Paket)
- Debian-Konform: "knxtool groupread xxx yyy"

Sollte doch ok sein, oder?

Makki

[RichiH]

Mach wenn dann von `groupread` auf `knxtool-groupread`; damit kann `knxtool` dann analog zu `git` einfach in seinem binary directory nachsehen und aus jedem `knxtool foo` ein `knxtool-foo` machen.

Und wenn es mal ne Erweiterung `knx bar` gibt wirft die der Entwickler einfach in's gleiche Verzeichnis und kann die Extension selber und disjunkt pflegen. Genauso machen es git-annex etc auch.