eibd(war bcusdk) Fork -> knxd

[WagoKlemme]

Manchmal ist die Lösung so nahe:
smarthome@ibbgateway:~$ knxtool groupreadresponse ip:127.0.1.1 0/0/8
Send request
Response from 1.1.80: B4 26 0E
Ending groupreadresponse.
smarthome@ibbgateway:~$

Sorry, wusste ich nicht.

[WagoKlemme]

Ich habe das IBBCape bekommen und mache meine ersten Gehversuche. Der knxd ist gestartet

smarthome@ibbgateway:~$ sudo /etc/init.d/knxd start
[ ok ] Starting knxd (via systemctl): knxd.service.
smarthome@ibbgateway:~$ ps -ef | grep knxd
knxd       405     1  0 20:15 ?        00:00:01 /usr/bin/knxd --GroupCache --Discovery --Routing --Tunnelling --Server --tpuarts-ack-all-group --layer2=tpuarts:/dev/ttyS2
smartho+   640   598  0 20:24 pts/0    00:00:00 grep knxd

dann kommt mein Problem:

smarthome@ibbgateway:~$ knxd groupreadresponse 1/1/80
not a valid url
smarthome@ibbgateway:~$

Meine Einstellungen in /etc/network/interfaces

auto eth0
iface eth0 inet static
address 192.168.2.37
netmask 255.255.255.0
gateway 192.168.2.1
post-up route add -net 224.0.23.12 netmask 255.255.255.255 eth0
pre-down route del -net 224.0.23.12 netmask 255.255.255.255 eth0

Kann mir jemand einen Tip geben ?
Schönes Wochenende
Armin

[bigblue1735]

bigblue1735 schalte bitte ein paar Logging-Optionen ein (knxd -t1023 -f9 …) und schicke mir die, idealerweise mit dem alten knxd als Vergeich.

Vielen Dank für deine Hilfe und dein Einsatz. Ich habe den Log-Output angehängt. Eine Datei heisst knxd_aktuell und die andere knxd_0_9. Ich habe in beide Dateien den Programmaufruf und die Version des knxd eingefügt.

Was mir schon jetzt aufgefallen ist. Die aktuelle Version scheint nur Probleme mit dem senden Schalten (1.001) zu haben. Ich kann weder über mein smarthome.py Server noch über die ETS das Licht anschalten. Das senden der Datum, Uhrzeit und Temperaturwerte, die der smarthome.py sender macht klappt ohne Probleme.

*EDIT*
Jetzt gerade habe ich gemerkt, dass er die Schaltung doch ausführt, jedoch mit sehr langer Verzögerung. Wie soll ich das erklären. Ich schalte per ETS Licht an. Es passiert nichts. Ich schalte per ETS das Licht wieder aus. Dann dauert es ca. 1 Minute, anschließend geht das Licht an und direkt wieder aus.

*EDIT2*
Die Programmierung von Geräten funktioniert bei beiden Versionen nicht. Ich bin aber der Meinung das hat schon mal geklappt.

Ich hoffe du kannst mit den LOG-Dateien was anfangen.

[hotzen]

Ich habe das selbe Problem! In dieser Datei ist der Port scheinbar reserviert?!?
/etc/systemd/system/sockets.target.wants/knxd.socket

Ich verstehe SystemD zu wenig dafür, aber bei anderen Programmen scheint es zu funktionieren. Warum will SystemD den Port hier schon reservieren?

Na ist doch eine elementare Einstellung zum starten des daemons?! Kannst es ja genau in der Datei auch einfach ändern, ist doch auch nichts weiter als eine daemon-config Datei...

Systemd ist absolut großartig, einfach anpassbar und systemctl sogar noch intuitiv....

[Smurf]

bigblue1735 schalte bitte ein paar Logging-Optionen ein (knxd -t1023 -f9 …) und schicke mir die, idealerweise mit dem alten knxd als Vergeich.

[Smurf]

Der Socket ist nicht "reserviert" vom systemd, sondern er wird verwendet, um den knxd zu starten, wenn sich ein Programm mit diesem Socket verbindet. Das hat den Vorteil, dass der Socket direkt nach dem Booten schon offen ist und man sich nicht mit Abhängigkeiten zwischen einzelnen Programmen herumschlagen muss.

Der offene Socket wird direkt an den knxd übergeben (Environment-Eintrag plus offener Dateideskriptor), ohne dass es dazu eine Option braucht.

Die Lösung des Probems: Lass diese Option in der knxd.conf einfach weg und es funktioniert alles.

[givemeone]

Auf initd wechsle ich nicht da sonst alles super läuft. Werde ich eben noch bei eibd bleiben. Danke für die Info!

Ich habe das selbe Problem! In dieser Datei ist der Port scheinbar reserviert?!?
/etc/systemd/system/sockets.target.wants/knxd.socket

Ich verstehe SystemD zu wenig dafür, aber bei anderen Programmen scheint es zu funktionieren. Warum will SystemD den Port hier schon reservieren?
Wenn ich dort einen anderen Port eintrage, geht es, wie fast zu erwarten war, nicht.

[umatz]

