[fixed] Dispatch-Funktion bei Signalduino u. IT V3 mit freezes

[KölnSolar]

Verstehe ich auch so. Aber dann ist das für mich ein Konstruktionsfehler in der Dispatch-Funktion. Es kann ja nicht sein, dass ein Client-Modul nicht zurückgeben kann "da stimmt was nicht mit der message", ohne dass das .clientArray gelöscht und (überflüssigerweise) bei der nächsten message wieder neu aufgebaut wird(was dann in meinem Fall und performanceschwachen Systemen zu freezes führt; insbesondere beim Signalduino, da es diese große Menge an client-Modulen gibt).

Ich trau mir aber auch nicht zu sämtliche (sinnvollen) Fälle bei 2-stufigen Modulen abschätzen zu können.

Ist es ein Workaround für den Signalduino per whitelist die client-Module zu reduzieren ?  Ich vermute aber nicht. 

[Beta-User]

Na ja, vermutlich hat zum einen keiner damit gerechnet, dass es mal so viele Client-Module werden könnten wie es heute bei Signalduino der Fall ist, und zum anderen ist es die Frage, ob es sinnvoll ist, in diesem Fall hier mit den "zu kurzen" Messages "nichts" zurückzugeben. Daher der Vorschlag, einen Fehler am IO zu melden...
Dort kann man ja durchaus ein Reading wie "faulty_it_message" - "i...." setzen und dann das IO als getriggertes Device zurückgeben (wenn sicher ist, dass es wirklich eine kaputte Message ist und kein anderes Modul was damit anfängt).

[Ralf9]

Wird demnach, wenn anstatt return "" ein return "beliebiger Text" zurückgegeben wird, das .clientArray nicht gelöscht?

[Beta-User]

Nope. Ein gültiger Device-Name muss es sein!

Nach meinem Verständnis ist der Prozess nur "fertig", wenn (mind.) ein gültiger Devicename im Rückgabe-Array steht (es können auch mehrere Devices sowie zusätzlich [NEXT] zurückgegeben werden).

[KölnSolar]

Daher der Vorschlag, einen Fehler am IO zu melden...

Finde ich nicht verkehrt. Ich probier mal was passiert...

[KölnSolar]

das sieht gut aus. Kein delete, keine freezes mehr. Der Fehler wird wie gehabt gelogged und im Signalduino steht die "fehlerhafte" message unter dmesg.

Code Auswählen Erweitern

