eibd(war bcusdk) Fork -> knxd

[makki]

Präambel
Also, es ist so:
mkoegler meldet sich dazu seit geraumer Zeit nicht mehr.
Ist ja sein gutes Recht, ich hätte mir nur ein Statement dazu gewünscht.. Egal..

Der eibd funktioniert verdammt gut, wir haben aber ausstehende Probleme:
-- cEMI (neue USB-SS - nicht weiter wild, es gibt seit ewig einen Patch auf der ML, =gefixed..)
-- ETS5 (schon ein echtes Problem, daher jetzt echter Aktionsbedarf!)

Nun zu den Fakten:
Daher werde ich - nach sehr reiflicher Überlegung! - einen Fork auf Github starten. (Es hat sich einfach kein anderer dummer gefunden)
Dafür braucht es Mitstreiter, egal ob Doku, Code-Review (ich bin IMHO in C(++) eher Anfänger), Tests, Packaging für Debian, ...

Erwartet aber bitte nicht zuviel und nicht sehr zeitnah (Wochen)..

-> Erstmal kommt die auto(make)/*-Suppe (die aber wichtig ist..) und das umbennen in knxd
- Dann kommt das Packacking (das bisher sehr vernachlässigt wurde!)
-> Integriertes Packaging für Debian, OpenWRT, OE halte ich ich für essentiell.
Zwischendrin muss ich noch GIT lernen..

In Release 1.0 (wäre 0.0.6, stimmt aber nicht, weil der eib 0.0.5 produktiv schon jahrelang funktioniert)
sähe ich dann ein erstes Release, das weitgehend dem eibd 0.0.5 mit den Fixes&Enhancements der letzten 2-3J entspricht.
Also CometVisu-Backend, cEMI für neue USB-Interfaces, ETS5-Support, (evtl. mehr)

Ausblick:
- Ich war schon immer der Meinung, das ein (eibd)knxd auch das DPT en/decoding via API beherrschen sollte - das ist im Prinzip nur Copy&Paste von meinem Code (oder linknx in C++ - aber der C-Code stammt echt von mir..)
-> Statt das in in Python/Perl/JS hundertfach immer wieder neu zu schreiben. Mit all den möglichen Fehlern (z.B. in DPT9, die wir ja nun schon kennen)..
- Ein eingebrachter Einwand ist, pthsem zukünftig einfach zu integrieren. (pthsem wird m.W. sonst nur von linknx verwendet); pth selbst auch nur von einer Handvoll..
- Komplette Funktionalität als LK / KNXnet/IP Router mit Filtertabellen - dank eines Forums-Mitglieds habe ich seit heute die im KNX-Standard mit * (on demand) markierte Beschreibung.

-> Ich brauche vor allem Mitstreiter!
Denn alleine packe ich das nicht.
- Das auto(make) Zeugs bekomme ich hin, auch ein paar Zeilen C++ sowie das Packaging (mache ich fürs WireGate, OpenWRT und Openembedded [Dreambox, mit Hilfe von do13] & eibd ja seit >6J).
Aber Doku ist nicht meine Stärke, ebensowenig (automatisierte?) Tests und mit GIT bin ich komplett "blank".

-> GitHub wurde gewählt, weil mir mehrere im Vorfeld dazu geraten haben: um die Zusammenarbeit so einfach&effizient wie möglich zu gestalten.

Für Anwender noch nutzlos, aber es geht los:
https://github.com/Makki1/knxd

Makki

P.S.: @Admins: ich poste das bewusst im Hauptforum, weil IMHO sehr viele den eibd benutzen um auf KNX zuzugreifen..

[Chris M.]

Sehr schön!

[henfri]

Hallo,

ich bin dabei. Danke für die Initiative, Makki.

Wie organisieren wir uns? Mail? Dieser Thread? Bietet GitHub dazu etwas?

Gruß,
Hendrik

[MarkusS]

Wir richten dafür jederzeit ein Unterforum ein, einfach melden.

[dombn]

top!

An git wirst du dich vermutlich sehr schnell gewöhnen und nicht wieder zurück wollen. Auch wenn es Anfangs ein bisschen anders ist …

[swiss]

Ich würde auch nach kräften mithelfen wenn ich kann.

[Chris M.]

An git wirst du dich vermutlich sehr schnell gewöhnen und nicht wieder zurück wollen. Auch wenn es Anfangs ein bisschen anders ist …

Ist hier zwar etwas OT: wenn Git besser ist (ich kenn's einfach nicht), können wir natürlich Open Automation (das, wo auch die CometVisu liegt) auch auf Git migrieren.

Da ich's nicht aus der Anwendung kenne, habe ich aber bisher keinen Vorteil gesehen...

[mjoe]

Kann auch helfen, habe gerade die Synology Paketierung für den eibd gepushed. Ansonsten sind c, make und co auch meine Baustellen. Github ist derzeit die defakto Standard Plattform für Social Coding. Insofern alles richtig gewählt.

[Knaller]

Mo in

Wo kann ich helfen?

Mich wuerde eine Anbindung an Codesys interessieren. Da sind noch einige die da warten.

In Codesys kann ich bzw mein Kollege weiter helfen.

Gruß Herbert

[makki]

Danke für die Antworten und werde gerne darauf zurückkommen; ich kämpfe noch etwas mit den "Basics"
Die muss ich aber erstmal selbst lösen.
Also Build-System, möglichst integrierte Doku und der "automagic" Client-API, automatisierte Tests, ... habe das offen gestanden etwas unterschätzt bzw. letzte Woche zuwenig Zeit gehabt.
Für einen ersten commit ist da noch zuviel Mist drin, es macht ja keinen Sinn bereits bekannte Probleme zu diskutieren..
(ich teste vorerst mit einem lokalen GIT..)

Ohne gescheites Build-System machts aber IMHO auch wenig Sinn, denn genau das würde ich anstreben, das es von Debian (z.B. WG oder RPi) über OpenEmbedded, OpenWRT bis Synology (von BSD, MingW oder OSX hab ich übrigens keine Ahnung..) z.B. Paketbetreuer/Tester gibt und dies dann auch soweit irgend möglich "Upstream" auch automatisiert stattfinden kann.
Möglichst kein "zusammenfummeln" für eine spezifische Plattform mit nachträglichen, lokalen Patches. (der geneigte Leser weiss evtl., was ich meine.. der eibd & das Packaging z.B. auf dem WG ist letztlich seit Jahren "händisch gepatched"; das ist einigermaßen ineffizient..)

-> Ich habe den eibd und pthsem selbst schon auf so viele Plattformen "gefummelt", das mir sehr wichtig ist, hier zukünftig - soweit möglich - ohne manuelle Eingriffe bei jedem Release auszukommen..
Auch s.o.: Thema pthsem. Weil so genial das ist, ebensoviel Kopfweh bereitet das z.B. bei der Paketerstellung für andere Plattformen..


@Herbert: Die CoDeSys-Frage verstehe ich in diesem Kontext nicht wirklich?
Entweder per vorhandener, gut dokumentierter API (die auf jeden Fall abwärts-kompatibel bleiben wird!) oder per eben via KNX.
Dafür brauchen wir keinen Fork (?)


@ChrisM: nun wir hatten ja im Vorfeld (PN/eMail) schon darüber gesprochen und du hast freundlicherweise zugestimmt, das unter OA "einzuhängen";
letztlich haben mich aber erstmal die Vorteile von GitHub überzeugt, das jeder ohne "Voranmeldung" mitmachen kann.

Ich strebe hier absolut nicht den "Project-Lead" an, ganz im Gegenteil. Nur die Initiative..


@Hendrik: zur Kommunikation tuts bis zu einem Release 0.0.6 / 1.0 (s.o.) denke ich erstmal das Forum, da es bis dahin nur um die Basics im selben Funktionsumfang geht.
Danach kann man denke ich mal sehen und abstimmen, was da Sinn macht; Unterforum (denke ich eher weniger), GitHub (bietet einiges- von Wiki bis ML) oder ein Umzug zu Openautomation/SF.

Makki

[makki]

Ich hadere gerade etwas, daher eine Frage (eher Entwickler, weniger Anwender - inkl. meiner subjektiven Antworten):
Was findet ihr besser:

- autoconfig/automake oder cmake
- Doku-System (so lassen oder was "besseres")

+ den ganzen Rest davon: was ihr machen könnt, ist mich mit Vorschlägen&Input zu versorgen..

Makki

(ich nenne bewusst keine Alternativen, um die AW nicht zu beeinflussen..)

[Robert]

cmake

[makki]

cmake

Na, da wäre ich ja bei dir, aber wie ersetze ich damit autoconf/make, Doku, Auto-API usw.
Das ist keine ketzerische Frage, sondern eine sachliche.. Es ist mir bisher nicht wirklich gelungen - mit all den Abhängigkeiten der diversen Pakete etc..

Es geht immernoch rein um bcusdk(eibd)->knxd.
Ich hatte es mir einfacher vorgestellt

Makki

[DerSeppel]

Also ich bin momentan voll im Bau-Stress. Aber wenn sich der Staub ein wenig gelegt hat, pack ich mit an.
Habe mal einen GitHub-Account angelegt und den Code ausgecheckt. Zum drüber schauen.

Git finde ich prinzipiell die richtige Lösung. Bin zwar nicht soo der Fan von Klicki-Bunti Clients, aber wir haben für Teilprojekte gerade git mit "SourceTree" als Client in der Firma eingeführt. Ist eigentlich ganz nett und sollte auch mit kostenloser Lizenz zu haben sein.

Ansonsten wäre CMAKE meine Wahl. Setzen wir auf der Arbeit für fast alle Projekte ein. Ich kann auch zwischenzeitlich mal schauen ob ich bei der Konfiguration unterstützen kann.

[mjoe]

Es geht immernoch rein um bcusdk(eibd)->knxd.
Ich hatte es mir einfacher vorgestellt

Der Hund liegt immer im Detail begraben. Ich würde schrittweise vorgehen, bei zuvielen Variablen verliert man schnell den Überblick. Vor allem musst Du/wir uns die Frage stellen was genau das Ziel sein soll, was soll alles abgedeckt werden, wo wollen wir hin.

Bei einem Wechsel des Buildsystems kommt man meistens nicht darum herum, den Code zuerst auf das Minimum zu reduzieren, resp. zu entschlacken, und ihn erst danach erneut, sozusagen von Grund auf in das Alternative Buildsystem zu integrieren.

Btw. hier gibts einen Überblick dazu http://www.scons.org/wiki/SconsVsOtherBuildTools