Beta-Test neues KNX-IO Modul

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

Vorheriges Thema - Nächstes Thema

erwin

Das Modul ist ab 26.5.2022 im SVN verfügbar, bitte die GIT-Version nicht mehr verwenden!


Hi,
ich hab ein neues KNXIO Modul gebastelt, dass mittelfristig das TUL und KNXTUL Modul ablösen soll und zusätzlich noch weitere Optionen bietet, wie KNX in FHEM integriert werden kann.
Ich bin auf der Suche nach eingen mutigen  ;D Beta Testern.[/s)
Folgenden connectivity optionen gibts:

  • H Host Mode - connect to a KNX-router with UDP point-point protocol.
      This is the mode also used by ETS when you specify KNXNET/IP as protocol. You do not need a KNXD installation. The protocol is complex and timing critical!
      If you have delays in FHEM processing close to 1 sec, the protocol may disconnect. It should recover automatically,
      however KNX-messages could have been lost!
  • M Multicast mode - connect to KNXD's or KNX-router's multicast-tree.
      This is the mode also used by ETS when you specify KNXNET/IP Routing as protocol.
      If you have a KNX-router that supports multicast, you do not need a KNXD installation. Default address:port is 224.0.23.12:3671
      Pls. ensure that you have only one GW/KNXD in your LAN that feed the multicast tree!
      This mode requires the IO::Socket::Multicast perl-module to be installed on yr. system.
      On Debian systems this can be achieved by <code>apt-get install libio-socket-multicast-perl</code>.
  • T TCP Mode - uses a TCP-connection to KNXD (default port: 6720).
      This mode is the successor of the TUL-modul, but does not support direct Serial/USB connection to a TPUart-USB Stick.
      If you want to use a TPUart-USB Stick or any other serial KNX-GW, use either the TUL Module, or connect the USB-Stick to KNXD and in turn use modes M,S or T to connect to KNXD.
  • S Socket mode - communicate via KNXD's UNIX-socket on localhost. default Socket-path: /var/run/knx
      Path might be different, depending on knxd-version or -config specification! This mode is tested ok with KNXD version 0.14.30. It does NOT work with ver. 0.10.0!
Modul-src (fhem cmd-line):
update add https://raw.githubusercontent.com/erw111n/FHEM-KNX/main/controls_KNXIO.txt

Hinweise:
fhem config sichern!
nach der definition die bisherigen io-module (TUL / KNXTUL) löschen, da diese keine (funktionierende) disable Möglichkeit haben!
restart fhem

Mode H: ist komplex und timing kritisch! (< 1sec). Indikatonen dass fhem zu langsam reagiert / etwas länger als 1 sekunde braucht sind Log-mesages:

TunnelRequest received: duplicate message received ...
TunnelRequest received: out of sequence ....
KNXIO_TunnelRequestTO hit - ...


evtl. hilft der cmd: "apptime average function" herauszufinden, welches modul zu langsam ist....Verdächtig sind bei mir z.b.: OneWire und SVG.
Mode S: funktioniert mit knxd version 0.14.30 - mit version 0.10.0 bei mir nicht! Wenn ihr testet, dann bitte um feedback der knxd version.
Mode M: kann ich nur gegen knxd testen, interessant wäre ein test mit einem KNX-Router der Multicast spricht! dazu natürlich den knxd beenden!
definitions syntax ist in der cmd-ref.

Ein Wechsel der modes sollte im laufenden Vetrieb möglich sein! Das Modul verwendet DevIO (wo immer möglich), mit einigen patches für devio wärs noch schöner, aber das ist der übernächste Schritt!
Offizielles release wird noch dauern, es fehlen noch einige Error- recovery routinen, speziell für mode H und vor allem euer Feedback!  ;D

Happy testing und Danke!

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

baerm

Hallo Erwin,
vielen Dank für diese Weiterentwicklung. Ich finde es super, dass sich bei FHEM immer noch die Module weiterentwickeln - auch wenn ich das Gefühl habe, es passiert um einiges weniger als noch vor 3-4 Jahren.
Ich verwende KNXD in Version 0.14.35 und würde mich evtl mit einer Testinstanz darüber wagen. Das Echtsystem ist mir zu wichtig und will ich derzeit nicht angreifen.
Was mir nicht ganz klar ist, was der Vorteil der neuen Version sein wird. Geht es hier nur um die Wartbarkeit bzw Modulpflege, oder soll sich aus "Usersicht" etwas wesentliches verbessern? Neue Features? Performance? Aktuell funktioniert ja mein Setup so sehr gut und die KNX Schnittstelle läuft und läuft und läuft  ;D
lg,
Matthias

erwin

Hi,
völlig richtig, einerseits gehts um die Wartbarkeit, aber wichtiger war (für mich), (fast) alle Möglichkeiten mit einem KNX system zu kommunizieren in einem Modul zu haben.
Bisher: TUL-Modul -> entspricht mode T , KNXTUL -> entspricht mode M
Und einiges an Performance und sollte auch besser werden...

Der Socket-mode könnte für jene interessant sein, die den knxd auf dem selben host wie FHEM betreiben - Kommunikation NICHT übers Netzwerk, sondern über (virtuelles) File-IO.
Der mode H ist was für Menschen, die den knxd nicht mögen...  ;D

Performance Vergleiche zwischen den modes habe ich dzt. keine.
Der code ist kein Merge der beiden bestehenden Module, sondern fast völlig neu geschrieben... deßwegen auch die Suche nach den "mutigen" Beta-Testern!
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

Hey erwin, finde es auch super aber da ich seit 1.10 ne neue Stelle habe, kann ich aktuell leider nicht testen, da fehlt mir einfach die Zeit. Finde es aber gut, wenn alles in ein Modul überführt wird :)
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...

GammaTwin

Hallo erwin,

ich habe es mal "mutig" in mein System geworfen, Setting M.

Nach den ersten 2 Minuten kann ich sagen, es läuft :)

erwin

Hi GammaTwin,
super!, lass es noch ein paar Tage laufen, und gib mir dann Bescheid...
mode M: testest du mit/gegen knxd ? wenn ja, dann bitte die knxd version posten - wenn nein: welcher router?

l.g. & danke 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

Grüße,

3 Tage ohne einen Logeintrag.
Ich teste Mode M ohne knxd. Ich nutze einen Enertex Router.

thorte

Frisch installiert, läuft!

kein knxd, Hager TYF120, Mode H

M habe ich auf die schnelle nicht zum Laufen gebracht - werde ich ggf. nochmal testen, wenn ich etwas Zeit finde. Log beobachte ich mal die nächsten Tage.

Gruß Thorsten

erwin

HI Thorsten,
danke für's testen, wenn ich die Produktspecs vom dem TYF120 richtig gelesen habe, kann der KEIN Multicast (mode M),
damit bleibt nur der mode: H als option!
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

#9
Hallo Erwin,

zu der Erkenntnis bin ich inzwischen auch gelangt  ;D

Dieses Gerät:

4/2/107:dpt1.001:schalten_set:nosuffix
4/3/107:dpt1.001:schalten_get:nosuffix
4/2/108:dpt3:do_dim:nosuffix
4/2/109:dpt5.001:dimmwert_set:nosuffix
4/3/109:dpt5.001:dimmwert_get:nosuffix
4/2/110:dpt3:do_hsv:nosuffix
4/3/110:dpt5.003:hsv_get:nosuffix
4/2/111:dpt3:do_sat:nosuffix
4/3/111:dpt5.001:sat_get:nosuffix

ist ein MDT-Glastaster Smart 2 (mit Display), den ich zur Ansteuerung einer RGB-Lampe nutze. Scheinbar bekommt er fortlaufend ein get. Mein Log sieht so aus:

2021-11-04_00:00:08 L.KiZ2.LED_Bett_KNX last-sender: fhem
2021-11-04_00:00:08 L.KiZ2.LED_Bett_KNX schalten_get: off
2021-11-04_00:00:08 L.KiZ2.LED_Bett_KNX off
2021-11-04_00:00:08 L.KiZ2.LED_Bett_KNX schalten: off
2021-11-04_00:00:08 L.KiZ2.LED_Bett_KNX last-sender: fhem
2021-11-04_00:00:08 L.KiZ2.LED_Bett_KNX dimmwert_get: 2 %
2021-11-04_00:00:08 L.KiZ2.LED_Bett_KNX 2 %
2021-11-04_00:00:08 L.KiZ2.LED_Bett_KNX dimmwert: 2
2021-11-04_00:00:08 L.KiZ2.LED_Bett_KNX last-sender: fhem
2021-11-04_00:00:08 L.KiZ2.LED_Bett_KNX hsv_get: 0 °
2021-11-04_00:00:08 L.KiZ2.LED_Bett_KNX 0 °
2021-11-04_00:00:08 L.KiZ2.LED_Bett_KNX last-sender: fhem
2021-11-04_00:00:08 L.KiZ2.LED_Bett_KNX sat_get: 1 %
2021-11-04_00:00:08 L.KiZ2.LED_Bett_KNX 1 %
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX last-sender: fhem
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX schalten_get: off
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX off
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX schalten: off
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX last-sender: fhem
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX dimmwert_get: 2 %
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX 2 %
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX dimmwert: 2
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX last-sender: fhem
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX hsv_get: 0 °
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX 0 °
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX last-sender: fhem
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX sat_get: 1 %
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX 1 %
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX last-sender: 15.15.206
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX schalten_get: off
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX off
2021-11-04_00:01:08 L.KiZ2.LED_Bett_KNX schalten: off
2021-11-04_00:02:08 L.KiZ2.LED_Bett_KNX last-sender: fhem
2021-11-04_00:02:08 L.KiZ2.LED_Bett_KNX schalten_get: off
2021-11-04_00:02:08 L.KiZ2.LED_Bett_KNX off
2021-11-04_00:02:08 L.KiZ2.LED_Bett_KNX schalten: off
2021-11-04_00:02:08 L.KiZ2.LED_Bett_KNX last-sender: fhem
2021-11-04_00:02:08 L.KiZ2.LED_Bett_KNX dimmwert_get: 2 %
2021-11-04_00:02:08 L.KiZ2.LED_Bett_KNX 2 %
2021-11-04_00:02:08 L.KiZ2.LED_Bett_KNX dimmwert: 2
2021-11-04_00:02:08 L.KiZ2.LED_Bett_KNX last-sender: fhem
2021-11-04_00:02:08 L.KiZ2.LED_Bett_KNX hsv_get: 0 °
2021-11-04_00:02:08 L.KiZ2.LED_Bett_KNX 0 °
2021-11-04_00:02:08 L.KiZ2.LED_Bett_KNX last-sender: fhem
2021-11-04_00:02:08 L.KiZ2.LED_Bett_KNX sat_get: 1 %
2021-11-04_00:02:08 L.KiZ2.LED_Bett_KNX 1 %
2021-11-04_00:03:08 L.KiZ2.LED_Bett_KNX last-sender: fhem
2021-11-04_00:03:08 L.KiZ2.LED_Bett_KNX schalten_get: off


In der alten Konfiguration mit knxd / knx lief es. Kann es sein, dass das KNXIO ein beständiges get sendet? Kann vielleicht heute Abend mit der ETS mal am Bus lauschen, dann kann ich Dir eventuell noch etwas mehr Details liefern. Die beiden weiteren Glastaster sind unauffällig, haben aber auch nur dpt1 und dpt3 GADs.

Update: Scheint eine Rückkopplung mit einem DOIF zu sein, dass die Brücke zwischen den KNX-Glastaster und einem ZigBee-RGB-Kontroller herstellt. Warum die jetzt auftritt, kann ich noch nicht nachvollziehen. Eventuell werden andere Events in dem KNX-Gerät getriggert als vorher.

Gruß Thorsten

GammaTwin

Grüße,

ich habe ein anderes Setting noch am laufen. MDT IP-Inerface. knxd 0.14.30.

fhem und knxd laufen jeweils in einem Container. T funktioniert, S logischerweise nicht.
Ich lasse T laufen.


thorte

Hallo Erwin,

hab vielleicht doch noch einen Fehler gefunden.

Ein "define H KNX-Gateway:3671 15.15.255" bei einem in Werkzustand zurückgesetzten Hager TYF120 führt zu einem Restart des FHEM.

Log:

2021.11.04 19:30:25.145 4: KNXIO_Read: TunnelRequest received - send Ack and decode. seqcntrRx=4
2021.11.04 19:30:25.146 4: KNXIO_decodeCEMI: src=02103 - dst=0443c - destaddrType=1  - prio=3 - hop_count=6 - leng=3 - data=80067c
2021.11.04 19:30:25.147 4: KNXIO_processFIFO: C02103w0443c067c Nr_msgs: 1
2021.11.04 19:30:29.897 4: KNXIO_Write: Mode=H buf=061004200023044d06001100bce0000021650f00800000000000000000000000000000 rc=0
2021.11.04 19:30:29.908 4: KNXIO_Write: Mode=H buf=061004200023044d06001100bce0000021660f008031392e3820b04300000000000000 rc=0
2021.11.04 19:30:31.398 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.11.04 19:30:32.902 4: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.11.04 19:30:32.903 4: KNXIO_Read: DisconnectResponse received - sending connrequ
2021.11.04 19:30:34.863 3: KNXIO_define: DNS query result= 192.168.102.10
2021.11.04 19:30:34.884 3: KNXIO_define: opening device KNX mode=H
2021.11.04 19:30:35.085 3: KNXIO_openDev: device KNX opened
'x' outside of string in unpack at ./FHEM/00_KNXIO.pm line 420.


Gruß Thorsten

baerm

Hi,
habe heute auf KNX-IO umgestellt. Verwende KNXD in Version 0.14.18 und damit KNX mode=T
Habe bis jetzt kein Problem damit.
lg,
Matthias

erwin

#13
@ Thorsten,

danke, Fehler gefunden!
Problem ist: wenn das GW einen Error-code zurückschickt (z.b. weil nicht konfiguriert...), dann ist die msg kürzer als ich erwarte.
Hoffentlich gefixt... Muss noch ein wenig testen, stelle im Lauf des Vormittags eine neues Version aufs GIT.

Nur um zu verstehen, was passiert ist:
1) um 19:30:25 ist noch alles ok, da wird eine msg ganz normal verarbeitet
2) um 19:30:31 geht was schief!
3) um 19:30:32 kommt ein disconnect-response, fhem schickt als Antwort einen connect-request - das wäre ok!
4) um 19:30:34 machst du offensichtlich ein define....
... und das GW antwortet mit einem Fehlercode - und den kann das Modul nicht verarbeiten... (hoffentlich gefixed!)

Die Frage: nach dem FHEM restart - funktioniert die Verbindung?
Ich bin nicht sicher, ob das GW im unkonfiguriertem Zustand die Verbindung akzeptiert, lt. standard sollte eine phy.adresse 15.15.255 NICHT verwendet werden, weil das die Indication für unkonfiguriert ist! Mit der neuen Version sollte ein Fehlercode im Log zu sehen sein.
Falls es funktioniert, bitte um ein list device (mit der bisherigen oder neuen Version).
PS: das sind die Dinge, die man nicht vorab testen kann......
l.g. erwin

Update: neue Version ist am GIT
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

Hallo Erwin,

hab mal geupdatet und nochmal etwas getestet. Der Fehler trat auf, nachdem ich das Gateway zurückgesetzt hatte, das Gateway also nur die eine Werkadresse 15.15.255 angeboten hat. Mit der Freigabe einer zusätzlichen Adresse war der Fehler dann weg, allerdings zeigt die PhyAddr ein für mich nicht ganz nachvollziehbares Verhalten.

Aktuell bin ich aufgrund von Connetivitätsproblemen im H mode auf den S mode mit knxd 0.14.46 umgestiegen. Läuft problemlos. Im H mode kommt gefühlt nur ein Teil der Telegramme durch.

Mit den PhyAddr kann ich folgendes Verhalten reproduzieren:
  define KNX S /var/run/knx 15.15.250 -> Internal PhyAddr 15.15.250

Internals:
   DEF        S /var/run/knx 15.15.250
   DeviceName UNIX:STREAM:/var/run/knx
   FD         25
   FUUID      6182e3bf-f33f-4189-b19b-28c72b5e77404a86
   NAME       KNX
   NR         415
   PARTIAL   
   PhyAddr    15.15.250
   STATE      connected
   TYPE       KNXIO
   model      S
   nextOpenDelay 60
   Helper:
     DBLOG:
       state:
         dblog:
           TIME       1636145936.57099
           VALUE      CONNECTED
   READINGS:
     2021-11-05 21:58:56   state           connected
Attributes:
   comment    S /var/run/knx 15.15.250