2022.01.10 16:26:30 3: Sduino IT: IT_V3_d892149 on->on
2022.01.10 16:26:30 3: Sduino IT: IT_V3_c092149 on->on
2022.01.10 16:26:31 3: Sduino IT: IT_V3_d892149 on->on
2022.01.10 16:26:34 3: Sduino IT: IT_V3_d892149 on->off
2022.01.10 16:26:34 3: Sduino IT: IT_V3_d892145 off->off
2022.01.10 16:26:59 5: UPNPController: try to renew subscriptions for services, device UPNP_Controller
2022.01.10 16:27:18 3: Sduino: SD_WS_Parse SD_WS_84_TH_2 - ERROR temperature -196.6
2022.01.10 16:27:18 3: Sduino: SD_WS_Parse SD_WS_84_TH_2 - ERROR temperature -196.6
2022.01.10 16:27:19 3: Sduino: SD_WS_Parse SD_WS_84_TH_2 - ERROR temperature -196.6
2022.01.10 16:27:19 3: Sduino: SD_WS_Parse SD_WS_84_TH_2 - ERROR temperature -196.6
2022.01.10 16:27:59 5: UPNPController: try to renew subscriptions for services, device UPNP_Controller
2022.01.10 16:28:46 3: Sduino IT: IT_V3_d892149 off->on
2022.01.10 16:28:46 3: Sduino IT: message "i569A56596559969" (16) too short!
2022.01.10 16:28:47 3: Sduino IT: IT_V3_3624856 off->off
2022.01.10 16:28:47 3: Sduino IT: IT_V3_d892149 on->on
2022.01.10 16:28:47 3: Sduino IT: message "i569A56596559969" (16) too short!
2022.01.10 16:28:48 4: UPNPDevice: heartbeat to be called next in 1800 s deviceManager
2022.01.10 16:28:48 3: Sduino IT: IT_V3_d892145 off->on
2022.01.10 16:28:48 3: Sduino IT: IT_V3_d892149 on->on
2022.01.10 16:28:48 2: Sduino IT: IT_V3_d252149 (0001101001001010010000101001001) not defined (Address: 00011010010010100100001010 Group: 0 Unit: 1001 Switch code: 1)
2022.01.10 16:28:48 4: autocreate: received 1 event(s) for 'IT 00011010010010100100001010 0 1001' during the last 30 seconds
2022.01.10 16:28:48 4: autocreate: ignoring event for 'IT 00011010010010100100001010 0 1001': at least 2 needed
2022.01.10 16:28:59 5: UPNPController: try to renew subscriptions for services, device UPNP_Controller
2022.01.10 16:29:08 3: Sduino IT: IT_V3_d892149 on->off
2022.01.10 16:29:08 3: Sduino IT: message "i569A56596559959" (16) too short!
2022.01.10 16:29:09 3: Sduino IT: IT_V3_3624852 off->off
2022.01.10 16:29:09 3: Sduino IT: IT_V3_d892145 on->off
2022.01.10 16:29:09 2: Sduino IT: IT_V3_c292149 (0001100001010010010000101001001) not defined (Address: 00011000010100100100001010 Group: 0 Unit: 1001 Switch code: 0)
2022.01.10 16:29:09 4: autocreate: received 1 event(s) for 'IT 00011000010100100100001010 0 1001' during the last 30 seconds
2022.01.10 16:29:09 4: autocreate: ignoring event for 'IT 00011000010100100100001010 0 1001': at least 2 needed
2022.01.10 16:29:09 3: Sduino IT: IT_V3_d892149 off->off
2022.01.10 16:29:10 3: Sduino IT: message "i569A56596559959" (16) too short!
2022.01.10 16:29:10 3: Sduino IT: IT_V3_3624852 off->off
2022.01.10 16:29:10 3: Sduino IT: IT_V3_d892145 off->off
2022.01.10 16:29:10 3: Sduino IT: IT_V3_d892149 off->off
2022.01.10 16:29:56 3: Sduino: SD_WS_Parse SD_WS_84_TH_2 - ERROR temperature -196.6
2022.01.10 16:29:57 3: Sduino: SD_WS_Parse SD_WS_84_TH_2 - ERROR temperature -196.6
2022.01.10 16:29:58 3: Sduino: SD_WS_Parse SD_WS_84_TH_2 - ERROR temperature -196.6
2022.01.10 16:29:59 3: Sduino: SD_WS_Parse SD_WS_84_TH_2 - ERROR temperature -196.6
2022.01.10 16:29:59 3: Sduino: SD_WS_Parse SD_WS_84_TH_2 - ERROR temperature -196.6


[Ralf9]

Daher der Vorschlag, einen Fehler am IO zu melden...

Mir ist nicht klar wie das gemacht wird

[Beta-User]

Mir ist nicht klar wie das gemacht wird

gemeint war: readings...Update() für einen "im Prinzip beliebigen" Reading-Namen und -Wert verwenden, dabei aber eben kein vorhandenes IT-Device (das ja nicht bestimmt werden kann) adressieren, sondern das IODev, und dann den Namen des IODev aus Dispatch() zurückgeben (sonst weiß fhem.pl nicht, dass es dort ein Event gegeben hat).

[KölnSolar]

Ähmm, ich habs einfacher gemacht. Anstatt dem

Code Auswählen Erweitern

return undef;ein

Code Auswählen Erweitern

