[gelöst] FHEM KNX Status wird nicht gelesen - Schalten geht aber

[puma8080]

Hallo,

ich habe das Problem, dass mir der aktuelle Status vom KNX nicht in FHEM angezeigt wird.

Ich habe in FHM eine Lampe definiert mit

Code: [Auswählen]

define Licht_Buero KNX 10/0/0:dpt1 10/0/1:dpt1
welches mit list Licht_Buero dann so aussieht:

Code: [Auswählen]

Internals:
   DEF        10/0/0:dpt1 10/0/1:dpt1
   DEVNAME    Licht_Buero
   EIB_MSGCNT 6
   EIB_RAWMSG C0110cw0a00101
   EIB_TIME   2022-11-24 20:17:37
   FIRSTGADNAME g1
   FUUID      637fbcb8-f33f-0cca-d78b-dc6aed9859f36502
   GETSTRING  g1:noArg g2:noArg
   IODev      EIB
   LASTInputDev EIB
   MSGCNT     6
   NAME       Licht_Buero
   NR         1821
   NTFY_ORDER 50-Licht_Buero
   SETSTRING  g1:off,on g2:off,on
   STATE      on
   TYPE       KNX
   GADDETAILS:
     g1:
       CODE       0a000
       GROUP      10/0/0
       MODEL      dpt1
       NO         1
       OPTION     
       RDNAMEGET  getG1
       RDNAMEPUT  putG1
       RDNAMESET  setG1
       SETLIST    :off,on
     g2:
       CODE       0a001
       GROUP      10/0/1
       MODEL      dpt1
       NO         2
       OPTION     
       RDNAMEGET  getG2
       RDNAMEPUT  putG2
       RDNAMESET  setG2
       SETLIST    :off,on
   GADTABLE:
     0a000      g1
     0a001      g2
   READINGS:
     2022-11-24 20:17:37   getG2           on
     2022-11-24 20:21:03   last-sender     fhem
     2022-11-24 20:21:03   setG1           on
     2022-11-24 20:21:03   state           on
Attributes:
   IODev      EIB
   icon       FS20.on
Mit set Licht_Buero on/off kann ich das Licht jetzt Ein- und Ausschalten. Funktioniert prima.
Was allerdings nicht geht, ist die Rückmeldung wenn ich das Licht am Lichtschalter Ein- und Ausschalte.
Der Status bleibt immer so stehen wie er nach dem letzten schalten bei FHEM war.

Die richtige Gruppenadressen habe ich angegeben. Bei der Überprüfung mit knxtool wird alles richtig angezeigt:

Code: [Auswählen]

pi@raspberrypi:~ $ knxtool vbusmonitor1 ip:localhost
L_Busmon: BC 11 51 50 00 E1 00 81 33 :L_Data low from 1.1.81 to 10/0/0 hops: 06 T_Data_Group A_GroupValue_Write (small) 01
L_Busmon: BC 11 0C 50 01 E1 00 81 6F :L_Data low from 1.1.12 to 10/0/1 hops: 06 T_Data_Group A_GroupValue_Write (small) 01
1.1.81 ist der Schalter im Büro der eine 1 in 10/0/0 schreibt um den Aktor zu schalten
1.1.12 ist Aktor der das Licht im Büro schaltet und hier eine 1 in 10/0/1 schreibt um den eingeschalteten Status zu beschreiben.

Wobei der Busmonitor immer relativ schnell seine Verbindung verliert, warum auch immer?:

Code: [Auswählen]

Read failed: Connection reset by peer
Warum kommt diese 1 jetzt aber nicht bei FHEM  an und ändert die ausgeschaltete Lampe in eine eingeschaltete Lampe und den Status von Off nach On?

Aufgefallen im FHEM Logfile wäre mir noch, dass es so aussieht als hätte ich immer wieder eine Unterbrechung zum KNX-Bus:

Code: [Auswählen]

