KNXD startet FHEM neu

Begonnen von Amenophis86, 27 April 2021, 21:46:00

Vorheriges Thema - Nächstes Thema

Amenophis86

@erwin dein Tipp mit auskommentieren hat geholfen, die restarts sind weg. Vielen Dank dafür.

Wie weit würdest du denn deine Version von KNXTUL beschreiben, macht es Sinn diese schon einzusetzen oder eher noch warten bis du aus der Beta raus bist?
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...

Amenophis86

Nachdem ich die Zeilen aus kommentiert habe, startet wie gesagt FHEM nicht mehr neu sobal der Socket beendet wird. Allerdings habe ich nun das Problem, dass KNXD keine Daten mehr senden und empfangen kann nachdem der Socket und Service wieder gestartet wurde. Es kommt immer folgender Fehler:

2021.05.02 19:01:19 2: sendRequest: TUL KNX: No known physical protocoll defined.

Erst nach einem Neustart des Pis kann ich wieder Telegramme senden und empfangen. Jemand eine Idee woran das liegt?

Und dazu noch direkt eine weitere Verständnisfrage, wenn ich mit KNXTUL arbeite, dann baut das Device eine eigene Verbindung auf, oder? Der Grund meine Frage ist folgender. Ich habe zwei FHEM Instanzen, die mit KNX verbunden sind, zwei Handys und die ETS. Mein IP Interface kann aber nur vier Verbindungen. Mit KNXD kein Problem, da die FHEM Instanzen alle über KNXD laufen und damit nur eine Verbindung darstellen. Wenn ich aber auf KNXTUL umstelle und jede Instanz dann eine eigene Verbindung aufbaut, komme ich auf 5 Verbindungen, was eine zu viel wäre. Daher die Frage.
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...

Amenophis86

*push*

Vielleicht hat ja doch jemand eine Idee bzw kann meine Frage zu den Tunneln beantworten.
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

Du hast geschrieben "IP Interface". Du brauchst einen Router, der Multicast kann. Manche IP Interface haben Multicast, aber für irgendwas anderes, nicht für die Kommunikation :)

erwin

Hi Amenophis86,

sorry bin erst jetzt vom Urlaub zurückgekommen, naja Urlaub ist zuviel gesagt.. Segeltraining in Kroatien, Wetter mittelprächtig, da bleibt nicht viel Energie um FHEM Fragen zu beantworten...

ad KNTUL beta: das gibts eine auf meinem GIT, da ist im wesentlichen die parse routine "robuster" gegen messages, die FHEM nicht braucht... (z.B: programmieren mittels ETS). Das ist nicht die Alpha version von der ich einem vorigen thread gesprochen hab.
Meines Wissen verwendet Hauswart diese produktiv.

ad TUL: sorry das war ein "dirty" fix - und eigentlich ist der code dort völlig unnötig, ausser du hast einen USB-TUL direkt an FHEM dran, ohne KNXD, was bei dir ja nicht der Fall ist..
das muss ich mir in Ruhe anschauen.

KNXTUL-Frage: das KNX-GW/Router sendet Mulitcast messages aus, das sind broadcasts, und beliebig viele Clients können auf diese brodcast adresse lauschen (z.B. FHEM-KNXTUL Modul aber auch die ETS) Die Einschränkung auf 4 oder 8 ports bei den KNX_GW'S gilt nur bei direct connect (sowiet ich das verstehe).
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

Sorry erwin, wollte dir da keinen Stress machen und dachte eher an andere User. Aber danke, dass du geantwortet hast. Und sorry, dass dein "Urlaub" nicht so gut war.

Ah, ich wusste nicht, dass KNXTUL über Multicast arbeitet und keine direkte Verbindung aufbaut. Dann kann ich mit meinem IP Interface eh nicht auf KNXTUL umstellen, alles klar. Danke für die Erklärung.

