Beta-Test neues KNX-IO Modul

Begonnen von erwin, 27 Oktober 2021, 10:26:06

Vorheriges Thema - Nächstes Thema

erwin

ok,
das mit der phy-addr im mode H kann ich erklären:
die definition ist nur ein "Vorschlag" von FHEM, bestimmt wird die verwendete phy-addr. (gilt nur für mode H) während des Verbindungsaufbaues durch das GW.
Bei mir mimmt er jeweils die nächste freie aus dem Pool der im GW definierten....

Im H mode kommt gefühlt nur ein Teil der Telegramme durch.
..dann sollten im Log diesbezüglich msg stehen : Timeout....
Das hängt mit dem kritischen timing zusammen! Wenn ein anderes Modul länger als 1 sek braucht....

das mit der falsche ip-addr. muss ich mir anschauen...
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,...

thorte


Nach den Schreiben von Texten auf die dpt16 kommt das -exit, Das Senden von "on" / "off" auf ein dpt1 führt offensichtlich zu einem Reconnet. Timeout finde ich im Log keine. FHEM läuft allerdings auch auf einen Ryzen3, der sich meistens im Leerlauf befindet ...

Das dblog mit Filter "KNX" als csv anbei (ich sollte wohl mein DOIF für die Statustexte nochmal anschauen, sendet sehr oft ...). Das fhem-log mit Filter "KNX" sieht so aus:

2021.11.06 12:03:19.563 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.06 12:03:21.067 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.06 12:03:21.068 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.06 12:04:36.197 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.06 12:04:37.700 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.06 12:04:37.702 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.06 12:06:19.579 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.06 12:06:21.082 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.06 12:06:21.084 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.06 12:07:30.804 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.06 12:07:31.285 4: KNXIO_Read: TunnelRequest received - send Ack and decode. seqcntrRx=8
2021.11.06 12:07:31.287 4: KNXIO_decodeCEMI: src=02107 - dst=044a0 - destaddrType=1  - prio=3 - hop_count=6 - leng=3 - data=800c0b
2021.11.06 12:07:31.287 4: KNXIO_processFIFO: C02107w044a00c0b Nr_msgs: 1
2021.11.06 12:07:32.307 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.06 12:07:32.309 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.06 12:09:19.589 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.06 12:09:21.092 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.06 12:09:21.093 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.06 12:11:19.631 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.06 12:11:20.390 4: KNXIO_Read: TunnelRequest received - send Ack and decode. seqcntrRx=21
2021.11.06 12:11:20.391 4: KNXIO_decodeCEMI: src=02103 - dst=0443c - destaddrType=1  - prio=3 - hop_count=6 - leng=3 - data=800672
2021.11.06 12:11:20.391 4: KNXIO_processFIFO: C02103w0443c0672 Nr_msgs: 1
2021.11.06 12:11:21.101 4: KNXIO_keepalive - expect ConnectionStateResponse
2021.11.06 12:11:21.133 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.06 12:11:21.135 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.06 12:13:19.687 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.06 12:13:21.142 4: KNXIO_keepalive - expect ConnectionStateResponse
2021.11.06 12:13:21.190 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.06 12:13:21.191 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.06 12:15:19.660 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.06 12:15:21.163 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.06 12:15:21.164 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.06 12:17:19.696 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.06 12:17:21.174 4: KNXIO_keepalive - expect ConnectionStateResponse
2021.11.06 12:17:21.199 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.06 12:17:21.200 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.06 12:19:19.737 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.06 12:19:21.208 4: KNXIO_keepalive - expect ConnectionStateResponse
2021.11.06 12:19:21.239 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.06 12:19:21.241 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.06 12:21:18.951 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.06 12:21:20.454 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.06 12:21:20.455 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.06 12:21:35.886 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.06 12:21:36.318 4: KNXIO_Read: TunnelRequest received - send Ack and decode. seqcntrRx=3
2021.11.06 12:21:36.320 4: KNXIO_decodeCEMI: src=02103 - dst=0443c - destaddrType=1  - prio=3 - hop_count=6 - leng=3 - data=80067c
2021.11.06 12:21:36.320 4: KNXIO_processFIFO: C02103w0443c067c Nr_msgs: 1
2021.11.06 12:21:37.390 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.06 12:21:37.391 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.06 12:23:19.737 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.06 12:23:20.306 4: KNXIO_Read: TunnelRequest received - send Ack and decode. seqcntrRx=12
2021.11.06 12:23:20.307 4: KNXIO_decodeCEMI: src=02103 - dst=0443c - destaddrType=1  - prio=3 - hop_count=6 - leng=3 - data=800686
2021.11.06 12:23:20.307 4: KNXIO_processFIFO: C02103w0443c0686 Nr_msgs: 1
2021.11.06 12:23:21.241 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.06 12:23:21.242 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.06 12:25:19.745 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.06 12:25:21.246 4: KNXIO_keepalive - expect ConnectionStateResponse
2021.11.06 12:25:21.248 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.06 12:25:21.249 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.06 12:25:42.763 2: KNX_Parse (wp): Visu.KiZ2.Info, READINGNAME: Statustext1, message C0ff12w041650000000000000000000000000000 could not be decoded
2021.11.06 12:26:19.753 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.06 12:26:21.253 4: KNXIO_keepalive - expect ConnectionStateResponse
2021.11.06 12:26:21.256 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.06 12:26:21.257 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.06 12:26:37.212 2: KNX_Parse (wp): Visu.KiZ2.Info, READINGNAME: Statustext1, message C0ff12w041650000000000000000000000000000 could not be decoded
2021.11.06 12:27:16.839 5: KNX_Set -enter: Visu.KiZ3.Info, Statustext1, >CLR<
2021.11.06 12:27:16.839 5: KNX_Set: set Visu.KiZ3.Info: desired target is gad: Statustext1, command: >CLR<, args:
2021.11.06 12:27:16.839 5: KNX_checkAndClean -enter: value= >CLR<, gadName= Statustext1
2021.11.06 12:27:16.839 5: KNX_checkAndClean -exit: value= >CLR<, gadName= Statustext1, model= dpt16.000, pattern= (?^ix:.{1,14})
2021.11.06 12:27:16.839 5: KNX_encodeByDpt -enter: Statustext1 model: dpt16.000, code: dpt16, value: >CLR<
2021.11.06 12:27:16.839 5: KNX_encodeByDpt -exit: Statustext1, model: dpt16.000, code: dpt16, value: >CLR<, hexval: 000000000000000000000000000000
2021.11.06 12:27:16.841 4: KNX_Set: Visu.KiZ3.Info, cmd= >CLR<, value= >CLR<, translated= 000000000000000000000000000000
2021.11.06 12:27:16.841 5: KNX_DbLog_split -enter: device= Visu.KiZ3.Info event= last-sender: fhem
2021.11.06 12:27:16.841 5: KNX_DbLog_split -exit: device= Visu.KiZ3.Info, reading= last-sender, value= fhem, unit=
2021.11.06 12:27:16.841 5: KNX_DbLog_split -enter: device= Visu.KiZ3.Info event= Statustext1: >CLR<
2021.11.06 12:27:16.841 5: KNX_DbLog_split -exit: device= Visu.KiZ3.Info, reading= Statustext1, value= >CLR<, unit=
2021.11.06 12:27:16.842 5: KNX_DbLog_split -enter: device= Visu.KiZ3.Info event= state: >CLR<
2021.11.06 12:27:16.842 5: KNX_DbLog_split -exit: device= Visu.KiZ3.Info, reading= state, value= >CLR<, unit=
2021.11.06 12:27:16.849 5: KNX_Set: -exit
2021.11.06 12:27:16.850 5: KNX_Set -enter: Visu.KiZ3.Info, Statustext2, 21.0, °C
2021.11.06 12:27:16.850 5: KNX_Set: set Visu.KiZ3.Info: desired target is gad: Statustext2, command: 21.0, args: °C
2021.11.06 12:27:16.850 5: KNX_checkAndClean -enter: value= 21.0 °C, gadName= Statustext2
2021.11.06 12:27:16.850 5: KNX_checkAndClean -exit: value= 21.0 °C, gadName= Statustext2, model= dpt16.000, pattern= (?^ix:.{1,14})
2021.11.06 12:27:16.850 5: KNX_encodeByDpt -enter: Statustext2 model: dpt16.000, code: dpt16, value: 21.0 °C
2021.11.06 12:27:16.850 5: KNX_encodeByDpt -exit: Statustext2, model: dpt16.000, code: dpt16, value: 21.0 °C, hexval: 0032312e3020b04300000000000000
2021.11.06 12:27:16.851 4: KNX_Set: Visu.KiZ3.Info, cmd= 21.0, value= 21.0 °C, translated= 0032312e3020b04300000000000000
2021.11.06 12:27:16.852 5: KNX_DbLog_split -enter: device= Visu.KiZ3.Info event= last-sender: fhem
2021.11.06 12:27:16.852 5: KNX_DbLog_split -exit: device= Visu.KiZ3.Info, reading= last-sender, value= fhem, unit=
2021.11.06 12:27:16.852 5: KNX_DbLog_split -enter: device= Visu.KiZ3.Info event= Statustext2: 21.0 °C
2021.11.06 12:27:16.852 5: KNX_DbLog_split -exit: device= Visu.KiZ3.Info, reading= Statustext2, value= 21.0, unit= °C
2021.11.06 12:27:16.852 5: KNX_DbLog_split -enter: device= Visu.KiZ3.Info event= state: 21.0 °C
2021.11.06 12:27:16.852 5: KNX_DbLog_split -exit: device= Visu.KiZ3.Info, reading= state, value= 21.0, unit= °C
2021.11.06 12:27:16.860 5: KNX_Set: -exit


