Beta-Test neues KNX-IO Modul

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

Code: [Auswählen]

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:

Code: [Auswählen]

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! 

Happy testing und Danke!
erwin

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

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!

[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

[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

[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

[thorte]

Hallo Erwin,

zu der Erkenntnis bin ich inzwischen auch gelangt 

Dieses Gerät:

Code: [Auswählen]

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:

Code: [Auswählen]

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:

Code: [Auswählen]

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]

@ 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

[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

Code: [Auswählen]

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

Code: [Auswählen]

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

Code: [Auswählen]

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:

Code: [Auswählen]

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