eibd anstatt knxd?

[Smurf]

Da hast du wohl die Ports zwischen UDP und TCP verwechselt, oder? Zudem ist es 3671, nicht 3761.

Wäre es nicht sinnvoll die Schnittstelle ip: als Parameter generell gar nicht zuzulassen? Multicast kann ja mit -RS aktiviert werden. Gibt es eine Situation, welche nur mit der Angabe von -b ip: gelöst werden kann? Den Namen des IP-Interfaces aus ip:[multicast_addr[: port[:interface]]] könnte man ja auch bei -S implementieren, oder?

Damit hast du vollkommen recht.

Wird im Zug der überfälligen Umstellung auf eine vernünftige Konfigurationsdatei passieren.

[Smurf]

okay
ich starte Ihn mit -e 0.0.1 -E 0.0.2:8 -c -b ipt:192.168.1.11 (Weinzierl 730)
sende dann Reads mit knxtools groupread local:/run/knx 5/1/18. Sehe im Gruppenmonitor als Quell-Adresse erst 0.0.2 dann 0.0.3 ... und schließlich auch 0.0.9. Danach schmeißt knxtool den Fehler "connection refused" und das wars.

Das ist sehr seltsam, weil der knxtool die Verbindung sofort wieder zumacht (zumindest bei groupread) und dann die Adresse für den nächsten Prozess verfügbar sein sollte. Bei mir tut das auch … verwendest du die aktuelle Version?

Bitte "-t 1022" vornewegschreiben, das Resultat in einen Pastebin schieben, und mir den Link schicken.

[Bit-te]

Smurf
ich habe das Image heute auf knxd 0.12.5 geupdatet.
Das hat auch soweit Problemlos funktioniert. Leider funktioniert seitdem meine Verbindung zum Bus nicht mehr.

smarthome@raspberrypi:~/knxd$ knxd --version
knxd 0.12.5
smarthome@raspberrypi:~/knxd$ sudo systemctl start knxd.service
smarthome@raspberrypi:~/knxd$ sudo systemctl status knxd.service -l
● knxd.service - KNX Daemon
Loaded: loaded (/lib/systemd/system/knxd.service; enabled)
Active: active (running) since Sun 2017-01-29 17:34:43 CET; 2s ago
Main PID: 12055 (knxd)
CGroup: /system.slice/knxd.service
└─12055 /usr/bin/knxd -t1022 -e 1.1.254 -E 1.1.253:8 -c -DTRS -t 0xffc -f 9 -B single -b tpuarts:/dev/ttyKNX1

Jan 29 17:34:43 raspberrypi knxd[12055]: knxd: Layer 2 [ 5:tpuarts:/dev/ttyKNX1 0.002] open-reset(001): 01
Jan 29 17:34:43 raspberrypi knxd[12055]: knxd: Layer 3 [ 2:layer3 0.002] registerLayer2 6:?-F:tpuarts:/dev/ttyKNX1 = 1
Jan 29 17:34:43 raspberrypi knxd[12055]: knxd: Layer 8 [ 7:systemd 0.002] OpenSystemdSocket
Jan 29 17:34:43 raspberrypi knxd[12055]: knxd: Layer 8 [ 7:systemd 0.002] SystemdSocket opened
Jan 29 17:34:43 raspberrypi knxd[12055]: knxd: Layer 3 [ 2:layer3 0.002] registerLayer2 7:systemd
Jan 29 17:34:43 raspberrypi knxd[12055]: knxd: Layer 3 [ 2:layer3 0.003] registerLayer2 7:systemd = 1
Jan 29 17:34:43 raspberrypi knxd[12055]: knxd: Layer 8 [ 8:systemd 0.003] OpenSystemdSocket
Jan 29 17:34:43 raspberrypi knxd[12055]: knxd: Layer 8 [ 8:systemd 0.003] SystemdSocket opened
Jan 29 17:34:43 raspberrypi knxd[12055]: knxd: Layer 3 [ 2:layer3 0.003] registerLayer2 8:systemd
Jan 29 17:34:43 raspberrypi knxd[12055]: knxd: Layer 3 [ 2:layer3 0.003] registerLayer2 8:systemd = 1
smarthome@raspberrypi:~/knxd$

Der Status meldet schonaml "running"
Aber es läuft nicht.
Nutze die serielle Rot-Schnittstelle von Busware.

so sieht zur Zeit meine knxd.conf aus:

# configuration for knxd.service
START_KNXD=YES