H 192.168.102.10:3671 15.15.250
   group      Gateway
   room       Syst


  define KNX H 192.168.102.10:3671 15.15.250 -> PhyAddr 15.15.19

Internals:
   DEF        H 192.168.102.10:3671 15.15.250
   DeviceName 192.168.102.10:3671
   FD         24
   FUUID      6182e3bf-f33f-4189-b19b-28c72b5e77404a86
   KNX_MSGCNT 6
   KNX_TIME   2021-11-05 22:02:08
   NAME       KNX
   NR         415
   PARTIAL   
   PhyAddr    15.15.19
   STATE      connected
   TYPE       KNXIO
   model      H
   nextOpenDelay 60
   Helper:
     DBLOG:
       state:
         dblog:
           TIME       1636146102.81078
           VALUE      connected
   READINGS:
     2021-11-05 22:01:42   state           connected
Attributes:
   comment    S /var/run/knx 15.15.250
H 192.168.102.10:3671 15.15.250
   group      Gateway
   room       System->FHEM
   verbose    3


  define KNX H 192.168.102.10:3671 15.15. -> PhyAddr 15.15.20

Internals:
   DEF        H 192.168.102.10:3671 15.15.19
   DeviceName 192.168.102.10:3671
   FD         24
   FUUID      6182e3bf-f33f-4189-b19b-28c72b5e77404a86
   KNX_MSGCNT 9
   KNX_TIME   2021-11-05 22:03:21
   NAME       KNX
   NR         415
   PARTIAL   
   PhyAddr    15.15.20
   STATE      connected
   TYPE       KNXIO
   model      H
   nextOpenDelay 60
   Helper:
     DBLOG:
       state:
         dblog:
           TIME       1636146160.84998
           VALUE      connected
   READINGS:
     2021-11-05 22:02:40   state           connected
Attributes:
   comment    S /var/run/knx 15.15.250
H 192.168.102.10:3671 15.15.250
   group      Gateway
   room       System->FHEM
   verbose    3


Das Spiel mit "define" und die PhyAddr im Internal ist dann um 1 höher kann ich beliebig treiben.

Interessanterweise liefert das Device auch ein "connected", wenn ich irgend eine IP-Adresse angebe:

Internals:
   DEF        H 199.100.75.20:3671 15.15.250
   DeviceName 199.100.75.20:3671
   FD         24
   FUUID      6182e3bf-f33f-4189-b19b-28c72b5e77404a86
   NAME       KNX
   NR         415
   PARTIAL   
   PhyAddr    15.15.250
   STATE      connected
   TYPE       KNXIO
   model      H
   nextOpenDelay 60
   Helper:
     DBLOG:
       state:
         dblog:
           TIME       1636146320.15244
           VALUE      connected
   READINGS:
     2021-11-05 22:05:20   state           connected
Attributes:
   comment    S /var/run/knx 15.15.250
H 192.168.102.10:3671 15.15.250
   group      Gateway
   room       System->FHEM
   verbose    4


Hilft Dir das weiter?

Gruß Thorsten

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

Amenophis86

Mode M werde ich nicht testen können, da ich nur ein IP Interface und kein IP Router habe. Mode T kann ich die Tage mal testen. Aktuell laufen beide mit Mode S und sind auch beide verbunden (mit gleicher physikalischer Adresse). Solange kein FHEM neustartet dürfte das auch erstmal kein Problem sein ;)
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

OK,
versuch mal unterschiedliche phy.addressen, bzw. schau vorher mal im list device unter .FIFOMSG das sollte sowas wie:
C051fb...... stehen, bedeutet phy-addr: 5.1.251 bei mir.
Sind die bei dir auf beiden fhem instanzen gleich?
Ich frage deßhalb, weil es ja durchaus möglich ist, das das KNX-GW eine Session wegschmeisst, wenn eine neue mit gleicher phy.addr daherkommt....
...aber nur Vermutung....
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

Ähm, in welchem device soll das Internal FIFOMSG stehen? In den KNXIO Device finde ich nix:

Internals:
   DEF        S /var/run/knx 1.0.241
   DeviceName UNIX:STREAM:/var/run/knx
   FD         29
   FUUID      61ac9037-f33f-92c6-4652-0a3be0cf8616c265
   KNX_MSGCNT 91624
   KNX_TIME   2021-12-06 22:19:55
   NAME       KNX
   NEXT_OPEN  1638757534.02
   NR         901
   PARTIAL   
   PhyAddr    1.0.241
   STATE      CONNECTED
   TYPE       KNXIO
   model      S
   nextOpenDelay 60
   READINGS:
     2021-12-06 03:24:34   state           CONNECTED
Attributes:
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

Ähm... ja sorry,
es braucht :
attr global showInternalValues 1
um internals die mit . (PUNKT) beginnen anzuzeigen.
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

FHEM1: .FIFOMSG C01101w0820102bc
FHEM2: .FIFOMSG C01102w0710d2dbc

KNXD hat bei mir 1.0.241 und 1.0.242 als phys Adressen hinterlegt.
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

Danke, das passt!
Was mir allerdings noch eingefallen ist:
Wieso kannst du nicht mode-M ? Du testest ja via FHEM<->knxd-daemon<->KNX-GW - oder läuft der knxd in einem Docker?
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

Ich dachte M wäre komplett ohne knxd und nur über Multicast? Aber ich seh, dass du im 1. Beitrag schreibst, dass Knxd auch Multicast raus haut? Dann könnte M auch gehen.

Edit l: nein, nutze Docker nicht
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

Du kannst ganz leicht checken, ob der knxd Multicast macht:
pi@xxx21:/ $ netstat -g
IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      224.0.0.251
lo              1      all-systems.mcast.net
eth0            1      224.0.23.12
....

die zahl unter RefCnt bei 224.0.23.12 ist die Anzahl der "Teilnehmer" am MC. - knxd ( option -S) ist einer davon...
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,...

baerm

#38
Hallo Erwin,
ich habe ja vor einiger Zeit auf das neue Modul umgestellt und inzwischen schon zweimal einen Ausfall gehabt.

2021.12.11 21:52:37 1: 127.0.0.1:6720 disconnected, waiting to reappear (KNX)
2021.12.11 21:52:37 1: KNXIO_Read: no data - disconnect
2021.12.11 21:52:37 1: KNXIO_disconnect: device KNX disconnected, waiting to reappear

