eibd(war bcusdk) Fork -> knxd

[mayrjohannes]

Ich hab jetzt noch etwas weitergetestet und auf meinem Laptop eibd installiert und mit meinem Tpuart interface (NCN5120) verbunden. Vom Server aus hab ich dann zwei Szenarien durchgespielt:
* Smarthome direkt mit eibd vom Netbook verbunden: Sound funktioniert perfekt
* Smarthome mit eibd vom Server verbunden und Server eibd mit ipt mit Netbook eibd verbunden: Sound funktioniert perfekt
* Wieder die alte Konfiguration mit Smarthome mit eibd vom Server direkt an NCN5120: Sound kracht wie verrückt.

Hat hier irgendwer einen Rat für mich? Will nicht nur für das noch einen zweiten Server (e.g. Raspi) laufen lassen. Ist nur eine zusätzliche Fehlerquelle und braucht Strom.

[MelbarKasom]

Hallo ich habe vor ein kurzer Zeit von eibd auf knxd umgestellt. Zuerst sah alles sehr problemlos aus. Jedoch habe ich aktuell Probleme mit der letzten Stable Version (0.10.15-1) und mindestens der Version 0.11.10-1 von knxd. Das Problembild, dass ich sehe ähnelt dem Problem aus folgenden Post:

https://knx-user-forum.de/forum/%C3%...-bis-x-x-x-aus

Groupswrite, knxd, ETS5, linknx funktionieren einzeln super. Sobald ich jedoch über CometVisu eine Abfrage starte, wird ein ganzer Haufen von read-requests 0/0/1, 0/0/2, 0/0/3, .... ausgelöst. Der Bus dampft aber CometVisu zeigt nichts an.

Die Lösung in dem o.a. Post war auf Version knxd v0.9 zurückzugehen. Ist das Problem bekannt und in einem aktuelleren Branch gelöst ?

Danke,

Thorsten

[Smurf]

Sobald ich jedoch über CometVisu eine Abfrage starte

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.

Wie ist dein knxd konfiguriert?

[MelbarKasom]

Wie ist dein knxd konfiguriert?

Hi Smurf,

ich starte knxd mit den folgenden Parametern:

KNXD_OPTS="-e 1.1.241 --eibaddr=1.1.128 -u /tmp/eib -c -D -T -R -S -b ipt:192.168.1.146:3671"

In dem Zuge: Ich habe (zumindest bei eibd und bei knxd 0.11.10-1) das Problem gehabt, dass ich nur dann parallel mit ETS5 "horchen" konnte, wenn ich die Parameter "-e 1.1.241 --eibaddr=1.1.128" übergeben habe. Mit nur "-e 1.1.241" musste ich für Arbeit mit der ETS immer den knxd deaktivieren. Startet knxd mehrere Serverprozesse wenn mehrere Adressen übergeben werden ?

raspi:/home/pi# systemctl status knxd.socket
● knxd.socket - KNX Daemon (socket)
Loaded: loaded (/lib/systemd/system/knxd.socket; enabled)
Active: active (running) since Di 2016-12-20 22:03:46 CET; 10h ago
Listen: /var/run/knx (Stream)
[::]:6720 (Stream)

raspi:/home/pi# systemctl status knxd.service
● knxd.service - KNX Daemon
Loaded: loaded (/lib/systemd/system/knxd.service; enabled)
Active: active (running) since Di 2016-12-20 22:20:33 CET; 10h ago
Main PID: 30080 (knxd)
CGroup: /system.slice/knxd.service
└─30080 /usr/bin/knxd -e 1.1.241 --eibaddr=1.1.128 -u /tmp/eib -c -D -T -R -S -b ipt:192.168.1.146:3671

Als IP-Schnittstelle habe ich von Gira die KNX/IP Schnittstelle 901410 im Einsatz.

[Smurf]

