eibd(war bcusdk) Fork -> knxd

[Smurf]

Bitte setze ein komplettes Protokoll (aktuelle Version) in einen Pastebin.

[vossy74]

Hallo ,

ich habe eine Weinzierl 730 IP-Schnittstelle und starte den knxd mit folgenden Parametern.

knxd -e 1.1.55 -E 1.1.245:8 -DTRS -c -i --send-delay=120 -B single -b ipt:x.x.x.x

Das Ergebnis ist, das die Verbindung zur schnittstelle bei der ETS4 und 5 als ok angezeigt wird. Leider kann ich weder Geräteinfos abfragen noch diese Programmieren.
Die ETS sagt dan Adresse kann nicht gefunden werden. Was mache ich falsch?
Smarthome.py und Smartvisu funktioniert einwandfrei.

Ach so fast vergessen , die Version ist 0.12.13-2

knxd: Layer 8 [ 8:mcast:knxd:1.1.245    495.702] TUNNEL_REQ
knxd: Layer 9 [ 8:mcast:knxd:1.1.245    495.703] Queue L_Data system from 1.1.245 to 1.1.2 hops: 06 T_DISCONNECT_REQ
knxd: Layer 8 [ 8:mcast:knxd:1.1.245    495.703] found addr 1.1.245
knxd: Layer 3 [ 3:layer3                495.703] Route L_Data system from 1.1.245 to 1.1.2 hops: 05 T_DISCONNECT_REQ
knxd: Layer 8 [ 2:mcast:knxd            495.703] Send_Route L_Data system from 1.1.245 to 1.1.2 hops: 05 T_DISCONNECT_REQ
knxd: Layer 2 [ 6:ipt:x.x.x.x     495.703] Send L_Data system from 1.1.55 to 1.1.2 hops: 05 T_DISCONNECT_REQ
knxd: Layer 8 [ 8:mcast:knxd:1.1.245    495.704] TUNNEL_ACK

knxd: Layer 5 [ 7:?-F:ipt:x.x.x.x 334.760] drop packet from 1.1.55
knxd: Layer 5 [ 7:?-F:ipt:x.x.x.x 334.882] drop packet from 1.1.55
knxd: Layer 8 [ 8:mcast:knxd:1.1.245    334.972] TUNNEL_ACK
knxd: Layer 8 [ 8:mcast:knxd:1.1.245    334.974] TUNNEL_ACK
knxd: Layer 8 [ 8:mcast:knxd:1.1.245    334.974] Wrong sequence 92<->93

[Smurf]

Hatte vorhin auch immer das "initialisation of backend 'tcp' failed: Address already in use" Problem, muss ich mir nochmals genau ansehen.

Das ist mit Sicherheit entweder der systemd-Socket (in deinem Fall eher unwahrscheinlich …), oder ein noch laufender zweiter knxd.

[Onkelandy]

Hallo Smurf
Ich hab jetzt am NAS nochmals alles platt gemacht, vermutlich war da einfach noch eine alte Version da, die dann wegen systemd gezickt hat.

Das mit dem --disable-systemd funktioniert nun. Ich konnte auch mittels make und checkinstall ein deb-File basteln und dieses dann erfolgreich auf dem NAS installen, nachdem ich ein paar lib-Probleme gelöst hatte.

Echt sonderbar ist, dass es bei mir häufig funktioniert und dann mit exakt den gleichen Attributen nach einem Neustart nicht mehr. Ich schau mir jetzt nochmals 0.11.18 an.

Hatte vorhin auch immer das "initialisation of backend 'tcp' failed: Address already in use" Problem, muss ich mir nochmals genau ansehen.

[Smurf]

Onkelandy Dann kopier halt libsystemd.so.0 mit rüber. Tut nicht weh. Ich weiß aber nicht wirklich, wie du das geschafft hast, denn wenn ich --disable-systemd verwende dann linkt der auch nicht damit. Schick mir mal einen Pastebin mit deinem config.log.

rdorsch sch Eine "Linie" (also Geräteadressen 1.1.X für X von 0 bis 255) verwendet man, weil man elektrisch eh nicht mehr Geräte an den Bus hängen kann und es am einfachsten ist, die durchzunumerieren. Und weil man einen vernünftigen KNX-Router beibringen kann, welche Linien wo sind -- dann schickt er Nachrichten, die an diese Geräte adressiert sind, nur da hin. Wie du den Rest so organisierst, dass du deinen Routern möglichst wenige Adressbereiche beibringen musst, bleibt dir überlassen.