# funktioniert nicht KNXD_OPTS="-e 1.1.254 -E 1.1.253:8 -c -DRS -t 0xffc -f 9 -B single -b tpuarts:/dev/ttyKNX1
# funktioniert nicht KNXD_OPTS="-e 1.1.254 -c -DTRS -t 0xffc -f 9 -B single -b tpuarts:/dev/ttyKNX1"
# funktioniert nicht KNXD_OPTS="-e 1.1.254 -c -DTRS -t 0xffc -f 9 -B single -b tpuarts:/dev/ttyAMA0"
# funktioniert nicht KNXD_OPTS="-e 1.1.254 -E 1.1.253:8 -c -DTRS -t 0xffc -f 9 -B single -b tpuarts:/dev/ttyAMA0"
# funktioniert nicht KNXD_OPTS="-e 1.1.254 -E 1.1.253:8 -c -DTRS -t 0xffc -f 9 -B single -b tpuarts:/dev/ttyKNX1"

# lauffaehig unter knxd0.10 KNXD_OPTS="-e 1.1.254 -DTRS -t 0xffc -c -f 9 -b tpuarts:/dev/ttyKNX1"

Falls jemand eine Idee für mich hat... gerne. Ich weiß mir nicht mehr zu helfen.

Vielen Dank
Gruß
Wolfgang

[itarch]

Bit-te
Also wenn ich das -e und -E richtig verstanden habe schlage ich folgendes vor:
-e 1.1.253 -E 1.1.254:2

Wenn das funktioniert, gäbe es ein Problem wenn Du es so konfigurierst?
-e 1.1.241 -E 1.1.242:8

[Smurf]

itarch hat recht. (Das muss ich noch abfangen.) Ist aber nicht wirklich schädlich, dann nutzt er halt die Adressen von 1.1.253 bis 1.2.4.


Bit-te Was genau heißt "es läuft nicht"? Offenbar läuft der knxd doch. Was genau funktioniert nicht?
Außerdem frage ich mich, wo das "-B single" herkommt. Mach das mal weg.

Und: wieso steht in deiner knxd.conf "START_KNXD=YES"? Das findet sich doch nur in /etc/default/knxd, die auf deinem System (wegen systemd) nicht verwendet wird.

[Bit-te]

Hallo Smurf,

danke für deine schnelle Rückmeldung.
Start_knx=yes stammt aus der alten knxd.conf. (Ich denke aus der die im Image war) Habs jetzt geändert.

Das -B single kommt hierher: https://github.com/knxd/knxd (Migrating to 0.12) Ich habe ziemlich viele Optionen heute Nachmittag probiert. Wollte nichts unversucht lassen, bevor ich mich hier melde.

Die aktuelle knxd.conf sieht folgendermaßen aus:

# configuration for knxd.service

KNXD_OPTS="-e 1.1.245 -E 1.1.246:8 -DTRS -t 0xffc -c -f 9 -b tpuarts:/dev/ttyKNX1"
# funktooniert nicht KNXD_OPTS="-e 1.1.254 -E 1.1.253:8 -c -DRS -t 0xffc -f 9 -B single -b tpuarts:/dev/ttyKNX1"
# funktioniert nicht KNXD_OPTS="-e 1.1.254 -c -DTRS -t 0xffc -f 9 -B single -b tpuarts:/dev/ttyKNX1"
# funktioniert nicht KNXD_OPTS="-e 1.1.254 -c -DTRS -t 0xffc -f 9 -B single -b tpuarts:/dev/ttyAMA0"
# funktioniert nicht KNXD_OPTS="-e 1.1.254 -E 1.1.253:8 -c -DTRS -t 0xffc -f 9 -B single -b tpuarts:/dev/ttyAMA0"
# KNXD_OPTS="-e 1.1.254 -E 1.1.253:8 -c -DTRS -t 0xffc -f 9 -B single -b tpuarts:/dev/ttyKNX1"

# lauffaehig unter knxd0.10 KNXD_OPTS="-e 1.1.254 -DTRS -t 0xffc -c -f 9 -b tpuarts:/dev/ttyKNX1"

Dann startet der knxd wie folgt:

smarthome@raspberrypi:~$ sudo systemctl status knxd.service
● knxd.service - KNX Daemon
Loaded: loaded (/lib/systemd/system/knxd.service; enabled)
Active: active (running) since Sun 2017-01-29 20:05:06 CET; 17s ago
Main PID: 4278 (knxd)
CGroup: /system.slice/knxd.service
└─4278 /usr/bin/knxd -e 1.1.245 -E 1.1.246:8 -DTRS -t 0xffc -c -f 9 -b tpuarts:/dev/ttyKNX1