-e und --eibaddr sind genau dasselbe, du überschreibst die erste Adresse mit der zweiten. Auf welches INterface hast du die ETS eingestellt (und mit welcher KNX-Adresse)? Verwendest du die aktuelle Version des knxd-Master?

[MelbarKasom]

Ich verwende aktuell die letzte Stable aus dem Repository:

raspi:/home/pi# ll /usr/bin/knxd
-rwxr-xr-x 1 root root 296K Dez 20 21:57 /usr/bin/knxd

raspi:/home/pi# knxd -V
knxd 0.10.14

raspi:/usr/local/src# ls -ltr
drwxr-xr-x 5 3001 12001 4096 Nov 28 20:37 pthsem-2.0.8
-rw-r--r-- 1 root staff 37752 Nov 28 20:38 libpthsem20_2.0.8_armhf.deb
-rw-r--r-- 1 root staff 95380 Nov 28 20:38 libpthsem-dev_2.0.8_armhf.deb
-rw-r--r-- 1 root staff 71266 Nov 28 20:38 libpthsem-dbg_2.0.8_armhf.deb
-rw-r--r-- 1 root staff 13048 Nov 28 20:38 libpthsem-compat_2.0.8_armhf.deb
-rw-r--r-- 1 root staff 1736 Nov 28 20:39 pthsem_2.0.8_armhf.changes
drwxr-sr-x 12 root staff 4096 Dez 20 21:52 knxd
-rw-r--r-- 1 root staff 98106 Dez 20 21:58 knxd_0.10.15-1_armhf.deb
-rw-r--r-- 1 root staff 37388 Dez 20 21:58 knxd-tools_0.10.15-1_armhf.deb
-rw-r--r-- 1 root staff 38698 Dez 20 21:58 knxd-dev_0.10.15-1_all.deb
-rw-r--r-- 1 root staff 13862 Dez 20 21:58 knxd-examples_0.10.15-1_armhf.deb
-rw-r--r-- 1 root staff 1672 Dez 20 21:58 knxd_0.10.15-1_armhf.changes

Interessant, die Version vom knxd passt nicht mit der aus dem Build zusammen :-)

In der ETS habe ich auf das Interface "1.1.128 knxd (192.168.1.114:3671)" konfiguriert.

Ich verwende die eibread-cgi aus /usr/lib/knxd/

raspi:/usr/lib/cgi-bin# ll
lrwxrwxrwx 1 root root 25 Dez 20 22:11 r -> /usr/lib/knxd/eibread-cgi
lrwxrwxrwx 1 root root 26 Dez 20 22:11 w -> /usr/lib/knxd/eibwrite-cgi

[MelbarKasom]

- Verwendest du die aktuelle Version des knxd-Master?

In diesem Punkt verhalten sich übrigens Master und Stable identisch.

[ctr]

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.

Ich glaube die Einsicht ist da, es hat sich nur noch niemand gefunden, der eine Alternative schreibt. Davon abgesehen ging es ja mit dem eibd und auch früheren Versionen, also eine Veränderung des Verhaltens scheint in neueren Versionen stattgefunden zu haben.

[MelbarKasom]

Ich glaube die Einsicht ist da, es hat sich nur noch niemand gefunden, der eine Alternative schreibt. Davon abgesehen ging es ja mit dem eibd und auch früheren Versionen, also eine Veränderung des Verhaltens scheint in neueren Versionen stattgefunden zu haben.

Ich werde gerne bei dem CometVisu-Team eine entsprechende Eingabe machen. Solange ich noch nicht auf SmartVisu umgestellt habe, wäre allerdings eine Lösung für die CGI-Schnittstelle hilfreich :-). Bevor ich alle alten Brachnes durchprobiere: gibt es eine neuere Version als 0.9, die funktionieren könnte ?

Was kann ich tun um dem Problem auf den Grund zu kommen und eine Hilfe für eine Code-Anpassung geben können ?

[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.

[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

[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. :-/

[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

[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.

[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.)