Und wenn du Zeit hast dir das KNXD Problem anzusehen und ich was testen soll, sag bescheid. Hat aber auch keine Eile. So oft lernt man ja nicht neue Teilnehmer an. Hatte bei mir nur alle GT2 gegen Smart 85 getauscht, weil uns das haptische Feedback gefehlt hat. Aber die sind jetzt alle durch :)
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 Amenophis86,

sorry, es hat etwas gedauert, ich musste ein neues Testsystem aufbauen und das Problem war, daß ich kein USB-C Netzteil mehr übrig hatte...

Testsystem raspi-4 4GB, raspberry-pi-os-32-bit,  Kernel Version 5.10
fhem install / update
knxd install w. apt-get

ich konnte allerdings dein Problem nicht nachstellen, hier der fhem-log von knxd.service / knxd.socket stoppen und wieder starten:
2021.05.13 15:06:08 5: SimpleRead msg.type: write, msg.src: 000c8, msg.dst: 0340a
2021.05.13 15:06:08 5: SimpleRead data: 0000
2021.05.13 15:06:08 4: myTUL: C000c8w0340a0000
2021.05.13 15:06:08 5: myTUL: dispatch C000c8w0340a0000
2021.05.13 15:06:08 5: KNX_Parse -enter: IO-name: myTUL, dest: 0340a, msg: C000c8w0340a0000
2021.05.13 15:06:08 5: KNX_parse -exit
2021.05.13 15:06:20 2: getRequest: communication to knxd failed

2021.05.13 15:06:20 2: GetGroup: seems like knxd not connected

2021.05.13 15:06:20 4: No data received.
2021.05.13 15:06:20 1: eibd:localhost:6720 disconnected, waiting to reappear
2021.05.13 15:06:25 3: OpenDev: OBD response from eibd:localhost:6720
2021.05.13 15:06:25 1: TUL eibd:localhost:6720 reappeared (myTUL)
2021.05.13 15:06:32 2: getRequest: communication to knxd failed

2021.05.13 15:06:32 2: GetGroup: seems like knxd not connected

2021.05.13 15:06:32 4: No data received.
2021.05.13 15:06:32 1: eibd:localhost:6720 disconnected, waiting to reappear
2021.05.13 15:06:49 3: KNX_checkAndClean: value= 15:00 was casted to 15:00:00
2021.05.13 15:07:27 3: KNX_checkAndClean: value= 15:05 was casted to 15:05:00
2021.05.13 15:07:37 3: OpenDev: OBD response from eibd:localhost:6720
2021.05.13 15:07:37 1: TUL eibd:localhost:6720 reappeared (myTUL)
2021.05.13 15:07:47 3: KNX_checkAndClean: value= 15:15 was casted to 15:15:00
2021.05.13 15:07:47 5: sending Cw0a009000f0f00
2021.05.13 15:07:47 5: SimpleRead msg.type: write, msg.src: 051fb, msg.dst: 0a009
2021.05.13 15:07:47 5: SimpleRead data: 0f0f00
2021.05.13 15:07:47 4: myTUL: C051fbw0a0090f0f00
2021.05.13 15:07:47 5: myTUL: dispatch C051fbw0a0090f0f00

... mit original TUL-Modul
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

#22
Kein Problem. Dann suchen wir doch mal zusammen. Hier ein List meines KNX Device:


Historie löschen
Internals:
   AckLineDef
   Clients    :KNX:EIB:
   DEF        knxd:localhost 1.0.100
   DevType    EIBD
   DeviceAddress 01064
   DeviceName knxd:localhost
   FD         7
   FUUID      5fa85105-f33f-92c6-6cf7-2142c84778cd3f0a
   KNX_MSGCNT 15880
   KNX_TIME   2021-05-13 20:12:26
   NAME       KNX
   NR         12
   PARTIAL   
   RAWMSG     C01152w071020e27
   REFUSED   
   STATE      CONNECTED
   TYPE       TUL
   MatchList:
     2:KNX      ^C.*
     3:EIB      ^B.*
   READINGS:
     2021-05-13 14:53:31   state           CONNECTED
Attributes:


die KNXD Config:

KNXD_OPTS="-e 1.0.100 -E 1.0.101:5 -c -b ipt:192.168.2.126"


Ich nutze ein MDT IP Interface

Und hier ein Verbose 5 (des KNX Device) Log beim stoppen und starten von knxd.socket und dann knxd.service:

2021.05.13 20:20:23 5: SimpleRead msg.type: write, msg.src: 01106, msg.dst: 00118
2021.05.13 20:20:23 5: SimpleRead data: 01
2021.05.13 20:20:23 4: KNX: C01106w0011801
2021.05.13 20:20:23 5: KNX: dispatch C01106w0011801
2021.05.13 20:20:23 5: KNX_Parse -enter: IO-name: KNX, dest: 00118, msg: C01106w0011801
2021.05.13 20:20:23 5: KNX_parse -exit
2021.05.13 20:20:23 5: SimpleRead msg.type: write, msg.src: 01106, msg.dst: 06107
2021.05.13 20:20:23 5: SimpleRead data: 01
2021.05.13 20:20:23 4: KNX: C01106w0610701
2021.05.13 20:20:23 5: KNX: dispatch C01106w0610701
2021.05.13 20:20:23 5: KNX_Parse -enter: IO-name: KNX, dest: 06107, msg: C01106w0610701
2021.05.13 20:20:23 5: KNX_parse -exit
2021.05.13 20:20:25 5: SimpleRead msg.type: write, msg.src: 01104, msg.dst: 00418
2021.05.13 20:20:25 5: SimpleRead data: 01
2021.05.13 20:20:25 4: KNX: C01104w0041801
2021.05.13 20:20:25 5: KNX: dispatch C01104w0041801
2021.05.13 20:20:25 5: KNX_Parse -enter: IO-name: KNX, dest: 00418, msg: C01104w0041801
2021.05.13 20:20:25 5: KNX_parse -exit
2021.05.13 20:20:25 5: SimpleRead msg.type: write, msg.src: 01104, msg.dst: 00518
2021.05.13 20:20:25 5: SimpleRead data: 1a
2021.05.13 20:20:25 4: KNX: C01104w005181a
2021.05.13 20:20:25 5: KNX: dispatch C01104w005181a
2021.05.13 20:20:25 5: KNX_Parse -enter: IO-name: KNX, dest: 00518, msg: C01104w005181a
2021.05.13 20:20:25 5: KNX_parse -exit
2021.05.13 20:20:25 5: SimpleRead msg.type: write, msg.src: 01104, msg.dst: 00518
2021.05.13 20:20:25 5: SimpleRead data: 9a
2021.05.13 20:20:25 4: KNX: C01104w005189a
2021.05.13 20:20:25 5: KNX: dispatch C01104w005189a
2021.05.13 20:20:25 5: KNX_Parse -enter: IO-name: KNX, dest: 00518, msg: C01104w005189a
2021.05.13 20:20:25 5: KNX_parse -exit
2021.05.13 20:20:26 5: SimpleRead msg.type: write, msg.src: 01106, msg.dst: 07107
2021.05.13 20:20:26 5: SimpleRead data: 147e
2021.05.13 20:20:26 4: KNX: C01106w07107147e
2021.05.13 20:20:26 5: KNX: dispatch C01106w07107147e
2021.05.13 20:20:26 5: KNX_Parse -enter: IO-name: KNX, dest: 07107, msg: C01106w07107147e
2021.05.13 20:20:26 5: KNX_parse -exit
2021.05.13 20:20:26 5: SimpleRead msg.type: write, msg.src: 01104, msg.dst: 00518
2021.05.13 20:20:26 5: SimpleRead data: ff
2021.05.13 20:20:26 4: KNX: C01104w00518ff
2021.05.13 20:20:26 5: KNX: dispatch C01104w00518ff
2021.05.13 20:20:26 5: KNX_Parse -enter: IO-name: KNX, dest: 00518, msg: C01104w00518ff
2021.05.13 20:20:26 5: KNX_parse -exit
2021.05.13 20:20:26 5: SimpleRead msg.type: write, msg.src: 01114, msg.dst: 00702
2021.05.13 20:20:26 5: SimpleRead data: 00ce
2021.05.13 20:20:26 4: KNX: C01114w0070200ce
2021.05.13 20:20:26 5: KNX: dispatch C01114w0070200ce
2021.05.13 20:20:26 5: KNX_Parse -enter: IO-name: KNX, dest: 00702, msg: C01114w0070200ce
2021.05.13 20:20:26 5: KNX_parse -exit
2021.05.13 20:20:26 5: SimpleRead msg.type: write, msg.src: 01106, msg.dst: 07107
2021.05.13 20:20:26 5: SimpleRead data: 1d78
2021.05.13 20:20:26 4: KNX: C01106w071071d78
2021.05.13 20:20:26 5: KNX: dispatch C01106w071071d78
2021.05.13 20:20:26 5: KNX_Parse -enter: IO-name: KNX, dest: 07107, msg: C01106w071071d78
2021.05.13 20:20:26 5: KNX_parse -exit
2021.05.13 20:20:26 5: SimpleRead msg.type: write, msg.src: 01152, msg.dst: 07102
2021.05.13 20:20:26 5: SimpleRead data: 0e4a
2021.05.13 20:20:26 4: KNX: C01152w071020e4a
2021.05.13 20:20:26 5: KNX: dispatch C01152w071020e4a
2021.05.13 20:20:26 5: KNX_Parse -enter: IO-name: KNX, dest: 07102, msg: C01152w071020e4a
2021.05.13 20:20:26 5: KNX_parse -exit
2021.05.13 20:20:26 2: getRequest: communication to knxd failed