Jan 29 20:05:06 raspberrypi knxd[4278]: knxd: Layer 8 [ 7:systemd 0.001] SystemdSocket opened
Jan 29 20:05:11 raspberrypi knxd[4278]: knxd: Layer 8 [ 7:systemd 4.431] New Connection
Jan 29 20:05:11 raspberrypi knxd[4278]: knxd: Layer 8 [ 7:systemd 4.431] ClientConnection Init
Jan 29 20:05:11 raspberrypi knxd[4278]: knxd: Layer 4 [ 4:cache 4.432] GroupCacheEnable
Jan 29 20:05:11 raspberrypi knxd[4278]: knxd: Layer 8 [ 8:systemd 4.432] SendMessage(002): 00 70
Jan 29 20:05:11 raspberrypi knxd[4278]: knxd: Layer 7 [ 9:systemd:1.1.246 4.432] OpenGroupSocket
Jan 29 20:05:11 raspberrypi knxd[4278]: knxd: Layer 4 [ 9:systemd:1.1.246 4.432] OpenGroupSocket RW
Jan 29 20:05:11 raspberrypi knxd[4278]: knxd: Layer 8 [ 8:systemd 4.432] SendMessage(002): 00 26
Jan 29 20:05:11 raspberrypi knxd[4278]: knxd: Layer 7 [ 9:systemd:1.1.246 4.432] OpenGroupSocket complete
Jan 29 20:05:16 raspberrypi knxd[4278]: knxd: Layer 2 [ 5:tpuarts:/dev/ttyKNX1 10.000] Watchdog Reset(001): 01
smarthome@raspberrypi:~$

Ich kann dann weder mit der ETS4 noch mit Smarthome/Smartvisu auf den Bus zugreifen.

Beim starten von smarthome im Debug-Modugs kommt folgendes:

2017-01-29 20:06:18 INFO plugin Main Start Plugins -- plugin.py:start:76
2017-01-29 20:06:18 DEBUG plugin Main Starting cli Plugin -- plugin.py:start:78
2017-01-29 20:06:18 DEBUG plugin Main Starting knx Plugin -- plugin.py:start:78
2017-01-29 20:06:18 DEBUG plugin Main Starting ow Plugin -- plugin.py:start:78
2017-01-29 20:06:18 DEBUG scheduler ow 1w-disc next time: 2017-01-29 20:06:20+01:00 -- scheduler.py:_next_time:316
2017-01-29 20:06:18 DEBUG plugin Main Starting mail Plugin -- plugin.py:start:78
2017-01-29 20:06:18 DEBUG plugin Main Starting visu Plugin -- plugin.py:start:78
2017-01-29 20:06:18 DEBUG plugin Main Starting sql Plugin -- plugin.py:start:78
2017-01-29 20:06:19 DEBUG connection Connections CLI: binding to 127.0.0.1:2323 (TCP) -- connection.py:connect:160
2017-01-29 20:06:19 DEBUG connection Connections KNX: connected to 127.0.0.1:6720 -- connection.py:connect:393
2017-01-29 20:06:19 DEBUG __init__ Connections KNX[default]: reading eibd cache -- __init__.py:handle_connect:130
2017-01-29 20:06:19 DEBUG __init__ Connections KNX[default]: enable group monitor -- __init__.py:handle_connect:134
2017-01-29 20:06:19 ERROR __init__ Connections 1-Wire: could not connect to 127.0.0.1:4304: [Errno 111] Connection refused -- __init__.py:connect:60
2017-01-29 20:06:19 DEBUG connection Connections _websocket: binding to 0.0.0.0:2424 (TCP) -- connection.py:connect:160

Wenn ich die Visu aufrufe kommt auch der rote "error" Balken oben rechts in der Ecke.

Bei der ETS 4 kommt, das das Gerät nicht gefunden werden konnte z.B. beim auslesen der Geräteinfo. Der Verbindungstest zeigt allerdings "OK" an.

Kann ich dir sonst noch was mitloggen oder zur Verfügung stellen?

Vielen Dank nochmal
Gruß
Wolfgang

[Smurf]

Hallo Smurf,

danke für deine schnelle Rückmeldung.
Start_knx=yes stammt aus der alten knxd.conf. (Ich denke aus der die im Image war) Habs jetzt geändert.

