Kommunikation mit KNX ohne knxd

Begonnen von jewuma, 29 April 2018, 15:13:03

Vorheriges Thema - Nächstes Thema

jewuma

Das sieht mir jetzt aber eher nach einem kleinen Bug im KNX-Modul aus. Wenn das öfter vorkommt, dann bitte mal den KNXTUL auf verbose 5 setzen und das entsprechende Gerät auch, anhand des Logs könnte ich nochmal forschen.

JoeALLb

Servus. Damit die Version ich nur Multicast , sondern auch direkt von einer IP hören kann, ist nicht möglich, (oder angedacht), oder?
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

jewuma

Bisher nicht. Ich muss es mir mal ansehen. Ich bin, wie eingangs geschrieben kein Perl-Guru und habe bis auf die kleinen Debug-Geschichten in den letzten Tagen nichts mehr mit Perl gemacht, daher ist die Einarbeitung noch etwas schwieriger. Aber vielleicht ist das Problem ja nocht so groß. Ich melde mich wieder...

GammaTwin

Grüße,

nachdem das Modul jetzt über einen Monat perfekte Dienste geleistet hat, ist folgendes passiert:
Ich habe mit der ETS einige Änderungen in die Busteilnehmer programmiert. Danach hatte ich neue Devices im FHEM. Ein Blick in den Log verät, dass die Nachrichten, welche die ETS schreibt, um die Busteilnehmer zu programmieren irgendwie falsch verstanden werden.

Und so sieht das dann aus:
...
2019.03.10 17:45:17.333 2: autocreate: define KNX_0200024 KNX 2/0/24:MODEL_NOT_DEFINED
2019.03.10 17:45:17.372 2: autocreate: define FileLog_KNX_0200024 FileLog ./log/autocreate/KNX_0200024-%Y.log KNX_0200024
2019.03.10 17:45:17.514 1: Received Message too short: 2900b0501018000100c2
2019.03.10 17:45:17.517 1: Received Message too short: 2900b0600001101800c2
2019.03.10 17:45:17.519 2: autocreate: define FileLog_KNX_0200024 FileLog ./log/autocreate/KNX_0200024-%Y.log KNX_0200024
2019.03.10 17:45:17.574 1: Received Message too short: 2900b0501018000100c6
2019.03.10 17:45:17.746 1: Received Message too short: 2900b0600001101800c6
2019.03.10 17:45:17.749 2: autocreate: define FileLog_KNX_0200024 FileLog ./log/autocreate/KNX_0200024-%Y.log KNX_0200024
2019.03.10 17:45:17.779 1: Received Message too short: 2900b0501018000100ca
2019.03.10 17:45:17.895 1: Received Message too short: 2900b0600001101800ca
...
2019.03.10 19:25:08.597 2: parse device hash (wpi): HASH(0x55d501f1f130) name: KNX_0200003, message could not be decoded - see log for details
2019.03.10 19:25:08.604 3: KNX: Unknown code C00001w0200340340426342635263626372714, help me!
2019.03.10 19:25:08.735 1: Received Message too short: 2900b0501003000100e6
2019.03.10 19:25:08.824 1: Received Message too short: 2900b0501003000100ea
2019.03.10 19:25:08.898 1: Received Message too short: 2900b0600001100300ce
2019.03.10 19:25:08.975 1: Received Message too short: 2900b0501003000100ee
2019.03.10 19:25:09.052 1: Received Message too short: 2900b0600001100300d2
2019.03.10 19:25:09.203 1: Received Message too short: 2900b0501003000100f2
2019.03.10 19:25:09.267 1: Received Message too short: 2900b0501003000100f6
2019.03.10 19:25:09.338 1: Received Message too short: 2900b0600001100300d6
2019.03.10 19:25:09.415 1: Received Message too short: 2900b0501003000100fa
2019.03.10 19:25:09.488 1: Received Message too short: 2900b0600001100300da
2019.03.10 19:25:09.501 2: parse device hash (wpi): HASH(0x55d501f1f130) name: KNX_0200003, message could not be decoded - see log for details
2019.03.10 19:25:09.508 3: KNX: Unknown code C00001w02003404c33273427352736, help me!
2019.03.10 19:25:09.629 1: Received Message too short: 2900b0501003000100fe
2019.03.10 19:25:09.694 1: Received Message too short: 2900b0501003000100c2
2019.03.10 19:25:09.759 1: Received Message too short: 2900b0600001100300de
2019.03.10 19:25:09.848 1: Received Message too short: 2900b0501003000100c6
...


