eibd(war bcusdk) Fork -> knxd

[makki]

Wie es weitergeht?

Ich würde vorschlagen (bis auf weiteres):
- Allgemeine Fragen/Sachen hier oder per eMail (oder PN wenns sein muss..)
- Tracker/Wiki auf Github (besser: es bewegt sich gerade einiges!)
https://github.com/Makki1/knxd

(timowi hat bereits Schreibrechte und die bekommt wegen mir jeder, der sich qualifiziert zu Wissen, was er da tut..)

Makki

Edit/PS: Es geht voran!

[timowi]

- Also man kann ein Wiki auf Github für das Projekt anlegen. Ansonsten kann ich auch im Openautomation-Wiki nen Bereich machen, aber um den Inhalt müsste sich jemand kümmern.
- ML? Gefällt mir ansich, geht aber bei Github soweit ich sehe nicht(?)
- Bug/Feature-Tracker und Milestones geht denke ich mit Github, ich lege gleich mal ein paar zum Test an..

Dann bleiben wir einfach bei github. Ich bekomme auf jeden Fall Emails wenn im Bugtracker o.ä. was geändert wird.
Den Rest dann dort im Wiki.

Das sind die aktuellen Quellen des Forks? Dann werde ich mal probieren was passiert wenn ich ihn unter OSX baue!

Jein :-)
Das ist/war ein branch von mir. Das ist jetzt in https://github.com/Makki1/knxd Dort geht es weiter. Ansonsten ist das der funktionierende Code des forks. Die Datei heißt dann knxd

[starwarsfan]

Hallo miteinander

@Richard:
...
2) was genau meinst du mit "Markdown" ? (Beispiel-Projekt o.ä.)

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.

[Jockel]

https://github.com/timowi/knxd/

Das sind die aktuellen Quellen des Forks? Dann werde ich mal probieren was passiert wenn ich ihn unter OSX baue!

[makki]

Hallo Timo,

erstmal vielen Dank für das autoconf/automake ! -> Ist bereits gemerged (inkl. dem cEMI-Patch von Meik Felser)
-> Damit ist ein erster Meilenstein erreicht: man kann knd bauen

Wie es weitergeht?
- Also man kann ein Wiki auf Github für das Projekt anlegen. Ansonsten kann ich auch im Openautomation-Wiki nen Bereich machen, aber um den Inhalt müsste sich jemand kümmern.
- ML? Gefällt mir ansich, geht aber bei Github soweit ich sehe nicht(?)
- Bug/Feature-Tracker und Milestones geht denke ich mit Github, ich lege gleich mal ein paar zum Test an..

@Richard:
1) ich melde mich dazu (Debian) separat nochmal (es gibt ja schon packerl für den eibd, allerdings schlechte oder ziemlich "individuelle"..),
2) was genau meinst du mit "Markdown" ? (Beispiel-Projekt o.ä.)

Makki

[timowi]

Geht es hier um das komplette BCUSDK oder nur um den KNX bus access und EIBD frontend? Ich denke fast alle hier nutzen nur den EIBD und selbst hier nur ein Bruchteil der Funktionalität.

Ja, es geht nur um den eibd. Deshalb hat Makki auch nur die eibd Quellen aus dem bcusdk in sein github repository kopiert.

Ich hab mal die fehlenden autoconf Dateien noch kopiert und das ganze angepasst:
https://github.com/timowi/knxd/
Dazu hab ich noch den bcusdk-usb-cemi.patch von SourceForge hinzugefügt. Damit lässt sich der eibd jetzt schon mal einzeln bauen.

Jetzt ist die Frage wie weitermachen? Da sollten wir mal irgendwo eine Roadmap anlegen.
Ich finde zum Beispiel die ganzen Client-programme sollten sortiert werden. => groupwrite,groupread,grouplisten: OK, Aber der meiste Rest? Ich finde die sollten nur installiert werden, wenn explizit gewünscht. Welche werden eigentlich verbreitet verwendet?
Dann ist da eine eigene libusb mit eingebaut. Wird die wirklich benötigt? Die Gründe dafür scheinen nicht Dokumentiert zu sein. Ich habs mal gegen die system libusb gebaut: funktioniert. Ich habe aber leider keine USB Hardware zum testen.
Es werden also auf jeden Fall Tester mit möglichst unterschiedlichen Systemen benötigt.

[Zepp]

Geht es hier um das komplette BCUSDK oder nur um den KNX bus access und EIBD frontend? Ich denke fast alle hier nutzen nur den EIBD und selbst hier nur ein Bruchteil der Funktionalität.

Nach einem kurzen Blick in die Sourcen halte ich den Vorschlag von NilsS (Redo) für den einfachsten. Wenn man sich auf die wirklich benötigten Features beschränkt sicher ein machbares Projekt, das aber nicht zu unterschätzen ist. Es braucht schon einen erfahrenen API-Entwickler der die Architektur in die Hand nimmt.