Das -B single kommt hierher: https://github.com/knxd/knxd (Migrating to 0.12)

Ja, schon, aber da steht genau drin bei welchen Treibern das zutrifft, und das ist bei dir ja nicht der Fall.

Blind rumprobieren ist nicht so dolle hilfreich, letztlich geht es schneller wenn man versteht was da passiert.

Ich kann dann weder mit der ETS4 noch mit Smarthome/Smartvisu auf den Bus zugreifen.

Mach mal "-t1023 -b tpuarts:…" und schau nach ob der dir überhaupt was sendet. Ist das ein USB-Teil, oder hängt der an der seriellen Schnittstelle eines Raspberry Pi?. Wenn Letzteres: bist du dir sicher, dass du in /boot/config.txt die serielle Konsole rausgeschmissen hast und dass kein agetty drauf läuft?
Wenn Ersteres: Rausziehen und wieder reinstecken, überprüfen dass ttyKNX1 noch passt, knxd neustarten.
In beiden Fällen: Leuchtet die KNX-LED des Adapters? sonst tut der nämlich nix.

[itarch]

Smurf ...

Hi smurf
hier der http://pastebin.com/7R6dcxkq
Von einem KNXD in der Version 0.12.4
pi@RASP3BI:~ $ sudo systemctl status knxd
● knxd.service - KNX Daemon
Loaded: loaded (/lib/systemd/system/knxd.service; enabled)
Active: active (running) since Sun 2017-01-29 22:52:05 CET; 10min ago
Main PID: 1785 (knxd)
CGroup: /system.slice/knxd.service
└─1785 /usr/bin/knxd -t1022 -e 0.0.1 -E 0.0.2:8 -c -b ipt:192.168.1.11

Auf einem weiteren Rasp3B (Jessie) hab ich den KNXD in der Version 0.12.5 auch gegen den Weizierl 730 verknüpft: das Ergebnis ist gleich. Nach der 8ten Quell-Adresse ist es vorbei.

Ich weiß nicht ob folgende Info ein beitrag leistet:
Ich lasse in einer Schleife knxtool read Befehle gegen die KNXD.0.12.5 Instanz (System 2) laufen, diese leitet die ops weiter zur eine KNXD.0.12.4 Instanz (System 1). In diesem Versuch ist der KNXD.0.12.4 gegen das Busware TUL Tpuart konfiguriert. Die Schleife reist NICHT ab. Das gleiche Verhalten wie wenn ich die Schleife direkt an der KNXD.0.12.4 Instanz laufen lasse.

[Smurf]

itarch bitte wiederhole mit der aktuellen Version, die schreibt mit auf welchem Kanal er die kollidierenden Adressen findet. Ich kann das leider nach wie vor nicht reproduzieren.

[Bit-te]

@smurf

Mach mal "-t1023 -b tpuarts:…" und schau nach ob der dir überhaupt was sendet. Ist das ein USB-Teil, oder hängt der an der seriellen Schnittstelle eines Raspberry Pi?. Wenn Letzteres: bist du dir sicher, dass du in /boot/config.txt die serielle Konsole rausgeschmissen hast und dass kein agetty drauf läuft?
Wenn Ersteres: Rausziehen und wieder reinstecken, überprüfen dass ttyKNX1 noch passt, knxd neustarten.
In beiden Fällen: Leuchtet die KNX-LED des Adapters? sonst tut der nämlich nix.

Hallo,
das mit -t1023... kann ich erst heute Abend wieder testen.
Es ist eine serielle Platine. Dadurch das es vor dem Update auf 0.12.5 funktioniert hat (mit Ausnahme der ETS Programmierung) bin ich mir ziemlich sicher dass ich den Eintrag aus der config.txt entfernt habe. (Es sei denn, beim Update wäre dort wieder was rein geschrieben worden?)
Ich kenne agetty nicht. Damit kann man lt. Google tty Ports öffnen. Ich habe das noch nie gebraucht und somit auch nicht installiert.
Wie gesagt. Das System lief ohne Probleme (außer ETS) dann habe ich das Update gemacht wie im github /knxd/knxd unter Building beschrieben.
Am System habe ich weiter nichts verändert, außer meine Probiererei in der knxd.conf. Habe noch die Einträge kontrolliert in der 70-knxd.rules

Danke für deine Bemühungen.
Gruß
Wolfgang

[Smurf]

