Modul 00_KNXIO.pm support

[Nokz]

Hallo erwin,

danke für die Erklärungen bzgl. dem Aufbau der Nachrichten. Kann ja nicht schaden sowas mal verstanden zu haben, wenn man mal Fehler sucht Bzgl. des Codings probiere ich das gerne mal aus. Leider musste ich heute morgen feststellen, dass ich mich scheinbar zu früh gefreut hatte. Ich habe jetzt erstmal wieder auf KNXD umgestellt und werde endlich meine lange Baustelle (LAN-Kabel ziehen für den FHEM-Server angehen) abschließen. Ich bin mir nämlich ziemlich sicher, dass die Wlan-AP's hier einen strich durch die Rechnung machen. Es ging nämlich alles bis zum Neustart des Switches/ Ap's und FHEM. Ich bleibe hier aber am Ball, weil ich will das zum Laufen bekommen ^^

Code: [Auswählen]

.. das war ja nur eine Vermutung... allerdings das ist ein Router, und der hätte gerne auf jedem seiner Interfaces einen anderen Adress-Bereich,
sprich: auf Twistet Pair 1.x.x auf dem LAN z.b.: 0.x.y. So stehts jedenfalls in den KNX-specs. Wenn es so auch funktioniert, solls mir recht sein! ;DDas ist glaube ich auch soweit richtig, nur das bei mir die Hauptlinie 1.x.x IP-Topologie ist und die Linie 1.1.x ist Twistet Pair. Somit stellt mein IP-Router mit der 1.1.0 die Verbindung zwischen der IP-Welt 1.x.x und der TP-Welt 1.1.X her. Da ich hier eh nochmal ran muss, wird es wahrscheinlich sinniger sein, dass man evtl. nochmal ein Dummy in z.B. 1.2.x anlegt, damit der Router auch denkt er muss mit der IP-Welt zwingend kommunizieren. Aber solange ich keine Lan-Verbindung gezogen habe ist die Fehlersuche wahrscheinlich zu schwierig. Am Modul liegt es jedenfalls nicht - das nutze ich ja aktuell für die Kommunikation über KNXD

[erwin]

... ja, ich hab mal wo gelesen, dass multicast und WLAN nicht unbedingt Freunde sind...
In diesem Fall ist das noch verschärft, weil falls die WLAN-Verbindung nur ganz kurz unterbricht - und FHEM davon nichts mitbekommt, (was der NormalFall ist),
dann macht natürlich FHEM auch kein reconnect...
Ich hab mir die Sache mit der src-adressen nochmal angesehen, muss noch weiter testen, wird jedenfalls in der nächsten Version für Multicast und Host-mode gefixt.
l.g. erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin

[ahermann86]

Hallo,

ich habe mit

Code: [Auswählen]

myKNXGW KNXIO H 192.168.2.150:3671 0.0.51die Anbindung zu meinem Bus über das Gateway MDT SCN-IP000.02 hergestellt.
Soweit funktioniert das auch.

Wenn ich aber über die FHEM Befehlszeile z.B. mit

Code: [Auswählen]

get EG_Fenster_Arbeit g1den Status Abfrage, erscheint ein leeres Fenster, das ich mit "ok" (Bild1) bestätigen kann.
Der Wert im Device wird dennoch aktualisiert.

Wenn ich aber

Code: [Auswählen]

get EG_Fenster.* g1
ausführe, passiert meistens nichts. Manchmal wird ein Device abgefragt.
In diesem Aufruf kommt auch das leere Fenster (Bild2) und manchmal ein request, der oben rechts mit dem schwarzen Fald angezeit wird.

Wenn ich das mit meinem bisherigen System (knxd/TUL) mache, werden alle betroffenen Devices abgefragt und das Fenster ist mit der Liste der requests gefüllt und die werden auch alle durchgeführt.

Ich habe in meinem neuen System bewusst das KNXIO direkt mit dem Gateway verbunden, da so knxd entfällt. Im Wiki zum KNXIO steht was mit Mode H und zeitkritisch.. ist dieser Fall damit betroffen oder habe ich einen anderen Denkfehler?

Gruß
Axel

[erwin]

Hi Axel,

get EG_Fenster.* g1

ist so nicht als cmd vorgesehen, wildcards sind in set/get cmd's nicht erlaubt. - diesen Fehler hab ich bisher nicht abgefangen...- sollte ich fixen!
Nachdem der set/get cmd immer über das KNX-Modul abgewickelt wird - und nur das IO-Modul  unterschiedlich ist, sollten hier keine Unterschiede sein. Das KNXIO-Modul ist allerdings um etliches schneller die cmd's abzuarbeiten, sodass du mgl. weise nicht alle requests sehen kannst...
Für deinen Problem gibts allerdings eine Lösung:

