eibd(war bcusdk) Fork -> knxd

[l0wside]

Da habe ich mit meiner Frage ja was losgetreten...

pthreads scheint es auch für Windows zu geben, http://sourceforge.net/projects/pthreads4w/. Ob das "large subset" ausreicht, kann ich nicht beurteilen. Allerdings dürften die Philosophieunterschiede Windows/Unix bei Threads geringer sein als bei Prozessen. Schließlich muss man hier kein fork() und exec() nachbilden.

Einen .ini-Parser würde ich ggf. noch beisteuern, das sollte mit überschaubarem Aufwand zu machen sein. Optimal fände ich, den bestehenden Parser so zu erweitern, dass er .ini und das bestehende Format automatisch erkennt und beides verarbeiten kann.

Max

[Smurf]

Äh … es gibt keinen bestehenden Parser. Die Befehlszeile wird mit einem langweiligen getopt linear abgearbeitet.

Die Befehlszeilenanalyse habe ich aber schon einigermaßen (un)sauber vom Zusammenbau der beteiligten Objekte getrennt, so dass ein .INI-Parser letzteren Code eigentlich nur aufrufen muss.

pthreads4w sieht ziemlich vollständig aus. Finde ich gut.

Was mir an der Stelle außerdem vorschwebt, ist eine saubere Trennung zwischen I/O-Code auf der einen und Ereignis/Queue-Behandlung auf der anderen Seite. Für I/O sind Threads praktisch. Aber den Rest kann man radikal zusammenstreichen -- der aktuelle Code hat für jeden L2 einen eigenen Thread, der auf mindestens eine Queue und ein Ereignis lauscht (nämlich das "das 'beende diesen Thread'-Semaphor wurde gesetzt"-Ereignis). In fast allen Fällen ist das ziemlich nutzlos, zumal das Datenpaket jedesmal kopiert wird.

[l0wside]

Meinst du bzgl. Init den Code in knxd.cpp? So recht überzeugt bin ich von der Trennung in parse_opt() ja noch nicht. Beim Lesen der argp-Routinen ist mir wieder eingefallen, warum ich so was meistens händisch gemacht habe (keine Kritik an dir, ich finde argp nur einfach zum Fürchten).
Wenn ich den Code richtig verstehe, genügt es, im argp-Code die Ini-Datei zu ermitteln (da wäre mir Hilfestellung lieb) und dann das Ergebnis in arg zu schreiben. Klingt lösbar.
Schreibt jemand einen Vorschlag für eine ini-Datei? Als Abschnitte fielen mir am ehesten "Backend" und "Options" ein, aber ich habe bestimmt was übersehen.
XML oder JSON gingen auch noch, wären aber vermutlich übertrieben.

Max

[nagilo]

Hi,

wollte mich hier nur kurz einmischen, weil -l0wside korrekterweise erwähnt hat, dass meine libknx nur multicast unterstützt. Wenn das das problem ist bau ich das gerne ein. Die libknx hat die thread problematik über die boost::thread gelöst, die ab c++11 fast identisch im standard sind.

Ob es sich lohnt was anderes als ip einzusetzen , also usb oder rs232 würde mich aber interessieren. Nutzt jemand KEIN ip gateway ? Und falls das so ist , warum ?

Gruss

[Smurf]

Ich würde das Ganze etwas elaborierter machen. Schließlich brauchen wir in Zukunft backend-spezifische Optionen zB für das Filtern von Gruppenadressen. Die Idee, aus der .INI-Datei die Argumente zu generieren, halte ich da für wenig zielführend.

Also sowas wie

[global]
backends=foo,bar
# wenn fehlt: automatisch alle ansonsten nicht behandelten Sektionen, in denen driver= vorkommt
eibaddr=0.0.99
addrpool=0.0.100:30

[debug]
trace=namen,für,die,einzelnen,Layer
# oder
trace=0x1ff
log=error – oder warn,info,debug

[foo]
driver=tpuarts
device=/dev/ttyBLA
monitor=no

[bar]
driver=multicast
address=224.99.99.99
port=12345
route=yes
tunnel=yes
discover=yes

Ja, es soll vorkommen, dass jemand gar kein IP nutzt. Ich werde hier auch zwei Pi einsetzen, die einfach irgendwo auf dem Schrank liegen, irgendwas monitoren, und die gar kein IP haben. Nur KNX.
IP-über-KNX lassen wir lieber von vornherein bleiben …

[l0wside]

Hallo Nagilo,

bei mir sind neben dem IP-Gateway zwei weitere im Einsatz: zum einen das Erweiterungsboard für den Beaglebone von Robert (TPUART2 seriell), zum anderen ein USB-Stick von Wiregate (für die Entwicklungs-Linie). Beide laufen mit eibd.

