eibd(war bcusdk) Fork -> knxd

[Jache]

Hallo,

darf ich mal fragen was der Unterschied zwischen busmonitor1, busmonitor2, busmonitor3, vbusmonitor1, vbusmonitor2, vbusmonitor3 bei den knxtools ist?

und muss ich die knxtools immer mit "knxtools groupswrite XXX" aufrufen? oder kann ich irgendwie einstellen, etc, dass ich nicht knxtools davor schreiben muss?

[MrMirror]

Kann mir jemand helfen?

Ich nutze den knxd für die homebridge - Verbindung zum KNX-Bus über einen IP-Gateway. Es funktioniert soweit auch alles perfekt, sowohl Lese- als auch Schreibzugriffe auf einzelne GAs klappen einwandfrei. Lediglich bei "mehrfach"-Telegrammen, wie sie Bpsw. die homebridge auslöst, wenn alle Lichter ausgeschaltet werden sollen, klappen nicht...

Im Log sieht das ganze so aus:

[KNX] knx data sent: Value 0 for GA 7/1/20
[KNX] knx data sent: Value 0 for GA 8/1/10
[KNX] knx data sent: Value 0 for GA 7/1/40
[KNX] knx data sent: Value 0 for GA 7/1/30

Auf dem Bus kommt aber lediglich das Telegramm für die GA 7/1/20 an, diese wird auch geschaltet, der Rest reagiert nicht, da hier erst gar keine Telegramme ankommen. Kann es sein, dass der Dienst die Telegramme zu schnell sendet, so dass der Bus diese nicht mitbekommt??

danke und Gruß,
Christoph

[henfri]

Hallo,

wenn ich mich mit der ETS mit dem KNXD verbinde, sagt der Busmonitor stets "ungültiger Frame".
Wie kann ich das Problem debuggen? Ich starte den KNXD mit
knxd -e=0.0.2 -D -T -R -S -i --no-tunnel-client-queuing --GroupCache -b ipt:192.168.177.24

Hinter der ip-adresse findet sich eine ip-Schnittstelle (eibmarkt).

Gruß,
Hendrik

[Tru]

Allerdings ist auch eine Zeile vorher ein readConfig() auskommentiert, die entsprechende Funktion sollte "/etc/wiregate/eibga.conf" auslesen.

Die Zeile vorher ruft readParseCGI() auf, liest die vielleicht die Parameter ein? Anyway, ich würde auf Master setzen und knxd mit -u /tmp/eib aufrufen.

[Elektrofitzfatz]

Hallo Tru,

danke für die Antwort, die Stelle habe ich auch gefunden. Allerdings ist auch eine Zeile vorher ein readConfig() auskommentiert, die entsprechende Funktion sollte "/etc/wiregate/eibga.conf" auslesen.
Ich habe mir damit geholfen, im Quelltext die Socketadresse /run/knx einzutragen. Dann hat sich die Meldung von "Open failed" immerhin in ein timeout gewandelt. Wie geschrieben, die v0.9 lief auf Anhieb.
Danke für den Hinweis auf die Exklusivität der *cgi für CometVisu. Im Moment scheint auch erst mal alles mit der v0.9 zu laufen.

[Tru]

Ich habe es zuerst mit branch master versucht, hier stellte ich zuerst fest, dass der socket für die Kommunikation mit dem knxd in eibread-cgi und eibwrite-cgi auf /tmp/eib steht, aber der knxd bereits nach /run/knx "umgezogen" ist.

Im Kommentar des Source Code von eibread-cgi und eibwrite-cgi lese ich dass local:/tmp/eib genommen wird, wenn nichts angegeben ist. Und im Code der cgi selber steht

if (*eiburl == NULL) *eiburl = "local:/tmp/eib";

Das bedeutet doch, dass du den Pfad angeben können solltest. Somit müsste es mit Master schon funktionieren. Mit Sicherheit kannst du den Pfad bei knxd angeben wie du willst. Leider kann ich nicht weiter helfen, weil ich Cometvisu nicht nutze. Meines Wissens sind die beiden cgi ein Addon von Makki explizit für Cometvisu.