und dann funktioniert die Verbindung zwischen KNXIO und KNXD nicht mehr. Erst wenn ich FHEM restarte, funktioniert alles wieder. Es war bei beiden malen das selbe Verhalten.  :(

Restart heute Nacht:
2021.12.12 04:28:47 3: KNXIO_define: DNS query result= 127.0.0.1
2021.12.12 04:28:47 3: KNXIO_define: opening device KNX mode=T
...
2021.12.12 04:28:58 3: KNX device opened


Scheinbar hat aber dann knxd restartet um kurz nach Mitternacht. Es hat aber wahrscheinlich keinen Zusammenhang.
root@raspberrypi4:/home/pi# ps -ef | grep knx
knxd      2385     1  0 Dec11 ?        00:00:16 /usr/bin/knxd -e 1.1.255 -E 0.0.2:8 -u /tmp/eib -b ipt:10.2.2.80

Irgend eine Idee wo hier ein Fehler liegt?

knxd 0.14.35:fc9ba78

Internals:
   DEF        T localhost:6720 1.1.5
   DeviceName 127.0.0.1:6720
   FD         330
   FUUID      61844c38-f33f-e2c0-a9da-f2f5c21d227ad239
   KNX_MSGCNT 27067
   KNX_TIME   2021-12-12 10:17:07
   NAME       KNX
   NR         960
   PARTIAL   
   PhyAddr    1.1.5
   STATE      connected
   TYPE       KNXIO
   model      T
   nextOpenDelay 60
   READINGS:
     2021-12-12 04:28:58   state           connected


lg,
Matthias

erwin

Hi Matthias,
ZitatScheinbar hat aber dann knxd restartet um kurz nach Mitternacht. Es hat aber wahrscheinlich keinen Zusammenhang.
00:00:16 ist sicher nicht die Uhrzeit, sondern die verbrauchten cpu-sekunden seit dem knxd start. Ich gehe mal davon aus, das er am 2021.12.11 21:52:...  abgestürzt ist!
Schau mal bitte hier:
journalctl -uknxd -f warum der knxd abstürzt/neu startet....
Bei mir läuft der seit:
Nov 30 11:46:12 MH-RPI-21 systemd[1]: Started KNX Daemon. ohne eine weitere msg im journal. (das war mein letzter linux-reboot)
ach ja: der letzte Parameter der KNXIO-def sollte in der Range vom -E parameter vom knxd sein, also bei dir: 0.0.2
ach ja2: 1.1.255 ist auch nicht gut, in der knxd def, nimm -e 0.0.1 !
ach ja3: -u /tmp/eib kannst du weglassen!
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

Hey erwin, kannst du im ersten Post mal Beispiele für die Definitionen dazu schreiben? Mir erschließt es sich nicht immer aus dem Text, wie sie zu definieren wären. Danke.
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...

baerm

Hallo Erwin,
das hast Du recht. Und ich hatte vergeblich nach einem Logfile von KNXD gesucht....

root@raspberrypi4:/home/pi# journalctl -uknxd -f
-- Logs begin at Thu 2021-12-02 18:07:16 CET. --
Dec 02 18:07:34 raspberrypi4 systemd[1]: Starting KNX Daemon...
Dec 02 18:07:34 raspberrypi4 systemd[1]: Started KNX Daemon.
Dec 11 21:52:37 raspberrypi4 knxd[634]: F00000105: [16:B.ipt] Link down, terminating
Dec 11 21:52:37 raspberrypi4 systemd[1]: knxd.service: Main process exited, code=exited, status=1/FAILURE
Dec 11 21:52:37 raspberrypi4 systemd[1]: knxd.service: Failed with result 'exit-code'.
Dec 11 21:52:48 raspberrypi4 systemd[1]: knxd.service: Service RestartSec=10s expired, scheduling restart.
Dec 11 21:52:48 raspberrypi4 systemd[1]: knxd.service: Scheduled restart job, restart counter is at 1.
Dec 11 21:52:48 raspberrypi4 systemd[1]: Stopped KNX Daemon.
Dec 11 21:52:48 raspberrypi4 systemd[1]: Starting KNX Daemon...
Dec 11 21:52:48 raspberrypi4 systemd[1]: Started KNX Daemon.


Ich habe nur das "Link down" im messages file gesehen, aber ohne brauchbaren Timestamp....
Inwischen ist mir klar, dass der Auslöser das SW Update meines Routers war. Das war eigentlich bis jetzt nie ein Problem. Eventuell ist das ein Problem dieser KNXD Version.
Danke für die Hinweise zu den Parametern. Nachdem es bis jetzt funktioniert hat, habe ich nicht mehr viel herumgeschraubt. Parameter werde ich aber  entsprechend anpassen.

Warum connected das KNXIO Modul nicht neu, wenn der KNXD wieder gestartet wurde? Das wäre hilfreich, damit mir so ein Ausfall nicht mehr passiert. Oder gibt es die Möglichkeit mittels DOIF den State zu überprüfen und dann ein Reconnect oder Ähnliches auszulösen?
lg,
Matthias



erwin

Hi Matthias,
ZitatWarum connected das KNXIO Modul nicht neu, ...
das sollte es tun, nach spätestens 60 Sekunden....
Falls das nochmal auftritt: Bitte auf Loglevel 5 gehen, im KNXIO-Modul, 1 Minute warten und schauen was im Log passiert.
Ich kanns mom. nicht nachstellen - Nach einem  knxd stop/ start connected mein KNXIO-Device sofort wieder! 
Wenn das nicht funktioniert, ein defmod auf's KNXIO device machen- Ergebnis?

PS: dein knxd verliert die Verbindung zum Router:
Dec 11 21:52:37 raspberrypi4 knxd[634]: F00000105: [16:B.ipt] Link down, terminating
deswegen crashed er! Ob das am knxd oder am Router liegt, kann ich nicht sagen. evtl. mal google fragen - mit dem Router Typ als Argument?
Falls das ein Router ist, der auch Multicast kann, kannst du versuchen Mode M zu verwenden und den knxd abschalten...

@Amenophis86:
Ich bin dabei, einen Wiki Eintrag für das modul zu basteln, meinst du KNXIO def Beispiele oder knxd-Beispiele  ? Beides gibts in der cmdref
Meine infoquelle für knxd ist:
https://github.com/knxd/knxd/wiki
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

Ich meine KNXIO, das gibt es doch bisher nur hier im Thread und damit noch nicht in der commandref, oder? Also was ich konkret meine sind Beispiele für Mode T, S und so weiter wie da die DEF lauten muss. Du hast es zwar beschrieben aber ganz schlau draus wurde ich nicht, dass mir ein konkretes Beispiel helfen würde.
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,
cmd-ref gibts schon, allerdings nur local - wenn du das modul geladen hast,
oder unter device-detail-view: "Device specific help" link.

Wenn da was fehlt, bitte um FB.
Mehr details wird's dann im wiki geben....
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

Ach, schau an. Danke für den Hinweis. Hatte ich echt nicht gesehen. Top.
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...

baerm

Hi Erwin,
also ich habe den MDT SCN-IP000.02 der als Interface und nicht als Router arbeitet. Daher funktioniert Mode M nicht.
Zitat von: erwin am 13 Dezember 2021, 07:50:07
Falls das ein Router ist, der auch Multicast kann, kannst du versuchen Mode M zu verwenden und den knxd abschalten...

Ich habe aber das Verhalten nachgestellt und das KNX Service gestoppt und wieder gestartet. Nach der Theorie sollte die Verbindung aber automatisch aufgebaut werden. Das passiert aber leider nicht. Ich bin mir sicher, dass es vor Umstellung auf KNXIO aber immer funktioniert hat.

KNXD Status mit Timestamps:
Dec 14 21:03:33 raspberrypi4 systemd[1]: Stopping KNX Daemon...
Dec 14 21:03:33 raspberrypi4 systemd[1]: knxd.service: Succeeded.
Dec 14 21:03:33 raspberrypi4 systemd[1]: Stopped KNX Daemon.
Dec 14 21:03:59 raspberrypi4 systemd[1]: Starting KNX Daemon...
Dec 14 21:03:59 raspberrypi4 systemd[1]: Started KNX Daemon.


FHEM Logs:

2021.12.14 21:01:40 3: KNXIO_define: DNS query result= 127.0.0.1
2021.12.14 21:01:40 3: KNXIO_define: opening device KNX mode=T
2021.12.14 21:01:41 3: Opening KNX device 127.0.0.1:6720
2021.12.14 21:01:41 3: KNX device opened
2021.12.14 21:03:15 5: KNXIO_Read: buf= 000a002711640c1c00800000
2021.12.14 21:03:15 5: KNXIO_Read Rawbuf: 000a002711640c1c00800000
2021.12.14 21:03:15 4: KNXIO_decodeEMI: src=01164 - dst=0141c - leng=3 - data=800000
2021.12.14 21:03:15 5: KNXIO_decodeEMI: C01164w0141c0000
2021.12.14 21:03:15 4: KNXIO_processFIFO: C01164w0141c0000 Nr_msgs: 1
2021.12.14 21:03:15 5: KNX: dispatch C01164w0141c0000
2021.12.14 21:03:15 5: KNX_Parse -enter: IO-name: KNX, dest: 0141c, msg: C01164w0141c0000
2021.12.14 21:03:15 5: KNX_parse -exit
2021.12.14 21:03:17 5: KNXIO_Read: buf= 000a0027115a074600806f27
2021.12.14 21:03:17 5: KNXIO_Read Rawbuf: 000a0027115a074600806f27
2021.12.14 21:03:17 4: KNXIO_decodeEMI: src=0115a - dst=00746 - leng=3 - data=806f27
2021.12.14 21:03:17 5: KNXIO_decodeEMI: C0115aw007466f27
2021.12.14 21:03:17 4: KNXIO_processFIFO: C0115aw007466f27 Nr_msgs: 1
2021.12.14 21:03:17 5: KNX: dispatch C0115aw007466f27
2021.12.14 21:03:17 5: KNX_Parse -enter: IO-name: KNX, dest: 00746, msg: C0115aw007466f27
2021.12.14 21:03:17 5: KNX_parse -exit
2021.12.14 21:03:17 5: KNXIO_Read: buf= 000a002711640c1d008024c7
2021.12.14 21:03:17 5: KNXIO_Read Rawbuf: 000a002711640c1d008024c7
2021.12.14 21:03:17 4: KNXIO_decodeEMI: src=01164 - dst=0141d - leng=3 - data=8024c7
2021.12.14 21:03:17 5: KNXIO_decodeEMI: C01164w0141d24c7
2021.12.14 21:03:17 4: KNXIO_processFIFO: C01164w0141d24c7 Nr_msgs: 1
2021.12.14 21:03:17 5: KNX: dispatch C01164w0141d24c7
2021.12.14 21:03:17 5: KNX_Parse -enter: IO-name: KNX, dest: 0141d, msg: C01164w0141d24c7
2021.12.14 21:03:17 5: KNX_parse -exit
2021.12.14 21:03:19 5: KNXIO_Read: buf= 000a0027115a074600806f27
2021.12.14 21:03:19 5: KNXIO_Read Rawbuf: 000a0027115a074600806f27
2021.12.14 21:03:19 4: KNXIO_decodeEMI: src=0115a - dst=00746 - leng=3 - data=806f27
2021.12.14 21:03:19 5: KNXIO_decodeEMI: C0115aw007466f27
2021.12.14 21:03:19 4: KNXIO_processFIFO: C0115aw007466f27 Nr_msgs: 1
2021.12.14 21:03:19 5: KNX: dispatch C0115aw007466f27
2021.12.14 21:03:19 5: KNX_Parse -enter: IO-name: KNX, dest: 00746, msg: C0115aw007466f27
2021.12.14 21:03:19 5: KNX_parse -exit
2021.12.14 21:03:19 5: KNXIO_Read: buf= 000a002711640c1e00800000000a00271140040500800794
2021.12.14 21:03:19 5: KNXIO_Read Rawbuf: 000a002711640c1e00800000
2021.12.14 21:03:19 4: KNXIO_decodeEMI: src=01164 - dst=0141e - leng=3 - data=800000
2021.12.14 21:03:19 5: KNXIO_decodeEMI: C01164w0141e0000
2021.12.14 21:03:19 5: KNXIO_Read Rawbuf: 000a00271140040500800794
2021.12.14 21:03:19 4: KNXIO_decodeEMI: src=01140 - dst=00405 - leng=3 - data=800794
2021.12.14 21:03:19 5: KNXIO_decodeEMI: C01140w004050794
2021.12.14 21:03:19 4: KNXIO_processFIFO: C01164w0141e0000 Nr_msgs: 2
2021.12.14 21:03:19 5: KNX: dispatch C01164w0141e0000
2021.12.14 21:03:19 5: KNX_Parse -enter: IO-name: KNX, dest: 0141e, msg: C01164w0141e0000
2021.12.14 21:03:19 5: KNX_parse -exit
2021.12.14 21:03:21 5: KNXIO_Read: buf= 000a002711640c0c008014a3
2021.12.14 21:03:21 5: KNXIO_Read Rawbuf: 000a002711640c0c008014a3
2021.12.14 21:03:21 4: KNXIO_decodeEMI: src=01164 - dst=0140c - leng=3 - data=8014a3
2021.12.14 21:03:21 5: KNXIO_decodeEMI: C01164w0140c14a3
2021.12.14 21:03:21 4: KNXIO_processFIFO: C01164w0140c14a3 Nr_msgs: 1
2021.12.14 21:03:21 5: KNX: dispatch C01164w0140c14a3
2021.12.14 21:03:21 5: KNX_Parse -enter: IO-name: KNX, dest: 0140c, msg: C01164w0140c14a3
2021.12.14 21:03:21 5: KNX_parse -exit
2021.12.14 21:03:22 5: KNXIO_Read: buf= 000a00271129040200800c4c
2021.12.14 21:03:22 5: KNXIO_Read Rawbuf: 000a00271129040200800c4c
2021.12.14 21:03:22 4: KNXIO_decodeEMI: src=01129 - dst=00402 - leng=3 - data=800c4c
2021.12.14 21:03:22 5: KNXIO_decodeEMI: C01129w004020c4c
2021.12.14 21:03:22 4: KNXIO_processFIFO: C01129w004020c4c Nr_msgs: 1
2021.12.14 21:03:22 5: KNX: dispatch C01129w004020c4c
2021.12.14 21:03:22 5: KNX_Parse -enter: IO-name: KNX, dest: 00402, msg: C01129w004020c4c
2021.12.14 21:03:22 5: KNX_parse -exit
2021.12.14 21:03:22 5: KNXIO_Read: buf= 000a002711640c1f00800000
2021.12.14 21:03:22 5: KNXIO_Read Rawbuf: 000a002711640c1f00800000
2021.12.14 21:03:22 4: KNXIO_decodeEMI: src=01164 - dst=0141f - leng=3 - data=800000
2021.12.14 21:03:22 5: KNXIO_decodeEMI: C01164w0141f0000
2021.12.14 21:03:22 4: KNXIO_processFIFO: C01164w0141f0000 Nr_msgs: 1
2021.12.14 21:03:22 5: KNX: dispatch C01164w0141f0000
2021.12.14 21:03:22 5: KNX_Parse -enter: IO-name: KNX, dest: 0141f, msg: C01164w0141f0000
2021.12.14 21:03:22 5: KNX_parse -exit
2021.12.14 21:03:23 5: KNXIO_Read: buf= 000a0027115a074600806f27
2021.12.14 21:03:23 5: KNXIO_Read Rawbuf: 000a0027115a074600806f27
2021.12.14 21:03:23 4: KNXIO_decodeEMI: src=0115a - dst=00746 - leng=3 - data=806f27
2021.12.14 21:03:23 5: KNXIO_decodeEMI: C0115aw007466f27
2021.12.14 21:03:23 4: KNXIO_processFIFO: C0115aw007466f27 Nr_msgs: 1
2021.12.14 21:03:23 5: KNX: dispatch C0115aw007466f27
2021.12.14 21:03:23 5: KNX_Parse -enter: IO-name: KNX, dest: 00746, msg: C0115aw007466f27
2021.12.14 21:03:23 5: KNX_parse -exit
2021.12.14 21:03:23 5: KNXIO_Read: buf= 000a002711640c0d008014e7
2021.12.14 21:03:23 5: KNXIO_Read Rawbuf: 000a002711640c0d008014e7
2021.12.14 21:03:23 4: KNXIO_decodeEMI: src=01164 - dst=0140d - leng=3 - data=8014e7
2021.12.14 21:03:23 5: KNXIO_decodeEMI: C01164w0140d14e7
2021.12.14 21:03:23 4: KNXIO_processFIFO: C01164w0140d14e7 Nr_msgs: 1
2021.12.14 21:03:23 5: KNX: dispatch C01164w0140d14e7
2021.12.14 21:03:23 5: KNX_Parse -enter: IO-name: KNX, dest: 0140d, msg: C01164w0140d14e7
2021.12.14 21:03:23 5: KNX_parse -exit
2021.12.14 21:03:25 5: KNXIO_Read: buf= 000a0027115a074600806f33
2021.12.14 21:03:25 5: KNXIO_Read Rawbuf: 000a0027115a074600806f33
2021.12.14 21:03:25 4: KNXIO_decodeEMI: src=0115a - dst=00746 - leng=3 - data=806f33
2021.12.14 21:03:25 5: KNXIO_decodeEMI: C0115aw007466f33
2021.12.14 21:03:25 4: KNXIO_processFIFO: C0115aw007466f33 Nr_msgs: 1
2021.12.14 21:03:25 5: KNX: dispatch C0115aw007466f33
2021.12.14 21:03:25 5: KNX_Parse -enter: IO-name: KNX, dest: 00746, msg: C0115aw007466f33
2021.12.14 21:03:25 5: KNX_parse -exit
2021.12.14 21:03:25 5: KNXIO_Read: buf= 0008002711640c200081
2021.12.14 21:03:25 5: KNXIO_Read Rawbuf: 0008002711640c200081
2021.12.14 21:03:25 4: KNXIO_decodeEMI: src=01164 - dst=01420 - leng=1 - data=81
2021.12.14 21:03:25 5: KNXIO_decodeEMI: C01164w0142001
2021.12.14 21:03:25 4: KNXIO_processFIFO: C01164w0142001 Nr_msgs: 1
2021.12.14 21:03:25 5: KNX: dispatch C01164w0142001
2021.12.14 21:03:25 5: KNX_Parse -enter: IO-name: KNX, dest: 01420, msg: C01164w0142001
2021.12.14 21:03:25 5: KNX_parse -exit
2021.12.14 21:03:27 5: KNXIO_Read: buf= 000a0027115a074600806f27
2021.12.14 21:03:27 5: KNXIO_Read Rawbuf: 000a0027115a074600806f27
2021.12.14 21:03:27 4: KNXIO_decodeEMI: src=0115a - dst=00746 - leng=3 - data=806f27
2021.12.14 21:03:27 5: KNXIO_decodeEMI: C0115aw007466f27
2021.12.14 21:03:27 4: KNXIO_processFIFO: C0115aw007466f27 Nr_msgs: 1
2021.12.14 21:03:27 5: KNX: dispatch C0115aw007466f27
2021.12.14 21:03:27 5: KNX_Parse -enter: IO-name: KNX, dest: 00746, msg: C0115aw007466f27
2021.12.14 21:03:27 5: KNX_parse -exit
2021.12.14 21:03:27 5: KNXIO_Read: buf= 0008002711640c210080
2021.12.14 21:03:27 5: KNXIO_Read Rawbuf: 0008002711640c210080
2021.12.14 21:03:27 4: KNXIO_decodeEMI: src=01164 - dst=01421 - leng=1 - data=80
2021.12.14 21:03:27 5: KNXIO_decodeEMI: C01164w0142100
2021.12.14 21:03:27 4: KNXIO_processFIFO: C01164w0142100 Nr_msgs: 1
2021.12.14 21:03:27 5: KNX: dispatch C01164w0142100
2021.12.14 21:03:27 5: KNX_Parse -enter: IO-name: KNX, dest: 01421, msg: C01164w0142100
2021.12.14 21:03:27 5: KNX_parse -exit
2021.12.14 21:03:27 5: KNXIO_Read: buf= 000a002711640c390080008c
2021.12.14 21:03:27 5: KNXIO_Read Rawbuf: 000a002711640c390080008c
2021.12.14 21:03:27 4: KNXIO_decodeEMI: src=01164 - dst=01439 - leng=3 - data=80008c
2021.12.14 21:03:27 5: KNXIO_decodeEMI: C01164w01439008c
2021.12.14 21:03:27 4: KNXIO_processFIFO: C01164w01439008c Nr_msgs: 1
2021.12.14 21:03:27 5: KNX: dispatch C01164w01439008c
2021.12.14 21:03:27 5: KNX_Parse -enter: IO-name: KNX, dest: 01439, msg: C01164w01439008c
2021.12.14 21:03:27 5: KNX_parse -exit
2021.12.14 21:03:29 5: KNXIO_Read: buf= 000a0027115a074600806f27
2021.12.14 21:03:29 5: KNXIO_Read Rawbuf: 000a0027115a074600806f27
2021.12.14 21:03:29 4: KNXIO_decodeEMI: src=0115a - dst=00746 - leng=3 - data=806f27
2021.12.14 21:03:29 5: KNXIO_decodeEMI: C0115aw007466f27
2021.12.14 21:03:29 4: KNXIO_processFIFO: C0115aw007466f27 Nr_msgs: 1
2021.12.14 21:03:29 5: KNX: dispatch C0115aw007466f27
2021.12.14 21:03:29 5: KNX_Parse -enter: IO-name: KNX, dest: 00746, msg: C0115aw007466f27
2021.12.14 21:03:29 5: KNX_parse -exit
2021.12.14 21:03:29 5: KNXIO_Read: buf= 0008002711640c220081
2021.12.14 21:03:29 5: KNXIO_Read Rawbuf: 0008002711640c220081
2021.12.14 21:03:29 4: KNXIO_decodeEMI: src=01164 - dst=01422 - leng=1 - data=81
2021.12.14 21:03:29 5: KNXIO_decodeEMI: C01164w0142201
2021.12.14 21:03:29 4: KNXIO_processFIFO: C01164w0142201 Nr_msgs: 1
2021.12.14 21:03:29 5: KNX: dispatch C01164w0142201
2021.12.14 21:03:29 5: KNX_Parse -enter: IO-name: KNX, dest: 01422, msg: C01164w0142201
2021.12.14 21:03:29 5: KNX_parse -exit
2021.12.14 21:03:31 5: KNXIO_Read: buf= 0008002711640c230080
2021.12.14 21:03:31 5: KNXIO_Read Rawbuf: 0008002711640c230080
2021.12.14 21:03:31 4: KNXIO_decodeEMI: src=01164 - dst=01423 - leng=1 - data=80
2021.12.14 21:03:31 5: KNXIO_decodeEMI: C01164w0142300
2021.12.14 21:03:31 4: KNXIO_processFIFO: C01164w0142300 Nr_msgs: 1
2021.12.14 21:03:31 5: KNX: dispatch C01164w0142300
2021.12.14 21:03:31 5: KNX_Parse -enter: IO-name: KNX, dest: 01423, msg: C01164w0142300
2021.12.14 21:03:31 5: KNX_parse -exit
2021.12.14 21:03:33 5: KNXIO_Read: buf= 000a0027115a074600806f27
2021.12.14 21:03:33 5: KNXIO_Read Rawbuf: 000a0027115a074600806f27
2021.12.14 21:03:33 4: KNXIO_decodeEMI: src=0115a - dst=00746 - leng=3 - data=806f27
2021.12.14 21:03:33 5: KNXIO_decodeEMI: C0115aw007466f27
2021.12.14 21:03:33 4: KNXIO_processFIFO: C0115aw007466f27 Nr_msgs: 1
2021.12.14 21:03:33 5: KNX: dispatch C0115aw007466f27
2021.12.14 21:03:33 5: KNX_Parse -enter: IO-name: KNX, dest: 00746, msg: C0115aw007466f27
2021.12.14 21:03:33 5: KNX_parse -exit
2021.12.14 21:03:33 5: KNXIO_Read: buf= 0008002711640c240080
2021.12.14 21:03:33 5: KNXIO_Read Rawbuf: 0008002711640c240080
2021.12.14 21:03:33 4: KNXIO_decodeEMI: src=01164 - dst=01424 - leng=1 - data=80
2021.12.14 21:03:33 5: KNXIO_decodeEMI: C01164w0142400
2021.12.14 21:03:33 4: KNXIO_processFIFO: C01164w0142400 Nr_msgs: 1
2021.12.14 21:03:33 5: KNX: dispatch C01164w0142400
2021.12.14 21:03:33 5: KNX_Parse -enter: IO-name: KNX, dest: 01424, msg: C01164w0142400
2021.12.14 21:03:33 5: KNX_parse -exit
2021.12.14 21:03:33 5: KNXIO_Read: buf= 000a002711640c0b00800dc3
2021.12.14 21:03:33 5: KNXIO_Read Rawbuf: 000a002711640c0b00800dc3
2021.12.14 21:03:33 4: KNXIO_decodeEMI: src=01164 - dst=0140b - leng=3 - data=800dc3
2021.12.14 21:03:33 5: KNXIO_decodeEMI: C01164w0140b0dc3
2021.12.14 21:03:33 4: KNXIO_processFIFO: C01164w0140b0dc3 Nr_msgs: 1
2021.12.14 21:03:33 5: KNX: dispatch C01164w0140b0dc3
2021.12.14 21:03:33 5: KNX_Parse -enter: IO-name: KNX, dest: 0140b, msg: C01164w0140b0dc3
2021.12.14 21:03:33 5: KNX_parse -exit
2021.12.14 21:03:33 1: 127.0.0.1:6720 disconnected, waiting to reappear (KNX)
2021.12.14 21:03:33 1: KNXIO_Read: no data - disconnect
2021.12.14 21:03:33 1: KNXIO_disconnect: device KNX disconnected, waiting to reappear
2021.12.14 21:03:33 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:33 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:34 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:34 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:34 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:34 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:34 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:34 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:36 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:36 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:36 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:36 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:37 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:37 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:37 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:37 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:37 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:37 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:37 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:38 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:38 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:40 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:40 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:40 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:42 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:42 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:42 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:44 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:45 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:45 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:46 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:46 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:46 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:46 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:46 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:47 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:48 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:48 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:48 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:48 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:48 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:48 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:48 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:48 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:49 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:50 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:50 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:51 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:51 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:52 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:52 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:52 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:54 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:54 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:54 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:55 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:55 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:55 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:56 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:56 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:57 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:57 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:58 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:58 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:58 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:58 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:58 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:03:58 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:00 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:00 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:01 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:01 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:02 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:02 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:02 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:04 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:04 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:04 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:04 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:04 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:04 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:04 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:04 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:04 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:04 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:04 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:04 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:05 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:05 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:05 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:05 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:05 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:05 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:05 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:05 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:05 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:06 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:06 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:06 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:06 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:06 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:07 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:07 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:07 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:07 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:07 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:07 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:08 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:08 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:09 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:09 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:09 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:10 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:10 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:10 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:10 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:10 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:10 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:10 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:10 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:10 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:10 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:10 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:10 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:10 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:12 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:12 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:12 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:12 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:12 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:12 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:12 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:12 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:12 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:12 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:12 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:14 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:14 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:15 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:16 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:17 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:17 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:17 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:17 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:17 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:17 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:17 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:17 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:17 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:18 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:18 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:18 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:18 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:18 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:18 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:18 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:18 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:18 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:19 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:20 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:20 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:22 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:22 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:23 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:24 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:24 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:26 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:26 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:26 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:26 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:26 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:26 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:26 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:28 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:28 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:28 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:29 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:30 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:30 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:32 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:32 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:32 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:32 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:32 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:04:33 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=1
2021.12.14 21:06:28 5: KNXIO_closeDev: device KNX closed
2021.12.14 21:06:28 3: KNXIO_define: DNS query result= 127.0.0.1
2021.12.14 21:06:28 5: KNXIO_closeDev: device KNX closed
2021.12.14 21:06:28 3: KNXIO_define: opening device KNX mode=T
2021.12.14 21:06:28 5: KNXIO_openDev: T, 127.0.0.1, 6720, reopen=0
2021.12.14 21:06:28 3: Opening KNX device 127.0.0.1:6720
2021.12.14 21:06:28 5: HttpUtils url=http://127.0.0.1:6720/ NonBlocking via http
2021.12.14 21:06:28 4: IP: 127.0.0.1 -> 127.0.0.1
2021.12.14 21:06:28 5: DevIo_SimpleWrite KNX: 00050026000000
2021.12.14 21:06:28 3: KNX device opened
2021.12.14 21:06:28 5: KNXIO_Read: buf= 00020026
2021.12.14 21:06:28 5: KNXIO_Read Rawbuf: 00020026
2021.12.14 21:06:28 4: KNXIO_decdeEMI: OpenGrpCon response received
2021.12.14 21:06:29 5: KNXIO_Read: buf= 000a002711640c1500800000
2021.12.14 21:06:29 5: KNXIO_Read Rawbuf: 000a002711640c1500800000
2021.12.14 21:06:29 4: KNXIO_decodeEMI: src=01164 - dst=01415 - leng=3 - data=800000
2021.12.14 21:06:29 5: KNXIO_decodeEMI: C01164w014150000
2021.12.14 21:06:29 4: KNXIO_processFIFO: C01164w014150000 Nr_msgs: 1
2021.12.14 21:06:29 5: KNX: dispatch C01164w014150000
2021.12.14 21:06:29 5: KNX_Parse -enter: IO-name: KNX, dest: 01415, msg: C01164w014150000
2021.12.14 21:06:29 5: KNX_parse -exit
2021.12.14 21:06:31 5: KNXIO_Read: buf= 000a002711640c16008055d1
2021.12.14 21:06:31 5: KNXIO_Read Rawbuf: 000a002711640c16008055d1
2021.12.14 21:06:31 4: KNXIO_decodeEMI: src=01164 - dst=01416 - leng=3 - data=8055d1
2021.12.14 21:06:31 5: KNXIO_decodeEMI: C01164w0141655d1
2021.12.14 21:06:31 4: KNXIO_processFIFO: C01164w0141655d1 Nr_msgs: 1
2021.12.14 21:06:31 5: KNX: dispatch C01164w0141655d1
2021.12.14 21:06:31 5: KNX_Parse -enter: IO-name: KNX, dest: 01416, msg: C01164w0141655d1
2021.12.14 21:06:31 5: KNX_parse -exit


Wie man sieht ist um 21:06:28 die Verbindung wieder aufgebaut worden, nachdem ich ein Modify auf das KNXIO Device gemacht habe (ohne Änderung an der Definition).
Kann ich das vielleicht mit einem DOIF lösen? Ich möchte vermeiden, dass mir auf Grund eines KNXD Restarts die Verbindung unbemerkt verloren geht...
lg,
Matthias 

erwin

Hi Matthias,
danke für die Analyse, damit kann ich was anfangen.. Mal sehen, wie ich das lösen kann...

Grundsätzlich bin ich gegen den Einsatz von doif/notify... als Fehler-Lösung, weil diese ja erst NACH einem Fehler einsetzen...
Und alles, was ich im Modul tun kann, ist auch nur auf den Fehler zu reagieren... - Ohne Garantie, das das in allen möglichen Situationen auch funktioniert und mit der Unsicherheit, dass inzwischen KNX-messages verloren gehen könnten... Soll heissen: ich kann mit dem Modul immer nur die zweit-beste Lösung anbieten!
Warum der knxd terminiert / restartet wissen wir ja, die Frage bleibt somit: warum geht bei dir die Verbindung SCN-IP000.2 <-> knxd verloren?
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,...

baerm

Hi Erwin,
wenn Du ein Lösung im Modul liefern kannst, wäre es natürlich optimal. Ein extra DOIF wäre nur eine Notlösung.
Aus meiner Sicht geht die Verbindung SCN-IP000.2 <-> knxd nicht verloren, sondern die Verbindung knxd <-> KNXIO und wird nicht wieder aufgebaut nach erfolgtem Start von KNXD.
Nachdem es immer sein kann, dass kurz mal die IP Verbindung weg ist, auf Grund von Upgrades oder Änderungen, sollte eben die Verbindung wieder erfolgreich aufgebaut werden ohne manuellen Eingriff... wäre mein Wunsch.
lg,
Matthias

erwin

Hi Matthias,
ZitatAus meiner Sicht geht die Verbindung SCN-IP000.2 <-> knxd nicht verloren,
die geht sehr wohl verloren siehe:
ZitatDec 11 21:52:37 raspberrypi4 knxd[634]: F00000105: [16:B.ipt] Link down, terminating
Dec 11 21:52:37 raspberrypi4 systemd[1]: knxd.service: Main process exited, code=exited, status=1/FAILURE
...und damit terminiert der knxd! Danach wird (via systemd) der knxd neu gestartet.
Damit wäre die Fehlersuche zw. GW und KNXD nicht unnötig....
Aber stimmt schon, das KNXIO-Modul sollte die Verbindung zum neu gestartetem knxd wieder aufbauen!
Bin gerade am testen, schaut gut aus. Evtl gibts heute Abend eine neue Version...
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,...

baerm

Hi Erwin,
ok, Du hast von dem Vorfall vom 11.12. gesprochen. Ich habe mich aber auf den gestrigen Test bezogen wo ich den KNXD gestoppt habe. Da kann das SCN-IP000.2 keinen Einfluss darauf haben.
Ich denke der Usecase ist der selbe und sobald die Verbindung verloren geht wird diese nicht wieder aufgebaut.
Dann bin ich schon gespannt auf heute Abend :-)
danke,
Matthias

