KNX-Anbindung über TPUART-Modul von Busware: fhem.pl hängt sich auf

Begonnen von jw9, 17 Januar 2021, 11:21:34

Vorheriges Thema - Nächstes Thema

jw9

Hallo allerseits,

ich versuche, eine KNX-Anbindung nach dieser Anleitung zu verwirklichen.

Das Flaschen des Moduls funktioniert, und beim nächsten Start erscheint es auch brav unter /dev/ttyACM0

Als nächstes trage ich das Gerät ein und definiere einen KNX-Datenpunkt:

define KNXIF TUL tul:/dev/ttyACM0 1.1.249
attr KNXIF room KNX
define Roll_EZ KNX 3/1/14:dpt1.008:Roll_EZ KNXIF
attr Roll_EZ webCmd on:off
attr Roll_EZ room KNX


Das wird mir im Logfile soweit auch bestätigt:

2021.01.17 11:11:24 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed (peer: 192.168.1.101)
2021.01.17 11:13:12 3: TUL opening KNXIF device tul:/dev/ttyACM0
2021.01.17 11:13:12 3: TUL setting KNXIF baudrate to 19200
2021.01.17 11:13:12 3: TUL device opened


Allerdings sehe ich keine KNX-Telegramme wenn ich den zugehörigen Taster drücke.

Wenn ich versuche, einen Wert an KNX zu senden:

set Roll_EZ on
[/quote]

dann  hängt sich fehm.pl auf. Fhem.pl geht auf 100% CPU und ist nicht mehr ansprechbar. Nur noch "kill -KILL <fhem-pid>" hilft. Kein Eintrag im Logfile.

Wer hat eine Idee was da schiefläuft?

erwin

Hi,
schau dir mal diesen Beitrag an: https://forum.fhem.de/index.php/topic,111225.0.html
ohne knxd gabs in der Vergangenheit immer wieder Probleme...die dringende empfehlung ist: TUL-Modul ->knxd ->USB-Schnittstelle
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

jw9

Hallo nochmal,

Ich halte den Umweg über knxd für sub-opimal.

Konnte das Problem jetzt beheben. Das Problem liegt nicht am Busware-Adapter, sondern am 00_TUL.pm. Da hat offensichtlich jemand das Datenblatt vom TPUART nicht gelesen.

Habe das Problem jetzt behoben, zumindest oberflächlich. Für eine saubere Lösung müssten da noch grössere Umbauten vorgenommen werden.

Das Modul hat allerdings auch noch weitere Probleme: es mach Busy-IO. Auch das erfordert erhebliche Umbauten.

Wenn ich richtig verstehe, gibt es derzeit keinen Maintainer für das KNX Subsystem? Wie gehe ich nun vor, um das gefixte Modul in die offizielle Release zu bekommen, wenn ich mit den fixes denn mal fertig wäre?

erwin

Hi,

wie schon gesagt, der TPUART ist tricky, und da alle error-recovery und sonstige specs nachzu-programmieren ist vmtl. sehr mühsam.
Der knxd hat den Vorteil, dass er das erledigt, und vermutlich in 100ten Installationen- es gibt ja nicht nur FHEM als GUI/Kontroll-system....
und der support ist gut! Auch zum debuggen gibts ein vernüftiges Tool! (knxtool).
Das TUL Modul funtioniert gut , wenn man die IP-option verwendet! Ich denke du bist ziemlich alleine mit deiner Variante, was ich in diesem Forum mitbekommen habe, sind fast alle user auf knxd oder KNX-router umgestiegen.
Ein anderer Weg wär der Einsatz eines KNX-Routers (z:b:Weinzirl-xxx), und dann mit dem KNXTUL-Modul (mit multicast) die Verbindung zu fhem herstellen.
In diesem Fall brauchst du auck keinen knxd!
Ein paar kleinere Probleme (Abstürze...) gibts mit dem KNXTUL, aber da werd ich demnächst einen patch liefern können.
Der Charme vom knxd liegt auch darin, dass er nicht auf demselben system wie fhem laufen muss! (Wartung / system uprgade / redundanz-optionen, usw...)
Offtopic:
Hauswart & ich haben uns jetzt mal das KNX-Modul vorgenommen - das auf einen aktuellen Stand zu bringen - wie wir's verteilen, findest du im von dir verlinkten thread..., und dann gibts natürlich noch den offiziellen Weg, wenn du die ownership für's TUL-modul übernimmst!
l.g.erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