Teilweise werden zufällig vorhanden Gruppenadressen getroffen. Dann passiert nichts, weil die Nachricht zu kurz ist :)
Siehe: KNX_0200003

Wird keine vorhandene Gruppenadresse getroffen, werden neue Devices angelegt :(
Siehe: KNX_0200024

Irgendwie müssten die "Systemnachrichten" ignoriert werden. Vielleicht kann man da etwas von knxd abschauen...

Schönen Abend

jewuma

Ich habe im Moment keine laufende KNX-Installation hier, daher kann ich den Fall nicht nachstellen.
Wenn du magst, dann stell doch mal KNXTUL auf verbose 5 und schick nochmal eine Umprogrammierung.
Dann könnte ich die Sache genauer analysieren und ggf. fixen.

Das mit dem Modul ohne Multicast wird wohl demnächst nichts, mein Router wollte mit dem Modul nicht so ohne Weiteres direkt kommunzieren.

Ich hoffe aber, dass KNXTUL außerhalb der Programmierung "unauffällig" läuft und auch die Meldungen es nicht aus dem Takt gebracht haben.

Gruß

Jens

GammaTwin

Grüße,

ich habe 2 unterschiedliche Aktoren programmiert:

Der erste erzeugt die von mir verwendeten "KNX_02000xx" Adressen. Z.B: "KNX, dest: 0200a". Das führt dann zu den neuen Devices.
2019.03.12 19:30:29.551 1: Received Message too short: 2900b0600001100a00c6
2019.03.12 19:30:29.571 5: RawMessage read: 2900b0600001100a0f4a8c47e4d1db070bd3db070bd4db070b
2019.03.12 19:30:29.572 5: Message read - CtrlByte: 01100000 Source: 0001 Dest: 100a Data: 4a8c47e4d1db070bd3db070bd4db070b
2019.03.12 19:30:29.572 5: KNX: dispatch C00001w0200a47e4d1db070bd3db070bd4db070b
2019.03.12 19:30:29.572 5: enter parse: hash: HASH(0x55e1aa461b30) name: KNX, dest: 0200a, msg: C00001w0200a47e4d1db070bd3db070bd4db070b
2019.03.12 19:30:29.573 2: parse device hash (wpi): HASH(0x55e1aaa48988) name: KNX_0200010, message could not be decoded - see log for details
2019.03.12 19:30:29.573 5: exit parse
2019.03.12 19:30:29.579 3: KNX: Unknown code C00001w0200a47e4d1db070bd3db070bd4db070b, help me!
2019.03.12 19:30:29.633 1: Received Message too short: 2900b050100a000100ca
2019.03.12 19:30:29.694 5: RawMessage read: 2900b050100a00010f4a4c47e4d1db070bd3db070bd4db070b
2019.03.12 19:30:29.694 5: Message read - CtrlByte: 01010000 Source: 100a Dest: 0001 Data: 4a4c47e4d1db070bd3db070bd4db070b
2019.03.12 19:30:29.694 5: KNX: dispatch C0100ap0000147e4d1db070bd3db070bd4db070b
2019.03.12 19:30:29.695 5: enter parse: hash: HASH(0x55e1aa461b30) name: KNX, dest: 00001, msg: C0100ap0000147e4d1db070bd3db070bd4db070b
2019.03.12 19:30:29.695 5: exit parse
2019.03.12 19:30:29.756 1: Received Message too short: 2900b0600001100a00ca
2019.03.12 19:30:29.777 5: RawMessage read: 2900b0600001100a0f4e8c47f0d5db070bd6db070bd7db070b
2019.03.12 19:30:29.778 5: Message read - CtrlByte: 01100000 Source: 0001 Dest: 100a Data: 4e8c47f0d5db070bd6db070bd7db070b
2019.03.12 19:30:29.778 5: KNX: dispatch C00001w0200a47f0d5db070bd6db070bd7db070b
2019.03.12 19:30:29.778 5: enter parse: hash: HASH(0x55e1aa461b30) name: KNX, dest: 0200a, msg: C00001w0200a47f0d5db070bd6db070bd7db070b
2019.03.12 19:30:29.779 2: parse device hash (wpi): HASH(0x55e1aaa48988) name: KNX_0200010, message could not be decoded - see log for details
2019.03.12 19:30:29.779 5: exit parse
2019.03.12 19:30:29.786 3: KNX: Unknown code C00001w0200a47f0d5db070bd6db070bd7db070b, help me!
2019.03.12 19:30:29.839 1: Received Message too short: 2900b050100a000100ce
2019.03.12 19:30:29.899 5: RawMessage read: 2900b050100a00010f4e4c47f0d5db070bd6db070bd7db070b
2019.03.12 19:30:29.900 5: Message read - CtrlByte: 01010000 Source: 100a Dest: 0001 Data: 4e4c47f0d5db070bd6db070bd7db070b
2019.03.12 19:30:29.900 5: KNX: dispatch C0100ap0000147f0d5db070bd6db070bd7db070b
2019.03.12 19:30:29.900 5: enter parse: hash: HASH(0x55e1aa461b30) name: KNX, dest: 00001, msg: C0100ap0000147f0d5db070bd6db070bd7db070b
2019.03.12 19:30:29.901 5: exit parse



Der zweite Aktor erzeugt "KNX, dest: 00001".
2019.03.12 19:38:41.541 5: RawMessage read: 2900b050101800010f724c497c000000000000000000000000
2019.03.12 19:38:41.541 5: Message read - CtrlByte: 01010000 Source: 1018 Dest: 0001 Data: 724c497c000000000000000000000000
2019.03.12 19:38:41.542 5: KNX: dispatch C01018p00001497c000000000000000000000000
2019.03.12 19:38:41.542 5: enter parse: hash: HASH(0x55e1aa461b30) name: KNX, dest: 00001, msg: C01018p00001497c000000000000000000000000
2019.03.12 19:38:41.543 5: exit parse
2019.03.12 19:38:41.600 1: Received Message too short: 2900b0600001101800f2
2019.03.12 19:38:41.622 5: RawMessage read: 2900b0600001101803720c4988
2019.03.12 19:38:41.623 5: Message read - CtrlByte: 01100000 Source: 0001 Dest: 1018 Data: 720c4988
2019.03.12 19:38:41.623 5: KNX: dispatch C00001r020184988
2019.03.12 19:38:41.623 5: enter parse: hash: HASH(0x55e1aa461b30) name: KNX, dest: 02018, msg: C00001r020184988
2019.03.12 19:38:41.623 5: exit parse
2019.03.12 19:38:41.631 3: KNX: Unknown code C00001r020184988, help me!
2019.03.12 19:38:41.666 1: Received Message too short: 2900b0501018000100f2
2019.03.12 19:38:41.727 5: RawMessage read: 2900b050101800010f764c49880000ff000000000000000000
2019.03.12 19:38:41.727 5: Message read - CtrlByte: 01010000 Source: 1018 Dest: 0001 Data: 764c49880000ff000000000000000000
2019.03.12 19:38:41.728 5: KNX: dispatch C01018p0000149880000ff000000000000000000
2019.03.12 19:38:41.728 5: enter parse: hash: HASH(0x55e1aa461b30) name: KNX, dest: 00001, msg: C01018p0000149880000ff000000000000000000
2019.03.12 19:38:41.729 5: exit parse
2019.03.12 19:38:41.803 1: Received Message too short: 2900b0600001101800f6
2019.03.12 19:38:41.824 5: RawMessage read: 2900b0600001101803760c4994
2019.03.12 19:38:41.825 5: Message read - CtrlByte: 01100000 Source: 0001 Dest: 1018 Data: 760c4994
2019.03.12 19:38:41.825 5: KNX: dispatch C00001r020184994
2019.03.12 19:38:41.825 5: enter parse: hash: HASH(0x55e1aa461b30) name: KNX, dest: 02018, msg: C00001r020184994
2019.03.12 19:38:41.825 5: exit parse
2019.03.12 19:38:41.832 3: KNX: Unknown code C00001r020184994, help me!
2019.03.12 19:38:41.867 1: Received Message too short: 2900b0501018000100f6
2019.03.12 19:38:41.929 5: RawMessage read: 2900b050101800010f7a4c4994000000000000000000000000
2019.03.12 19:38:41.929 5: Message read - CtrlByte: 01010000 Source: 1018 Dest: 0001 Data: 7a4c4994000000000000000000000000
2019.03.12 19:38:41.930 5: KNX: dispatch C01018p000014994000000000000000000000000
2019.03.12 19:38:41.930 5: enter parse: hash: HASH(0x55e1aa461b30) name: KNX, dest: 00001, msg: C01018p000014994000000000000000000000000
2019.03.12 19:38:41.931 5: exit parse
2019.03.12 19:38:42.009 1: Received Message too short: 2900b0600001101800fa
2019.03.12 19:38:42.031 5: RawMessage read: 2900b06000011018037a0c49a0
2019.03.12 19:38:42.031 5: Message read - CtrlByte: 01100000 Source: 0001 Dest: 1018 Data: 7a0c49a0
2019.03.12 19:38:42.032 5: KNX: dispatch C00001r0201849a0
2019.03.12 19:38:42.032 5: enter parse: hash: HASH(0x55e1aa461b30) name: KNX, dest: 02018, msg: C00001r0201849a0
2019.03.12 19:38:42.032 5: exit parse
2019.03.12 19:38:42.039 3: KNX: Unknown code C00001r0201849a0, help me!
2019.03.12 19:38:42.074 1: Received Message too short: 2900b0501018000100fa
2019.03.12 19:38:42.136 5: RawMessage read: 2900b050101800010f7e4c49a0000000000000000000000000
2019.03.12 19:38:42.136 5: Message read - CtrlByte: 01010000 Source: 1018 Dest: 0001 Data: 7e4c49a0000000000000000000000000
2019.03.12 19:38:42.137 5: KNX: dispatch C01018p0000149a0000000000000000000000000
2019.03.12 19:38:42.137 5: enter parse: hash: HASH(0x55e1aa461b30) name: KNX, dest: 00001, msg: C01018p0000149a0000000000000000000000000
2019.03.12 19:38:42.138 5: exit parse


Genau genommen: Ich habe keine Ahnung :)