Code: [Auswählen]

{KNX_scan('EG_Fenster.*')} Details dazu zu finden unter "help KNX" auf der FHEM cmd-line.

Im Wiki zum KNXIO steht was mit Mode H und zeitkritisch..

Ob du betroffen bist, würdest du im Log sehen, die relevanten Messages sind im KNXIO- wiki beispielhaft dokumentiert.
l.g. erwin

[erwin]

Hi Axel,
Korrektur zu meinem post:
Ein set/ get cmd mit wildcards ist grundsätzlich erlaubt ( das wird durch eine core funktion in fhem.pl erledigt) - damit kann ich das im KNX-Modul gar nicht verhindern. - dort kommen die device namen einzeln / komplett an!
jetzt zum Problem damit:
Es gehen alle msg richtig aus FHEM hinaus (verifiziert mit ETS-Monitor).
Allerdings so schnell hintereinander, dass evtl. das KNX-GW bzw. der KNX-bus diese nicht so schnell verarbeiten kann.  Das ist auch der Grund, warum ich im KNX_scan eine Verzögerung um 200ms (nonblocking) zwischen den einzelnen requests eingebaut habe.
Das könnte auch den Unterschied zw. TUL und KNXIO Modul erklären. Das KNXIO Modul ist im processing etwa um den Faktor 4 schneller!

noch eine Frage: wie startest du das "get EG_Fenster.* ... ? Aus der FHEM-cmdline ? oder beim FHEM-start mittels notify, doif,.... ?
gibts im fhem Log irgendwelche fehler/msgs?

[ahermann86]

Hallo Erwin,

ich habe meine Fenster als Devices in mein neues FHEM per define eingefügt.
Da sie in dem Moment noch nie abgrufen waren, existierte jeweils das Reading getG1 noch nicht...

Ich habe dann versucht, alle Zustände in der FHEM Kommandozeile mit "get EG_Fenster.* g1" abzurufen.
Eine Fehlermeldung bekomme ich nicht sowie auch keine Log Einträge.

Gruß
Axel

[erwin]

Hi Axel!
danke fürs feedback,

Da sie in dem Moment noch nie abgrufen waren, existierte jeweils das Reading getG1 noch nicht...

...die Set/Get Kommandos funktionieren auch wenn es das entspechende reading noch nicht gibt und erzeugen/updaten auch das entsprechende reading, ALLERDINGS: Du must danach einen Browser refresh machen, damit du die neu erzeugten readings siehst! (NUR falls es das entsprechende reading vorher nicht gab! - sonst automatisch...) Das ist eine core-FHEM Funktion.
ich hab weitere Fragen:
1) Funktioniert ein "einzel device Get...." ?
2) hast du das KNX_Scan versucht ?
3) Gibts im Log Hinweise auf KNXIO Timeouts ? (Mode H)

PS: ich bin gerade dabei das KNX- und KNXIO-Modul zu überarbeiten - falls es Vorschläge/Probleme gibt... kann ich das noch berücksichtigen.
l.g. erwin   

[GammaTwin]

Grüße,

ich habe zum Jahreswechsel vom Mode M auf Mode H gewechselt. Hat etwas mit docker zu tun, ist aber hier nicht wichtig.

Ich beobachten die selben Effekte. Ich frage zum Bsp. mehrere Jalousiezustände mit Wildcards ab wenn ich Szenen für ganze Räume schalte. Die Sperre der MDT-Aktoren sendet nämlich keine Aktualisierung wenn diese durch eine zweite Gruppenadresse gesetzt wird.
Im Mode M läuft das problemlos. Im Mode H passiert viel weniger. Es gibt keinen Logeintrag im FHEM.

Bsp einer Jalousie-Sperren-Abfrage, Teil eines DOIFs, es sind 14 Adressen

Code: [Auswählen]

get KNX_02060..Mode M: Löst 14 Abfragen aus. Laut ETS "schlagen" diese innerhalb von 0,007 Sekunden auf dem Bus auf. Die 14 Antworten starten 0,020 Sekunden nach der ersten Abfrage und brauchen 0,516 Sekunden
Mode H: Eine Abfrage erreicht die ETS. Die ETS antwortet nach 0,057 Sekunden

Auch so hatte ich das Gefühl, dass manche Abfrage nicht ankamen, kann das aber sicher sagen.

Habe es wieder auf Mode M umgestellt. Kann aber jederzeit testen.

[ahermann86]

Hallo Erwin,

1) Funktioniert ein "einzel device Get...." ?

Das resultierende Fenster bleibt zwar leer und man kann "ok" klicken aber das Reading des jeweiligen Devices wird abgefragt und aktualisiert.