• Ließe sich der Backend-Code, also die Treiber, von knxd/eibd bei dir denn integrieren?
• Ist die USB-Ansteuerung von Linux überhaupt sinnvoll nach Windows zu portieren?

Max

[Smurf]

Soweit ich weiß, gibt es libusb für Windows.

Es ist schon sinnvoll, auch die TCP-Verbindung zum knxd und/oder einen UDP-Tunnel zu unterstützen. Ich habe hier auch noch zwei WLAN-Router, die bei Multicast jedesmal Mist bauen, sobald irgendwelche nicht-trivialen Dinge passieren. :-/

[Smurf]

Es gibt im github jetzt einen neuen Zweig namens "next".

Neue Features:

Die Option "-E" wählt einen Adressbereich aus, "-E 15.0.2:10" z.B. die Adressen 15.0.2 bis 15.0.11 inklusive, der an Klienten vergeben wird, die sich mit dem knxd verbinden. Die ausgewählte Adresse wird denen nicht mitgeteilt (dafür gibt es entweder keine Mechanismen oder ich habe sie nicht gefunden), sondern es wird lediglich der Absender 0.0.0 ersetzt. Unnötig zu sagen, dass dieser Adressbereich sonst nirgends am Bus verwendet werden sollte.

Multicast-Loopback ist wieder an. Das heißt, man kann jetzt einen zweiten knxd (oder irgendwas Anderes, das KNX redet) als Multicast-Client auf demselben Rechner laufen lassen wie ein knxd, der via "-DTRS" als Multicast-Server agiert.

Damit das einigermaßen sauber ins Programm passt, waren mehr Umbauarbeiten notwendig, als mir lieb ist. Insbesondere "groupswrite" und Konsorten machte Probleme, weil der seine Verbindung schließt, bevor knxd das Paket überhaupt verarbeiten kann. Deswegen werden die Layer2-Objekte jetzt über shared_ptr verwaltet, d.h. es wird ein aktueller C++-Compiler benötigt. Sorry – aber ich habe keine Lust, selber einen Referenzzähler zu implementieren und zu debuggen …

[Sven aus Hannover]

Hallo Zusammen,
ich lese als KNX-Neuling hier jetzt schon länger mit, mir fehlt jedoch der aktuelle Status zu diesem Thema. Könnt ihr mir bitte kurz sagen ob das Programmieren von KNX-Geräten inzwischen wieder von der ETS5 über den EIBD funktioniert? Als KNX-IP-Interface möchte ich den RPi mit busware Pigator und KNX-Module einsetzen.
Mit Wiregate soll es inzwischen schon wieder funktionieren und der nutzt doch sicherlich auch den eibd.
Vielen Dank schon einmal.

[Smurf]

Sven aus Hannover Der eibd heißt jetzt knxd. Programmieren via ETS5 funktioniert, ich setze die Pigator-Schnittstelle und den TUL in meinem Haus mehrfach ein.

Aktuelle Probleme:

* man muss das Programmieren bei "größeren" Geräten teilweise mehrfach probieren (wahrscheinlich Paketverluste; an der Ursache forsche ich noch). Aber irgendwann sagt die ETS "OK" und dann ist das auch so.

* ETS5 kann nur Multicast (in der ETS das Interface auswählen, knxd mit -DRS gestartet); Tunnelmodus (in der ETS den knxd auswählen, knxd mit -DTS gestartet) klemmt, wohl wegen eines falschen Datentyps. Multicast wiederum setzt voraus, dass du nicht über WLAN gehst oder dein Router nicht zu hirntot dafür ist.

[l0wside]

Ich würde das Ganze etwas elaborierter machen. Schließlich brauchen wir in Zukunft backend-spezifische Optionen zB für das Filtern von Gruppenadressen. Die Idee, aus der .INI-Datei die Argumente zu generieren, halte ich da für wenig zielführend.

Die vorgeschlagene Struktur sieht mir ganz plausibel aus. Ich hatte den bestehenden Code so verstanden, dass die Ergebnisse des Argumente-Parsens in arg landen. Allerdings werden sich so nicht mehrere Interfaces abbilden lassen.

Welche Darreichungsform wäre denn passender? Klassischerweise hätte ich so was gemacht:

• Abstrakte Basisklasse ConnectionDesc
• Davon abgeleitete Klassen ConnectionDescIP, ConnectionDescTPUART, ...
• Als Ergebnis des Parsens ein std::list<ConnectionDesc>

Gegenvorschläge willkommen, Noch ein paar Fragen zum Thema Legacy:

• Muss die Variante via Kommandozeilenparameter hinterher noch funktionieren?
• Wenn ja:
  • Müssen die Kommandozeilenparameter kompatibel zu den jetzigen sein?
  • Muss nur der bestehende Satz an Parametern unterstützt werden, oder sollen auch per Kommandozeile mehrere Interfaces konfiguriert werden können?

Max

[MGK]

Hier mal meine Meinung als Anwender:

die Kommandozeilen Parameter sollten auf jeden Fall gehen und gleich bleiben, damit man knxd als Ersatz für den eibd einfach so einsetzen kann.

neue Optionen (wie mehrere Schnittstellen) würde ich da aber nicht einbauen, da sollen die Leute sich auf die config Datei umstellen.

und ich würde evt. noch einen Hinweis einbauen: wenn man den mit den Kommandozeilen Parametern startet. "Using command line options is deprecated, please use the config file /etc/knxd.cfg" oder so was.

Gruss und danke für die Arbeit!
Michael

[l0wside]

Hört sich sinnvoll an. Matthias, lieferst du noch einen Kommentar? Oder liegst du gerade am Mittelmeer am Strand?

Max

[maitscha]

Ich würde auch gern auf den knxd wechseln, da dieser wesentlich mehr Infrastruktur (Build-Scripts für Debian-Packages, Daemon-Scripts, usw) mitbringt. Ich möchte den knxd dabei als Router für einen Python-Service (das über Socket mit dem knxd kommuniziert, um Werte zu lesen und zu schreiben) und gelegentlich auch zum Programmieren über die ETS3 verwenden. Ich verwende einen Weinzierl KNX IP Linemaster 760. (bisher hab ich den eibd mittels "--Server --Discovery --GroupCache --listen-tcp --no-tunnel-client-queuing --eibaddr=1.1.2 ipt:192.168.1.2" gestartet).

Wo bekomm ich denn am besten Info mit welchem Layer2 Treiber ich den knxd starten sollte (mal abgesehen von den ganzen anderen Parametern)? Für welchen Anwendungsfall starte ich den knxd als Multicast Server?

[Maniac]

Ich würde mich auch gern mit einklinken... ich habe derzeit auch den eibd auf einem Ubuntu Server laufen. Da ich einen neuen Server aufgesetzt habe, habe ich auch nach einer aktuellen Version vom eibd gesucht und diesen Thread hier gefunden.
Ich bin Software-Entwickler und würde auch gern unterstützen. Allerdings ist meine Zeit derzeit sehr eingeschränkt und "low-level" C/C++ und Unix-Builds sind auch nicht gerade meine Stärke.
Ich könnte ggf. eine kleine Anleitung beisteuern, wie der knxd auf einem Ubuntu-Server (15.04) gebaut wird (man muss ja noch ein wenig zusätzlich installieren). Das habe ich offensichtlich (in meiner VM) erfolgreich hinbekommen, müsste dann zu Hause jetzt mal testen, ob der knxd genauso funktioniert wie der eibd auf meinem alten Server...

Edit:
Ich habe mich nun doch durch den Thread gequält. Ganz klar ist mir trotzdem noch nicht, wo nun die hauptsächliche Kommunikation statt findet? Ist die alte bcu-Mailingliste noch aktiv? Die letzten Einträge sahen mir eher nach chinesischem Spam aus.
Dann gibt es auch noch die englischsprachige Google Group? Oder ist das auch nicht mehr aktuell? Ich habe noch keinen Zugan dazu beantragt...

Da hier ja jetzt schon ganz oft die commits und merges in den master-Branch usw. besprochen wurden, würde ich nochmal git-flow in den Raum werfen. Wundert mich eigentlich, dass das noch niemand vorgeschlagen hat. Bei uns in der Firma ist das mittlerweile standard und eine in meinen Augen sehr saubere Organisation des Code-Stands.
Hier eine Kurzübersicht: http://danielkummer.github.io/git-flow-cheatsheet/ Mit ein bißchen googlen findet man sicher noch mehr dazu, einfache Fragen kann ich sicher auch beantworten...
Die Idee ist im wesentlichen einen develop Branch anzulegen, in dem die Entwicklung stattfindet (quasi der "trunk" bei svn). Neue Features usw. natürlich weiterhin in zusätzlichen Branches. Aber was als "ok / stabil" erachtet wird, wird dann in develop gemergt. In master gibt es dann nur noch die releases, d.h. ab und an schnappt sich jemand den Stand von develop und macht daraus ein Release. Damit sind dann z.B. auch hotfixes einfacher zu integrieren.
Weitere Info dazu: http://nvie.com/posts/a-successful-git-branching-model/