Bit-te agetty ist per Default installiert. Prüf einfach ob es läuft. Dito die Konsole. Der knxd-Update hat das natürlich nicht angefasst …

Ich will einfach 100% ausschließen, dass irgendsonstwas auf dem Port hockt. Kann man auch mit

lsof /dev/ttyAMA0

testen.

Allgemein: wenn der TPUART nicht reagiert, kann das eigentlich nur drei Ursachen haben:

• tpuart (oder die Verbindung dahin) kaputt
• kein KNX-Bus am tpuart – dann reagiert er auch nicht
• ein anderes Programm liest vom Port und klaut dir die Daten

[itarch]

hi Smurf
http://pastebin.com/YcKUYSHE mit Version 0.12.5
Ab Zeile 277 versuche ich den 9ten (rsp. den 10ten) Zugriff zu machen...

[itarch]

Bit-te
leise eingemischt, da ich auch ein Busware Adapter habe...

a. nachdem der Busware TUL- TPUART USB-Adapter erfolgreich im Rasp eingebunden war (kann mit dmesg geprüft werden)
b. musste ich mit udevadm info --attribute-walk die KERNELS Wert auslesen
c diesen in die datei "70-knxd.rules" an entsprechender Stelle eintragen
d. udevadm test /sys ... ausführen und erst dann wurde /dev/ttyKNX1 generiert, auf diesen der user knxd Rechte hat
c. zu prüfen mit ls -lL /dev/ttyKNX1

[Smurf]

Ah. Gefunden.

Jan 30 08:59:04 RASP3BII knxd[12151]: knxd: Layer 1 [ 4:ipt:192.168.1.11 28.239] Recv L_Data low from 0.0.20 to 5/1/28 hops: 05 T_DATA_XXX_REQ A_GroupValue_Read

Danke. Kannst du mir erklären, wieso dein Adapter unmotiviert im Busmonitor-Modus arbeitet – und die Pakete, die der knxd ihm sendet, kommentarlos wiederholt? (Rhetorische Frage, ich weiß … aber falls man das irgendwie wegkonfigurieren kann …)

Das zu filtern ist nichttrivial, aber wegen Busschleifenunterdrückung auch unabhängig davon sinnvoll. Ich arbeite dran.

[Bit-te]

itarch
du darfst dich auch gerne "laut" einmischen. Ich bin für jede Hilfe dankbar.
Mein Problem ist einfach, das ich mit dem meisten was hier bzgl. knxd gesprochen wird, nichts anfangen kann. Hab mit Linux noch nie in meinem Leben was zu tun gehabt, geschweige denn mit Schnittstellen, und auslesen etc.
Alles was hier steht gehe ich mir -teils sehr mühsam- bei Tante Google zusammensuchen.

Daher bin ich um jeden froh der mir irgendeinen Hinweis geben kann. Im Moment habe ich wieder meinen Raspi 1 mit dem alten Image und eibd am laufen, weil ich hier absolut Hilflos und teilweise überfordert bin. Hab mir auch schon überlegt auf dem alten zu bleiben. Aber letzten Endes ist das auch kein Lösung.

Die Werte von denen du sprichst (udevadm) habe ich gestern Abend noch ausgelsen und mit der 70-knxd.rules verglichen. Das passt.

Den Befehl "udevadm test /sys" habe ich bisher nirgends begegnet. Das werde ich noch testen.

in meiner knxd.conf steht auch (KNXD_OPTS="-e 1.1.245 -E 1.1.246:8 -DTRS -t 0xffc -c -f 9 -b tpuarts:/dev/ttyKNX1")
In der Anleitung steht aber (KNXD_OPTS="-e 1.1.245 -E 1.1.246:8 -DTRS -t 0xffc -c -f 9 -b tpuarts:/dev/ttyAMA0")

Habs mit beiden Parametern versucht gestern. Aber keiner von beiden hat was getan.Was ich sehr komisch finde ist, dass wenn ich den knxd starte, meine Smartvisu den roten "Error" Balken anzeigt. Dann werden auch meine 1 wire Werte nicht akualisiert, die ich über einen USB Busmaster abfrage. Wenn der knxd nicht gestartet ist, funktioniert wenigstens die 1wire Abfrage und die Visu läuft (natürlich ohne Werte vom KNX Bus)

Wie hängt denn das zusammen? Die Visu spricht doch nicht direkt mit knxd, oder? Die unterhält sich doch nur mit "Smarthome"

Du siehst, ein ziemlich ratloser Wolfgang

Vielen Dank schonmal