Du hattest nach sonstigen Problemen gefragt, oder ob die Meldungen irgwelche Effekte hatten. Ich habe keine Meldung im letzten Monat in den Logfiles gefunden :)
Während der Programmierung ist auch keine Jalousie verfahren, gesperrt oder irgendwie beeinträchtigt worden. (KNX_02....) ist bei mir Verschattung. Also alles gut.

Solange das Thema besteht, werde ich fhem beenden während des Programmiervorganges.

Schönes Abend

jewuma

Hallo und danke für die Testdaten.

Ich habe jetzt mal die nicht "normalen" Nachrichten ausgefiltert, das sollte das Anlegen von ungewollten KNX-Geräten unterbinden.

Gruß

Jens

GammaTwin

Habe es mehrere Tage ausprobiert. Lief problemlos.

Heute habe ich mit der ETS programmiert. Es ist ein einziges "help me!" aufgetaucht mit verbose 5 aufgetaucht. Kein Gerät würde angelegt, ich habe auch sonst nichts negatives bemerkt.

Daumen hoch!!


Ich habe etwas anderes endeckt. Ist aber wahrscheinlich völlig unbedeutend:
Ich habe teilweise die Definitionen set, get, listenonly im Einsatz.

Mit listenonly wollte ich verhindern, dass FHEM den Wert verändert.
defmod KNX_0407050 KNX 4/7/50:dpt9.021:listenonly