[Elektrofitzfatz]

Hallo,

seit ein paar Tagen versuchte ich, die Kombination knxd und CometVisu auf meinem CentOS-System zum Laufen zu bringen. Leider scheiterte ich immmer an der Stelle eibread-cgi und eibwrite-cgi. Erst nachdem ich einen Beitrag hier im Forum (KNX EIB Forum) von jemanden fand, der es ebenfalls erst nicht zum Laufen brachte, habe ich das Ganze mit der v0.9 des knxd probiert, was dann auch gelang. Im Ergebnis kann ich nun erst mal die von meiner MDT Wetterstation gemessene Temperatur per CometVisu anzeigen.

Ich habe es zuerst mit branch master versucht, hier stellte ich zuerst fest, dass der socket für die Kommunikation mit dem knxd in eibread-cgi und eibwrite-cgi auf /tmp/eib steht, aber der knxd bereits nach /run/knx "umgezogen" ist. Trotz Anpassung der Quellen hat eibread-cgi dann doch nicht funktioniert.
Der Versuch mit branch conn-sep war ebenfalls erfolglos, da sich der knxd nicht mit der Option -c starten läßt ("Aborted").

Nachdem ich sowohl hier im Forum als auch bei Git viel gelesen habe, finde ich Bestätigungen für die Probleme, aber leider keine Lösung.

Wer nutzt eigentlich die eibread-cgi und eibwrite-cgi scripte außer den Cometvisu-Nutzern?

Kann ich etwas dazu beitragen, dass neuere Versionen auch für Selbstkompilierer lauffähig werden?

[o5i]

Es scheint als ob ein Telegramm empfangen wurde aber nicht verarbeitet wurde???

Layer 8(0174D1E0,56BDAFE4) New Connection
Layer 8(01790F48,56BDAFE4) ClientConnection Init
Layer 8(01790F48,56BDAFE4) RecvMessage(005): 00 22 01 0A 00
Layer 7(017A140C,56BDAFE4) OpenGroup
Layer 4(0175E180,56BDAFE4) OpenGroup 0/1/10 RW
Layer 3(0173CC60,56BDAFE4) registerLayer2 0175E180
Layer 3(0173CC60,56BDAFE4) registerLayer2 0175E180 = 1
Layer 7(017A140C,56BDAFE4) OpenGroup complete
Layer 8(01790F48,56BDAFE4) SendMessage(002): 00 22
Layer 8(01790F48,56BDAFE4) RecvMessage(004): 00 25 00 00
Layer 7(017A140C,56BDAFE4) Send(002): 00 00
Layer 4(0175E180,56BDAFE4) Send Group T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(0173CC60,56BDAFE4) Enqueue L_Data low from 0.0.0 to 0/1/10 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(0173CC60,56BDAFE4) RecvData L_Data low from 0.0.0 to 0/1/10 hops: 06 T_DATA_XXX_REQ A_GroupValue_Read
Layer 2(01780A28,56BDAFE4) Send L_Data low from 1.1.254 to 0/1/10 hops: 06 T_DATA_XXX_REQ A_GroupValue_Read
Layer 1(01780A28,56BDAFE4) Send L_Data low from 1.1.254 to 0/1/10 hops: 06 T_DATA_XXX_REQ A_GroupValue_Read
Layer 0(0175EBE0,56BDAFE4) Send-EMI(009): 11 0C 00 00 01 0A E1 00 00
Layer 1(0175D6F0,56BDAFE4) Send(064): 01 13 11 00 08 00 09 01 01 00 00 11 0C 00 00 01 0A E1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(0175D6F0,56BDAFE4) Send(064): 01 13 11 00 08 00 09 01 01 00 00 11 0C 00 00 01 0A E1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(0175D6F0,56BDAFE4) StartSend
Layer 0(0175D6F0,56BDAFE4) SendComplete 64
Layer 0(0175D6F0,56BDAFE4) RecvComplete 64
Layer 0(0175D6F0,56BDAFE4) RecvUSB(064): 01 13 11 00 08 00 09 01 01 00 00 4E BC FF FF 01 0A E1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(0175D6F0,56BDAFE4) StartRecv
Layer 1(0175D6F0,56BDAFE4) Recv(064): 01 13 11 00 08 00 09 01 01 00 00 4E BC FF FF 01 0A E1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(0175EBE0,56BDAFE4) RecvEMI(009): 4E BC FF FF 01 0A E1 00 00
Layer 7(017A140C,56BDAFEE) CloseGroup
Layer 4(0175E180,56BDAFEE) CloseGroup
Layer 3(0173CC60,56BDAFEE) deregisterLayer2 0175E180 = 1
Layer 8(01790F48,56BDAFEE) ClientConnection closed

