eibd(war bcusdk) Fork -> knxd

[Jockel]

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

Nach einigen Jahren Erfahrung mit USB in anderen Bereichen kann ich das nur so unterschreiben!

[makki]

Also meine Erfahrung ist halt dass ich als Python-Programmierer eine API erwarte, die im weitesten Sinne "pythonic" ist, also dem Muster entspricht wie die meisten anderen APIs auch funktionieren. Das ist sicher bei den anderen Sprachen nicht anders. Mit einer nach Sprache X umgewurschtelten C-API hantieren zu müssen führt dann nur zu Frust. Ging mir jedenfalls so.

Aber klar, man kann natürlich die Auto-APIs erstmal drinlassen und parallel sowas wie einen "native" client entwickeln. Ich persönlich würde halt keine Energie darauf verschwenden ohne Feedback, dass die Auto-APIs auch tatsächlich genutzt werden.

Nun, ich drücke es jetzt mal bewusst überspitzt sarkastisch aus: Als Perl-Entwickler erwarte ich eine total ineffiziente, idiotische, mit Speicherlecks geradezu bestückte API

Wie gesagt: es dürfte wegen mir auch beides geben, die bessere gewinnt mittelfristig, fertig.
Das soll der Markt/die Community entscheiden.

Hallo Michael,
super, dass Du Bewegung reinbringst in die Entwicklung.
Ich habe mir auch schon einige Gedanken gemacht, wie wir mit der ptsem umgehen können: Es muss einen Grund geben warum kaum jemand pthsem und pth verwendet und weiterpflegt. Der Mainstream geht jedenfalls woanders hin.

Hmm, da bin ich echt komplett anderer Meinung.. Der Grund ist IMHO eher, weil SW-Entwickler von mindestens vier Cores und zwei GB RAM ausgehen dürfen.
Das war, wird und ist nicht mein Ziel. Der knxd soll&wird (so wie der eibd) problemlos auf einem Single-Core mit 32MB RAM und 0.5-1W laufen.

Ich denke, am besten sollten wir versuchen, ganz auf Threads zu verzichten. Der Vorteil ohne Threads ist, dass der Code einfacher zu debuggen und zu verstehen ist. Außerdem verwendet pth intern soweit ich weiß sowieso keine echten Linux-Threads sondern bildet alles auf einen Linux-Thread ab.

Ehrlich, da kommt mir nur die Galle hoch.
Das ist die Denke von "Strom kommt aus der Steckdose", "Ist es zu langsam braucht man halt nen Core-i7", "4GB mehr", ..

Statt Threads sollte es eine globale poll-Schleife geben, die auf KNX und allen außeren Connections (TCP, Socket) lauscht.

Schonmal was von "select" gehört ?

]Als ich damals mich in libusb eingearbeitet hatte, um die verlorenen Telegramme zu finden, habe ich genau so eine Programmstruktur in in der Doku von libusb gefunden.

Mit einer USB-Schnittstelle (HID) ist "realtime" (25+ Telegramme) nicht machbar.

Ich würde hier auch unterstützen, vermutlich aber erst im neuen Jahr. Ich würde mit libusb anfangen. Die andere Hardware kann ich nicht testen.

Gerne, jede Hilfe ist willkommen!
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

Noch was: Solange wir noch pthsem haben: Kannst Du meinen Patch von damals für die verlorenen gegangenen usb-Telegramme einspielen: BCU SDK with eibd / Mailing Lists

Danke und Gruß

Christian

Teste ich noch diese Woche (hab mir heute zwei USB-SS "reserviert" - auch wenn ich nicht daran glaube..)

Makki

Edit: @Timo: teste ich natürlich - wenn ich schon dabei bin- auch mit der nativen, aktuellen libusb. Aber ohne präjustiz: das Ergebniss kenne ich in beiden Fällen schon.. Die USB-SS ist leider nicht "vollgasfest" (das ist mit der ETS übrigens nicht andes..)

[timowi]

Noch was: Solange wir noch pthsem haben: Kannst Du meinen Patch von damals für die verlorenen gegangenen usb-Telegramme einspielen: BCU SDK with eibd / Mailing Lists

Könnte da mal bitte jemand testen, wie es mit der aktuellen knxd Version und einen aktuellen libusb aussieht? Die 30s hören sich verdächtig nach einen Bug in libusb an, der vor längerem gefixt wurde. Bisher verwendete eibd eine eigene (sehr alte) Version von libusb. Knxd verwendet jetzt die installierte Version.

[timowi]

Es muss einen Grund geben warum kaum jemand pthsem und pth verwendet und weiterpflegt. Der Mainstream geht jedenfalls woanders hin.

