eibd(war bcusdk) Fork -> knxd

[mjoe]

Ich stelle hier das Makefile gerne zur Weiterentwicklung zur Verfügung.

-->GitHub contrib/openwrt

[Tru]

knxd auf OpenWrt

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

[makki]

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.

Das musst du mir erklären?!
Beispiel-Projekt? (in einfach, bei git bin ich froh das Frontend 10% zu kapieren..)
Wie gesagt: #1 Prio ist eben auch Abwärtskompatibilität..

Das Debian-Paket für Upstream können wir aber auch noch etwas schieben, weil es IMHO eh spätestens an der pth(sem)-Sache scheitern wird.
Trotzdem kann man schonmal darauf hinarbeiten..

Makki

[makki]

...
Die KNX-USB-Spezifikation ist ein wunderbares Beispiel für kaputtes Design in bester Konnex-Tradition. Man berühmt sich eines Standards und vergewaltigt gleichzeitig die Standards anderer Leute bis an die Berstgrenze.

Danke für die Unterstützung! Und auch schön zusammengefasst.
Denn das hört man zwar von jedem (KNX)Entwickler im persönlichen Gespräch - seit Jahren - unisono, aber nur wenige fassen es in klare Worte..

Und nochmal, nur zu Sicherheit: das alles hat rein garnichts mit den USB TP-UART zu tun! (das benutzt CDC-ACM/USB->Seriell - geht aber nicht mit der ETS)

-> Damit möchte ich die "USB"-Diskussion hier aber auch bitte beenden, darum gehts nämlich garnicht.
USB-SS bleiben drin, solange vertretbar und sich jemand darum kümmert, fertig.
(Ich habe nur keine Lust 100x zu erklären, warum es nicht optimal geht..)

Was ist denn das Problem mit den USB Interfaces? HID an sich sollte eigentlich kein Problem darstellen.

Das Problem ist das Design, der eibd/knxd muss(müsste) als Linienkoppler/Bereichskoppler oder Endgerät (i)ACKs senden, das geht mit den USB-SS schlicht nicht.

Genügend Hardware übrig?

Soll heissen: ich kann hier jederzeit eine Testumgebung aufbauen (USB nur bis Ende Januar, da ausgeliehen)

Makki

[timowi]

Ich finde usb support (wenigsten auf dem level von eibd 0.0.5) muss drinnen bleiben. Von mir aus mit Warnungen oder mit den Kommandozeilenoption --ich-weiss-das-usb-nicht-funktioniert-moechte-es-aber-trotzdem. Sonst ist es halt kein vollständiger Ersatz für den eibd.

Was ist denn das Problem mit den USB Interfaces? HID an sich sollte eigentlich kein Problem darstellen. Haben die nochmal irgendwas blödes oben drauf gesetzt? Ist nur das empfangen ein größeres Problem oder kann auch beim Senden grundsätzlich was schief gehen?

BTW: In Wiesbaden hat man sich auch an einem KNX-USB-Linux-Treiber versucht, ich habe aber keine Ahnung ob der irgendwie "besser" ist als die wiener Implementierung KNX USB Linux driver - so oder so löst der das generelle Problem auch nicht KNX USB Linux driver

Naja, zumindest verwendet es din HID Treiber. Die libusb ist dafür eigentlich keine gute Wahl. Das hier wäre wohl noch besser geeignet: HID API for Linux, Mac OS X, and Windows

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

Genügend Hardware übrig? Falls möglich sollten wir auf jeden Fall ein automatisches Testsystem anstreben. Ich dachte dabei schon an mehr als nur Telegramme zählen. Eher verschiedene (vor allem auch viele einfache) Testfälle definieren. Wenn sich die Ergebnisse geändert haben gibts halt ne Fehlermeldung.
Benötigt würde dafür ein PC, Netzteil/Drossel, und wenigsten USB,IP,TPUART

Ich hab mir schon vorgenommen wenigstens mal ein System aufzubauen das automatisch verschiedene Konfigurationen kompiliert und grundsätzlich testet. Das wird sich fürs erste aber auf die Kompatibilität beschränken.

[StefanW]

