knxtool groupwrite schaltet nichts

[Tru]

hier stören mich zwar das die knxd.service beim starten Fehler aufweisen aber am schluss ist das service ja gestartet... oder?

Nein, das sieht nicht gesund aus. knxd wird vom systemd immer wieder gestartet und bricht dann gleich wieder ab. Versuch zuerst mal knxd ohne systemd zum Laufen zu kriegen.
# systemctl disable knxd
# systemctl disable knxd.socket
# systemctl stop knxd
# systemctl stop knxd.socket
# knxd -e 1.0.0 -E 1.0.10:8 -f9 -D -T -R -S -i -t 1023 -b tpuarts:/dev/ttyKNX1

das -i benötigst du nur in diesem Fall, wo sich nicht systemd um den Socket kümmert.
testen solltest du deine GA mit:
# knxtool groupswrite ip:localhost 24/4/0 1

[stelar68480]

hi
Vielen Dank für die Schnelle Reaktion
# systemctl disable knxd
# systemctl disable knxd.socket
# systemctl stop knxd
# systemctl stop knxd.socket
# knxd -e 1.0.0 -E 1.0.10:8 -f9 -D -T -R -S -i -t 1023 -b tpuarts:/dev/ttyKNX1

Layer 0 [15:B.tpuarts/log 0.000] Insert 14:LowF / 13:tpuart
Layer 0 [15:B.tpuarts/log 0.000] Setup
Layer 0 [17:B.tpuarts/log 0.000] Insert 16:TPU_ser / 14:LowF
Layer 0 [15:B.tpuarts/log 0.000] Filter single not found
Layer 0 [17:B.tpuarts/log 0.000] Setup
Layer 0 [17:B.tpuarts/log 0.000] Setup OK: yes
Layer 0 [15:B.tpuarts/log 0.000] Setup OK: yes
Layer 3 [12:B.tpuarts/Conn 0.000] registerLink: 12:B.tpuarts
Layer 3 [12:B.tpuarts/Conn 0.000] Start: cfg:B.tpuarts
Layer 5 [12:B.tpuarts/Conn 0.000] down => >up
Layer 5 [12:B.tpuarts/Conn 0.001] Starting
Layer 0 [15:B.tpuarts/log 0.001] Start
Layer 0 [17:B.tpuarts/log 0.001] Start
Layer 0 [16:B.tpuarts/TPU_ser 0.001] Opened /dev/ttyKNX1 with baud 19200
Layer 2 [16:B.tpuarts/TPU_ser 0.001] Opened
Layer 2 [16:B.tpuarts/TPU_ser 0.001] Buffer Setup on fd 4
Layer 0 [17:B.tpuarts/log 0.001] Started
Layer 8 [14:B.tpuarts/LowF 0.001] state: new > start
Layer 0 [14:B.tpuarts/LowF 0.001] SendReset 01
Layer 0 [17:B.tpuarts/log 0.001] Send(001): 01
Layer 4 [12:B.tpuarts/Conn 0.002] >up
N00000127: [20:router.pace_] The 'pace' filter without a queue acts globally.
Layer 4 [12:B.tpuarts/Conn 0.003] is >up
Layer 0 [17:B.tpuarts/log 0.010] Recv(001): 03
Layer 8 [14:B.tpuarts/LowF 0.010] RESET_ACK
Layer 8 [14:B.tpuarts/LowF 0.010] state: in_reset > in_setaddr
Layer 8 [14:B.tpuarts/LowF 0.010] addr zero: in_reset > in_getstate
Layer 0 [14:B.tpuarts/LowF 0.010] Send GetState 02
Layer 0 [17:B.tpuarts/log 0.010] Send(001): 02
Layer 0 [17:B.tpuarts/log 0.013] Recv(001): 07
Layer 8 [14:B.tpuarts/LowF 0.013] State: 07
Layer 8 [14:B.tpuarts/LowF 0.013] state: in_getstate > is_online
Layer 0 [15:B.tpuarts/log 0.013] Started
Layer 5 [12:B.tpuarts/Conn 0.013] >up => up
Layer 4 [12:B.tpuarts/Conn 0.013] up
Layer 5 [12:B.tpuarts/Conn 0.013] Started
Layer 0 [15:B.tpuarts/log 0.013] send_Next
Layer 6 [12:B.tpuarts/Conn 0.013] sendNext called, send_more set
Layer 6 [12:B.tpuarts/Conn 0.013] is OK

danach aber
knxtool groupswrite ip:localhost 24/4/0 1
Open failed: Connection refused


Habe die Installation check nochmal geprüft:
https://github.com/knxd/knxd/wiki/Ad...RT-(Raspberry)

in raspi-config:
The serial login shell is disabled │
The serial interface is enabled