Wenn du Geräte 1.1.X und 1.2.Y gleichzeitig auf ein Kabel hängst, funktioniert das auch. Macht man zB bei einem mehrstöckigen Haus wenn die initiale Installation klein genug ist, dass man (noch) ohne Router auskommt, aber später bei der Bustrennung nicht umnummerieren will.

Dem knxd kann man (noch) nicht beibringen, welche Linien wo sind, aber er merkt sich, an welcher Verbindung er welche Adresse zuletzt gesehen hat, und schickt die Pakete dort hin. Ist aber auch relativ unwichtig, weil du eigentlich nur beim Programmieren überhaupt direkt adressierst, der Rest geht über Gruppenadressen.

Gruppenadressen sind eine komplett andere Nummer. Einem vernünftigen KNX-Router kann man beibringen, welche Adressbereiche für welche Linien interessant sind. Beim knxd geht das noch nicht, der schickt alles überallhin. Ist in Arbeit. Die typische Home-Installation braucht das aber nicht wirklich.

Physisch gibt es auf dem KNX-Kabel keine Router wie bei IP, wo du Pakete, die irgendwo anders hingehen, direkt an den Router adressieren musst. KNX-Pakete liegen direkt am Bus an; derjenige Router, der sich dafür verantwortlich fühlt (inkl. aktuell jeder knxd), bestätigt die und leitet sie weiter. (Ansonsten werden sie ein paarmal wiederholt.) Bei normalen Daten, die an Gruppenadressen gehen, ist die Zahl der interessierten Geräte eh potenziell unbegrenzt.

[Onkelandy]

Danke für das Privileg, dass das nur ich machen darf Leider funzt es auch so nicht.. hatte das eh mit 0.12.2 oder 0.12.0 schon probiert. Also mittels configure --disable-systemd, make, make install alles auf der VM installiert und dann die einzelnen Files raus geklaubt und aufs NAS kopiert.
Dort gibt es nun folgende Meldung:

root@SynologyDS1515:~# /usr/lib/knxd/busmonitor1
usage: busmonitor1 url: Success
root@SynologyDS1515:~# /usr/lib/knxd/busmonitor1 ip:127.0.0.1
...blabla, da kann ich ganz normal mitlauschen
root@SynologyDS1515:~# knxd --version
knxd: error while loading shared libraries: libsystemd.so.0: cannot open shared object file: No such file or directory

[rdorsch]

Wenn das Prinzip auf Lauschen auf dem Bus beruht und der ETS nicht bekannt ist, heißt das dann, dass es auf die Linie beschränkt ist in der mein IP-Interface enthalten ist?

Mir war erstmal wichtig, dass ich ein grundlegendes Verständnis für die untersten Schichten habe, damit ich verstehe was prinzipiell möglich ist und was nicht .... und dass ich sicher sein kann, dass sie auch funktionieren.

Was ich darüber baue habe ich noch nicht final entschieden, aber OpenHAB und smarthome.py sind gerade die Favoriten. smarthome.py nutzt linknx soweit ich weiss, bei openhab weiss ich das noch nicht.

Auf PyKNyX bin ich in jedem Fall gespannt, da ich eine python basierte Lösung sympathisch finde und damit evtl. kleine Automatisierungsaufgaben effizient zu erledigen sind.

[Tru]

Kann ich mit knxd Operationen auf dem Host auslösen (z.B. per Callback, Polling oder was auch immer), wenn auf dem KNX Bus eine Schreiboperation auf eine Gruppenadresse passiert?

Ich verwende für solche Sachen linknx als Logic Engine.

[Smurf]

Ja, geht. Sinnvollerweise schreibst du dazu ein kleines Programm in der Programmiersprache deiner Wahl. Ich selber bin gerade dabei, das PyKNyX-Paket (Python) soweit aufzubohren, dass man es "einfach" einbinden kann. (Geht jetzt schon ganz gut, ist aber noch zu kompliziert für den Hausgebrauch.)

Die simple Methode ist, einfach auf dem Bus mitzuhören, ob irgendwas passiert ist, und dann entsprechend zu agieren. So einfach würde ich es mir aber nicht machen: Eigentlich willst du einen Busteilnehmer haben, der (a) einen Zustand hat, den man (b) auslesen können muss, und der (c) diese Zustandsänderung auch kommuniziert (damit dein Sensor sein kleines Licht einschalten kann).