[knux]

Sooo...Danke Smurf für deine Tipps. Letztendlich habe ich den Fehler nicht gefunden, auch habe ich das laufende knxd nicht gefunden. Da ich aber vorgestern nach dem das Ganze das erste Mal funktioniert hatte ein Image gezogen habe, habe ich es neu aufgespielt und seit dem geht es. Vielleicht hatte sich ein Bit verlaufen ...

[o5i]

Hallo

Hab jetzt nochmal alles installiert aber immer das selbe ergebnis.
Dank stoppen vom systemd socket kann ich knxd endlich auch unter jessy starten...

 sudo -u knxd /usr/bin/knxd -d -i -b usb:/dev/KNXUSB

udev rules

SUBSYSTEM=="usb", ATTR{idVendor}=="135e", ATTR{idProduct}=="0024", ACTION=="add", GROUP="knxd", MODE="0664", SYMLINK+="ttyKNX", OWNER="knxd"

ps axww | grep knx
 1112 ?        Ss     0:00 /usr/bin/knxd -d -i -b usb:/dev/KNXUSB

lsof -p $(pidof knxd)
knxd    1112 knxd  txt       REG  179,2   300124  4467 /usr/bin/knxd

 knxtool busmonitor1 ip:localhost
LPDU: BC 11 A0 20 0E E1 00 80 BD :L_Data low from 1.1.160 to 4/0/14 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
LPDU: CC :ACK
LPDU: BC 11 70 20 0F E1 00 80 6C :L_Data low from 1.1.112 to 4/0/15 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
LPDU: CC :ACK
LPDU: BC 11 12 16 05 E1 00 80 32 :L_Data low from 1.1.18 to 2/6/5 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
LPDU: CC :ACK
LPDU: BC 11 03 20 0B E1 00 80 1B :L_Data low from 1.1.3 to 4/0/11 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
LPDU: CC :ACK

funktioniert

knxtool groupswrite ip:localhost 0/0/5 1

funktioniert

knxtool groupreadresponse ip:localhost 0/1/22
Send request
Ending groupreadresponse.

Funktioniert nicht

Wiso?

*DEBUG MODE ON*

Wenn ich

knxtool groupreadresponse ip:localhost 0/1/10
Send request
Ending groupreadresponse.

mache passiert das:

