Modul 00_KNXIO.pm support

Begonnen von erwin, 25 Mai 2022, 14:00:35

Vorheriges Thema - Nächstes Thema

erwin

@EinEinfach:
super das es geklappt hat!

@Markus: den counter gibt es bereits, siehe device internal: <name>_MSGCNT und <name>_TIMESTAMP. Der zählt die empfangenen msg's.
Dasselbe gibts dann nochmal pro KNX-device...
ad knxd loswerden: Du kannst den knxd auch ohne weiteres für deine speziellen Zwecke weiterbetreiben und dennoch mit KNXIO eine direkte Verbindung zum GW aufbauen. Nur nicht FHEM -> GW UND FHEM ->knxd gleichzeitig!!! GW -> knxd und GW -> FHEM gleichzeitig sind kein Problem (bei Mode M aufpassen - siehe mein post v. gestern 14:04).

@Patrik: Falls es nur um die "harten" Fehler geht (=wo msgs verloren gehen), kannst du auch auf den event <name>: disconnected triggern....
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,...

MarkusN

Super, das mit dem internal reicht mir zum monitoren, danke!
Erwin, wie hast du denn dein 1-Wire Netz angebunden? owserver scheint ja aufgrund von delays weniger optimal zu funktionieren. Ich habe aktuell einen USB stick in einem entfernten RaspberryPi stecken welcher über owserver mit FHEM kommuniziert. Hätte am liebsten irgendwas mit MQTT.

erwin

Hi Markus,
re OWServer: ich hab da noch keine wirklich zufriedenstellende Lösung.....
Tatsache ist, dass trotz nonblocking die Abfrage von 18B20 knapp eine Sekunde FHEM blockiert..... Ich hab OW via I2C angebunden. - DS2480 wenn ich mich richtig erinnere...
Ich hab mir damit geholfen, die resolution  der 18x20's auf 10 zu stellen (insgesamt 8Stück), damit komm ich auf < 500ms und das passt dann fürs KNXIO mode H.
l.g. erwin
PS: irgendwo hab ich was von OW2MQTT gelesen, aber (noch) nicht weiterverfolgt....
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,...

MarkusN

Ich habe jetzt mal von KNX/TUL via KNXD auf KNXIO im H-Modus gewechselt.

Die Definition sieht so aus:
defmod KNX KNXIO H 10.0.2.142:3671 0.0.3
attr KNX icon knx
attr KNX room 25_KNX->99_Interface


Verbindung steht, im eventMonitor sehe ich auch die Events für alle definierten Devices, und das deckt sich auch mit dem was ich im Gruppenmonitor der ETS sehe.
Was nicht so gut funktioniert ist senden. Wenn ich eine gewisse Zeit (Minuten) nichts auf den Bus sende, und dann ein Gerät schalte, sehe ich zwar im eventMonitor dass der Befehl rausgeht, aber im Gruppenmonitor der ETS taucht nichts auf, und das entsprechende Gerät schaltet natürlich auch nicht. Manchmal passiert das auch noch ein bis zwei mal direkt danach, aber irgendwann sehe ich die Telegramme auf dem Bus und ab dann geht auch alles durch. Bis einige Zeit wieder nichts gesendet wird. Es sieht aus als würde FHEM die Verbindung zu meinem Interface (MDT SCN-IP000.03) verlieren, was aber nicht stimmt da ich die ankommenden Telegramme in FHEM ohne Unterbrechung sehen kann, es scheint also nur die sendende Richtung zu betreffen.
Irgendwelche Ideen?

erwin

Hi Markus,
3 Ideen dazu:
1) Gibts im Log - auf Level3 irgendwelche Messages ? (Timeout / duplicate packets.... /disconnect/connect...)
2) stimmt das reading IODev im betroffenen KNX-device
3) stimmt 0.0.3 mit dem im GW definierten Tunnel-Adressen überein?

Es gibt ein keepalive zwischen KNXIO und dem GW, wenn das nicht funktioniert, gibts was im Log!
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,...

MarkusN

Zitat von: erwin am 03 Juni 2022, 18:39:29
1) Gibts im Log - auf Level3 irgendwelche Messages ? (Timeout / duplicate packets.... /disconnect/connect...)

Ja, ich kann in der Tat Meldungen in den Fällen wo nichts durchgeht sehen, habe dafür das KNX device auf verbose 3 gesetzt, ich denke das ist der richtige Weg, oder?

2022.06.03 18:56:50 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2022.06.03 18:56:49 3: KNXIO_TunnelRequestTO hit - attempt resend
2022.06.03 18:52:06 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2022.06.03 18:52:04 3: KNXIO_TunnelRequestTO hit - attempt resend
2022.06.03 18:49:33 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2022.06.03 18:49:32 3: KNXIO_TunnelRequestTO hit - attempt resend


Zitat von: erwin am 03 Juni 2022, 18:39:29
2) stimmt das reading IODev im betroffenen KNX-device