erwin

OK, neue Version ist am GIT
fix knxd reconnect ( nach 30 Sekunden !!!)
... hoffentlich keine Nebeneffekte.....
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,...

baerm

Danke für die schnelle Lieferung dieser Version. Habs mal gleich eingespielt. Werde am Abend den Test mit dem KNXD wiederholen.
lg,
Matthias

baerm

Hallo Erwin,
Reconnect funktioniert nun nach KNXD Restart automatisch. Vielen Dank für die Änderung!


2021.12.15 22:17:41 1:  127.0.0.1:6720 disconnected, waiting to reappear (KNX)
2021.12.15 22:17:41 1:  KNXIO_Read: no data - disconnect
2021.12.15 22:17:41 1:  KNXIO_disconnect: device KNX disconnected, waiting to reappear
2021.12.15 22:18:13 2:  KNXIO_callback: device open KNX failed with: 127.0.0.1: Connection refused (111)
2021.12.15 22:18:44 1:  127.0.0.1:6720 reappeared (KNX)

erwin

Hi Matthias, das ist erfreulich, wieder was gefixed!

@All: ich habe begonnen, einen wiki Eintrag zum Modul zu schreiben: https://wiki.fhem.de/wiki/KNXIO
Ist noch nicht fertig, manches dort beschriebene funkt. noch nicht.. Anregungen / Korrekturen erwünscht..
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

