eibd(war bcusdk) Fork -> knxd

[Smurf]

Update mit korrigierten Logs gepusht. Sollte jetzt wieder durchlaufen.

[Smurf]

Hmm, das ist "nur" der Test. Mach den mal vorläufig aus (in debian/rules auskommentieren).

Ich schau mal woran das liegt.

[Knaller]

Moin
Hallo Smurf
Ein neuer Versuch den Fehler darzustellen.
Von dieser Seite
https://www.boernyblog.de/raspberry-...r-ios-homekit/
hab ich den Installation Vorschlag.

Grund :
Installiert wird der knxd einfach nach der Anleitung der Projektseite, mit ein paar kleinen Ergänzungen, wie bspw die cdbs und andere Abhängigkeiten die noch installiert werden müssen. Mein modifiziertes Script sieht daher wie folgt aus:


<# Do not use "sudo" unless told to do so.
# If "dpkg-buildpackage" complains about missing packages
# ("Unmet build dependencies"): install them
# (apt-get install …) and try that step again.
# If it wants "x | y", try just x; install y if that doesn't work.
# Also, if it complains about conflicting packages, remove them (duh).

# first, install build tools and get the source code
sudo apt-get install -y git-core build-essential cdbs autoconf automake libtool libsystemd-dev libsystemd-daemon-dev dh-systemd base-files libusb-1.0.0-dev
git clone https://github.com/knxd/knxd.git

# knxd requires libpthsem which unfortunately isn't part of Debian
wget https://www.auto.tuwien.ac.at/~mkoeg...m_2.0.8.tar.gz
tar xzf pthsem_2.0.8.tar.gz
cd pthsem-2.0.8
dpkg-buildpackage -b -uc
cd ..
sudo dpkg -i libpthsem*.deb

# now build+install knxd itself
cd knxd
dpkg-buildpackage -b -uc
cd ..
sudo dpkg -i knxd_*.deb knxd-tools_*.deb
>

Das Compilieren läuft bis zum Schluß
Das erscheint nach langem warten
<
+ test -z 32
+ rm -f /tmp/fileV99rwp /tmp/fileIrWW0p /tmp/fileZUIRso /tmp/filesMQRXo /tmp/filex9CB5r /tmp/fileygQ2Qs /tmp/fileqzO71c
debian/rules:48: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/home/pi/knxd'
debian/rules:14: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2
pi@raspberrypi:~/knxd $ cd ..
pi@raspberrypi:~ $ sudo dpkg -i knxd_*.deb knxd-tools_*.deb
dpkg: Fehler beim Bearbeiten des Archivs knxd_*.deb (--install):
Auf das Archiv kann nicht zugegriffen werden: Datei oder Verzeichnis nicht gefunden
dpkg: Fehler beim Bearbeiten des Archivs knxd-tools_*.deb (--install):
Auf das Archiv kann nicht zugegriffen werden: Datei oder Verzeichnis nicht gefunden
Fehler traten auf beim Bearbeiten von:
knxd_*.deb
knxd-tools_*.deb
pi@raspberrypi:~ $ >



Ich hoffe das hilft

[Smurf]

Nö, reicht noch nicht. Welchen Zweig baust du? Was steht in den Zeilen vor dieser Fehlermeldung?

Und: Bitte solche Sachen als Code hier reinpasten (die "<>"-Taste), sonst kann es keiner lesen-

[Knaller]

Moin

Heute hab ich versucht auf einen PI2 mit dem neusten Jessie und allen Update den knxd zu installieren.
Es geht nicht. Mit der Anleitung vom Git geht es ab hier
sudo apt-get install git-core build-essential mit Fehlern los .
Auf der Seite https://www.boernyblog.de/raspberry-...r-ios-homekit/ gibt es eine Änderung
sudo apt-get install -y git-core build-essential cdbs autoconf automake libtool libsystemd-dev libsystemd-daemon-dev dh-systemd base-files libusb-1.0.0-dev damit geht es ein Stück weiter aber hier ist dann Schluß dpkg-buildpackage -b -uc dann erscheint das hier make[1]: *** [override_dh_auto_test] Error 1 make[1]: Leaving directory '/home/pi/knxd' debian/rules:14: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2 Als Linux Dummi steht man dann da ;-) Vieleicht reicht das ja als info für einen Entwicklungsschub. Bei Fragen bitte melden. Gruß Herbert

[Smurf]

Moin,

an dieser Stelle mal ein dickes Danke für deine Arbeit am KNXD!

Gruß,
Hendrik

Bitte sehr.

Wer die Arbeit finanziell unterstützen mag: ich kann zwar keine Spendenquittungen ausstellen, aber Rechnungen. :-)
Bitcoin (16tRzG66je6ikgoFoFHQqBZQMnzZ6ERYUy) und Paypal (matthias@urlichs.de) geht auch …

[henfri]

Moin,

an dieser Stelle mal ein dickes Danke für deine Arbeit am KNXD!

Gruß,
Hendrik

[Smurf]

Auf einem anderen Planeten, genauer gesagt im Zweig libev des knxd-Repository auf github, geschehen derweil seltsame Dinge.

Konkret: Die pthsem-Bibliothek fliegt raus und wird durch libev ersetzt. Die Vorteile dieses Umbaus kann man in https://github.com/knxd/knxd/issues/29 nachlesen, inkl. den Fortschritt. Das Hauptziel ist, (a) Tools wie valgrind verwenden zu können (unerlässlich bei der Suche nach Speicherlecks) und (b) den knxd irgendwann in Debian zu haben.

Ich suche Leute, die mir helfen können, ihre KNX-Hardwareanbindung (insbesondere wenn sie nicht TPUART-basiert ist) mit dem neuen Code zu debuggen. Oder die mir ein Interface aus ihrer Reservekiste ausleihen, dann mache ich es selber.

Außerdem ist das Testscript (in tools/test.sh) nach wie vor ziemlich rudimentär. Wenn jemand helfen mag, das Teil aufzubohren, wäre das superb und würde Allen weiterhelfen. Es fehlt insbesondere Code zum Testen der Datencache (das, was die CGIs so auslesen …) und der Managementbefehle.

Der libev-Umbau ist im Übrigen fast abgeschlossen; ich muss noch den Managementkram umschreiben und dann das Ganze kräftig durchtesten.

NB: es gibt einen "experimentellen" bcu1serial- alias pei16s-Treiber im knxd. Den auf libev umzuschreiben ist eine Heidenarbeit, die ich nur mache, wenn es unbedingt sein muss.
Mit anderen Worten: Verwendet jemand diesen Treiber? Wenn nicht, fliegt er raus.

[Chris M.]

Latenz ist nicht spürbar. (Ausnahme: der Server hat gerade eine Load von 5, dann kann es ein paar Sekunden dauern bis das Telegramm auf dem Bus ist - liegt aber nicht am knxd oder den CGIs sondern daran, dass die Kiste wegen der Load erst mal dazu kommen musste...).

Von den CGI Aufrufen gibt's eigentlich nur drei verschiedene:

initialer Read (man beachte das t=0):

http://wiregate/cgi-bin/r?s=undefined&a=12/7/1&a=12/7/160&a=12/7/161&a=12/7/51&a=12/7/222&a=12/7/91&a=12/7/92&a=12/7/93&a=12/7/20&a=4/0/11&a=3/3/11&a=3/0/11&a=12/7/220&a=0/3/1&a=0/3/0&a=12/7/24&a=12/7/219&a=12/7/9&t=0

-> Antwort mit den Werten der abgefragten GAs sollte sofort kommen, inkl. einem Index-Wert

folgender Read (man beachte, dass kein t vorhanden ist, statt dessen ist im i=47223 der Index-Wert der letzten Antwort):

http://wiregate/cgi-bin/r?s=undefined&a=12/7/1&a=12/7/160&a=12/7/161&a=12/7/51&a=12/7/222&a=12/7/91&a=12/7/92&a=12/7/93&a=12/7/20&a=4/0/11&a=3/3/11&a=3/0/11&a=12/7/220&a=0/3/1&a=0/3/0&a=12/7/24&a=12/7/219&a=12/7/9&i=47223

-> Antwort wird auf dem Server verzögert, bis für eine dieser GAs ein neuer Wert vorliegt

ein Write:

http://wiregate/cgi-bin/w?s=undefined&a=12/7/1&v=81&ts=1483347285887

Damit sollte man eigentlich alles auch lokal testen können

[Smurf]

CGIs muss man zum Testen übrigens nicht installieren. Environment Variablen passend setzen und einfach von der Kommandozeile aus aufrufen reicht

Ist mir klar, die CGIs wollte ich auch nicht installieren (sind sie eh schon), sondern das CometVisu im nachzusehen was es so tut.

Auch wenn das Prozess-pro-Aufruf einem erst mal das Messer in der Tasche aufgehen lässt wenn man sich auch nur entfernt um Ressourcen und Performance Gedanken macht - bei der Datenrate des KNX und der Anzahl der gleichzeitigen Clients ist das eine lächerliche Last. Auch auf Minimal-Systemen wie OpenWRT Routern. Daher halten sich die CGIs so locker.

Mein Problem ist nicht so sehr die Last, sondern eher die Latenz, insbesondere beim write. (Ein read-Aufruf läuft eh länger.)

[Chris M.]

Kannst du mir mal protokollieren, welche CGI-Aufrufe der CometVisu konkret macht? ich mag den ungern auch noch bei mir installieren. :-/

Genau die, die in den CGI-Dateien, also

https://github.com/knxd/knxd/blob/ma.../eibread-cgi.c
https://github.com/knxd/knxd/blob/ma...eibwrite-cgi.c

aufgeführt sind.

Infos für die übergebenen Parameter: https://github.com/CometVisu/CometVisu/wiki/Protokoll

CGIs muss man zum Testen übrigens nicht installieren. Environment Variablen passend setzen und einfach von der Kommandozeile aus aufrufen reicht

Auch wenn das Prozess-pro-Aufruf einem erst mal das Messer in der Tasche aufgehen lässt wenn man sich auch nur entfernt um Ressourcen und Performance Gedanken macht - bei der Datenrate des KNX und der Anzahl der gleichzeitigen Clients ist das eine lächerliche Last. Auch auf Minimal-Systemen wie OpenWRT Routern. Daher halten sich die CGIs so locker.

[NetFritz]

Hallo
Ich nutze seit einiger Zeit vom User "tuxedo" den KnXAutomationsDaemon um eine InfluxDB mit KNX Werten zu füllen, Grafana zeigt dann diese Werte an.
Diesen KnXAutomationsDaemon gibt es auch als Backend for the CometVisu (http://www.cometvisu.org) with ServerSentEvents (SSE) support.
Wie dieser aber installiert wird kann ich nicht sagen, bei tuxedo mal anfragen.
Bei mir läuft der KnXAutomationsDaemon einwandfrei.
Gruß NetFritz

[Smurf]

OK, das mit CometVisu war ein bisschen unfair. Letztlilch sollst nicht du von CometVisu wegmigrieren, sondern der knxd soll von diesen unzeitgemäßen und untauglichen CGI-Programmen weg. Aber trotzdem sollte man dieses Problem beheben.

Kannst du mir mal protokollieren, welche CGI-Aufrufe der CometVisu konkret macht? ich mag den ungern auch noch bei mir installieren. :-/

[MelbarKasom]

Hallo Chris,
hallo Smurf,

ich hoffe Ihr hattet schöne Feiertage !

Eure Hinweise bzgl. der CGIs kann ich nachvollziehen, jedoch hilft mir das aktuell nicht weiter. Bevor ich von CometVisu weg migriere würde ich gerne CometVisu mit dem aktuellen knx Deamon zum fliegen kriegen. Leider lassen sich die älteren Release von knxd (0.9.1/0.10.1) nicht unter Jessie kompilieren "debian/rules:14: recipe for target 'configure.in' failed" - ich schätze das liegt am Wechsel von init.d auf systemd ?

Ich möchte eigentlich nicht wirklich auf eibd zurückwechseln. Was kann ich tun um einen älteren 0.9.1-basierten knxd unter Jessie zu bauen ? Smurf hast Du eine Idee, wie ich das CGI-Problem aus dem aktuellen Master beheben kann ?

Danke & vg

Thorsten

[Chris M.]

Irgendjemand sollte mal den CometVisu-Leuten verklickern, dass es ressourcenschonendere (und somit schnellere) Methoden gibt, als für jeden Buszugriff über einen Webserver ein CGI zu starten.

Klar. Das mit den CGIs ist auch nur der von der Implementierung her einfachste Ansatz.

Dem CometVisu Protokoll und dem CometVisu Client (also der JavaScript Bibliothek auf der die Echtzeitkommunikation im Browser basiert) ist es herzlich egal ob auf dem Server ständig neue Prozesse gestartet werden oder immer der gleiche wartet und die Anfragen passend beantwortet.

Es gibt auch schon verschiedene andere Backends die das nicht so machen - die klassischen CGIs sind aber vermutlich noch die am meisten verbreitetsten. Der All-Inclusive-Ansatz von OpenHAB hat vermutlich die zweit größte Verbreitung.
Der Rest dürfte vermutlich nirgendwo produktiv sein.