Autor Thema: Beta-Test neues KNX-IO Modul (Gelesen 8150 mal)

erwin · « **Antwort #15 am:** 06 November 2021, 08:48:43 »

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....

Code: [Auswählen]

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

thorte · « **Antwort #16 am:** 06 November 2021, 12:46:16 »

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:

Code: [Auswählen]

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 · « **Antwort #17 am:** 06 November 2021, 16:03:56 »

Zitat

KNXIO_TunnelRequestTO hit

das sind timeouts....

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

Code: [Auswählen]

 KNX_Set -enter: ...
KNX_Set: -exit

ist völlig normal...auf diesem loglvl.
erwin

thorte · « **Antwort #18 am:** 06 November 2021, 16:14:00 »

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 · « **Antwort #19 am:** 11 November 2021, 13:56:07 »

Grüße,

ich habe heute folgende Meldungen im Log

Code: [Auswählen]

KNXIO_decodeCEMI: no valid acpi-code (read/reply/write) received, discard packet
Es trat auf, während ich KNX-Komponenten programmiert habe, ETS.

erwin · « **Antwort #20 am:** 11 November 2021, 14:41:38 »

Hi GammaTwin,
Das ist gut so, ansonst hätte das KNX-Modul irgend ein GA / reading verändert!

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....

GammaTwin · « **Antwort #21 am:** 12 November 2021, 08:00:09 »

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 · « **Antwort #22 am:** 12 November 2021, 08:41:54 »

HI Gammatwin,
vergiss es vorerst, ich baue zusätzliche Log-Messages ein, dann wirds einfach... beim nächsten mal!
l.g. erwin

erwin · « **Antwort #23 am:** 30 November 2021, 10:04:27 »

Hi,
neue Version ist am GIT,
keine großen changes, erweiterte Log-Messages ( GammaTwin) und KNX-Error Messages in Langtext...
l.g. erwin

GammaTwin · « **Antwort #24 am:** 30 November 2021, 17:07:38 »

Code: [Auswählen]

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 · « **Antwort #25 am:** 01 Dezember 2021, 14:22:11 »

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

Amenophis86 · « **Antwort #26 am:** 05 Dezember 2021, 11:16:15 »

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.

erwin · « **Antwort #27 am:** 05 Dezember 2021, 14:07:35 »

Hi,

Zitat

Aber 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

Amenophis86 · « **Antwort #28 am:** 05 Dezember 2021, 21:50:36 »

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

Sollte ich dann lieber auf den T mode wechseln und die eigene IP (127.0.0.1) angeben, dass ich sicher bin?

erwin · « **Antwort #29 am:** 05 Dezember 2021, 23:11:03 »

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

:
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:

Zitat

Du 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 Forum

Neuigkeiten:

Autor Thema: Beta-Test neues KNX-IO Modul (Gelesen 8150 mal)

erwin

Antw:Beta-Test neues KNX-IO Modul

thorte

Antw:Beta-Test neues KNX-IO Modul

erwin

Antw:Beta-Test neues KNX-IO Modul

thorte

Antw:Beta-Test neues KNX-IO Modul

GammaTwin

Antw:Beta-Test neues KNX-IO Modul

erwin

Antw:Beta-Test neues KNX-IO Modul

GammaTwin

Antw:Beta-Test neues KNX-IO Modul

erwin

Antw:Beta-Test neues KNX-IO Modul

erwin

Antw:Beta-Test neues KNX-IO Modul

GammaTwin

Antw:Beta-Test neues KNX-IO Modul

erwin

Antw:Beta-Test neues KNX-IO Modul

Amenophis86

Antw:Beta-Test neues KNX-IO Modul

erwin

Antw:Beta-Test neues KNX-IO Modul

Amenophis86

Antw:Beta-Test neues KNX-IO Modul

erwin

Antw:Beta-Test neues KNX-IO Modul