jw9

Zitat von: erwin am 22 Januar 2021, 19:06:50
Der knxd hat den Vorteil, dass er das erledigt, und vermutlich in 100ten Installationen- es gibt ja nicht nur FHEM als GUI/Kontroll-system....

und der support ist gut! Auch zum debuggen gibts ein vernüftiges Tool! (knxtool).
Der hat aber auch den Nachteil, dass die Doku recht sportanisch ist. Viel mehr als den Artikel von Mathias drüben im knx-user-forum ist da nicht. Weder für knxd noch für knxtool gibt es eine Manpage. Auch "knxd --help" ist nicht wirklich hilfreich. Und die Ausgabe von "knxtool help" ist geradezu ein Witz...

Ich behaupte jetzt mal: wer knxd installiert, der tut das zu 99% nach dem Wiki-Artikel ohne im Detail zu wissen wozu die Optionen gut sind.

ZitatIch denke du bist ziemlich alleine mit deiner Variante, was ich in diesem Forum mitbekommen habe, sind fast alle user auf knxd oder KNX-router umgestiegen.
Das ist ja auch kein Wunder. Da das direkte Ansprechen des USB-Adapters dazu führt, dass sich der ganze fhem-Prozess aufhängt, gibt man auf und packt den knxd dazwischen.

ZitatEin anderer Weg wär der Einsatz eines KNX-Routers (z:b:Weinzirl-xxx), und dann mit dem KNXTUL-Modul (mit multicast) die Verbindung zu fhem herstellen.
In diesem Fall brauchst du auck keinen knxd!
Dann ist aber die Kommunikation unverschlüsselt auf dem LAN/WLAN. Da habe ich heftige Bauchschmerzen...

Zitat
Ein paar kleinere Probleme (Abstürze...) gibts mit dem KNXTUL, aber da werd ich demnächst einen patch liefern können.
Mit hoher Wahrscheinlichkeit hat KNXTUL diese Abstürze von TUL geerbt. Soweit ich sehe, ist KNXTUL als Kopie von TUL entstanden, was an sich schon sehr unglücklich ist: Die Module sind später dann deutlich auseinandergedriftet.

ZitatDer Charme vom knxd liegt auch darin, dass er nicht auf demselben system wie fhem laufen muss!
Damit hat man wieder unverschlüsselte Kommunikation auf dem LAN, denn weder knxd noch TUL/KNXTUL beherrschen (derzeit) KNX IP Secure.

Das Gute beim direkten Ansprechen des USB-Sticks ist, dass die Kommunikation direkt auf den Bus geht. Somit kann auch niemand über LAN/WLAN meinen Türöffner betätigen. Dazu müsste der Angreifer erst noch eine weitere Hürde nehmen und den fhem-Rechner knacken.

Zitat
Offtopic:
Hauswart & ich haben uns jetzt mal das KNX-Modul vorgenommen - das auf einen aktuellen Stand zu bringen - wie wir's verteilen, findest du im von dir verlinkten thread...,
Ja, das habe ich gesehen. Und ich muss sagen: ich versteh's nicht. Wieso pflegt ihr die Patches nicht in das offizielle System ein? Zumindest bei den Patches die keine Kompatibilitäts-Brüche einbringen sollte das doch machbar sein.

Und was ist mit dem (alten?) EIB-Modul? Sollte das nicht mal entsorgt werden? Toter Code ist böse!

Zitat
und dann gibts natürlich noch den offiziellen Weg, wenn du die ownership für's TUL-modul übernimmst!
Heisst das, dass es derzeit keinen Owner for TUL/KNXTUL gibt?

Nun, ich habe sowieso vor dieses Modul massiv zu überarbeiten.

Ich finde aber, dass da insgesamt einiges aufgeräumt werden sollte: TUL und KNXTUL haben viel duplizierten Code, der auseinandergedriftet ist: Ein Albtraum für jeden Entwickler! Meiner Meinung nach gehört das wieder sauber zusammengeführt.