Auf initd wechsle ich nicht da sonst alles super läuft. Werde ich eben noch bei eibd bleiben. Danke für die Info!

Mein drei Posts weiter oben beschriebenes Setup läuft auf Ubuntu 15.10 mit systemd.

[ChrisP]

Auf initd wechsle ich nicht da sonst alles super läuft. Werde ich eben noch bei eibd bleiben. Danke für die Info!

[hronny]

Das Problem hatte ich zusätzlich nachdem ich auf Jessie gewechselt bin. Hier scheint durch den Systemd Dienst der Port zu blockieren. Probiere mal ein

netstat -tupln |grep 6720

hier wird sicher ein Prozess herauskommen. Eine Lösung hatte ich nicht, da ich mich mit systemd nicht wirklich anfreunden kann. Ohne einen Krieg zu beginnen, musste ich auf Grund von anderen Dingen von systemd auf initd wechseln. Hier funktioniert der Start hingegegen reibungslos.

[ChrisP]

Habe, bevor ich eibd auf meinen Produktionsserver gegen knxd ersetze mal auf dem RPi versucht, und bekomme folgendes:
E00000013: OpenInetSocket 6720: bind: Address already in use
initialisation of the knxd inet protocol failed: Address already in use

Jemand einen Tipp? OS: Debian Jessie, ps-ef bringt kein knxd, eibd war hier nie installiert

[umatz]

Da eibd auch routing aktiviert hast, könntest du da eine Schleife gebaut haben.

Ja, meine IP-Schnittstelle soll auch Routing können und ich vermute auch, dass ich eine Schleife erzeugt hatte.
Es läuft jetzt seit einer Woche mit folgenden Parametern:

knxd -e 15.15.2 --listen-tcp -u --GroupCache ipt:192.168.178.10

Wenn ich (mit den ansonsten gleichen Parametern) versuche, mich mit via Routing-Protokoll mit der Schnittstelle zu verbinden ("ip:"), dann sehe ich mit dem knxd zwar sämtlichen traffic auf dem Bus, aber die auf dem Rechner erzeugten Telegramme werden nicht in den KNX-Bus übernommen. Ich meine, dass ich mich früher^TM sowohl über Routing- als auch über Tunneling-Protokoll erfolgreich mit dieser IP-Schnittstelle verbinden konnte. Ist mir aber jetzt aber auch nicht so wichtig, Hauptsache ist, dass es läuft.

[hronny]

Guten Morgen. Ich habe eine ewig alte knxd 0.9 Version auf meinem RPi am laufen und wollte jetzt mal die aktuelle Version probieren. Das kompilieren hat auch ohne Probleme geklappt, allerdings habe ich keinen Verbindung zum KNX - Bus. Ich muss ehrlich gestehen, dass ich keine Ahnung davon habe wie das alles läuft, beim letzten mal hat es direkt ohne Probleme geklappt.

Ich würde euch gerne mehr Informationen zukommen lassen, jedoch finde ich kein LOG-File in dem was drinsteht. Ich starte den knx-daemon mit folgendem Befehl.

 [B]knxd[/B] --daemon=/tmp/knx.log --eibaddr=1.1.128 -D -T -R -S -i -u usb:1:6:1:0:0

Infos:
knxd 0.10.0 (update von gestern Abend)
Schnittstelle MDT - USB

Mit einer älteren Version 0.9.0 klappt alles ohne Probleme.

Vielen Dank für Eure Hilfe.

Das Problem habe ich auch gerade. Mein System ist ein normales Debian Wheezy mit ABB USB Schnittstelle. mit der "alten" knxd 0.9 funktioniert alles, mit der neuen nicht. Das komische daran ist, das man über den Busmonitor alles "mithören" kann, aber schreiben auf den Bus oder Leseanforderungen funktionieren nicht. Sendet man mehrere Lesebefehle hintereinander kommen nach vielen Sekunden auch viele Antworten. Ich versuche gerade herauszufinden bis zu welcher Commit Version es noch funktionierte. Ich glaube kaum, dass es am Wheezy selbst liegt, aber ein Upgrade werde ich die Tage wohl auch noch machen.

[Zepp]

Telegrammvermehrungen (genauer gesagt Vervierfachungen).

ist deine IP Schnittstelle ein Router?
Da eibd auch routing aktiviert hast, könntest du da eine Schleife gebaut haben.
Schau dir mal die Routing-counter der 4 Telegramme an, sind die zufällig 6,4,2,0?

[umatz]

Wenn ich mich mit der IP-Schnittstelle über das Tunneling-Protokoll verbinde

knxd --listen-tcp --GroupCache --Discovery --Routing --Tunnelling --Server --layer2=ipt:192.168.178.10

gibt es keine Telegrammdopplung.

Ich muss mich korrigieren, auch wenn ich mich via tunneling mit der IP-Schnittstelle verbinde, gibt es Telegrammvermehrungen (genauer gesagt Vervierfachungen).
Nun habe ich die Optionen

--Server --Tunneling --Routing

beim knxd entfernt und mich wieder via "ip:" mit der IP-Schnittstelle verbunden. Mal schauen, wie es nun geht.