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
define Licht_Buero KNX 10/0/0:dpt1 10/0/1:dpt1
welches mit list Licht_Buero dann so aussieht:
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:
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?:
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:
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
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:
define mydev KNXIO M ....
- wie im wiki beschrieben und die TUL definition zu löschen..
l.g. erwin
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:
Unknown module KNXIO
An was kann das liegen?
Habe folgendes probiert:
define myKNXGW KNXIO M localhost:3671 1.1.200
und
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 (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
ZitatAn was kann das liegen?
Wann hast du zuletzt fhem update gemacht?
und richtig ist:
define myKNXGW KNXIO M 244.0.23.12:3671 1.1.200
wobei die 1.1.200 zu deiner knxd -E definition passen sollten!
Hallo Erwin,
also das Update hat geholfen.
Die neue Verbindung ist da und so wie es aussieht auch verbunden:
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:
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
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?
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:
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:
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:
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:
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
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....
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:
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):
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:
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:
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?
was mir in deinem Log aufgefallen ist:
2022.11.25 22:16:44 1: usb create end
diese 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 usb create
als cmd enthält. Entweder das notify deleten oder disablen!
deine knxd.conf sollte so ausssehen:
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:
myKNXGW KNXIO T 127.0.0.1:6720 1.0.200
Erwin, vielen herzlichen Dank für den tollen Support!
Das Multicast war der Übeltäter!
Mit der Änderung des Gateway auf:
myKNXGW KNXIO T 127.0.0.1:6720 1.0.200
funktioniert es jetzt.
Danke & Grüße
Timo
OK, super!
Um den thread zu komplettieren:
zu Multicast steht im knxd wiki folgendes:
Zitat
Wer Multicast nutzen möchte, muss ab Buster dieses noch aktivieren (z.B. für Tasmota-KNX)
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
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
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