#55
Hatte heute den KNXD mal über socket und dann service gestoppt und in gleicher Reihenfolge wieder gestartet. Im S Mode ist keine Verbindung aufgebaut worden, weder von FHEM1 noch von FHEM2. Erst, als ich bei FHEM2 ein defmod gemacht habe, haben beide FHEM sich direkte verbunden :D sehr komisch.

EDIT:
Und jetzt gerader fällt mir was ein, was alles an komischen Verhalten erklärt. Ich habe auf FHEM1 ein FHEM2FHEM laufen und greife die LOGs von FHEM2 ab, welche auf FHEM1 als eigene Ereignisse dargestellt werden. Da beide Device gleich heißen, werden diese Daten übertragen. Somit vergiss vorerst alles was ich über den S Mode gesagt habe, die Daten sind total verfälscht. Aber laufen tut er auf jeden Fall ;)

Edit2:
Ich habe die beiden Device jetzt mal unterschiedlich benannt, damit dieser Fehler nicht mehr passiert und werde jetzt mal alles neu betrachten. Sorry für die Umstände.
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,
wenn du von 2 FHEM's auf einen knxd (gleichzeitig) verbindest, dann brauchst du KEIN FHEM2FHEM mehr, oder ? Du hast dann alles in beiden systemen.

Alternativ: Schau dir bitte doch mal das wiki https://wiki.fhem.de/wiki/KNXIO, da habe ich ganz unten beschrieben, wie das mit FHEM2FHEM RAW mode geht...
Funktionieren wird das allerdings erst mit der nächsten Version von KNXIO UND KNX.pm !! ich bin noch am testen.
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