2022.11.24 20:34:33 3: decode_tpuart: Control Byte 0x11 does not match expected mask 2x1001nnnn
2022.11.24 20:34:33 3: TUL EIB refused message: 110e4201e3800c
2022.11.24 20:34:38 1: tul:/dev/ttyACM0@57600 disconnected, waiting to reappear
2022.11.24 20:34:44 3: TUL setting EIB baudrate to 57600
2022.11.24 20:34:44 1: TUL tul:/dev/ttyACM0@57600 reappeared (EIB)
Das würde auch dazu passen, dass meine Lampe wenn ich Sie durch FHEM bediene mal sofort schaltet und es mal bis zu 10s dauert, oder?

Ich hoffe es kann mir bitte jemand helfen.
Vorab schon vielen herzlichen Dank dafür.

Grüße Timo

[erwin]

Hi Timo,
2 dinge sind mir aufgefallen:
1) die Rückmeldung vom Aktor (1/0/1) kommt offensichtlich an. Ich würde stateFormat auf "getG2" setzen. Das ist immer der aktuelle status der Lampe.
2) Deine Implementation ist nicht "state of the Art"....
Es gibt bekannte Schwächen des TUL Moduls, speziell mit der direkten Verbindung über Seriell/USB, wie es bei dir der Fall ist.
Scheinbar bricht die Verbindung mit dem TUL zusammen (lt. deinem Log) und dann ist durchaus möglich, dass Messages verloren gehen können.

Die Empfehlung ist daher (ich glaube seit 2018 !), falls man ein serielles KNX-GW betreibt... das über den knxd zu machen!
Da ist ab Jessie auch kein Problem mehr, man muss das NICHT mehr kompilieren, sondern nur mittels apt-get installieren.
... und FHEM verbindet man dann mittels dem KNXIO Modul - das ersetzt das seit 2018 nicht mehr gewartete TUL-Modul!.

Das der BusMonitor und FHEM ... die Verbindung verliert, ist auch klar: du greifst von knxtool (via knxd) UND FHEM gleichzeitig auf die serielle Schnittstelle zu. Eine serielle Schnittstelle kann (sinnvoll) nur von einem Programm verwendet werden! - somst gibts Probleme - wie von dir beschrieben: knxtool-fehler/TUL Verbindungsfehler!

...suche bitte im wiki KNXIO - da steht das ganz gut beschrieben...
nachdem du knxtool verwendest, musst du auch den knxd am laufen haben, daher empfehle ich als FHEM-definition:

Code: [Auswählen]

define mydev KNXIO M .... - wie im wiki beschrieben und die TUL definition zu löschen..
l.g. erwin
 

[puma8080]

Hallo Erwin,

erst einmal vielen Dank für deine Unterstützung.
Zu 1):
stateFormat auf "getG2" hat leider keine Veränderung gebracht. Der Status wird immer noch falsch angezeigt.

Zu 2):
Ich bekomme als Antwort immer:

Code: [Auswählen]

Unknown module KNXIOAn was kann das liegen?

Habe folgendes probiert:

Code: [Auswählen]

define myKNXGW KNXIO M localhost:3671 1.1.200
und

Code: [Auswählen]

define myKNXGW KNXIO M 244.0.23.12:3671 1.1.200
Habe ich im Wiki https://wiki.fhem.de/wiki/KNXIO#Umstellung_von_TUL_oder_KNXTUL_Modul was übersehen was ich zuerst machen muss?
Bitte entschuldige, aber ich steh gerade echt auf am Schlauch.

Grüße Timo

[erwin]

An was kann das liegen?

Wann hast du zuletzt fhem update gemacht?
und richtig ist:

Code: [Auswählen]

define myKNXGW KNXIO M 244.0.23.12:3671 1.1.200wobei die 1.1.200 zu deiner knxd -E definition passen sollten!

[puma8080]

Hallo Erwin,

also das Update hat geholfen.
Die neue Verbindung ist da und so wie es aussieht auch verbunden:

Code: [Auswählen]