return $ioname;
Jetzt erst einmal nur dort, wo ".... too short" gelogged wird. Könnte man dann aber überall machen, wo das Modul einen "Fehler" erkennt und deshalb "return undef" zurückgibt.

[Beta-User]

...so geht's anscheinend auch...

Meinereiner hätte das Modul schon lange gepackaged und dann keine Schmerzen, sowas in eine eigene Funktion umzuleiten, mit der man dann das Logging auch abhängig von den verbose-Einstellungen am IO machen kann usw. .

Könnte man dann aber überall machen, wo das Modul einen "Fehler" erkennt und deshalb "return undef" zurückgibt.

Prinzipiell sollte man sich mAn. schon individuell ansehen, was der eigentliche Schmerz ist. Wenn es wirklich (!) kein Modul geben kann, das dafür zuständig ist, mag das angehen, aber der Mechanismus an sich ist schon sinnvoll, bei Schwierigkeiten wieder "bei Adam und Eva" anzufangen.

[Ralf9]

Ich hab in meinem Testsystem auch mal in die fhem.pl die beiden "SYSTEM" log Ausgaben eingebaut.

Bei mir reichts, wenn ich im IT-Modul

Code Auswählen Erweitern

return undef;
durch dies ersetze

Code Auswählen Erweitern

return "";

[KölnSolar]

Mein Testsystem ist nun wieder relativ freeze free. Wie gehen wir weiter vor ? Hier noch 2 seltene freezes, weil ich return $ioname; nur an der einen Stelle eingebaut habe:

Code Auswählen Erweitern

2022.01.11 02:00:54.092 3: Sduino IT: For autocreate please use the on button.
2022.01.11 02:00:54.094 2: SYSTEM : clientArray deleted

Code Auswählen Erweitern

2022.01.11 06:51:14.820 4: SIGNALduino_unknown Sduino Protocol:19 | To help decode or debug, please add u19! (attr Sduino development u19)
2022.01.11 06:51:14.820 4: Unknown, please report2022.01.11 06:51:14.822 2: SYSTEM : clientArray deleted

Prinzipiell sollte man sich mAn. schon individuell ansehen, was der eigentliche Schmerz ist. Wenn es wirklich (!) kein Modul geben kann, das dafür zuständig ist, mag das angehen, aber der Mechanismus an sich ist schon sinnvoll, bei Schwierigkeiten wieder "bei Adam und Eva" anzufangen.

Sehe ich anders. Über die Client- u. Match-list ist ein Modul "bewusst" zugeordnet. Wenn dann eine message aus welchen Gründen als "nicht verarbeitbar" verworfen werden soll, macht es herzlich wenig Sinn, eine als fehlerhaft erkannte message von einem anderen Modul verarbeiten zu lassen. Kann dann ja auch dort nur "nicht verarbeitbar sein".

Kennst Du einen Fall, wo das client-Modul per Client- u. Match-list zugeordnet ist, das client-Modul den Fall feststellt "Fehlerhaft ist die message nicht, aber wohl doch nicht für mich. Lass mal andere ran" ? Da stimmt doch dann schon Client- u. Match-list nicht, oder ?

Und selbst wenn, ich sehe nicht wirklich einen Sinn im Neuaufbau des .clientArray. Was soll sich denn zwischenzeitlich verändert haben ? Mir kommt da lediglich der case in den Sinn, dass jemand an einem 2-stufigen Modul und somit Client- u. Match-list arbeitet. Ach nein, mir kommt gerade der "rfmode" in den Sinn. Da wird ja quasi dynamisch die Client- u. Match-list verändert(glaub ich  ). Da sehe ich dann aber das "physische Modul" in der Verantwortung das .clientArray zu löschen, anstatt das zentral automatisch und regelmäßig zu machen, nur weil eine message nicht verarbeitet werden konnte.

Grüße Markus

[Beta-User]