Das FHEM2FHEM brauche ich auch noch für andere Dinge, deswegen hatte ich es nicht aufm Schirm. Aber ja, theoretisch könnte ich mir dann einen Zugriff auf das knxd sparen, hab ich auch noch nicht drüber nachgedacht.
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

Ich habe eine neue Version hochgeladen,
wesentliche Änderungen betreffen Mode M:
Es wird statt den selbst geschriebenen Multicast routinen jetzt TcpServerUtils.pm verwendet.
Daher muss FHEM (im speziellen TcpServerUtils.pm) auf dem aktuellen Stand sein, sonst gibts crash!
Vorteil: Standardroutinen aus dem Core-FHEM,
keine Notwendigkeit mehr das IO::Socket::Multicast perl-module zu installieren.

Alle anderen Modes: keine (wesentlichen) changes!

Bitte um Feedback, wenn alles gut geht, kommt das Modul demnächst ins offizielle SVN.
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

Grüße,

klingt ja risikoreich :D
Habe es mal eingespielt, im Mode M.

So in den ersten 2 Minuten fließen die Signale ganz normal...

GammaTwin

Grüße,

ich habe eine Kleinigkeit, die vielleicht mit dem Update zu tun hat.

Es gibt ein Reading, was ich zufällig entdeckt habe.
SV-g1