Gruß Thorsten

erwin

ZitatKNXIO_TunnelRequestTO hit
das sind timeouts....  ;D

dein device Visu.KiZ3.Info ist offensichtlich auf loglevel 5, - die Llogmessages sind ok, zeigen keinen Fehler...
KNX_Set -enter: ...
KNX_Set: -exit

ist völlig normal...auf diesem loglvl.
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,...

thorte

#18
Danke für die Analyse. Dann ich da mal bei Gelegenheit auf Suche ....

Aber immerhin soweit das Feedback - im Socket Mode läuft es wunderbar !

GammaTwin

Grüße,

ich habe heute folgende Meldungen im Log
KNXIO_decodeCEMI: no valid acpi-code (read/reply/write) received, discard packet

Es trat auf, während ich KNX-Komponenten programmiert habe, ETS.

erwin

#20
Hi GammaTwin,
Das ist gut so, ansonst hätte das KNX-Modul irgend ein GA / reading verändert!  ;D
Ich nehme nicht an, dass du die raw-daten von der message hast, falls doch bitte posten, damit ich mir das anschauen kann, ob man es "früher" wegschmeissen kann.
Es muss sich um eine "zufällige byte-Kombination" handeln, die nicht schon im header-check verworfen wird.
l.g. erwin

edit: ich baue eine zusätzlich Log-msg ein, damit man (im Fehlerfall) das packet im Log hat....
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,...

GammaTwin

Puh, ob diese Raw-Message finde?

Es waren zwischen 14 - 20 Logeinträge pro Programmierung. Die Programmierung eines Linienkopplers und einer Wetterstation müsste ich mehrfach machen. Das sind ja hunderte ETS-Nachrichten...

erwin

HI Gammatwin,
vergiss es vorerst, ich baue zusätzliche Log-Messages ein, dann wirds einfach... beim nächsten mal!
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,...

erwin

Hi,
neue Version ist am GIT,
keine großen changes, erweiterte Log-Messages ( GammaTwin) und KNX-Error Messages in Langtext...
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,...

GammaTwin

 :)

2021.11.30 17:06:02.956 3: KNXIO_decodeCEMI: no valid acpi-code (read/reply/write) received, discard packet
2021.11.30 17:06:02.956 3: discarded packet: src=00001 - dst=01200 - destaddrType=0  - prio=0 - hop_count=6 - leng=5 - data=d500011001
2021.11.30 17:06:03.026 3: KNXIO_decodeCEMI: no valid acpi-code (read/reply/write) received, discard packet
2021.11.30 17:06:03.026 3: discarded packet: src=01200 - dst=00001 - destaddrType=0  - prio=0 - hop_count=5 - leng=7 - data=d6000110010000


Programmierung Linienkoppler

erwin

Hi GammaTwin,

ja die Logik passt, das sind "programmier" - msgs,
beim KNXTUL und TUL-Modul gab's an dieser Stelle keinen Log....
ich muss mir überlegen, was sinnvoll ist: mehr Log's (auf Lvl3) oder auf Lvl4 verschieben...
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,...

Amenophis86

#26
Ich wollte heute auch mal einen Test starten aber scheitere am einrichten. Ich habe das Modul über update hinzugefügt und entsprechend definiert. Das alte Device habe ich gelöscht. Aber wie erkennt FHEM nun, dass es ein neues IO Device setzen muss?

EDIT:
Ah, der Name muss wohl gleich sein. Jetzt klappt es.

Werde jetzt mal den S Mode testen.

