Modul 00_KNXIO.pm support

[StefanG]

Hi Erwin,

danke für Dein Feedback!

Ich mache mit notify folgendes:

Code Auswählen Erweitern

Internals:
   DEF        KNXD:(CONNECTED|INITIALIZED) { knxStarted($EVENT) }
   FUUID      658c735f-f33f-2679-1718-e5016136e52bb75f
   NAME       notify_knx_started
   NR         431
   NTFY_ORDER 50-notify_knx_started
   REGEXP     KNXD:(CONNECTED|INITIALIZED)
   STATE      2024-01-14 21:50:57
   TRIGGERTIME 1705265457.06469
   TYPE       notify
   READINGS:
     2024-01-14 21:37:08   state           active
     2024-01-14 21:50:57   triggeredByDev  KNXD
     2024-01-14 21:50:57   triggeredByEvent CONNECTED
Attributes:
   room       Allgemein


Code Auswählen Erweitern

sub knxStarted($) {
  my ($event) = @_;
 
  if ($event eq "CONNECTED") {
    sendTelegram("KNXD gestartet ($event/Schritt 2) ...");
  } elsif ($event eq "INITIALIZED") {
    sendTelegram("KNXD gestartet ($event/Schritt 3) ...");

    updateKNXPerSecond();

    fhem("set InBetrieb_Dimmaktor off");
    fhem("set InBetrieb_Glastaster off");
    fhem("set InBetrieb_IPRouter off");
    fhem("set InBetrieb_Jalousieaktor off");
    fhem("set InBetrieb_LEDController off");
    fhem("set InBetrieb_Schaltaktor off");
  }
}

Im Erfolgsfall kommt CONNECTED und INITIALIZED, im Fehlerfall nur CONNECTED wie folgt:

Code Auswählen Erweitern