Internals:
   ADDR       224.0.23.12
   DEF        M 224.0.23.12:3671 1.1.200
   DeviceName 224.0.23.12:3671
   FD         4
   FUUID      6380bca0-f33f-0cca-fb63-8dcef9c8deb965cf
   MULTICAST  1
   NAME       myKNXGW
   NR         1647
   PARTIAL   
   PORT       3671
   PhyAddr    011c8
   STATE      connected
   SVN        26687 2022-11-12 21:43:22
   TYPE       KNXIO
   eventCount 1
   model      M
   msg_count  171
   msg_time   2022-11-25 14:29:45
   nextOpenDelay 10
   KNXIOhelper:
     FIFOMSG    C01164w0b20000
     FIFOTIMER  0
     FIFO:
   READINGS:
     2022-11-25 14:19:11   state           connected
Attributes:
   room       KNX_IO
Meine Lampe habe ich neu angelegt:

Code: [Auswählen]

Internals:
   CFGFN     
   DEF        10/0/0:dpt1 10/0/1:dpt1
   DEVNAME    Licht_Buero
   FIRSTGADNAME g1
   FUUID      6380c2b2-f33f-0cca-a48e-0b90d7e92cbd2fd6
   GETSTRING  g1:noArg g2:noArg
   IODev      myKNXGW
   NAME       Licht_Buero
   NR         1675
   SETSTRING  on:noArg off:noArg g1:on,off,toggle g2:on,off,toggle
   STATE      getG2
   SVN        26686 2022-11-12 21:41:59
   TYPE       KNX
   eventCount 9
   model      dpt1
   GADDETAILS:
     g1:
       CODE       0a000
       GROUP      10/0/0
       MODEL      dpt1
       NO         1
       OPTION     
       RDNAMEGET  getG1
       RDNAMEPUT  putG1
       RDNAMESET  setG1
       SETLIST    :on,off,toggle
     g2:
       CODE       0a001
       GROUP      10/0/1
       MODEL      dpt1
       NO         2
       OPTION     
       RDNAMEGET  getG2
       RDNAMEPUT  putG2
       RDNAMESET  setG2
       SETLIST    :on,off,toggle
   GADTABLE:
     0a000      g1
     0a001      g2
   READINGS:
     2022-11-25 14:27:14   IODev           myKNXGW
     2022-11-25 14:29:06   last-sender     fhem
     2022-11-25 14:29:06   setG1           on
     2022-11-25 14:29:06   state           on
Attributes:
   room       Buero
   stateFormat getG2
Neues Problem:
Ich kann jetzt auch nicht mehr schalten!   

Kannst du bitte noch einmal helfen?

Danke & Gruß
Timo

[erwin]

Das schaut eigentlich gut aus...

Tatsache ist, das der Empfang vom knx-Bus->FHEM funktioniert, ich sehe in deinem list eine msg (die aktuelle als du das list gemacht hast...) von 1.1.100 nach GA 11/2/0 mit wert 0.
Bis zu diesem Zeitpunkt sind 171 msg beim KNXIO eingetroffen! (msg_count).

Du könntest nochmal mit dem knxtool überprüfen, was da rein oder raus geht...
Das TUL device hast du gelöscht?

[puma8080]

Erwin, ich krieg die Kriese 

Habe zur Sicherheit FHEM gelöscht und neu installiert.
Jetzt aktualisiert sich der Status, aber ich kann immer noch nicht schalten.

knxd funktioniert:

Code: [Auswählen]

pi@raspberrypi:~ $ knxtool vbusmonitor1 ip:localhost
L_Busmon: BC 11 51 50 00 E1 00 80 32 :L_Data low from 1.1.81 to 10/0/0 hops: 06 T_Data_Group A_GroupValue_Write (small) 00
L_Busmon: BC 11 0C 50 01 E1 00 80 6E :L_Data low from 1.1.12 to 10/0/1 hops: 06 T_Data_Group A_GroupValue_Write (small) 00
in FHEM habe ich eine Verbindung. List myKNXGW zeigt:

Code: [Auswählen]