Fragt dann allerdings eine KNX-Komponente den Status ab, kommt im LOG:
KNXTUL - Read started
2019.03.18 18:32:27.698 5: RawMessage read: 2900bce000012732010000
2019.03.18 18:32:27.698 5: Message read - CtrlByte: 11100000 Source: 0001 Dest: 2732 Data: 0000
2019.03.18 18:32:27.699 5: KNX: dispatch C00001r0473200
2019.03.18 18:32:27.699 5: enter parse: hash: HASH(0x5595f6e8bf08) name: KNX, dest: 04732, msg: C00001r0473200
2019.03.18 18:32:27.699 5: exit parse
2019.03.18 18:32:27.705 3: KNX: Unknown code C00001r0473200, help me!


Ändere ich die Definition auf "get"
defmod KNX_0407050 KNX 4/7/50:dpt9.021:get
kommt keine "help me!"-Meldung
2019.03.18 18:33:23.225 5: KNXTUL - Read started
2019.03.18 18:33:23.225 5: RawMessage read: 2900bce000012732010000
2019.03.18 18:33:23.225 5: Message read - CtrlByte: 11100000 Source: 0001 Dest: 2732 Data: 0000
2019.03.18 18:33:23.226 5: KNX: dispatch C00001r0473200
2019.03.18 18:33:23.226 5: enter parse: hash: HASH(0x5595f6e8bf08) name: KNX, dest: 04732, msg: C00001r0473200
2019.03.18 18:33:23.226 5: exit parse


Die Meldungen unterscheiden sich ja nur in der letzten Zeile. Wahrscheinlich ist gar kein "Bug", da bei "listenonly" kein Request erwartet wird...

EinEinfach

ZitatOkay, ich habe ein MDT SCN-IP000.02 (IP Interface); das kann wohl kein Multicast. Das kann nur der MDT SCN-IP100.02 (IP Router).
Schade.

hast du es doch noch irgendwie zum Laufen bekommen? Habe die gleiche Hardware, macht es Sinn sich mit dem Modul zu beschäftigen oder ist es gleich von vorne aus aussichtslos

Gruß
fhem auf Intel NUC6CAYH mit Proxmox im LXC (Debian 10), KNX mit knxd über MDT SCN-IP000.02, Buderus GB192-15i über KM100, Solaredge WR SE9K über Modbus-TCP

kasperle_1

Hallo,

ich habe das Modul eingebunden und erhaltet sobald ich einen AKTOR Betätige folgende Meldung:


2019.04.03 11:35:38.863 3: KNXTUL opening KNXHome
2019.04.03 11:35:38.863 3: KNXTUL device opened
2019.04.03 11:36:06.261 3: KNXHome: Unknown code C01102w0021400, help me!
2019.04.03 11:36:06.328 3: KNXHome: Unknown code C0fffaw0021400, help me!
2019.04.03 11:36:06.457 3: KNXHome: Unknown code C01202w0021300, help me!
2019.04.03 11:36:06.537 3: KNXHome: Unknown code C0fffaw0021400, help me!
2019.04.03 11:36:06.835 3: KNXHome: Unknown code C01202w0021300, help me!
2019.04.03 11:36:06.915 3: KNXHome: Unknown code C0fffaw0021400, help me!


Ich dachte erkannte Geräte werden automatisch angelegt?

jewuma

Ich habe das mal nachvollzogen.
Dies liegt nicht an dem KNXTUL sondern an dem KNX-Modul selbst, welches zuerst mindestens ein Gerät händisch angelegt haben will, bevor es neue Geräte automatisch anlegt.
Allerdings ist es sowieso sinnvoll, die Geräte selbst anzulegen, da die Datenpunkte angegeben werden müssen, um sinnvoll mit den Geräten zu arbeiten.

Gruß

Jens

markofnoise

Hallo zusammen,

da mich mein knxd quält, würde ich sehr gerne umsteigen. Ich halte das Projekt für einen tolle Idee, die eine Menge Komplexität einsparen kann.

Selbst umfangreiche Tests (knxd stand-alone auf RPI, im Docker) konnten das Problem der doppelten Telegramme nicht lösen. Auf fhem-Seite bekomme ich sauber nur einfache Telegramme, ebenso über vbusmonitor1, aber in der ETS ist alles doppelt. Ebenso steigen bei mir nach zuschalten vom knxd KNX-Rolladen-Aktoren aus. Recherchen bzgl. Linienkoppler und Router wegen Telegramm-Bestätigung haben mich auch nicht weiter gebracht.

So, nun zu meiner Hoffnung. Da ich bereits viele Devices habe, möchte ich auf jeden Fall vorher ein bisschen genauer testen. Ich benutze fhem in erster Linie als Gateway von Homematic, ZigBee, Z-Wave nach KNX und zurück (per notify) und habe mich eher mit der Anwendungsseite beschäftigt.

Da ich bisher wenig Erfahrung mit TUL bzw. Devices im allgemeinen habe, bitte ich hier um eine etwas genauere Beschreibung der Konfiguration in fhem.

Meine Sicht
1. Schritt: Installtion (Modul und cpan), soweit ok
2. Danach fehlt mir einfach das Wissen (u.a. Syntax und Bedeutung, TUL etc.)

Könnte mich da jemand abholen?

Viele Grüße
Markus

jewuma

#42
Hallo,
ich weiß nicht, ob ich die Wissenslücken richtig erkannt habe, aber ich versuche es einfach mal.

Für die Kommunikation mit deinen KNX-Geräten brauchst du entweder das KNX-Modul und den knxd oder das KNX-Modul und das KNXTUL-Modul.
Der knxd bzw. das KNXTUL stellen die physikalische Kommunikation mit dem KNX-Gateway her.

dazu machst du ein
define KNX KNXTUL 1.1.254, wobei die 1.1.254 eine physikalische KNX-Adresse ist, unter der die Pakete an die einzelnen Geräte geschickt werden. Eine IP-Adresse wird nicht benötigt, da das Modul immer über die KNX-Standard-Multicast-Adresse kommuniziert.

Jetzt kann das KNX-Modul (hoffentlich) mit den KNX-Geräten sprechen.
Dazu musst du dem KNX Modul nur noch mitteilen, mit welchen Gruppenadressen es kommunizieren soll, die Datenpunkte, die den Gruppenadressen entsprechen, einen Namen unter dem die erhaltenen Werte gelistet werden und schließlich, dass die Kommunikation über den KNXTUL laufen soll, der hier mit dem Namen KNX definiert wurde. Beispiel:

define KThermo KNX 0/0/2:dpt9.001:SollTemp 0/0/3:dpt9.001:IstTemp KNX

Ich hoffe, das hilft weiter.

Gruß
Jens

markofnoise

Vielen Dank für Deine Erklärung, jetzt versuche ich es nochmal mit meinen eigenen Worten:

Ein KNX-Modul benötigt ein TUL um mit KNX (TP,IP) zu kommunizieren, im Falle des KNXTUL (als TUL) findet eine Kommunikation über Multicast statt.

Das Device <name> ist eine KNX-Modul-Instanz, welches ein [IODev] benötigt:
define <name> KNX <group>:<DPT>:[gadName]:[set|get|listenonly]:[nosuffix] [<group>:<DPT> ..] [IODev]

In Deinem Post definierst Du also eine KNXTUL-Instanz mit
define KNX KNXTUL 1.1.254
define KThermo KNX 0/0/2:dpt9.001:SollTemp 0/0/3:dpt9.001:IstTemp KNX


wobei das erste KNX = KNX-Modul-Instanz und das zweite KNX = [IODev] definiert wird

Damit ich das besser auseinander halten kann:
define KNXIP KNXTUL 1.1.254
define KThermo KNX 0/0/2:dpt9.001:SollTemp 0/0/3:dpt9.001:IstTemp KNXIP


Um jetzt einzelne Devices testweise auf Multicast umzulenken, müsste doch die Umdefinition des Attributes [IODev] genügen, oder?

VG
Markus

jewuma

Hallo,

mit meinem bescheidenen FHEM Wissen würde ich sagen, dass das so korrekt ist und funktionieren müsste.

Gruß

Jens