eibd(war bcusdk) Fork -> knxd

[Smurf]

Als Schnittstelle werde ich wohl einen KNX-IP-Router nehmen

Warum nicht einen Pi2? Für den gibt es ein Hutschienengehäuse, KNX gibt's als USB-Stick oder für Huckepack, und den ganzen anderen Kram, den man so braucht (OpenHAB und/oder FHEM und/oder ???), kann man da auch drauf laufen lassen.

[Wurschtel]

Ist knxd schon einsetzbar?

Ein heftiges Hallo an die Experten!

Bevor ich mich ganz tief einzulesen beginne:
Funktioniert der knxd schon mit der ETS5(lite)?

Ich habe bislang nur mit Homematic/FHEM "gearbeitet" und werde anstehende Renovierungsarbeiten dazu nutzen, kleine grüne Kabel zu verlegen.
Thema ist also das funktionierende Miteinander von FHEM, ETS5 und knxd. Als Schnittstelle werde ich wohl einen KNX-IP-Router nehmen, wobei ich mich hier noch nicht auf ein bestimmtes Modell festgelegt habe.

[mjoe]

Danke Makki, Travis CI ist nun grün ..

[makki]

Kein schneller Widerspruch, also sind wir jetzt auf
https://github.com/knxd/knxd
Zuhause!

Issues, Branches, Forks, wurden mitgenommen..

Makki

[Smurf]

Die Erfahrung sagt, dass "so schnell wie möglich umstellen" bei sowas so gut wie immer die bessere Lösung ist. Do it.

[mjoe]

Alles klar, mit 'Pseudo' meinte ich nur im Sinne von, es ist keine juristische Person. Egal, sollte keine Deutung sein in irgend einer Richtung.

mjoe

[makki]

Ist ja keine (pseudo) Org, alle die derzeit Schreibrechte haben sind als Maintainer schon drin..
Ich teste das nochmal sep., falls es keine Einsprüche gibt, wird verschoben, denn ich sehe es ähnlich: lieber gleich als später..

Musste die ganze Github-Story nur auch erstmal lernen..

Makki

P.S.: weitere Meinungen sind erwünscht!

[mjoe]

Hi Makki