2021.05.13 20:20:26 2: GetGroup: seems like knxd not connected

2021.05.13 20:20:26 4: No data received.
2021.05.13 20:20:26 1: knxd:localhost disconnected, waiting to reappear
2021.05.13 20:22:10 5: sending Cw0010200
2021.05.13 20:22:10 2: sendRequest: TUL KNX: No known physical protocoll defined.


Es kommt nix mehr an von KNXD. Er wechselt allerdings im STATE von DISCONNCTED zu CONNECTED. Komisch, dass nicht mal das Log steht. Müsste da nicht auch Initialized stehen?
Das sendRequest ist ein manuelle ausgelöstes Telegram, was nicht durchgeht. Mehr bietet verbose 5 mir nicht an.

Hier noch der Status von systemctl knxd nach einem stop / start:
pi@FHEMPi:~ $ sudo systemctl status knxd
● knxd.service - KNX Daemon
   Loaded: loaded (/etc/systemd/system/knxd.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2021-05-13 20:20:46 CEST; 3min 15s ago
Main PID: 29453 (knxd)
    Tasks: 1 (limit: 2062)
   CGroup: /system.slice/knxd.service
           └─29453 /usr/bin/knxd -e 1.0.100 -E 1.0.101:5 -c -b ipt:192.168.2.126

Mai 13 20:20:46 FHEMPi systemd[1]: Starting KNX Daemon...
Mai 13 20:20:46 FHEMPi systemd[1]: Started KNX Daemon.


Kann ich dir noch irgendwas liefern? Und hast du dran gedacht in Zeile 303 ff aus zukommentieren?
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...

Amenophis86

journalctl -u knxd.service -b

bietet auch nur folgendes an:
Mai 13 20:20:25 FHEMPi systemd[1]: Stopping KNX Daemon...
Mai 13 20:20:25 FHEMPi systemd[1]: knxd.service: Succeeded.
Mai 13 20:20:25 FHEMPi systemd[1]: Stopped KNX Daemon.
Mai 13 20:20:46 FHEMPi systemd[1]: Starting KNX Daemon...
Mai 13 20:20:46 FHEMPi systemd[1]: Started KNX Daemon.
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,

sehr komisch, bis zu knxd:localhost disconnected, waiting to reappear
sind die logs ident...
ich hab allerdings vom Bus was geschickt während knxd down war und du von FHEM!
ich hab mit der "original" TUL probiert, jetzt ist mir noch eins aufgefallen:
(ab Zeile 301):
        # This is relevant for windows/USB only
        if(defined($hash->{USBDev})) {
                my $po = $hash->{USBDev};
                my ($BlockingFlags, $InBytes, $OutBytes, $ErrorFlags) = $po->status;
                return ($InBytes>0);
        }
        return 0;
}