2024.01.14 16:22:03.244 3: KNXD [KNXIO_Define 244]: opening mode=T
2024.01.14 16:22:03.257 3: INIT: FB4040_debugLog
2024.01.14 16:22:03.272 3: [SamsungAV] SamsungLED defined with host: 192.168.0.21 port: 55000
2024.01.14 16:22:15.515 3: BOSEST: BOSE SoundTouch v2.2.1
2024.01.14 16:22:15.542 3: RokuBuero: ssdp responder started
2024.01.14 16:22:15.542 3: RokuBuero: listener started
2024.01.14 16:22:15.542 3: RokuWZ: ssdp responder started
2024.01.14 16:22:15.542 3: RokuWZ: listener started
2024.01.14 16:22:15.561 3: freezemon defined FreezeMon freezemon
2024.01.14 16:22:15.561 3: [Freezemon] FreezeMon: Wrapping Log3
2024.01.14 16:22:15.564 1: Including ./log/fhem.save
2024.01.14 16:22:15.597 2: Alexa: starting alexa-fhem: /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg -a xx:xx -s
2024.01.14 16:22:15.598 3: Alexa: starting
2024.01.14 16:22:15.603 3: Alexa: using logfile: ./log/alexa-2024-01-14.log
2024.01.14 16:22:15.604 3: Opening GristPresenceBT device 127.0.0.1:5222
2024.01.14 16:22:15.605 3: GristPresenceBT device opened
2024.01.14 16:22:15.606 3: Opening GristPresenceBTKueche device 10.0.1.13:5111
2024.01.14 16:22:15.609 3: GristPresenceBTKueche device opened
2024.01.14 16:22:15.610 3: Opening GristPresenceBTWZ device 10.0.1.14:5111
2024.01.14 16:22:15.613 3: GristPresenceBTWZ device opened
2024.01.14 16:22:15.614 3: harmony: starting discovery
2024.01.14 16:22:15.614 3: harmony: sending discovery
2024.01.14 16:22:15.615 3: harmony: sending discovery
2024.01.14 16:22:15.615 3: Opening KeeperPresenceBT device 127.0.0.1:5222
2024.01.14 16:22:15.616 3: KeeperPresenceBT device opened
2024.01.14 16:22:15.707 2: PhilipsHue: autocreate: created 0/0/0 devices (ignored 0/0/4)
2024.01.14 16:22:15.709 3: Opening PolarPresenceBT device 127.0.0.1:5222
2024.01.14 16:22:15.710 3: PolarPresenceBT device opened
2024.01.14 16:22:15.714 3: RokuBuero: ssdp responder stoped
2024.01.14 16:22:15.714 3: RokuBuero: ssdp responder started
2024.01.14 16:22:15.717 3: RokuBuero: listener stoped
2024.01.14 16:22:15.719 3: RokuBuero: listener started
2024.01.14 16:22:15.719 3: RokuWZ: ssdp responder stoped
2024.01.14 16:22:15.719 3: RokuWZ: ssdp responder started
2024.01.14 16:22:15.722 3: RokuWZ: listener stoped
2024.01.14 16:22:15.724 3: RokuWZ: listener started
2024.01.14 16:22:15.724 3: [SamsungAV] device SamsungLED initialising....
2024.01.14 16:22:15.724 3: Opening SeiliPresenceBT device 127.0.0.1:5222
2024.01.14 16:22:15.726 3: SeiliPresenceBT device opened
2024.01.14 16:22:15.728 3: Opening SeimaPresenceBT device 127.0.0.1:5222
2024.01.14 16:22:15.730 3: SeimaPresenceBT device opened
2024.01.14 16:22:15.735 3: sendTelegram: FHEM-System neu gestartet (INITIALIZED/Schritt 1) ...
2024.01.14 16:22:15.748 2: [Freezemon] FreezeMon: ready to watch out for delays greater than 1 second(s)
2024.01.14 16:22:15.748 3: NTFY return:  sysmon:Initialized
2024.01.14 16:22:15.748 0: Featurelevel: 6.2
2024.01.14 16:22:15.748 0: Server started with 349 defined entities (fhem.pl:28227/2023-11-29 perl:5.034000 os:linux user:fhem pid:1571796)
2024.01.14 16:22:15.768 3: telnetForBlockingFn_1705245735.76591: port 39433 opened
2024.01.14 16:22:15.848 3: sendTelegram: KNXD gestartet (CONNECTED/Schritt 2) ...
2024.01.14 16:22:15.963 1: Velux: Can't connect to 192.168.0.12:51200: 192.168.0.12: No route to host (113)
2024.01.14 16:22:15.968 3: KNXD [KNXIO_handleConn 928]: initial-connect
2024.01.14 16:22:16.037 2: AttrTemplates: got 260 entries
2024.01.14 16:22:16.173 3: [FBWLAN450E | 0000 | 128.07.15 | API_Check_Run.2570] - BASIC:API luaQuery call responded with: 403 Forbidden
2024.01.14 16:22:16.364 3: [FBWLAN450E | 0000 | 128.07.15 | API_Check_Run.2593] - BASIC:API luaData call responded with: 403 Forbidden
2024.01.14 16:22:16.542 2: PhilipsHue: autocreate: created 0/0/0 devices (ignored 0/0/4)
2024.01.14 16:22:18.785 3: sendTelegram: SamsungLED: absent
2024.01.14 16:22:22.494 1: KNXD [KNXIO_Read 284]: no data - disconnect
2024.01.14 16:22:22.495 1: KNXD [KNXIO_disconnect 1060]: disconnected, waiting to reappear
2024.01.14 16:22:33.133 3: sendTelegram: KNXD gestartet (CONNECTED/Schritt 2) ...
2024.01.14 16:22:33.138 3: KNXD [KNXIO_handleConn 923]: connected
2024.01.14 16:22:42.748 1: KNXD [KNXIO_Read 284]: no data - disconnect
2024.01.14 16:22:42.748 1: KNXD [KNXIO_disconnect 1060]: disconnected, waiting to reappear
2024.01.14 16:22:47.621 3: BOSEST: BoseRec, new IP (192.168.0.22)
2024.01.14 16:22:49.912 3: BOSEST: BoseRec, WebSocket connection succeed.
2024.01.14 16:22:53.443 3: sendTelegram: KNXD gestartet (CONNECTED/Schritt 2) ...
2024.01.14 16:22:53.449 3: KNXD [KNXIO_handleConn 923]: connected
2024.01.14 16:23:02.999 1: KNXD [KNXIO_Read 284]: no data - disconnect
2024.01.14 16:23:02.999 1: KNXD [KNXIO_disconnect 1060]: disconnected, waiting to reappear
2024.01.14 16:23:13.122 3: sendTelegram: KNXD gestartet (CONNECTED/Schritt 2) ...
2024.01.14 16:23:13.129 3: KNXD [KNXIO_handleConn 923]: connected
2024.01.14 16:23:23.141 1: KNXD [KNXIO_Read 284]: no data - disconnect
2024.01.14 16:23:23.141 1: KNXD [KNXIO_disconnect 1060]: disconnected, waiting to reappear
2024.01.14 16:23:34.006 3: sendTelegram: KNXD gestartet (CONNECTED/Schritt 2) ...
2024.01.14 16:23:34.011 3: KNXD [KNXIO_handleConn 923]: connected

Der Root-Cause ist ein DHCP-Lease-Problem, das ich zwischenzeitlich gelöst habe. Der KNX-IP-Router war dann einfach nicht erreichbar und KNXD hat immer wieder neu gestartet. Trotzdem wäre es m.E. gut, wenn der FHEM/KNX-Start toleranter gegen Verbindungsprobleme wäre. Ich hätte jetzt noch daran gedacht, $init_done abzufragen, d.h. wenn $init_done == 0, dann CONNECTED ignorieren, ansonsten eine fixe Zeitspanne warten und dann KNX-Kommunikation starten, sofern kein disconnected zwischenzeitlich auftritt. Ist natürlich nur ein unschöner Workaround, sofern er überhaupt funktioniert.

Freue mich jedenfalls auf Dein Feedback, danke nochmals!

LG
Stefan