Es gibt hunderte threading Bibliotheken. Fast alle werden nicht mehr verwendet. Allgemein hat sich nie eine richtig durchgesetzt. (Es gibt mittlerweile std::threads im neusten C++ standard c++11

Ich denke, am besten sollten wir versuchen, ganz auf Threads zu verzichten. Der Vorteil ohne Threads ist, dass der Code einfacher zu debuggen und zu verstehen ist.

Ja, threads bringen eine gewisse komplexität mit sich. Allerdings wird die Programmierung dadurch auch einfacher.

Statt Threads sollte es eine globale poll-Schleife geben, die auf KNX und allen außeren Connections (TCP, Socket) lauscht.

Das halte ich nicht für sinvoll. Es bedeutet das jede Aktion für sich komplett abgearbeitet werden können muss, bevor in die Hauptscheife zurückgesprungen werden kann. Die dafür notwendigen Zustände und Warteschlangen werden wahrscheinlich genauso komplex wie Threads...

Außerdem würde dies die Struktur des eibd komplett über den Haufen werden. Da wäre es wahrscheinlich einfacher, komplett neu anzufangen.

[christianwicke]

Sollte man statt dem poll nicht lieber ein select nehmen?

Und: C oder C++? Native oder mit Bibliothek?

Hallo Chris,
Du hast vermutlich recht, dass select besser ist. Ich bin selber Java-Entwickler und bin nicht so ganz sattelfest mit C. Ich musste eben erst einmal nachgeschauen, was eigentlich die Unterschiede genau sind zwischen poll und select.
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.
Mit Native oder Bibliothek weiß ich nichts recht anzufangen. Gibt es Bibliotheken, die man statt des normalen select() nehmen kann?
Gruß
Christian

[Chris M.]

Statt Threads sollte es eine globale poll-Schleife geben,

Sollte man statt dem poll nicht lieber ein select nehmen?

Und: C oder C++? Native oder mit Bibliothek?

[christianwicke]

Zu ptsem-Problematik

Hallo Michael,
super, dass Du Bewegung reinbringst in die Entwicklung.
Ich habe mir auch schon einige Gedanken gemacht, wie wir mit der ptsem umgehen können: Es muss einen Grund geben warum kaum jemand pthsem und pth verwendet und weiterpflegt. Der Mainstream geht jedenfalls woanders hin.
Ich denke, am besten sollten wir versuchen, ganz auf Threads zu verzichten. Der Vorteil ohne Threads ist, dass der Code einfacher zu debuggen und zu verstehen ist. Außerdem verwendet pth intern soweit ich weiß sowieso keine echten Linux-Threads sondern bildet alles auf einen Linux-Thread ab.

Statt Threads sollte es eine globale poll-Schleife geben, die auf KNX und allen außeren Connections (TCP, Socket) lauscht. Als ich damals mich in libusb eingearbeitet hatte, um die verlorenen Telegramme zu finden, habe ich genau so eine Programmstruktur in in der Doku von libusb gefunden.
Damit der Rest vom Code vorerst weiterverwendet werden kann könnte man die 10 Layers von eib alle nacheinander solange aufrufen, bis jeder fertig ist. Die Datenübertragung zwischen den Layers müsste man allerdings dafür ändern.
Ich würde hier auch unterstützen, vermutlich aber erst im neuen Jahr. Ich würde mit libusb anfangen. Die andere Hardware kann ich nicht testen.

Michael, lohnt es sich für pthsem-Ablösung eine Unterkategorie zu machen?

Noch was: Solange wir noch pthsem haben: Kannst Du meinen Patch von damals für die verlorenen gegangenen usb-Telegramme einspielen: BCU SDK with eibd / Mailing Lists

Danke und Gruß
Christian

[TiberiusTribun]

Ich habe dazu keine gefestigte Meinung, benutze selbst nur die Perl und C-API.

Versuche mal die Vor- und Nachteile zu skizzieren:
- "auto-API": fällt halt so raus, ohne das man die Sprache kennen muss - oder jemand das extra befummeln muss.
Dafür lohnt sich IMHO auch ein bisschen Aufwand "vornedran"
- "custom-API" muss jeder für "seine" Sprache jedesmal aufwändig anfassen.

Also meine Erfahrung ist halt dass ich als Python-Programmierer eine API erwarte, die im weitesten Sinne "pythonic" ist, also dem Muster entspricht wie die meisten anderen APIs auch funktionieren. Das ist sicher bei den anderen Sprachen nicht anders. Mit einer nach Sprache X umgewurschtelten C-API hantieren zu müssen führt dann nur zu Frust. Ging mir jedenfalls so.

Aber klar, man kann natürlich die Auto-APIs erstmal drinlassen und parallel sowas wie einen "native" client entwickeln. Ich persönlich würde halt keine Energie darauf verschwenden ohne Feedback, dass die Auto-APIs auch tatsächlich genutzt werden.

[makki]

Wäre es nicht ganz sinnvoll unter den Support Foren ein KNX toppic auf zu machen?
Da könnte man alles nachlesen und auch mal fragen stellen?

Das Angebot steht ja, momentan sind wir aber gerade mal seit 24h soweit, das "Makefile-Versteher" das kompiliert bekommen.
Die Sache steht eher in dem Stadium Antworten zu brauchen, Fragen gibts schon genug

Makki

Edit/PS: Kommt Zeit, kommt Rat, ETA Ende 2014..

[makki]

Tach,

Sollen die Skriptsprachen-Clients weiterhin Teil des Projektes sein? Wenn ja dann würde ich dafür plädieren einen kompletten rewrite der Clients in nativer Form anzustreben und diesen Übersetzungskram bleiben zu lassen. Sprachen für die sich kein Entwickler findet sollte man dann erstemal fallen lassen.

Ich würde mich beim Python Client einbringen. Ich hab während meiner Master-Thesis ein bißchen damit rumgespielt und mich über diesen Übersetzungsmurks geärgert. Ich bin mehr Hacker als richtiger Programmierer aber vielleicht gibts ja noch Python-affine Mitstreiter.

Gruß

Kevin

Ich habe dazu keine gefestigte Meinung, benutze selbst nur die Perl und C-API.

Versuche mal die Vor- und Nachteile zu skizzieren:
- "auto-API": fällt halt so raus, ohne das man die Sprache kennen muss - oder jemand das extra befummeln muss.
Dafür lohnt sich IMHO auch ein bisschen Aufwand "vornedran"
- "custom-API" muss jeder für "seine" Sprache jedesmal aufwändig anfassen.

-> Deswegen ist ein langfristiges Ziel auch, den "blödesten" Teil (DPT en/decoding) auch innen zu machen, statt zig APIs & Clients die das dann "hintenrum verwurschteln".
Soll heissen: ich habe nach 7J eibd mit Perl, Python, C, Bash schon eine sehr konkrete Vorstellung, wie man die Client-API weiterentwickeln könnte

Ich bin für Vorschläge aber absolut offen! ( nur kann niemand bei einem Release auf XXX warten, bis er seine API angepasst hat,..)

Evtl. gibts halt dann zwei, eine gut gepflegte Custom-Python-API und eine "auto"? Wär ja auch ne Idee, oder?

Wie gesagt, Ihr braucht nur "pieps" sagen und wir richten Euch ein Unterforum ein, bei Bedarf auch mit Gesichtskontrolle und nur für Auserwählte sichtbar.

Verstanden, wir sind aber gerade mal 10 - wenns hoch kommt. Und das soll keine geschlossene Veranstaltung mit Gesichtskontrolle sein/werden.
Auf der anderen Seite gibt es sicher mehrere tausend Benutzer des eibd (ohne den wäre ich nicht seit 2007 hier..)

-> Lass uns das mal abwarten, momentan passt es mit einem Thread und dem Tracker auf Github glaube ich..

Die API bzw. der Code allgemein sollte natürlich im Code dokumentiert werden -> doxygen
da gibts doch eigentlich keine alternative...

Viel wichtiger ist aber ein allgemeine Doku für anwender. Da passt Markdown ganz gut.

Klingt gut, beides, doxygen scheint mir für die API besser, .md zur Benutzung.

Ich kümmere mich morgen erstmal wieder um die ETS5

Makki

[larsrosen]

Wäre es nicht ganz sinnvoll unter den Support Foren ein KNX toppic auf zu machen?
Da könnte man alles nachlesen und auch mal fragen stellen?

[timowi]

Ok, verstanden.
"Inline" fände ich bei der API aber besser, weil der Entwickler so gut wie sonst keiner seine Funktion kennt.. Und keine sepearte Datei aufmachen muss (Entwickler sind faul Menschen )
Dafür gibts dutzende Systeme, Vorschläge?

Die API bzw. der Code allgemein sollte natürlich im Code dokumentiert werden -> doxygen
da gibts doch eigentlich keine alternative...

Viel wichtiger ist aber ein allgemeine Doku für anwender. Da passt Markdown ganz gut.

[MarkusS]

Ich würde vorschlagen (bis auf weiteres):
- Allgemeine Fragen/Sachen hier oder per eMail (oder PN wenns sein muss..)

Wie gesagt, Ihr braucht nur "pieps" sagen und wir richten Euch ein Unterforum ein, bei Bedarf auch mit Gesichtskontrolle und nur für Auserwählte sichtbar.

[TiberiusTribun]

Skriptsprachen

Tach,

Sollen die Skriptsprachen-Clients weiterhin Teil des Projektes sein? Wenn ja dann würde ich dafür plädieren einen kompletten rewrite der Clients in nativer Form anzustreben und diesen Übersetzungskram bleiben zu lassen. Sprachen für die sich kein Entwickler findet sollte man dann erstemal fallen lassen.

Ich würde mich beim Python Client einbringen. Ich hab während meiner Master-Thesis ein bißchen damit rumgespielt und mich über diesen Übersetzungsmurks geärgert. Ich bin mehr Hacker als richtiger Programmierer aber vielleicht gibts ja noch Python-affine Mitstreiter.

Gruß

Kevin

[makki]

Hallo miteinander



Markdown ist die Syntax, in welcher die Dokumente zum Projekt verfasst werden. Das sind die Files mit der Endung *.md. In der Regel gibt es in jedem Projekt ein Readme.md, welches auf der GitHub-Einstiegsseite zum Projekt entsprechend gerendert wird.

Ok, verstanden.

"Inline" fände ich bei der API aber besser, weil der Entwickler so gut wie sonst keiner seine Funktion kennt.. Und keine separate Datei aufmachen muss (Entwickler sind faule Menschen )
Dafür gibts dutzende Systeme, Vorschläge?

Makki