[timowi]

finde ich gut -> bin dabei :-)

Erstmal zu Einführung:
Ich nutze den eibd seit ca 3 Jahren für die knx konfiguration über LAN/WLAN und automatische Steuerung/Visualisierung (vorläufig) mit linknx und knxweb2.
C/C++ behersche ich (Mache sonst hardwarenahe Software und Elektronik). git verwende ich regelmäßig, cmake und autoconf eher als reiner Anwender.

So:
Wie ist der aktuelle Stand? Wie die weiteren Planungen? (fürs erste)

Autoconf/CMAKE:
autoconf ist weit verbreitet und eigentlich recht einfach. CMAKE ist extrem flexibel (insbesondere unter nicht GNU systemen). Autoconf ist halt GNU lastig (gcc/make). CMAKE kann auch gut andere targets (MacOS: xcode, WIN: VisualStudio).
Wenn die Flexibilität nicht so wichtig: Einfach nehmen was man schon kann!

pthsem:
Erstmal draußen lassen! Habe gerade mal nachgesehen: GNU pth hat das selbe Problem wie bcusdk/eibd: seit 2006! kein release mehr. Daher mein Vorschlag: Durch zeitgemäßere bibliothek ersetzen. Muss nicht zum ersten release, sollte aber mittelfristig.


Ich möchte gerne beim Programmieren und auch der Planung helfen. Zur Kommunikation wäre mir eine Mailingliste lieber.
Ein Bug-/Aufgabentracker wär nicht schlecht. Da könnte man gut festhalten was fürs nächste (bzw. erste :-) release noch gemacht werden muss.

Auf ein gutes gelingen
Timo

[henfri]

Die Jungs von Wiregate setzten auch den EIBd ein. Vielleicht haben die ja interesse sich an dem Projekt zu beteiligen.

Ich bin sicher Makki hat da gute Kontakte :-)

[Hotstepper13]

Vorschlag oder Hinweis...

Die Jungs von Wiregate setzten auch den EIBd ein. Vielleicht haben die ja interesse sich an dem Projekt zu beteiligen.

Gruß
Frank

[RichiH]

Stellt sich natürlich die grundlegende Frage nach dem wie dokumentieren wir?

Markdown als Textdatei hat den Vorteil, dass man es auf der Kommandozeile lesen kann und es auf zB GitHub automagisch schoen angezeigt wird. Und die Doku zieht man dann immer zusammen mit dem Code runter, man hat sie also immer auf den Maschinen wo knxd laeuft...

Wenn ihr soweit seid, dass knxd unter Debian sauber baut meldet euch per PM; packaging & upload kann ich machen. Email per PM extra freigeschaltet da ich sonst nicht oft hier bin.


Richard

[gregory1969]

Präambel

Aber Doku ist nicht meine Stärke, ebensowenig (automatisierte?) Tests und mit GIT bin ich komplett "blank".

Bei der Doku kann ich unterstützen.
Stellt sich natürlich die grundlegende Frage nach dem wie dokumentieren wir?
Ist ein Wiki immer noch die präferierte Art und Weise der Dokumentation?

Viele Grüße
Jörg

[Jockel]

Um noch die Frage von Makki zu beantworten, cmake ist auf dem Mac von Haus aus nicht installiert. Es gibt es natürlich, aber das erhöht wieder die Abhängigkeiten. Automake & Co sind auch nicht meine größten Freunde, aber gewisse Vorteile sehe ich da schon.

[NilsS]

Um wie viele Zeilen Code geht es hier denn? (hab gerade keinen Sourcen zur Hand)

Ich halte ein komplettes Redo immer für die bessere Alternative. Man überlegt sich halt erstmal was die bestehenden Probleme sind und wo man hin möchte.

Legt dann fest wie man das programmieren möchte, und arbeitet das dann ab.

Dann hat man nicht das Problem das man immer versucht Abhängigkeiten zu lösen, sondern kann vorher schon selbst bestimmen welche man überhaupt haben möchte.

[mjoe]

Also, meine Tests mit cmake (es geht - inkl. pthsem!) waren nicht gerade erfrischend.. Um nicht zu sagen: ziemlich ernüchternd.
Es geht - auf genau einem System. OpenWRT, Openembedded (von MingW oder OSX garnicht zu sprechen..) waren ein Griff ins Klo.

Vielleicht ist alt doch nicht unbedingt schlecht? Denn ich hätte gerne, das es weiterhin auf allen Plattformen läuft..

Makki

Der klassische Weg ist sicher nicht falsch. Ich hätte daran auch vorerst nichts verändert und den Fokus auf die anderen Teile gelegt. Automake und co. sind halt doch recht verbreitet und gut etabliert. Von mir aus, bleib dabei ..