..der code ist abgekupfert von: https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Ready
nur das if(defined.... hat man wohl vergessen. - deswegen dein ursprünglicher Absturz!
Ich hab jetz noch das "return 0;" hinzugefügt, um zu dokumentieren, dass kein TUL_OpenDev stattgefunden hat.
Kannst du das bitte versuchen? Und falls nach 60 sekunden das TUL nicht wieder auf initialised geht - dann bitte ein defmod auf das TUL device
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

Schau an.

- Ich habe die TUL Datei geändert mit deinem Code
- FHEM neugestartet
- knxd.socket und knxd.service gestoppt
- FHEM schmiert schon mal nicht ab (nice)
- KNX geht auf connected aber nicht auf Initialized
- Befehle von FHEM an KNX gehen nicht durch, im Log weiterhin sendRequest: TUL KNX: No known physical protocoll defined.
- defmode auf KNX -> neuer STATE: Initialized
- Befehle gehen durch und kommen an

Ich schätze das hilft dir, weil vermutlich irgendwas im Device nicht neu gestartet wird, was ein defmod aber anstößt ;)
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...

Amenophis86

Zwischenfrage: Hast du eine Ahnung, warum KNXD dazu führt, dass zwei Geräte im Programmiermodus gemeldet werden, wenn man eine neue Phys. Adresse vergeben will? Und vielleicht auch, wie man das unterbinden kann? Das ist ja erst der Grund, wie ich auf den Fehler hier gekommen bin. Wenn nicht ist nicht schlimm, sieht ja danach aus, dass zumindest der FHEM-KNXD Fehler behoben werden kann und dann muss ich halt weiterhin KNXD stoppen aber zumindest nicht FHEM immer noch neu starten :)
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,
ok, das sind good news. Ich will eigentlich nicht weiter in der TUL.pm herumpfuschen, das ist mir zu heikel, das fehlen mir auch die Test- Debug-möglichkeiten.
Ad Zwischenfrage:
Du meinst in der ETS werden 2 Geräte im Programmiermodus gemeldet? - Keine Ahnung, ich hatte mal ein Problem mit dem Programmieren ETS->KNXD->Weinzirl731 und irgendwo hab ich gelesen, "-B single" soll helfen. Meine KNXD-Option schaut so aus:
KNXD_OPTS="-e 0.0.10 -E 0.0.11:8 -D -T -R -S -B single -b ipt:192.168.5.246"
Bei mir funktioniert aber auch ETS->Weinzirl direct! der KNXD läuft dabei weiter ohne Auffälligkeiten.
...und im knxd git schreibt der author:
ZitatETS programming may or may not work out of the box. You might need to use the single filter in front of your KNX interface.
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

Danke für die Rückmeldung zum KNXD, dann werde ich das mit -B single mal testen.

ZitatIch will eigentlich nicht weiter in der TUL.pm herumpfuschen, das ist mir zu heikel, das fehlen mir auch die Test- Debug-möglichkeiten.
Wenn du magst, dann helfe ich dir gerne. Ansonsten baue ich mir einen Workaround mit einem notify und defmod, auch kein Problem. Vielleicht setzt du ja irgendwann deinen merge von KNXTUL und TUL um ;)

Vielen Dank für die Hilfe
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...

Amenophis86

Zitat von: erwin am 14 Mai 2021, 08:35:56
"-B single"

habe es in der Conf eingefügt und es scheint zu helfen. Es werden mir keine doppelten Geräte mehr im Programmiermodus angezeigt. Danke für den Tipp.
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...