Edit2:
Folgendes ist mir aufgefallen. Ich nutze den S-Mode, habe auf einem PI KNXD laufen und auf dem PI zwei FHEM Instanzen. Nun definiere ich KNXIO auf FHEM1 und es verbindet sich. Definiere ich KNXIO auf FHEM2, wird FHEM1 disconnected. Mit defmod bei FHEM1 kann ich die Verbindung wieder herstellen und beide sind verbunden. Startet allerdings eine der FHEM Instanzen neu und verbindet sich damit mit KNXD neu, wird die Verbindung de anderen unterbrochen und muss mittels defmod neu hergestellt werden. Lässt sich soweit reproduzieren.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

erwin

Hi,
ZitatAber wie erkennt FHEM nun, dass es ein neues IO Device setzen muss?
Das ist eine Logik in fhem.pl, die wurde irgendwann heuer geändert...
Grundsätzlich (bei fhem-start):
1) Wenn im KNX-device ein Attr IODev gesetzt ist, nimmt er das - Das ist wohl bei dir der Fall ... "Name muss wohl gleich sein"
2) Wenn im device kein Attr  IODev gesetzt ist, sucht er sich ein passendes..(TUL/KNXTUL/KNXIO). Nachdem die Empfehlung ist für KNX immer nur ein IO-Device definiert zu haben....
Noch nicht klar ist, welches IO-Dev er nimmt, falls es mehr als ein "passendes" gibt, meine Vermutung ist: das in der config als letztes definierte...
Wobei: das IODevice beeinflusst nur das senden FHEM->KNX, empfangen wird über alle IO-Dev's! Das gilt für alle 2-stufigen Module, ausser der Modul-Maintainer verhindert das explizit.

S-Mode: im prinzip will fhem auf einen file im dateisystem schreiben (z.b.: /var/run/knxd), Schreiben darf eigentlich nur immer 1 Task auf einen File - ich bin mir nicht sicher, wie das sich verhält!
Evtl. kannst du testen, ob du von beiden FHEM's auf die selbe GA senden/empfangen kannst, oder ob es da Fehler gibt...
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,...

Amenophis86

Zitat von: erwin am 05 Dezember 2021, 14:07:35
S-Mode: im prinzip will fhem auf einen file im dateisystem schreiben (z.b.: /var/run/knxd), Schreiben darf eigentlich nur immer 1 Task auf einen File - ich bin mir nicht sicher, wie das sich verhält!
Evtl. kannst du testen, ob du von beiden FHEM's auf die selbe GA senden/empfangen kannst, oder ob es da Fehler gibt...

Du meinst ich soll testen, ob trotz disconncetd alles geht?

Habe mir das vorhin nochmal angeschaut. Wenn FHEM1 definiert und verbunden ist und dann FHEM2 startet und sich verbindet, verliert FHEM1 die Verbindung. Mit defmod auf FHEM1 stellt er die Verbindung wieder her und alle beide zeigen Verbunden an. Ist FHEM2 verbunden und FHEM1 startet, dann verbindet sich FHEM1 zusätzlich und FHEM2 bleibt die Verbindung verstehen. So ganz checke ich es noch nicht :D Sollte ich dann lieber auf den T mode wechseln und die eigene IP (127.0.0.1) angeben, dass ich sicher bin?
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

erwin

So ganz check ich das nicht, eigentlich sollte kein Unterschied zw. defmod und fhem-start sein, und schon gar nicht sollten sich 2 fhem's auf einem system unterschiedlich benehmen...
Nachdem ja du einer meiner "aktivesten" beta tester bist  ;D :
1) Mode T auf beiden fhem's sollte auf jeden fall funktionieren (wenn der knxd 2 Tunnel zulässt...) !! unterschiedliche phy-addressen angeben!!!
2) interessant wär auch, wie sich mode M (auf beiden FHEMs) verhält....
3) "gemischt" geht natürlich auch
l.g.erwin

PS: der mode-S macht beim starten/defmod ein close-IO/open-IO, evtl "nervt" das die andere FHEM instanz... Die Frage ist, ob ein disconnect  nach 60 Sekunden autom. recoverd wird ?

PSS:
ZitatDu meinst ich soll testen, ob trotz disconncetd alles geht?
Nein, macht nur Sinn, wenn beide auf connected sind!

Das sollte alles keine KNX-msg loop erzeugen, ausser du hast die beiden FHEMs (die KNX-devices) auch noch irgemdwie anders verbunden... (FHEM2FHEM....)
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,...