Ich denke dass KNX-USB mittelfristig zu Gunsten von KNXnet/IP langsam aussterben wird. Neue USB-SS gab es seit längerer Zeit nicht mehr. Lieber ein sauber implementiertes KNXnet/IP als ein USB welches broken by design ist.

Wenn ich hier anfügen darf, ich gebe Dir recht, was USB und HID-Design mit aufgepropftem Cemi usw. betrifft.

USB ist schon mit Low-Speed (USB 1.0, Eingeführt 1996) mit 1,5 MBit/s um das fünfzehnfache schneller als KNX-TP, von Datenraten heutiger USB-Spezifikationen bis in den Gigabit-Bereich hinein ganz zu schweigen. Das Problem ist nicht USB ansich sondern das Protokoll drumherum.

Eine USB-Schnittstelle ohne HID und ohne aufgesetztem Protokoll, sondern einfach nur relativ natives KNX von USB über TP-UART auf KNX wird auch allen Bandbreitenanforderungen gerecht. Man bräuchte nur noch einen nativen Treiber anstatt dem Falcon, dann kann damit auch die ETS und wäre deutlich billiger und einfacher als KNXnet/IP.

lg

Stefan

[timowi]

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.

Ich finde die Idee von Makki schon ok so. Ich glaub das hast
du nur etwas falsch verstanden. Es soll nur noch wenig tools geben. (z.B. knxtool für alles mit dem bus, knxsuper um den knxd selber zu konfigurieren/überwachen)
Es werden dann nur diese beiden binaries installiert.

Der symlink oder auch umbenennen ist ein Trick für die Abwärtskompatibilität. Normalerweise soll das nicht installiert werden. Wenn aber ein anderes Programm groupwrite benötigt, reicht es dafür einen symlink auf knxtool zu erstellen, und das verhält sich dann wir das alte groupwrite.

[MarkusS]

BTW: In Wiesbaden hat man sich auch an einem KNX-USB-Linux-Treiber versucht, ich habe aber keine Ahnung ob der irgendwie "besser" ist als die wiener Implementierung KNX USB Linux driver - so oder so löst der das generelle Problem auch nicht http://www.cs.hs-rm.de/~werntges/proj/knxusb01.html

[MarkusS]

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.

Gefühlt ist es eher nicht so dass die KNX-USB-SS hier deutlich präferiert werden, der Trend geht mittlerweile doch eher zu KNXnet/IP. Die USB-SS werden hier häufiger als KNX-Anbindung für den Gira Homeserver empfohlen, gelegentlich auch allgemein weil sie vermeintlich "einfach" sind plug, play, forget.

Die KNX-USB-Spezifikation ist ein wunderbares Beispiel für kaputtes Design in bester Konnex-Tradition. Man berühmt sich eines Standards und vergewaltigt gleichzeitig die Standards anderer Leute bis an die Berstgrenze.

Ich vermute die Genese der Application Note 037/02 lief so: "Wir brauchen was neues, das RS232 stirbt aus" - "was gibts da noch?" - "Firewire?" - "zu kompliziert, zu teuer, hat nicht jedes Notebook" - "USB?" - könnte gehen - hat sich zwischenzeitlich durchgesetzt" - "aber UM GOTTES WILLEN, dann müssen wir dafür ja einen TREIBER schreiben!!!" - "hm, vielleicht kommen wir da ohne Treiber hin, USB HID kann jedes Betriebssystem, das würde sogar auf Linux oder Mac funktionieren" - "USB HID? Wir wollen aber keine [Tastatur|Maus|Joystick] bauen?" - "macht nix, da gibt es ein obskures USB HID Generic Device, das könnten wir nehmen"

Frei nach der Sparkassen-Werbung ("wir machen das mit den Fähnchen") einigt man sich auf den kleinsten gemeinsamen Nenner und kaschiert die immanenten Fehler in der Software.

Ich denke dass KNX-USB mittelfristig zu Gunsten von KNXnet/IP langsam aussterben wird. Neue USB-SS gab es seit längerer Zeit nicht mehr. Lieber ein sauber implementiertes KNXnet/IP als ein USB welches broken by design ist.

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

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

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.

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

[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

[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