Layer 8(0174D1E0,56BDAFE4) New Connection
Layer 8(01790F48,56BDAFE4) ClientConnection Init
Layer 8(01790F48,56BDAFE4) RecvMessage(005): 00 22 01 0A 00
Layer 7(017A140C,56BDAFE4) OpenGroup
Layer 4(0175E180,56BDAFE4) OpenGroup 0/1/10 RW
Layer 3(0173CC60,56BDAFE4) registerLayer2 0175E180
Layer 3(0173CC60,56BDAFE4) registerLayer2 0175E180 = 1
Layer 7(017A140C,56BDAFE4) OpenGroup complete
Layer 8(01790F48,56BDAFE4) SendMessage(002): 00 22
Layer 8(01790F48,56BDAFE4) RecvMessage(004): 00 25 00 00
Layer 7(017A140C,56BDAFE4) Send(002): 00 00
Layer 4(0175E180,56BDAFE4) Send Group T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(0173CC60,56BDAFE4) Enqueue L_Data low from 0.0.0 to 0/1/10 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(0173CC60,56BDAFE4) RecvData L_Data low from 0.0.0 to 0/1/10 hops: 06 T_DATA_XXX_REQ A_GroupValue_Read
Layer 2(01780A28,56BDAFE4) Send L_Data low from 1.1.254 to 0/1/10 hops: 06 T_DATA_XXX_REQ A_GroupValue_Read
Layer 1(01780A28,56BDAFE4) Send L_Data low from 1.1.254 to 0/1/10 hops: 06 T_DATA_XXX_REQ A_GroupValue_Read
Layer 0(0175EBE0,56BDAFE4) Send-EMI(009): 11 0C 00 00 01 0A E1 00 00
Layer 1(0175D6F0,56BDAFE4) Send(064): 01 13 11 00 08 00 09 01 01 00 00 11 0C 00 00 01 0A E1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(0175D6F0,56BDAFE4) Send(064): 01 13 11 00 08 00 09 01 01 00 00 11 0C 00 00 01 0A E1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(0175D6F0,56BDAFE4) StartSend
Layer 0(0175D6F0,56BDAFE4) SendComplete 64
Layer 0(0175D6F0,56BDAFE4) RecvComplete 64
Layer 0(0175D6F0,56BDAFE4) RecvUSB(064): 01 13 11 00 08 00 09 01 01 00 00 4E BC FF FF 01 0A E1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(0175D6F0,56BDAFE4) StartRecv
Layer 1(0175D6F0,56BDAFE4) Recv(064): 01 13 11 00 08 00 09 01 01 00 00 4E BC FF FF 01 0A E1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0(0175EBE0,56BDAFE4) RecvEMI(009): 4E BC FF FF 01 0A E1 00 00
Layer 7(017A140C,56BDAFEE) CloseGroup
Layer 4(0175E180,56BDAFEE) CloseGroup
Layer 3(0173CC60,56BDAFEE) deregisterLayer2 0175E180 = 1
Layer 8(01790F48,56BDAFEE) ClientConnection closed

später kommt auch noch das Zeugs dazu:

Layer 0(0175D6F0,56BDB002) RecvError 2
W00000033: RecvError 2
Layer 0(0175D6F0,56BDB002) StartRecv
Layer 0(0175D6F0,56BDB020) RecvError 2
W00000033: RecvError 2
Layer 0(0175D6F0,56BDB020) StartRecv
Layer 0(0175D6F0,56BDB03E) RecvError 2
W00000033: RecvError 2
Layer 0(0175D6F0,56BDB03E) StartRecv
Layer 0(0175D6F0,56BDB05C) RecvError 2
W00000033: RecvError 2

[Smurf]

Äh, sorry aber wenn da "address already in use" steht, dann ist da ein Prozess, der den entsprechenden Socket offen hat.
Notfalls bemühe "lsof|grep knx" (oder, für IP, 6720, oder für den alten Socket /tmp/eib).

[knux]

Oh sorry. Mein Fehler!
Ich habe jetzt alles durchsucht, per "Hand" die Prozessliste durch gesucht und versucht einfach knxd zu stoppen, er findet einen solchen Prozess nicht.

[Smurf]

Bitte stelle nicht-knxd-spezifische Unix-Grundwissen-Fragen a la "wie bringe ich einen Prozess um" nicht hier.

[knux]

okay. knxtool mit groupswrite, was gestern funktionierte, tut's nicht mehr. Naja, ich hab knxd aus dem Autostart per

update-rc.d -f -n knxd remove

rausgeworfen und neu gestartet. openHAB ist auch schon draußen. Leider keine Besserung. Beim Startversuch kommt "Address already in use".
Wie kann ich die laufende Version umbringen?

[Smurf]

Unter Wheezy gibt's natürlich weder systemctl noch systemd. In dem Fall läuft dein knxd tatsächlich schon, eine andere Erklärung gibt es nicht. Bring die laufende Version einfach um.