Ob dieser Teilnehmer jetzt ein KNX-Aktor auf dem Gebäudebus ist oder ein Programm in deinem Rechner, ist für die Systematik des Ganzen egal.

[rdorsch]

Kann ich mit knxd Operationen auf dem Host auslösen (z.B. per Callback, Polling oder was auch immer), wenn auf dem KNX Bus eine Schreiboperation auf eine Gruppenadresse passiert?

Wenn, ja, gibt es irgendwelche Doku, die beschreibt wie das aufgesetzt wird?

Dank des guten HInweises von Michixx funktioniert die umgekehrte Richtung (Auslösen einer Schreiboperation auf eine Gruppenadresse vom Host) :-)

Danke und Gruß
Rainer

[Smurf]

Mal eine blöde Frage -- gar kein libc6? was machst du dann überhaupt mit Debian-Paketen auf der Kiste?

dpkg-buildpackage interessiert sich einen Feuchten für das, was du dem ./configure gesagt hast – die Konfiguration findest du (wie bei allen debian-Sourcen) in der Datei debian/rules.
Du (und nur du!) solltest statt dpkg-buildpackage einfach ./configure und dann "make && make install" aufrufen, und den Kram dann manuell aus /usr/local extrahieren und zusammen mit den benötigten Libraries rüberkopieren.

[Onkelandy]

Ich führe auf einer Debian 64bit Virtual Machine nach dem Klonen der neuesten Version von knxd folgende Befehle aus:
./bootstrap.sh
./configure --disable-systemd
dpkg-buildpackage -b -uc

Das deb installiere ich dann auf dem Synology DS1515+ und erhalte folgende Dependency Probleme:

dpkg: verification on package knxd-tools_0.12.4-2_amd64.deb failed; but installing anyway as you requested
Preparing to replace knxd-tools 0.12.4-2 (using knxd-tools_0.12.4-2_amd64.deb) ...
Unpacking replacement knxd-tools ...
dpkg: dependency problems prevent configuration of knxd:
 knxd depends on libc6 (>= 2.4); however:
  Package libc6 is not installed.
 knxd depends on libev4 (>= 1:4.04); however:
  Package libev4 is not installed.
 knxd depends on libgcc1 (>= 1:4.1.1); however:
  Package libgcc1 is not installed.
 knxd depends on libstdc++6 (>= 4.8); however:
  Package libstdc++6 is not installed.
 knxd depends on libsystemd0; however:
  Package libsystemd0 is not installed.
 knxd depends on libusb-1.0-0 (>= 2:1.0.8); however:
  Package libusb-1.0-0 is not installed.
 knxd depends on init-system-helpers (>= 1.18~); however:
  Package init-system-helpers is not installed.
 knxd depends on lsb-base; however:
  Package lsb-base is not installed.

Libusb hätt ich eigtl. im lib Verzeichnis, und es ist auch im Pfad drin: export LD_LIBRARY_PATH=/usr/local/lib
Bekäme ich sicher irgendwie gelöst, aber da steht jedenfalls noch libsystemd0, obwohl ich das beim Config disabled hatte..?

[Smurf]

Was wäre denn nun die vernünftigere Lösung? Beide über ipt (was imho in 0.12 nicht gegangen ist) oder 1 als ip -DRS und der andere mit ipt?

Letzteres sollte funktionieren. Sinnvollerweise verwendet ein knxd "-DRS -b ipt:…" und der andere "-b ip:".

Und wenn ich das deb File von nem Jessie nehme, gibt es Fehler wegen systemd.

Welcher bitte genau?

[Smurf]

Wenn ich den Busmonitor auf dem NAS starte (direkt über busmonitor1),

Busmonitor schaltet das Interface auf Bus-Monitor. Ansonsten ist es tot.

Du willst vbusmonitor1.

Weil darüber so gut wie jeder stolpert., wird es in Zukunft eine Option geben, welches Interface der Hardware-Busmonitor ist (wenn man denn einen braucht), und ohne die wird busmonitor-ohne-V nicht mehr funktionieren.

[Onkelandy]

Danke.. wenn ich das jetzt noch auf der Syno blicken würde... Die 2 Container laufen mal, aber dann steh ich an, hehe. Danke dennoch schon mal!