Internals:
   ADDR       224.0.23.12
   DEF        M 224.0.23.12:3671 1.1.200
   DeviceName 224.0.23.12:3671
   FD         4
   FUUID      6380e992-f33f-0cca-59e1-afde1f5dd7c9a9b9
   MULTICAST  1
   NAME       myKNXGW
   NR         14
   PARTIAL   
   PORT       3671
   PhyAddr    011c8
   STATE      connected
   SVN        26687 2022-11-12 21:43:22
   TYPE       KNXIO
   eventCount 1
   model      M
   msg_count  744
   msg_time   2022-11-25 18:19:18
   nextOpenDelay 10
   KNXIOhelper:
     FIFOMSG    C01164w0b20001
     FIFOTIMER  0
     FIFO:
   READINGS:
     2022-11-25 17:37:49   state           connected
Attributes:
   room       myKNXGW
Meine Lampe habe ich wieder gleich angelegt:

Code: [Auswählen]

Internals:
   DEF        10/0/0:dpt1 10/0/1:dpt1
   DEVNAME    Licht_Buero
   FIRSTGADNAME g1
   FUUID      6380e9b1-f33f-0cca-708a-75530d19ca8f26be
   GETSTRING  g2:noArg g1:noArg
   IODev      myKNXGW
   LASTInputDev myKNXGW
   MSGCNT     40
   NAME       Licht_Buero
   NR         19
   SETSTRING  g2:on,off,toggle on:noArg off:noArg g1:on,off,toggle
   STATE      off
   SVN        26686 2022-11-12 21:41:59
   TYPE       KNX
   eventCount 92
   model      dpt1
   myKNXGW_MSGCNT 40
   myKNXGW_TIME 2022-11-25 18:16:57
   GADDETAILS:
     g1:
       CODE       0a000
       GROUP      10/0/0
       MODEL      dpt1
       NO         1
       OPTION     
       RDNAMEGET  getG1
       RDNAMEPUT  putG1
       RDNAMESET  setG1
       SETLIST    :on,off,toggle
     g2:
       CODE       0a001
       GROUP      10/0/1
       MODEL      dpt1
       NO         2
       OPTION     
       RDNAMEGET  getG2
       RDNAMEPUT  putG2
       RDNAMESET  setG2
       SETLIST    :on,off,toggle
   GADTABLE:
     0a000      g1
     0a001      g2
   READINGS:
     2022-11-25 17:37:45   IODev           myKNXGW
     2022-11-25 18:16:57   getG1           off
     2022-11-25 18:16:57   getG2           off
     2022-11-25 18:16:57   last-sender     1.1.12
     2022-11-25 18:16:47   setG1           off
     2022-11-25 18:16:57   state           off
Attributes:
   webCmd     On:Off

Das steht in meiner knx.conf:

Code: [Auswählen]

KNXD_OPTS="-e 1.1.199 -E 1.1.200:10 -u /tmp/eib -D -T -R -S -b tpuarts:/dev/knx"
In der ETS kann ich mein Gateway auch sehen. Aber am Busmonitor kommt nichts an.

Gibt es vielleicht noch irgendeinen Tipp, was ich prüfen/machen könnte?

Grüße Timo

[erwin]

irgendwas spinnt in deinem setup:
744 messsages in 42 minuten sind relativ viel....
Was ist da alles am KNX-Bus drauf?
schon mal ein reboot vom raspi gemacht ?
hast du die Möglichkeit, mit dem ETS GroupMonitor zu schauen?
und was ist die GA 11/2/0 - (phy 1.1.100) die kommt jetzt schon zum zweiten mal in FIFOMSG vor, was darauf hindeutet, das sie sehr oft bzw. mehrfach gesendet wird, weil im Normalfalll ist FIFOMSG leer!
evtl. das myKNXGW auf verbose 4 setzen und das Log-file beobachten....

[puma8080]

Die vielen Botschaften (1.1.100) kommen von der Wetterstation auf dem Dach. Die habe ich jetzt einmal reduziert, die hat alle 5s gesendet (warum auch immer...)
Reboot habe ich heute schon mehrmals durchgeführt - ohne Verbesserungen.

Ich habe jetzt aus Verzweiflung mal meine knxd.conf geändert:

Code: [Auswählen]