Ja die passen alle, der Einfachheit halber hat das KNX Device auch den exakt gleichen Namen behalten.

Zitat von: erwin am 03 Juni 2022, 18:39:29
3) stimmt 0.0.3 mit dem im GW definierten Tunnel-Adressen überein?

Okay, hier muss ich passen. Ich habe nie richtig verstanden wie ich das konfigurieren muss. An welcher Stelle würde ich das konfigurieren, und muss es in der selben Linie wie meine restliche Installation sein? Habe jedenfalls nur ein IP Interface, keinen Router.

erwin

Na da haben wir ja das Problem,
irgendwas in deinem FHEM ist zu langsam/blockiert für ???ms ... - nach einem disconnect dauerts ein paar sekunden, bis die Verbindung wieder aufgebaut wird! In dieser Zeit geht nix raus oder rein....
schon mal apptime laufen lassen?
Falls du das nicht unmittelbar lösen kannst, würde ich auf mode T gehen - mit knxd.
ad phy-addr.: schau mal in den internals unter PhyAddr da stehts (in Hex codiert) - poste einfach ein list device!
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,...

MarkusN

Zitat von: erwin am 03 Juni 2022, 19:12:35
Na da haben wir ja das Problem,
irgendwas in deinem FHEM ist zu langsam/blockiert für ???ms ... - nach einem disconnect dauerts ein paar sekunden, bis die Verbindung wieder aufgebaut wird! In dieser Zeit geht nix raus oder rein....
schon mal apptime laufen lassen?
Falls du das nicht unmittelbar lösen kannst, würde ich auf mode T gehen - mit knxd.
ad phy-addr.: schau mal in den internals unter PhyAddr da stehts (in Hex codiert) - poste einfach ein list device!

Bezüglich der Physikalischen Adresse habe ich mich mal auf meinem IP interface angemeldet und FHEM eine der Tunneling Adressen gegeben die dort angegeben ist (15.15.241). Angehängt habe ich noch ein screenshot vom Webinterface.


Internals:
   DEF        H 10.0.2.142:3671 15.15.241
   DeviceName 10.0.2.142:3671
   FD         29
   FUUID      629a2275-f33f-b36e-3cb5-b5253492dfe1a509
   KNX_MSGCNT 393
   KNX_TIME   2022-06-03 19:23:17
   NAME       KNX
   NR         345
   PARTIAL   
   PhyAddr    0fff1
   STATE      connected
   TYPE       KNXIO
   eventCount 43
   model      H
   nextOpenDelay 30
   KNXIOhelper:
     CCID       16
     FIFOMSG    C0110aw032050c06
     FIFOTIMER  0
     SEQUENCECNTR 3
     SEQUENCECNTR_W 0
     FIFO:
   READINGS:
     2022-06-03 19:22:51   state           connected
Attributes:
   icon       knx
   room       25_KNX->99_Interface
   verbose    3


Bezüglich dem timeout/block:
Ich bin mir ziemlich sicher dass dem nicht so ist. Bis auf ein paar Ausreisser (einmal alle paar Stunden, z.B. echodevice oder octoprint) habe ich keine delays über 200ms. Um das sicherzustellen nutze ich apptime und freezemon (letzerer ist auf freezes ab 0.5s konfiguriert). Auch sonst sollte performance kein Problem sein (FHEM läuft auf proxmox als LXC container), das Netzwerk schließe ich auch aus (alles direkt verkabelt, kein WiFi, Powerline oder sonstige Bastellösung).

PatrickR

Hi!
Zitat von: erwin am 03 Juni 2022, 10:03:49
@Patrik: Falls es nur um die "harten" Fehler geht (=wo msgs verloren gehen), kannst du auch auf den event <name>: disconnected triggern....
Auf dem KNXIO-Device? Da habe ich schon einen Trigger, der bislang ruhig ist. Betrifft das ein- und ausgehende verlorene Nachrichten?

Bekomme aktuell im Log nur duplicate messages, die wenn ich Dich richtig verstehe, harmlos sind, da die Acks nur zu spät kamen.

2022.06.03 06:12:52.129 3: KNXIO_Read: TunnelRequest received: duplicate message received (seqcntr=213) - ack it
2022.06.03 06:30:20.844 3: KNXIO_Read: TunnelRequest received: duplicate message received (seqcntr=217) - ack it
2022.06.03 08:57:51.999 3: KNXIO_Read: TunnelRequest received: duplicate message received (seqcntr=159) - ack it
2022.06.03 09:46:51.940 3: KNXIO_Read: TunnelRequest received: duplicate message received (seqcntr=210) - ack it
2022.06.03 20:36:47.401 3: KNXIO_Read: TunnelRequest received: duplicate message received (seqcntr=121) - ack it


Patrick
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

erwin