Sehe ich anders. Über die Client- u. Match-list ist ein Modul "bewusst" zugeordnet. Wenn dann eine message aus welchen Gründen als "nicht verarbeitbar" verworfen werden soll, macht es herzlich wenig Sinn, eine als fehlerhaft erkannte message von einem anderen Modul verarbeiten zu lassen. Kann dann ja auch dort nur "nicht verarbeitbar sein".

Weiß nicht: nur weil ein Modul die als "fehlerhaft" einstuft, weil sie nicht deren Erwartungen entspricht, kann es durchaus sein, dass ein anderes Modul die Message als "ok" empfindet.

Ich bin aber überhaupt nicht in den Funkthemen drin und mag auch nicht behaupten, dass ich irgendwie einschätzen könnte, ob das Sinn macht oder nicht. Tendenziell würde ich es eher beim IO als allgemeine Einstellung verorten, ob der Suchprozess bei nicht zuordenbaren Messages mit der Zerstörung des clientArray enden sollte oder nicht. Ist aber mehr Bauchgefühl und mein persönliches Verständnis der Zusammenhänge.

Kennst Du einen Fall, wo das client-Modul per Client- u. Match-list zugeordnet ist, das client-Modul den Fall feststellt "Fehlerhaft ist die message nicht, aber wohl doch nicht für mich. Lass mal andere ran" ?

Genau den Fall kenne ich , deswegen habe ich mich nämlich überhaupt mit dem Thema beschäftigt....: MQTT2_(SERVER|CLIENT)
Da hat man das Problem, dass die eingehenden Infos prinzipiell immer gültig sind, und das Client-Modul, das grade dran ist, jeweils "entscheiden" muss, ob FHEM "fertig" ist oder ob es ggf. doch noch einen Client für die Daten gibt, der sie (auch) haben will...

Deswegen kennen diese IO's das Attribut "clientOrder" und die Client-Module "forceNEXT" (MQTT2_DEVICE, MQTT_GENERIC_BRIDGE und RHASSPY).

(Ob man dafür aber das Zerstören des clientArray benötigt, sei mal dahingestellt).

[KölnSolar]

(Ob man dafür aber das Zerstören des clientArray benötigt, sei mal dahingestellt).

Darauf wollte ich ja hinaus. Wo lösen wir das derzeit blockierende Verhalten ?

Müssen jetzt ALLE Module-Maintainer von Client-Modulen ihre return-Zeilen kontrollieren und modifizieren.
oder
das "delete($hash->{".clientArray"});" wird in fhem.pl entfernt und die physischen Module, die einen Neuaufbau aufgrund ihrer Funktionsweise benötigen, müssen das delete selber durchführen.

Ich horch mal bei Rudi nach....

[Ralf9]

Wenn ich den Code in der dispatch Routine der fhem.pl richtig verstehe, dann müsste eigentlich die Rückgabe eines Leerstrings ausreichen.
Wenn was zurückgegeben wird, dann wird die Schleife mit last abgebrochen und das clientArray wird nicht gelöscht.
wenn "[NEXT]" zurückgegeben wird, dann gehts weiter mit dem nächsten Modul

Code Auswählen Erweitern

    if(int(@tfound) && defined($tfound[0])) {
      if($tfound[0] && $tfound[0] eq "[NEXT]") {
        shift(@tfound);
        push @found, @tfound;
      } else {
        push @found, @tfound;
        last;
      }
    }

Wenn ich es bei meinem Testsystem teste, wird bei rückgabe von einem Leerstring das clientArray nicht gelöscht.

Weiß nicht: nur weil ein Modul die als "fehlerhaft" einstuft, weil sie nicht deren Erwartungen entspricht, kann es durchaus sein, dass ein anderes Modul die Message als "ok" empfindet.

Dies kann beim Signalduino nicht passieren.
Da gibts eine Protokollliste wo jedes Protokoll eine IDnr hat und jede IDnr ist eindeutig zu einem Modul zugeordnet.