KNXD_OPTS="-e 1.0.1 -E 1.0.200:10 -u /tmp/eib -D -T -R -S -b tpuarts:/dev/knx"Hatte sorge, dass die Adressen Probleme machen - war aber nicht so.

myKNXGW habe ich logischerweise angepasst und dabei gleich verbose auf 4 gesetzt (FiFo ist jetzt auch leer):

Code: [Auswählen]

Internals:
   ADDR       224.0.23.12
   DEF        M 224.0.23.12:3671 1.0.200
   DeviceName 224.0.23.12:3671
   FD         4
   FUUID      6380e992-f33f-0cca-59e1-afde1f5dd7c9a9b9
   MULTICAST  1
   NAME       myKNXGW
   NR         14
   PARTIAL   
   PORT       3671
   PhyAddr    010c8
   STATE      connected
   SVN        26687 2022-11-12 21:43:22
   TYPE       KNXIO
   eventCount 1
   model      M
   msg_count  29
   msg_time   2022-11-25 22:27:04
   nextOpenDelay 10
   KNXIOhelper:
     FIFOMSG    C01151w0a2000c29
     FIFOTIMER  0
     FIFO:
   READINGS:
     2022-11-25 22:16:44   state           connected
Attributes:
   room       myKNXGW
   verbose    4
Nachdem ich verbose auf 4 gesetzt habe, habe ich zur Sicherheit noch einen Reboot durchgeführt.
Es sieht für mich so aus, als würde alles sauber starten. Im Logfile steht zumindest KNXIO connected.
Dann habe ich die Lampe manuell am Schalter geschaltet (22:20:48 Uhr). Geht weiter wie erwartet. src=01151 (1.1.81) ist mein Schalter, der das Licht schaltet und src=0110c (1.1.12) ist der Aktor der den Satus setzt. Der passt auch und wird in FHEM sauber aktualisiert.
Danach (22:21:12) habe ich versucht die Lampe über FHEM zu schalten. Und das geht halt weiterhin nicht. Die Ausgabe im Logfile sieht halt auch komplett anders aus, ich hätte hier Ähnlichkeiten zum Eintrag vom manuellen Schalten erwartet, oder?

Logfile:

Code: [Auswählen]

2022.11.25 22:16:44 1: usb create end
2022.11.25 22:16:44 0: Featurelevel: 6.1
2022.11.25 22:16:44 0: Server started with 65 defined entities (fhem.pl:26635/2022-11-01 perl:5.028001 os:linux user:fhem pid:635)
2022.11.25 22:16:44 3: myKNXGW: port 3671 opened
2022.11.25 22:16:44 3: KNXIO (myKNXGW) connected
.....
2022.11.25 22:20:48 4: KNXIO_decodeCEMI: src= 01151 dst= 0a000 destaddrType= 1 prio= 3 hop_count= 5 leng= 1 data= 80
2022.11.25 22:20:48 4: KNXIO_processFIFO (myKNXGW): buf= C01151w0a00000 Nr_msgs= 1
2022.11.25 22:20:48 4: KNX_Parse -enter: IO-name= myKNXGW dest= 0a000 msg= C01151w0a00000
2022.11.25 22:20:48 4: KNXIO_decodeCEMI: src= 0110c dst= 0a001 destaddrType= 1 prio= 3 hop_count= 5 leng= 1 data= 80
2022.11.25 22:20:48 4: KNXIO_processFIFO (myKNXGW): buf= C0110cw0a00100 Nr_msgs= 1
2022.11.25 22:20:48 4: KNX_Parse -enter: IO-name= myKNXGW dest= 0a001 msg= C0110cw0a00100
2022.11.25 22:20:54 4: KNXIO_decodeCEMI: src= 01151 dst= 0a000 destaddrType= 1 prio= 3 hop_count= 5 leng= 1 data= 81
2022.11.25 22:20:54 4: KNXIO_processFIFO (myKNXGW): buf= C01151w0a00001 Nr_msgs= 1
2022.11.25 22:20:54 4: KNX_Parse -enter: IO-name= myKNXGW dest= 0a000 msg= C01151w0a00001
2022.11.25 22:20:54 4: KNXIO_decodeCEMI: src= 0110c dst= 0a001 destaddrType= 1 prio= 3 hop_count= 5 leng= 1 data= 81
2022.11.25 22:20:54 4: KNXIO_processFIFO (myKNXGW): buf= C0110cw0a00101 Nr_msgs= 1
2022.11.25 22:20:54 4: KNX_Parse -enter: IO-name= myKNXGW dest= 0a001 msg= C0110cw0a00101
...
2022.11.25 22:21:12 4: KNXIO_Write: Mode= M buf=0610053000112900bce000005000010080 rc= 17
2022.11.25 22:21:13 4: KNXIO_Write: Mode= M buf=0610053000112900bce000005000010081 rc= 17
2022.11.25 22:21:13 4: KNXIO_Write: Mode= M buf=0610053000112900bce000005000010080 rc= 17
2022.11.25 22:21:14 4: KNXIO_Write: Mode= M buf=0610053000112900bce000005000010081 rc= 17
Erwin, kannst du mit der Info aus dem Logfile was anfangen? Hier bin ich leider komplett blank und daher definitiv auf Hilfe angewiesen.