Ich kann es durch get <Device> g1 aktualisieren. Es löst keinen Event aus (die drei Ausrufezeichen). Und wird erst als aktualisiert angezeigt, wenn man die Webseite aktualisiert. Dann ist der Zeitstempel zu g1 gleich.

Es betrifft mehrere Devices. Aber nicht alle.

Internals:
   DEF        3/3/122:dpt9:g1:nosuffix
   DEVNAME    KNX_0303122
   FIRSTGADNAME g1
   FVERSION   10_KNX.pm:v5.1.0-s25855/2022-03-18
   GETSTRING  g1:noArg
   IODev      KNX
   KNX_MSGCNT 1
   KNX_TIME   2022-04-01 12:42:57
   LASTInputDev KNX
   MSGCNT     1
   NAME       KNX_0303122
   NR         1379
   SETSTRING  g1:slider,-670760,13415,670760
   STATE      0.00
   TYPE       KNX
   model      dpt9
   GADDETAILS:
     g1:
       CODE       0337a
       GROUP      3/3/122
       MODEL      dpt9
       NO         1
       OPTION     
       RDNAMEGET  g1
       RDNAMEPUT  g1
       RDNAMESET  g1
       SETLIST    :slider,-670760,13415,670760
   GADTABLE:
     0337a      g1
   READINGS:
     2022-04-01 12:40:45   IODev           KNX
     2022-04-01 12:42:57   SV-g1           0.00
     2022-04-01 12:42:57   g1              0.00
     2022-04-01 12:42:57   last-sender     1.0.7
     2022-04-01 12:42:57   state           0.00
Attributes:
   IODev      KNX
   event-on-change-reading .*
   event-on-update-reading (?!last-sender).*
   webCmd     g1
   widgetOverride g1:slider,-3,0.5,3,1

erwin

#61
Hi GammaTwin,
das kann ich nicht nachstellen...
Wo kommt das reading her?
Vermutungen:  8)
1) Es gibt ein notify od. doif, das so ein reading generiert... da das keinen event wirft, könnte es ein setreading <device> SV-g1 ... sein.
2) Du hast den GAD-Namen irgendwann von SV-g1 auf g1 geändert...
3) Es gibt ein weiteres Device im system mit 3/3/122

mach mal bitte ein  {PrintHash($modules{KNX}{defptr},3) }
auf der fhem-cmdline und suche nach 0337a: - gibts da mehr als eine hash(xxxx) entry?

PS: g1 kannst du weglassen auf der definitionszeile.
PS2: Sobald ein reading mal existiert (und im state-file geispeichert ist), gibts nichts was das wieder löscht, auch kein fhem-restart. Was hilft ist (evtl.) ein defmod oder (sicher) ein deletereading !
PS3: event-on-update : ich würde dort einfach state, g1 schreiben (je nachdem was du brauchst)  und event-on-change komplett weglassen - ist billiger/logischer
l.g. erwin
edit: PS1: g1 kannst du weglassen auf der definitionszeile. - IST FALSCH - nosuffix geht sonst nicht!
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

Zu meinen Hausaufgaben :D

Zitat von: erwin am 02 April 2022, 16:38:41
1) Es gibt ein notify od. doif, das so ein reading generiert... da das keinen event wirft, könnte es ein setreading <device> SV-g1 ... sein.
Oh man, natürlich. Ich habe da ein notify, das feiert demnächst seinen 8. Geburtstag :D
SV steht für Sollwertverschiebung. Ich löse damit das Problem, dass das Widget "Heizungsregler" in der Visu einen Sollwert braucht und der KNX-Aktor eine Sollwertverschiebung. Und gefunden habe ich nicht, weil das notify Wildcards nutzt, um alle Devices zu bedienen. Danke Dir.

Zitat von: erwin am 02 April 2022, 16:38:41
mach mal bitte ein  {PrintHash($modules{KNX}{defptr},3) }
auf der fhem-cmdline und suche nach 0337a: - gibts da mehr als eine hash(xxxx) entry?
Was immer diese Funktion macht  ;D
Es gibt einen Hash, nur einen. Kannst Du kurz sagen, was das ist?

erwin

ZitatKannst Du kurz sagen, was das ist?
das ist eine (interne) liste mit der findet eine KNX-msg, die vom Bus kommt - in welchem Device(hash) die gad vorkommt.
Sprich: ein mapping vom z.b. 3/3/122 auf den hash(dahinter versteckt sich dann der devicename-gadname). - in deinem Beispiel: KNX_0303122 - g1
... 0337a ist die hex-representation von 3/3/122....

Nachdem ein und derselbe  GAD ja in mehreren FHEM-devices vorkommen darf, hat diese liste 1 bis x entries  und die werden in KNX_parse abgearbeitet.
Wenn es KEINEN entry gibt - dann wird der autocreate mechanismus aktiviert....
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 KNX Community!
Ich habe eine neue Version hochgeladen,
das wird (vermutlich) die letzte Beta-Version sein,
falls ok, werde ich diese version ins offizielle SVN einchecken.
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 KNX Community!

Das Modul ist ab heute im SVN verfügbar - unter 00_KNXIO.pm.
Support gibts hier:
https://forum.fhem.de/index.php/topic,127792.0.html

Danke an alle Beta-Tester!
Für die user des Beta-Moduls: Bitte die GIT Version NICHT MEHR verwenden!
Die GIT version werdet ihr wie folgt los:

update delete https://raw.githubusercontent.com/erw111n/FHEM-KNX/main/controls_KNXIO.txt

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