Edit: $init_done-Workaround funktioniert nicht, weil das bereits 1 ist, wenn CONNECTED das erste Mal aufgerufen wird. Ich könnte nur generell bei jedem CONNECTED 30 Sek. warten (das macht anscheinend INITIALIZED beim FHEM-Start auch), bevor ich was auf den Bus schreibe (sofern nicht ein DISCONNECT/disconnected zwischenzeitlich auftritt).

[erwin]

Hi Stefan,
der erste Teil des Problems ist gefunden:
versuche im notify und im sub knxstarted NICHT 'CONNECTED' sondern 'connected' zu schreiben!
Das GROSSGESCHRIEBENE kommt aus dem Modul DevIO, kann ich nicht ändern, einfach ignorieren,
das kleingeschriebene kommt aus KNXIO - und wäre richtig! - siehe cmd-ref

Den zweiten Teil des Problems schau ich mir morgen an. (..falls das erste connect nach 30 sekunden nicht erfolgreich ist...)
PS: völlig richtig, init_done hilft hier nicht - das ist zeitgleich mit global:INITIALIZED gesetzt und daher für diesen Zweck zu früh!

d.h. wenn $init_done == 0, dann CONNECTED ignorieren, ansonsten eine fixe Zeitspanne warten und dann KNX-Kommunikation starten, sofern kein disconnected zwischenzeitlich auftritt.

Fast genauso funktioniert die INITIALIZED/connected Logik im KNXIO Modul, einziger Unterschied:
das erste connected wird ignoriert, 30 Sekunden gewartet, nochmal gecheckt ob reading state noch immer connected ist- und dann INITIALIZED ausgelöst!
l.g.erwin

[StefanG]

Hi Erwin,

danke für das Feedback, soweit verstanden! Damit könnte ich notfalls auch selber einen Timer basteln.

Eine Frage noch: Wenn die kleingeschriebenen connected/disconnected die vom KNXIO sind, warum wird dann beim Disconnecten kein disconnected-Event ausgelöst? Den bekomme ich nur beim Runterfahren von FHEM. D.h. beim Connecten zum KNXIO kommt CONNECTED, gefolgt von connected. Beim Disconnecten kommt aber nur DISCONNECTED. Wenn ich das sauber lösen will, muss ich ja bei zwischenzeitlichen Unterbrechungen auch die KNX-Kommunikation stoppen und irgendeinen Alert ausgeben. Dass generell der Root-Cause zu lösen ist, ist klar.

Siehe hier:

Code Auswählen Erweitern

2024-01-20_13:22:41 global DEFINED at_updateKNXPerSecond
2024-01-20_13:22:41 global ATTR at_updateKNXPerSecond room Allgemein
2024-01-20_13:22:42 KNXD CONNECTED
2024-01-20_13:22:42 Telegram msg 2024-01-20 13:22:42: KNXD gestartet (CONNECTED/Schritt 2) ...
2024-01-20_13:22:42 KNXD connected
2024-01-20_13:22:42 Telegram msg 2024-01-20 13:22:42: KNXD gestartet (connected) ...
2024-01-20_13:22:42 Telegram sentMsgResult: SUCCESS
2024-01-20_13:22:42 Telegram sentMsgId: 440969

Aber hier:

Code Auswählen Erweitern

2024-01-20_13:22:52 FBWLAN450E WLAN: on gWLAN: on
2024-01-20_13:22:52 FBWLAN450E retStat_lastReadout: 64 values captured in 0.37 s
2024-01-20_13:22:52 KNXD DISCONNECTED
2024-01-20_13:22:52 Telegram msg 2024-01-20 13:22:52: KNXD gestoppt (DISCONNECTED) ...
2024-01-20_13:22:52 Telegram sentMsgResult: SUCCESS
2024-01-20_13:22:52 Telegram sentMsgId: 440971
2024-01-20_13:22:52 Telegram sentMsgPeerId: 6001913647
2024-01-20_13:22:53 PiZeroPresence present

lg
Stefan

[erwin]

Hi Stefan!

Damit könnte ich notfalls auch selber einen Timer basteln.

Das versteh ich nicht. Wenn du NICHT auf CONNECTED triggerst, sondern nur auf INITIALIZED und connected, brauchst du keinen zusätzlichen timer, um z.B: set-cmds zu schicken!

Es stimmt, ein disconnected event wird erst geschickt, falls die Kommunikation absolt tot ist, nicht solange noch recovery versucht wird... es sollte allerdings ein connected event passieren, sobald die Verbindung wieder steht!
Das zweite Problem (falls der erste conn-Versuch schiefgeht..., KEIN INITALIZED geschickt wird), wird mit dem update heute gefixt.
Sorry, ich hatte verstanden, das der root-cause bei dir gefixt ist, dasshalb hatte ich keine Prio mit dem update....
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

[erwin]

Hi KNX-Community!
ich bin gerade am testen von FHEM im Docker (noch nicht die Version 4).
Dazu hab ich zum Thema Docker & Multicast bzw. knxd im Docker das Wiki ergänzt.
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

[erwin]

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

l.g. erwin