eibd(war bcusdk) Fork -> knxd

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

[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

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

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

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.

[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

[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

[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

[mjoe]

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

-->GitHub contrib/openwrt

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

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

[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

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

[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

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