sudo udevadm info -a /dev/ttyAMA0 | grep KERNELS.*uart
ist leer.. wäre das schon ein problem?

sudo udevadm info -a /dev/ttyAMA0 | grep \{id\}
ATTRS{id}=="00241011"

[Tru]

danach aber
knxtool groupswrite ip:localhost 24/4/0 1
Open failed: Connection refused

Zur Anbindung mit TPUART kann ich nichts sagen, da habe ich keine Erfahrung.
Hast du den knxtool-Befehl in einer anderen Shell eingegeben? Oder den knxd zuerst wieder gestoppt - dann läuft er natürlich auch nicht mehr. Was gibt denn "sudo netstat -anutp |grep knxd" bei laufendem knxd zurück?

[stelar68480]

soo sieht nach neue Installation besser aus:

journalctl -u knxd
-- Logs begin at Fri 2019-10-11 11:16:35 BST, end at Fri 2019-10-11 11:17:08 BST
Oct 11 11:16:51 STELARKNXD systemd[1]: Starting KNX Daemon...
Oct 11 11:16:51 STELARKNXD systemd[1]: Started KNX Daemon.

Problem bleibt aber bestehend:
knxtool read ip:localhost 24/4/3
00
knxtool groupswrite ip:localhost 24/4/3 1
Send request
knxtool read ip:localhost 24/4/3
00

das ETS 5 sieht die Befehlen:
über Schalter HAGER WKT302R:
source 1.5.3 ; destination 24/4/3 ; GroupevalueWrite ; $01 activated
Licht HAGER STR210 geht an

über knxtool:
source 1.0.10 ; destination 24/4/3 ; GroupevalueWrite ; $01 activated
Licht HAGER STR210 bleibt aus

und
knxtool vbusmonitor1 ip:localhost
LPDU: BC 10 16 C4 03 E1 00 81 E2 :L_Data low from 1.0.22 to 24/4/3 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 01

[stelar68480]

Hallo zusammen

Nun habe ich weiter gegoogelt und es scheint als wäre das TR131B als medien copler der Spassverderber.

Ich versuche ja Opensource Lösungen einzusetzen (knxd, openhab), die über das Medien-coupler TR131B kommunizieren an RF Geräten befehle senden müssen.
Die Verbindungen und Programmierungen functionniert auf das TX100 (TJA665).

Ich kann auf das knxd und openhab bis zum TR131B einwandfrei kommunizieren.

https://community.openhab.org/t/knx-...-in-oh/65012/2
Dann scheint es mich zumindest langsam verständlich, wieso ein groupswrite befehl aus Openhab oder knxtool über ein TR131B auf RF Geräten gar nicht funktionieren kann.
Bei knx gäbe es eine apps - fill visualization dummy - um die GA zu verbinden:

For full system visualisation, telegrams shall be allowed to pass the line coupler. To this end, a dummy device is inserted in the ETS project. It contains all the Group Addresses required by the visualisation system. The ETS takes the Group Addresses from the dummy device into account when creating the filter tables.

Fill Visualizationdummy helps you to link a dummy device in the ETS with a list of Group Addresses for a visualization.
Product data for dummy devices can be obtained from several manufacturers.

The information about the group addresses can be read either from a file (different formats are supported), or the group addresses can be selected from the current ETS4 project by drag and drop.

Das komische an das ganze ist dass ich die GA's mit kndtool ja lesen kann, aber nicht schreiben...
Hat es jemanden schon getestet und kann es bestätigen? oder gibt es ein Workaround? ich verwende ETS4 und ETS5lite.

Vielen Dank und viele Grüsse

[pakka]

Hallo zusammen,

ich habe hier auch dieses Problem. Der ABB IP-Router IPR/S2.1 funktioniert in der ETS5 (getunnelt) problemlos, ich kann über den Gruppenmonitor meine Test-Lampe schalten und den Wert auslesen. Der Hauptlinien-Medientyp ist IP, der Linien-Medientyp ist TP.

knxd.conf hat folgende Einstellung: KNXD_OPTS="-e 1.1.2 -E 1.1.3:4 -c -u /tmp/eib -b ip:", im journalctl ist nur folgendes vermerkt:

Jan 05 15:47:29 smarthome systemd[1]: Starting KNX Daemon...
Jan 05 15:47:29 smarthome systemd[1]: Started KNX Daemon.
Daher denke ich läuft der Dienst korrekt. Dies sagt auch der status knxd.service:


● knxd.service - KNX Daemon
Loaded: loaded (/lib/systemd/system/knxd.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2020-01-05 15:47:29 CET; 21min ago
Main PID: 18943 (knxd)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/knxd.service
└─18943 /usr/bin/knxd -e 1.1.2 -E 1.1.3:4 -c -u /tmp/eib -b ip:

Jan 05 15:47:29 smarthome systemd[1]: Starting KNX Daemon...
Jan 05 15:47:29 smarthome systemd[1]: Started KNX Daemon.


Der knxd groupsocketlisten sieht, wenn ich über die ETS die Lampe schalte.
knxtool read ip:localhost 1/1/6 kann aber den Wert nicht auslesen. Hier wird einfach nichts angezeigt.
knxtool groupswrite ip:localhost 1/1/5 1 gibt die Meldung "send request", aber die Lampe wird nicht geschaltet.

Weder der read noch der groupswrite Befehl taucht aber in dem log von journalctl auf, ist das normal?

Gruß pakka

[pakka]

PS: die alternative Konfiguration vom knxd als Router KNXD_OPTS="-e 1.1.2 -E 1.1.3:4 -c -D -T -R -S" funktioniert nicht, vielleicht liefert das ja einen Hinweis?

Dabei wird folgendes geloggt:


Jan 05 14:39:56 smarthome systemd[1]: knxd.service: Ignoring invalid environment assignment 'KNXD_OPTS=-e 1.1.2 -E 1.1.3:8 -D -T -R -S
Jan 05 14:39:56 smarthome systemd[1]: # configuration for knxd.service using new configuration format in /etc/knxd.ini
Jan 05 14:39:56 smarthome systemd[1]: # use only this line if you used knxd_args to convert your old startup options
Jan 05 14:39:56 smarthome systemd[1]: # KNXD_OPTS=/etc/knxd.ini
Jan 05 14:39:56 smarthome systemd[1]: # The default options are -u /tmp/eib -b ip:"': /etc/knxd.conf

[Smurf]

"Ignoring invalid environment assignment" bedeutet dass du nicht tippen kannst und/oder ein Anführungszeichen vergessen oder falsch gesetzt hast (", nicht „ oder “ oder ”, wenn du das mit Libreoffice editiert hast passiert das schnell mal).

[pakka]

Stimmt, das Anführungszeichen war falsch.
Also auch mit DTRS Konfiguration das gleiche Problem. Bus-Lesen klappt, gezielte Gruppenadresse lesen oder schreiben nicht.
Was mich stutzig macht ist der Status, der trotz knxd.config mit DTRS hier "-b ip:" angibt. ich habe aber normal neu gestartet mit

sudo systemctl stop knx.socket
sudo systemctl stop knx.service
sudo systemctl start knxd.socket
sudo systemctl start knxd.service


● knxd.service - KNX Daemon
Loaded: loaded (/lib/systemd/system/knxd.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2020-01-05 15:47:29 CET; 56min ago
Main PID: 18943 (knxd)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/knxd.service
└─18943 /usr/bin/knxd -e 1.1.2 -E 1.1.3:4 -c -u /tmp/eib -b ip:

Jan 05 15:47:29 smarthome systemd[1]: Starting KNX Daemon...
Jan 05 15:47:29 smarthome systemd[1]: Started KNX Daemon.

[Smurf]

Äh, "systemctl daemon-reload".

Soltle aber bei dir keinen Unterschied machen. Ich würde mal die Konfig deines IP-Routers überprüfen, wenn der denkt dass 1.1.x die Adressen auf deinem KNX-Drahtbus sind dann könnte er Telegramme mit diesen Absendern, die von woanders herkommen, schlicht nicht weiterleiten.

[pakka]

Hm, macht anscheinend einen Unterschied. Jetzt hab ich mit DTRS gestartet. Aber eigentlich kein Unterschied, außer dass ich den knxd eben jetzt auch in der ETS als Tunnel nutzen kann. Aber dann eben keinen Wert mehr schreiben.

So ist der Router konfiguriert, da sollte doch erstmal alles durchgehen?

Unbenannt.PNG
Unbenannt.PNG

[pakka]

tja, das war´s dann doch. Habe nochmal die Applikation neu auf den Router geschrieben, jetzt geht´s!!!

Danke, Smurf!!

[pakka]

Nach ein paar Test stelle ich fest, dass nach einem Neustart des KNX IP-Routers zunächst das Schreiben auf den Bus funktioniert.
Nach ein paar Minuten/Befehlen steigt der knxd dann aber aus.

Im Busmonitor in der ETS sehe ich, dass mit jedem Befehl der Absender des Befehls (also die knxd phys. Adresse) um einen ansteigt.
Erreicht er das angegebene Ende -E 1.1.3:6 fängt er nicht wieder von vorn an bzw. denkt er vielleicht, diese wären noch belegt?!
Gibt es da eine Einstellmöglichkeit, um dies zu beheben?

[Smurf]

Nein. Dein Client hat einen Bug. Bring ihn dazu, nicht für jedes Paket eine neue Verbindung aufzumachen ohne die alte zu beenden.

[pakka]

Mein Client war in dem Fall knxtool.