Ankündigung

Einklappen

Hinweis

Die Forenregeln wurden überarbeitet (Stand 7.11.22). Sie sind ab sofort verbindlich. Wir bitten um Beachtung.
Mehr anzeigen
Weniger anzeigen

eibd(war bcusdk) Fork -> knxd

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #31
    Zitat von Hotstepper13 Beitrag anzeigen
    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 :-)

    Kommentar


      #32
      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

      Kommentar


        #33
        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.

        Kommentar


          #34
          Zitat von Zepp Beitrag anzeigen
          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.

          Kommentar


            #35
            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
            EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
            -> Bitte KEINE PNs!

            Kommentar


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

              Kommentar


                #37
                Hallo miteinander

                Zitat von makki Beitrag anzeigen
                @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.
                Kind regards,
                Yves

                Kommentar


                  #38
                  Zitat von makki Beitrag anzeigen
                  - 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.

                  Zitat von Jockel Beitrag anzeigen
                  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

                  Kommentar


                    #39
                    Zitat von makki Beitrag anzeigen
                    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!
                    EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                    -> Bitte KEINE PNs!

                    Kommentar


                      #40
                      Zitat von starwarsfan Beitrag anzeigen
                      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
                      EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                      -> Bitte KEINE PNs!

                      Kommentar


                        #41
                        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

                        Kommentar


                          #42
                          Zitat von makki Beitrag anzeigen
                          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.

                          Kommentar


                            #43
                            Zitat von makki Beitrag anzeigen
                            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.

                            Kommentar


                              #44
                              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?
                              Elektroinstallation-Rosenberg
                              -Systemintegration-
                              Planung, Ausführung, Bauherren Unterstützung
                              http://www.knx-haus.com

                              Kommentar


                                #45
                                Zitat von TiberiusTribun Beitrag anzeigen
                                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?

                                Zitat von MarkusS Beitrag anzeigen
                                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..

                                Zitat von timowi Beitrag anzeigen
                                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
                                EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                                -> Bitte KEINE PNs!

                                Kommentar

                                Lädt...
                                X