Hi Patrick,
JA, auf dem KNXIO-device.  disconnect kann bei ein- u. aus-gehenden msgs passieren.
Und ja, in der Häufigkeit ist das harmlos, heisst nur, dass das GW eine msg nochmals geschickt hat, weil es nicht rechtzeitig ein Ack von FHEM bekommen hat. (obwohl FHEM die 1ste msg bekommen und verarbeitet hat.....)
da gibts KEIN disconnect, erst falls das Ack auf die duplicate msg auch nicht ankommt, dann sendet das GW einen disconnect request....
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,...

erwin

@Markus:
ZitatPhyAddr    0fff1
ergibt 15/15/241 - das stimmt also jetzt mit dem GW-Settings überein!
Was mir aufgefallen ist - in deinem screenshot:

individual-address 15/15/255 -  das ist lt. KNX-specs der wert für nicht konfiguriert, und soll nicht für normalen Betrieb verwendet werden.
Ob das was mit deinen Problemen zu tun hat, weiß ich allerdings nicht.
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,...

erwin

#26
Hi KNX-Community!
Eine neue Version, keine funktionellen Änderungen!
Es gibt ein neues Internal: SVN - zeigt SVN-id und commit datum, falls das wer ausser mir noch brauchen soltte...
Es ist sehr ruhig hier, das kann 2 Ursachen haben:
1) Das Ding verwendet niemand...  ;D
2) Es gibt keine Probleme / Fragen!

schönen Sommer !
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,...

PatrickR

lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

MarkusN

Bei mir läuft es auch ohne Probleme, allerdings nur im TCP mode. Der Host-Mode macht nach wie vor Probleme

MarkusN

Habe heute morgen mein FHEM geupdated und danach konnte ich nichts mehr auf den Bus senden. Sowohl TCP mode über knxd als auch der Hostmode direkt ans interface hat nicht mehr funktioniert. Bin wieder zurück auf die Version vom 25.05.

Konkret sah das Log so aus mit der neuen Version (das KNXIO Device sagte jederzeit "connected"):
2022.07.07 09:17:42 3: KNXIO_write called while not connected! Msg: w0320800079e lost
2022.07.07 09:17:42 3: KNXIO_write called while not connected! Msg: w0340100442a lost
2022.07.07 09:16:25 3: KNXIO_write called while not connected! Msg: w0110100 lost
2022.07.07 09:16:25 3: KNXIO_write called while not connected! Msg: w0110101 lost
2022.07.07 09:16:24 3: KNXIO_write called while not connected! Msg: w0110100 lost
2022.07.07 09:16:23 3: KNXIO_write called while not connected! Msg: w0110101 lost
2022.07.07 09:15:56 3: KNXIO_write called while not connected! Msg: w0110000 lost
2022.07.07 09:15:56 3: KNXIO_write called while not connected! Msg: w0110100 lost
2022.07.07 09:15:56 3: KNXIO_write called while not connected! Msg: w0110101 lost
2022.07.07 09:15:55 3: KNXIO_write called while not connected! Msg: w0110001 lost
2022.07.07 09:15:55 3: KNXIO_write called while not connected! Msg: w0110000 lost
2022.07.07 09:15:54 3: KNXIO_write called while not connected! Msg: w0110100 lost
2022.07.07 09:15:52 3: KNXIO_write called while not connected! Msg: w0110101 lost
2022.07.07 09:15:51 3: KNXIO_write called while not connected! Msg: w0110001 lost
2022.07.07 09:15:31 3: KNXIO_write called while not connected! Msg: w032080007bc lost
2022.07.07 09:15:31 3: KNXIO_write called while not connected! Msg: w03401003fb7 lost
2022.07.07 09:15:13 3: KNXIO_write called while not connected! Msg: w015000002 lost
2022.07.07 09:14:32 3: KNXIO_write called while not connected! Msg: w0111b00 lost
2022.07.07 09:13:52 3: KNXIO_write called while not connected! Msg: w0110000 lost
2022.07.07 09:13:51 3: KNXIO_write called while not connected! Msg: w0110100 lost
2022.07.07 09:13:51 3: KNXIO_write called while not connected! Msg: w0110101 lost
2022.07.07 09:13:51 3: KNXIO_write called while not connected! Msg: w0110001 lost
2022.07.07 09:13:50 3: KNXIO_write called while not connected! Msg: w0110000 lost
2022.07.07 09:13:50 3: KNXIO_write called while not connected! Msg: w0110100 lost
2022.07.07 09:13:50 3: KNXIO_write called while not connected! Msg: w0110101 lost
2022.07.07 09:13:49 3: KNXIO_write called while not connected! Msg: w0110001 lost
2022.07.07 09:13:49 3: KNXIO_write called while not connected! Msg: w0110000 lost
2022.07.07 09:13:48 3: KNXIO_write called while not connected! Msg: w0110100 lost
2022.07.07 09:13:47 3: KNXIO_write called while not connected! Msg: w0110101 lost
2022.07.07 09:13:46 3: KNXIO_write called while not connected! Msg: w0110001 lost