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

  • Smurf
    antwortet
    Update mit korrigierten Logs gepusht. Sollte jetzt wieder durchlaufen.

    Einen Kommentar schreiben:


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

    Ich schau mal woran das liegt.

    Einen Kommentar schreiben:


  • Knaller
    antwortet
    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

    Einen Kommentar schreiben:


  • Smurf
    antwortet
    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-

    Einen Kommentar schreiben:


  • Knaller
    antwortet
    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

    Einen Kommentar schreiben:


  • Smurf
    antwortet
    Zitat von henfri Beitrag anzeigen
    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 …

    Einen Kommentar schreiben:


  • henfri
    antwortet
    Moin,

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

    Gruß,
    Hendrik

    Einen Kommentar schreiben:


  • Smurf
    antwortet
    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.

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    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):
    Code:
    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):
    Code:
    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:
    Code:
    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

    Einen Kommentar schreiben:


  • Smurf
    antwortet
    Zitat von Chris M. Beitrag anzeigen
    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.)

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    Zitat von Smurf Beitrag anzeigen
    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 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.

    Einen Kommentar schreiben:


  • NetFritz
    antwortet
    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

    Einen Kommentar schreiben:


  • Smurf
    antwortet
    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. :-/

    Einen Kommentar schreiben:


  • MelbarKasom
    antwortet
    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

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    Zitat von Smurf Beitrag anzeigen
    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.

    Einen Kommentar schreiben:

Lädt...
X