Und zur Sicherheit noch ein Test mit dem knxtool:

Code: [Auswählen]

pi@raspberrypi:~ $ knxtool groupswrite ip:192.168.0.100 10/0/0 0
Send request
pi@raspberrypi:~ $ knxtool groupswrite ip:192.168.0.100 10/0/0 1
Send request-> Der knxd funktioniert. Damit ging die Lampe Aus und wieder An.
Es muss also an der Kommunikation von fhem zu knxd scheitern, aber halt wo?

[erwin]

was mir in deinem Log aufgefallen ist:

Code: [Auswählen]

2022.11.25 22:16:44 1: usb create enddiese Funktion testet beim FHEM start ALLE möglichen seriellen/USB Schnittstellen und sucht nach einem CUL-Device. - Effekt ist, das an andere serielle Geräte irgenwelche mgs geschickt werden, die u.U. die Initialisierung des TUL's stören!
Abhilfe: es gibt ein notify in deinem FHEM, (das wird default angelegt) das 

Code: [Auswählen]

usb create als cmd enthält. Entweder das notify deleten oder disablen!

deine knxd.conf sollte so ausssehen:

Code: [Auswählen]

KNXD_OPTS="-e 1.0.1 -E 1.0.200:10  -D -T -R -S -b tpuarts:/dev/knx"
-u /tmp/eib sollte nicht gesetzt sein . steht so in der knxd.conf!

Andere Möglichkeit: dein System hat ein Problem mit dem Multicast protokoll....
Ändere mal versuchsweise dein GW auf mode T:

Code: [Auswählen]

myKNXGW KNXIO T 127.0.0.1:6720 1.0.200

[puma8080]

Erwin, vielen herzlichen Dank für den tollen Support!

Das Multicast war der Übeltäter!

Mit der Änderung des Gateway auf:

Code: [Auswählen]

myKNXGW KNXIO T 127.0.0.1:6720 1.0.200funktioniert es jetzt.

Danke & Grüße
Timo

[erwin]

OK, super!

Um den thread zu komplettieren:
zu Multicast steht im knxd wiki folgendes:

Wer Multicast nutzen möchte, muss ab Buster dieses noch aktivieren (z.B. für Tasmota-KNX)

Code: [Auswählen]

sudo nano /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts "1" durch "0" ersetzen
Nach einem reboot ....

Es wäre cool, wenn du das noch testen könntest, ich hatte bisher noch nicht das Problem...
l.g. erwin

[puma8080]

Hallo Erwin,

ich habe es getestet. Leider ohne Erfolg.
So konnte ich nicht einmal eine Verbindung herstellen. Mein KNX-Gateway in FHEM stand immer auf "disconnected"

Grüße Timo

[erwin]

Hi Timo,
danke für den Versuch, nachdem diese Info nicht von mir stammt. wollte ich das verifiziert haben.
Muss mir überlegen, wie ich das selbst testen kann...
l.g. erwin