Wie ich bereits in meinem letzten Kommentar (github #44) geschrieben habe, denke ich dass es vielleicht sinvoller ist zuerst einen 'reinen Tisch' zu machen. Sobald ein erster Release von knxd erstellt wurde, wird auch bestimmt die Popularität zunehmen und das Verschieben des Projektes in die (pseudo) Organisation wird dann auch nicht unbedingt einfacher. Also ich meinte dass eine Umstellung je früher desto besser ist. Was denkst Du, resp. die Community?

mjoe

[makki]

No need to excuse yourself for english..
Yes.

Makki
Über Mobile Device

[Tru]

is knxd at its current state working in Ubuntu, say in 14.04 for example?

Yes, I have it in production exactly like that.

Othmar

[MaximilianX]

Hallo!

Sorry English, but: is knxd at its current state working in Ubuntu, say in 14.04 for example?

Gruss
- Teemu

[Alger]

Ich würde noch hinzufügen, dass man sehr leicht Pakete (deb, rpm, ...) bauen kann. CMake erleichtert sicher auch den Einstieg für neue Entwickler. Aber jedes zusätzliche OS ist auch zusätzlich Arbeit. Windows Support läuft auch mit CMake nicht einfach so mit!

[timowi]

Nun, ich auch - im Prinzip. Ehrlich gesagt würde ich das aber eher etwas hinten anstellen, weil halt ein wahnsinniger Rattenschwanz dranhängt.

Was macht man mit den Client-API's, BSD, OpenWRT, Solaris, ... ?

Die client APIS sind noch etwas Arbeit. C und Python hab ich schon (benötigt leider die üblichen tools, als nicht vollständig platform unabhängig.)
Ansonsten sollten alle Platformen funktionieren. Bis auf die Bugs

Der "Rattenschwanz" dürfte sich sehr in grenzen halten. Betrifft hauptsächlich den Bau der Pakete.

Das wäre natürlich alles eine schöne Sache! Vor allem letzteres.
Aber soweit ich verstanden habe muss man auch cmake in Win & OSX (xcode) ziemlich manuell "hinfummeln"(?)

eigentlich nicht
z.B. cmake -G "Visual Studio 12 2013"
dann bekommst du eine Projekt Datei, kannst die öffnen und dann erstellen.

Vorschlag: es sollte dank github & branch ja möglich sein, auch andere Änderungen am Code in der "cmake-branch" fortzuführen? Bis wir da 99% sauber sind - oder evtl. ein MSVC/xcode-release daraus(?)
So oder so ähnlich..

Zwei build Systeme gleichzeitig fortzuführen halte ich für wenig praktikabel. Ich habs mal angefangen und wenn ich es einigermaßen getestet habe, werde ich mal auf github ein Issue erstellen und das zur Diskussion stellen. Wenn es nicht weiter verfolgt wird werde ich den branch wieder fallen lassen. Länger weiter pflegen werde ich das (zumindest alleine) nicht.

Ich sehe in CMake einiger Vorteile
- platformunabhäniger (Kann von Makefiles bis xcode/msvc ziemlich vieles)
- build in getrenntem Verzeichnis finde ich sehr praktisch zum Entwickeln
- Ich finde CMakeFiles wesentlich einfacher als autoconf/automake
- Mit CTest werden Tests direkt unterstützt

Ich persönlich halte jetzt für den besten Zeitpunkt zum wechseln. Dann werden mit dem wechsel eibd-0.0.5 -> knxd-1.0.0 das packaging ein mal angepasst. Sonst haben wir zu knxd-1.0.0 ein mal eine wechsel (wird sich ja schon einiges ändern) und dann später nochmal umfangreiche Änderungen von autoconf -> CMake

[apoc4lyps]

Hi,
wenn das ganze direkt über Debian usw verfügbar ist um so besser
Mir ging es nur darum, dass nicht jeder den build krams laden muss und die pakete selber baut (build krams hat meiner meinung nach nichts auf einem live system zu suchen).

[makki]

Hi,
wäre es denkbar im Rahmen des KNXUF ein Repo für diverse Distris / Pakete einzurichten? Nur mal als Idee in den Raum gestellt (muss natürlich mit den Chefs abgeklärt werden)

Denkbar ist sicher alles..
Ich versuche nochmal etwas zu erklären, wie das (IMHO) optimal läuft:
- Distro-Integration möglichst direkt (Beispiel /debian)
Das ist anstrengend, ja aber dafür nachhaltig! Ich pflege seit etwa 7J eibd-Pakete, das ist enervierend..
- (Binary-)Pakete: durch die Distro, nicht durch irgendwelche Kopien, denn diese sind wiederum mittelfristig ziemlich enervierend für den Anwender.
Beispiel OpenWRT (durch tru jetzt bereits realisiert): da ist das halt dort mit drin und dann dort im Repo.

Zwischenlösungen - ich nenne es mal so - wie z.B. Ubuntu-ppa gibts ja auch noch, ebenso wie die Möglichkeit für jedermann ohne Voranmeldung auf Github einen Fork+Pull-request zu erstellen.

Letztlich: nichts gegen das knxuf, aber ich möchte die Entwicklung damit auch etwas Internationalisieren (bisher nur teilw. gelungen), denn es gibt neben 80 Mio deutschsprachigen noch etwa 7 Milliarden andere
Die Diskussion darf gerne hier auf Deutsch geführt werden (das war auch so gedacht!), aber parallel ein Github-Repo auf englisch - und ebenso sollte man an Pakete für internationale Distros rangehen denke ich.

Makki