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

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 717
Antw:Beta-Test neues KNX-IO Modul
« 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....

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 mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline thorte

  • New Member
  • *
  • Beiträge: 38
Antw:Beta-Test neues KNX-IO Modul
« 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:
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

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 717
Antw:Beta-Test neues KNX-IO Modul
« Antwort #17 am: 06 November 2021, 16:03:56 »
Zitat
KNXIO_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 mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline thorte

  • New Member
  • *
  • Beiträge: 38
Antw:Beta-Test neues KNX-IO Modul
« 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 !
« Letzte Änderung: 06 November 2021, 16:15:46 von thorte »

Offline GammaTwin

  • Full Member
  • ***
  • Beiträge: 152
Antw:Beta-Test neues KNX-IO Modul
« Antwort #19 am: 11 November 2021, 13:56:07 »
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.

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 717
Antw:Beta-Test neues KNX-IO Modul
« 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!  ;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....
« Letzte Änderung: 11 November 2021, 18:11:55 von erwin »
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline GammaTwin

  • Full Member
  • ***
  • Beiträge: 152
Antw:Beta-Test neues KNX-IO Modul
« 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...

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 717
Antw:Beta-Test neues KNX-IO Modul
« 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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 717
Antw:Beta-Test neues KNX-IO Modul
« 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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline GammaTwin

  • Full Member
  • ***
  • Beiträge: 152
Antw:Beta-Test neues KNX-IO Modul
« Antwort #24 am: 30 November 2021, 17:07:38 »
 :)

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

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 717
Antw:Beta-Test neues KNX-IO Modul
« 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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2950
  • Anti-Statement befreite Zone ;)
Antw:Beta-Test neues KNX-IO Modul
« 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.
« Letzte Änderung: 05 Dezember 2021, 11:25:47 von Amenophis86 »
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...

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 717
Antw:Beta-Test neues KNX-IO Modul
« 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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2950
  • Anti-Statement befreite Zone ;)
Antw:Beta-Test neues KNX-IO Modul
« Antwort #28 am: 05 Dezember 2021, 21:50:36 »
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...

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 717
Antw:Beta-Test neues KNX-IO Modul
« 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  ;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:
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 aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

 

decade-submarginal