2) hast du das KNX_Scan versucht ?

Nein, noch nicht - wo geht das?

3) Gibts im Log Hinweise auf KNXIO Timeouts ? (Mode H)

Ich habe "verbose" auf 5 gesetzt und das aus dem Log kopiert:

Code: [Auswählen]

2023.01.22 01:25:22 4: KNXIO_keepalive - expect ConnectionStateResponse
2023.01.22 01:25:22 5: DevIo_SimpleWrite myKNXGW: 0610020700102f000801000000000000
2023.01.22 01:25:22 5: KNXIO_Read: buf= 0610020800082f00
2023.01.22 01:25:22 5: KNXIO_Read: buf= 061004200017042f9a002900bce0114012280300800c47
2023.01.22 01:25:22 4: KNXIO_ReadH: TunnelRequest received - send Ack and decode. seqcntrRx= 154
2023.01.22 01:25:22 5: DevIo_SimpleWrite myKNXGW: 06100421000a042f9a00
2023.01.22 01:25:22 4: KNXIO_decodeCEMI: src=1.1.64 dst=2/2/40 destaddrType=1 prio=3 hop_count=6 leng=3 data=800c47
2023.01.22 01:25:22 5: KNXIO_decodeCEMI: buf=C01140w022280c47
2023.01.22 01:25:22 4: KNXIO_processFIFO (myKNXGW): buf= C01140w022280c47 Nr_msgs= 1
2023.01.22 01:25:22 5: myKNXGW: dispatch C01140w022280c47
2023.01.22 01:25:22 4: KNX_Parse -enter: IO-name=myKNXGW src=1.1.64 dest=2/2/40 msg=C01140w022280c47
2023.01.22 01:25:22 5: KNXIO_processFIFO (myKNXGW): finished
2023.01.22 01:25:23 5: KNXIO_Read: buf= 061004200017042f9b002900bce011f007040300800000
2023.01.22 01:25:23 4: KNXIO_ReadH: TunnelRequest received - send Ack and decode. seqcntrRx= 155
2023.01.22 01:25:23 5: DevIo_SimpleWrite myKNXGW: 06100421000a042f9b00
2023.01.22 01:25:23 4: KNXIO_decodeCEMI: src=1.1.240 dst=0/7/4 destaddrType=1 prio=3 hop_count=6 leng=3 data=800000
2023.01.22 01:25:23 5: KNXIO_decodeCEMI: buf=C011f0w007040000
2023.01.22 01:25:23 4: KNXIO_processFIFO (myKNXGW): buf= C011f0w007040000 Nr_msgs= 1
2023.01.22 01:25:23 5: myKNXGW: dispatch C011f0w007040000
2023.01.22 01:25:23 4: KNX_Parse -enter: IO-name=myKNXGW src=1.1.240 dest=0/7/4 msg=C011f0w007040000
2023.01.22 01:25:23 5: KNXIO_processFIFO (myKNXGW): finished
2023.01.22 01:25:31 5: KNXIO_Read: buf= 061004200017042f9c002900bce011f0070503008086b6
2023.01.22 01:25:31 4: KNXIO_ReadH: TunnelRequest received - send Ack and decode. seqcntrRx= 156
2023.01.22 01:25:31 5: DevIo_SimpleWrite myKNXGW: 06100421000a042f9c00
2023.01.22 01:25:31 4: KNXIO_decodeCEMI: src=1.1.240 dst=0/7/5 destaddrType=1 prio=3 hop_count=6 leng=3 data=8086b6
2023.01.22 01:25:31 5: KNXIO_decodeCEMI: buf=C011f0w0070586b6
2023.01.22 01:25:31 4: KNXIO_processFIFO (myKNXGW): buf= C011f0w0070586b6 Nr_msgs= 1
2023.01.22 01:25:31 5: myKNXGW: dispatch C011f0w0070586b6
2023.01.22 01:25:31 4: KNX_Parse -enter: IO-name=myKNXGW src=1.1.240 dest=0/7/5 msg=C011f0w0070586b6
2023.01.22 01:25:31 5: KNXIO_processFIFO (myKNXGW): finished
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r02633
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/51
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff11633010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff11633010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r02636
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/54
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff11636010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff11636010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r02637
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/55
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff11637010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff11637010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r0263a
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/58
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff1163a010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff1163a010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r02639
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/57
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff11639010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff11639010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r02632
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/50
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff11632010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff11632010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r02634
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/52
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff11634010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff11634010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_write: started
2023.01.22 01:25:34 5: KNXIO_write: sending r02635
2023.01.22 01:25:34 5: KNXIO_Write: data=00 size=01 acpi=00 src=15.15.241 dst=2/6/53
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 061004200015042f21001100bce0fff11635010000
2023.01.22 01:25:34 4: KNXIO_Write: Mode= H buf=061004200015042f21001100bce0fff11635010000 rc= 0
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 06100421000a042f2100
2023.01.22 01:25:34 5: KNXIO_Read: buf= 061004200015042f9d002e00bce0fff11633010000
2023.01.22 01:25:34 4: KNXIO_ReadH: TunnelRequest received - send Ack and decode. seqcntrRx= 157
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 06100421000a042f9d00
2023.01.22 01:25:34 4: KNXIO_decodeCEMI: src=15.15.241 dst=2/6/51 destaddrType=1 prio=3 hop_count=6 leng=1 data=00
2023.01.22 01:25:34 5: KNXIO_decodeCEMI: buf=C0fff1r0263300
2023.01.22 01:25:34 4: KNXIO_processFIFO (myKNXGW): buf= C0fff1r0263300 Nr_msgs= 1
2023.01.22 01:25:34 5: KNXIO_Read: buf= 061004200015042f9e002900bce011991633010040
2023.01.22 01:25:34 4: KNXIO_ReadH: TunnelRequest received - send Ack and decode. seqcntrRx= 158
2023.01.22 01:25:34 5: DevIo_SimpleWrite myKNXGW: 06100421000a042f9e00
2023.01.22 01:25:34 4: KNXIO_decodeCEMI: src=1.1.153 dst=2/6/51 destaddrType=1 prio=3 hop_count=6 leng=1 data=40
2023.01.22 01:25:34 5: KNXIO_decodeCEMI: buf=C01199p0263300
2023.01.22 01:25:34 5: KNXIO_processFIFO (myKNXGW): dispatch not complete, waiting
2023.01.22 01:25:34 5: myKNXGW: dispatch C0fff1r0263300
2023.01.22 01:25:34 4: KNX_Parse -enter: IO-name=myKNXGW src=15.15.241 dest=2/6/51 msg=C0fff1r0263300
2023.01.22 01:25:34 4: KNXIO_processFIFO (myKNXGW): buf= C01199p0263300 Nr_msgs= 1
2023.01.22 01:25:34 5: myKNXGW: dispatch C01199p0263300
2023.01.22 01:25:34 4: KNX_Parse -enter: IO-name=myKNXGW src=1.1.153 dest=2/6/51 msg=C01199p0263300
2023.01.22 01:25:34 5: KNXIO_processFIFO (myKNXGW): finished
Gruß
Axel

[erwin]

Hi Axel & GammaTwin !

Das resultierende Fenster bleibt zwar leer und man kann "ok" klicken....

Gut, aus KNX-sicht ist damit alles ok. Allerdings scheint ein Problem mit dem automatischen refresh der Webseite zu sein. Der OK dialog kommt nur, wenn FHEMWEB ein Prblem hat, siehe Attribute: longpoll...
bei mir sieht die Seite so aus (für ca. 5 sec):

hast du das KNX_Scan versucht ?

siehe mein posting vom 15.1.2023 hier....

KNXIO Timeouts: Timeout Log msgs kommen auf Loglevel 3, und schauen so aus:

Code: [Auswählen]

2021.12.13 00:00:08.023 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.12.15 13:12:09.045 3: KNXIO_Read: TunnelRequest received: duplicate message received (seqcntr=67) - ack it
2021.12.15 13:12:10.012 3: KNXIO_Read: TunnelRequest received: out of sequence, (seqcntrRx=99, seqcntrTx= 45) - no ack & discard... keine Notwendigkeit verbose hochzusetzen.

@GammaTwin:
Genau für diesen Fall hab ich das KNX_scan cmd gebaut....
Das Problem: lt. KNX-specs sind nicht mehr als 40 Messages/Sekunde auf dem KNX-Bus (TP1) empfohlen.... - dein Beispiel (14 msg / 0.007sec) hochgerechnet ergibt 20000 msg/sec!
Ich glaube nicht, dass die Messages zwischen FHEM und Router verworfen werden, da würden entsprechende Fehlermeldungen im FHEM Log auftauchen....
Im Mode M wirds funktionieren, weil der KNX-Router die multicast msg aktiv abholen muss, und das multicast protoll offensichtlich puffert....

KNX_scan ist ASYNCRON - soll heissen: wenn das command returned, sind die Antworten vom Bus noch nicht da!!! dass gilt allerdings auch für das Get-cmd, nur beim KNX_scan dauert es noch viel länger!!! (0.2 sec pro get ist die Verzögerung )

OT:

Die Sperre der MDT-Aktoren sendet nämlich keine Aktualisierung ....

...kann man evtl. mit ETS parametrierung ändern, siehe ETS Group Address Flag T
l.g.erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin