Hi Ralf,
freezemon zeigt mir in meinem Testsystem andauernd freezes zwischen dispatch und Verarbeitung von 3-4s an. So richtig glauben konnte ich es nicht. mit verbose=5 gelogged ist es scheinbar tatsächlich so. Ne Idee woran das liegen könnte ? Hier noch ein Log zu einem IT V3 Bwm
2022.01.08 21:09:51 4: Sduino/msg READredu: MU;P0=-273;P1=249;P2=-1070;P3=-9472;P4=-2564;CP=1;R=29;D=01212101314101210121012121012101012121012101012101210121210101210121210101210121210101210121012101212101012121010121012121012101012101212101;e;
2022.01.08 21:09:51 4: Sduino: Fingerprint for MU Protocol id 17.1 -> Intertechno matches, trying to demodulate
2022.01.08 21:09:51 5: Sduino: Starting demodulation (StartStr: 4 cut Pos 10; Signal: (?:1210|1012){28,} Pos 0) length_min_max (28..36) length=32
2022.01.08 21:09:51 5: Sduino: applying postDemodulation , value before : 0 0 0 1 1 0 1 1 0 0 0 1 0 0 1 0 0 1 0 0 0 0 1 0 1 0 0 1 1 0 0 1
2022.01.08 21:09:51 5: Sduino: rcode=1, modified after postDemodulation: 0 1 0 1 0 1 1 0 1 0 0 1 1 0 1 0 0 1 0 1 0 1 1 0 0 1 0 1 1 0 0 1 0 1 1 0 0 1 0 1 0 1 0 1 1 0 0 1 1 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0
2022.01.08 21:09:51 5: Sduino: dispatching bits: 0101011010011010010101100101100101100101010110011001011010010110
2022.01.08 21:09:51 4: Sduino: decoded matched MU Protocol id 17.1 dmsg i569A565965599696 length 64 RSSI = -59.5
2022.01.08 21:09:51 4: Sduino: equalDMS i569A565965599696 (1)
2022.01.08 21:09:51 5: Sduino Dispatch: i569A565965599696, test ungleich: disabled
2022.01.08 21:09:51 4: Sduino Dispatch: i569A565965599696, -59.5 dB, dispatch
2022.01.08 21:09:51 5: Sduino: dispatch i569A565965599696
************************* 4s Verzug ****************************************
2022.01.08 21:09:55 4: Sduino IT: message "i569A565965599696" (17)
2022.01.08 21:09:55 4: Sduino ITv3: bin message "0101011010011010010101100101100101100101010110011001011010010110" (64)
2022.01.08 21:09:55 4: Sduino IT: msgcode "00011011000100100100001010011001" (32) bin = 0101011010011010010101100101100101100101010110011001011010010110
2022.01.08 21:09:55 3: Sduino IT: IT_V3_d892149 on->on
2022.01.08 21:09:55 4: Sduino: Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
2022.01.08 21:09:55 5: Sduino: regex ((?:31)((?:01|01){12,})) did not match, aborting
2022.01.08 21:09:55 5: Sduino applied filterfunc: SIGNALduino_compPattern, count=0
2022.01.08 21:09:55 4: Sduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2022.01.08 21:09:55 5: Sduino: Starting demodulation (Signal: (?:12|10){30,} Pos 11) length_min_max (30..48) length=64
2022.01.08 21:09:55 5: Sduino: skip demodulation (length 64 is to long)
2022.01.08 21:09:55 4: Sduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2022.01.08 21:09:55 5: Sduino: regex ((?:)((?:10|10){50,})) did not match, aborting
2022.01.08 21:09:55 4: Sduino: Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2022.01.08 21:09:55 5: Sduino: regex ((?:)((?:10|10){59,})) did not match, aborting
2022.01.08 21:09:55 4: Sduino: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2022.01.08 21:09:55 5: Sduino: regex ((?:)((?:10|10){50,})) did not match, aborting
2022.01.08 21:09:55 4: Sduino: Fingerprint for MU Protocol id 78 -> BeSmart_Sx matches, trying to demodulate
2022.01.08 21:09:55 5: Sduino: regex ((?:4)((?:10|10){19,}(?:1)?)) did not match, aborting
2022.01.08 21:09:55 4: Sduino: Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2022.01.08 21:09:55 5: Sduino: regex ((?:)((?:12|10){104,})) did not match, aborting
2022.01.08 21:09:55 4: Sduino: Fingerprint for MU Protocol id 95 -> Techmar matches, trying to demodulate
2022.01.08 21:09:55 5: Sduino: regex ((?:12)((?:10|10){50,})) did not match, aborting
2022.01.08 21:09:55 4: Sduino: Fingerprint for MU Protocol id 99 -> Navaris 44344.04 matches, trying to demodulate
2022.01.08 21:09:55 5: Sduino: regex ((?:10)((?:10|10){24,})) did not match, aborting
2022.01.08 21:09:55 3: [Freezemon] freezedetect: possible freeze starting at 21:09:52, delay is 3.687 possibly caused by: tmr-SamsungAV_Init(Fernseher) tmr-SamsungAV_Init(Fernseher2) tmr-SIGNALduino_KeepAlive(Sduino)
oder einem Oregon
2022.01.08 21:16:31.648 4: Sduino/msg READ: MC;LL=-1069;LH=894;SL=-538;SH=384;D=AAAAAAAA66959A65555969AA5599699555556955A6A55A65;C=480;L=192;R=87;s1;b1;O;w;
2022.01.08 21:16:31.652 4: Sduino: Found manchester Protocol id 10 clock 480 RSSI = -30.5 -> Oregon Scientific v2|v3
2022.01.08 21:16:31.653 5: Sduino: extracted data 010101010101010101010101010101011001100101101010011001011001101010101010101001101001011001010101101010100110011010010110011010101010101010101010100101101010101001011001010110101010010110011010 (bin)
2022.01.08 21:16:31.654 4: Sduino: OSV2 protocol detected: preamble_pos = 32
2022.01.08 21:16:31.656 4: Sduino: OSV2 protocol converted to hex: (501A2D40F6501600063B2C) with length (88) bits
2022.01.08 21:16:31.657 5: Sduino Dispatch: 501A2D40F6501600063B2C, test ungleich: disabled
2022.01.08 21:16:31.658 4: Sduino Dispatch: 501A2D40F6501600063B2C, -30.5 dB, dispatch
2022.01.08 21:16:31.661 5: Sduino: dispatch 501A2D40F6501600063B2C
***********************3,5 s Verzug **************************************
2022.01.08 21:16:35.179 5: OREGON: decoding delay=8 hex=501A2D40F6501600063B2C
2022.01.08 21:16:35.180 5: OREGON: sensor_id=1a2d BitsMsg=80 Bits=80
2022.01.08 21:16:35.181 5: OREGON: checksum2 = 59 berechnet: 59
2022.01.08 21:16:35.207 4: Sduino: Found manchester Protocol id 12 clock 480 RSSI = -30.5 -> Hideki
2022.01.08 21:16:35.208 5: Sduino: extracted data 010101010101010101010101010101011001100101101010011001011001101010101010101001101001011001010101101010100110011010010110011010101010101010101010100101101010101001011001010110101010010110011010 (bin)
2022.01.08 21:16:35.210 5: Sduino: protocol does not match return from method: (Start pattern (10101110) not found)
2022.01.08 21:16:35.211 4: Sduino: Found manchester Protocol id 52 clock 480 RSSI = -30.5 -> Oregon Scientific PIR
2022.01.08 21:16:35.212 5: Sduino: extracted data 010101010101010101010101010101011001100101101010011001011001101010101010101001101001011001010101101010100110011010010110011010101010101010101010100101101010101001011001010110101010010110011010 (bin)
2022.01.08 21:16:35.214 5: Sduino: protocol does not match return from method: ( header not found)
2022.01.08 21:16:35.214 4: Sduino: Found manchester Protocol id 58 clock 480 RSSI = -30.5 -> TFA 30.3208.0
2022.01.08 21:16:35.215 5: Sduino: extracted data 010101010101010101010101010101011001100101101010011001011001101010101010101001101001011001010101101010100110011010010110011010101010101010101010100101101010101001011001010110101010010110011010 (bin)
2022.01.08 21:16:35.216 5: Sduino: protocol does not match return from method: (undef)
2022.01.08 21:16:35.227 3: [Freezemon] freezedetect: possible freeze starting at 21:16:32, delay is 3.223 possibly caused by: no bad guy found :-(
Ggfs. könnte ich den Signalduino gegen einen 433CUL mit aculfw zum Vergleich mal tauschen, denn eigentlich liegt ja zwischen Signalduino und der Verarbeitung des Signals die Dispatchfunktion, die sich bei beiden gleich verhalten sollte.
Grüße Markus
Hallo Markus,
kann ich bei mir nicht nachvollziehen
2022.01.08 22:26:25 4 : sduino/msg READredu: MS;P0=-1094;P2=314;P4=1010;P5=-414;P6=-11181;D=26204520202020202020202020202020202020204520452045;CP=2;SP=6;R=68;e;m1;
2022.01.08 22:26:25 4 : sduino: Matched MS Protocol id 3 -> itv1, bitLen=24
2022.01.08 22:26:25 4 : sduino: Decoded MS Protocol id 3 dmsg i400015 length 24 RSSI = -40
2022.01.08 22:26:25 4 : sduino Dispatch: i400015, -40 dB, dispatch
2022.01.08 22:26:25 4 : sduino IT: message "i400015" (7)
2022.01.08 22:26:25 4 : sduino IT: msgcode "F00000000FFF" (12) bin = 010000000000000000010101
2022.01.08 22:26:25 3 : sduino IT: IT_F00000000F_ITV1 on->on
2022-01-08 22:26:25 IT IT_F00000000F_ITV1 on
2022-01-08 22:26:25 IT IT_F00000000F_ITV1 RAWMSG: MS;P0=-1094;P2=314;P4=1010;P5=-414;P6=-11181;D=26204520202020202020202020202020202020204520452045;CP=2;SP=6;R=68;e;m1;
2022-01-08 22:26:25 IT IT_F00000000F_ITV1 DMSG: i400015
2022-01-08 22:26:25 IT IT_F00000000F_ITV1 Protocol_ID: 3
2022-01-08 22:26:25 IT IT_F00000000F_ITV1 RSSI: -40
2022.01.08 22:29:19 4 : sduino/msg READredu: MS;P1=482;P2=-1956;P3=-968;P4=-3890;D=14121313121312131212131313131313131212131213121312121212121313121312131213;CP=1;SP=4;R=8;O;m1;
2022.01.08 22:29:19 4 : sduino: Matched MS Protocol id 7 -> weatherID7, bitLen=36
2022.01.08 22:29:19 4 : sduino: Decoded MS Protocol id 7 dmsg P7#9580D5F2A length 36 RSSI = -70
2022.01.08 22:29:19 4 : sduino Dispatch: P7#9580D5F2A, -70 dB, dispatch
2022.01.08 22:29:19 4 : sduino SD_WS07: P7#9580D5F2A, length=9
2022.01.08 22:29:19 4 : sduino SD_WS07: model=SD_WS07_TH, id=95, channel=1, temp=21.3, hum=42, bat=ok
2022-01-08 22:29:19 SD_WS07 SD_WS07_TH_1 T: 21.3 H: 42
Gruß Ralf
Hi Ralf,
das dachte ich mir. Ich glaube auch nicht, dass es am Modul liegt sondern an der dispatch-Funktion. Und an der selber wahrscheinlich auch nicht, sondern einer Besonderheit meines Testsystems. Ich ändere mal den Betreff.
Du kennst den dispatch-Prozess aber besser als ich und hast vielleicht eine Idee, wo ich weiter auf die Suche gehen kann.
Der Hintergrund bei mir ist, dass mein in der Entwicklung befindliches UPNP/DLNA Thema definitiv freezes verursacht. Wenn dann gleichzeitig noch eine weitere Fehlerquelle dazwischen funkt(im wahrsten Sinne des Wortes ;D), ist eine Analyse für mich unmöglich(zumal die freezes durch UPNP/DLNA tw. nur User-Meldungen sind, auf deren System ich nicht zugreifen kann :'( ) Will heißen: Ich muss freezes in meinem Modul entweder definitiv ausschließen oder wenigstens die Konstellationen kennen).
Grüße Markus
ZitatDer Hintergrund bei mir ist, dass mein in der Entwicklung befindliches UPNP/DLNA Thema definitiv freezes verursacht.
Will heißen: Ich muss freezes in meinem Modul entweder definitiv ausschließen oder wenigstens die Konstellationen kennen
Du solltest die freezes wegbekommen.
Beim Signalduino können dadurch bei slowrf (ASK) empfangene Nachrichten verloren gehen.
Bei einigen Protokollen sind die MU-Nachrichten sehr lang (z.B. bei der ID 9, WH3080 bis zu ca 450 Zeichen). Nachrichten die kurz danach empfangen werden, können bei freezes verloren gehen.
Du kannst ja mal bei "FHEM - Entwicklung - FHEM Development" nachfragen ob da jemand eine Idee hat, wie man die freezes wegbekommt
1 Schritt weiter. Es liegt in der Dispatch-Funktion, wo die client-module über 2 verschachtelte Schleifen ermittelt werden. Die äußere über alle Module(nur über wirklich 2-stufige würde schon erheblich performance bringen. Geht das über clientArray ?). Die Innere über $hash->{Clients}. Hier sehe ich 10% Gewinn, wenn die Leerzeilen rausgenommen werden:
my $clientsSIGNALduino = ":IT:"
."CUL_TCM97001:"
."SD_RSL:"
."OREGON:"
."CUL_TX:"
."SD_AS:"
."Hideki:"
."SD_WS07:"
."SD_WS09:"
." :" # Zeilenumbruch
."SD_WS:"
."RFXX10REC:"
."Dooya:"
."SOMFY:"
."SD_BELL:" ## bells
."SD_UT:" ## universal - more devices with different protocols
."SD_WS_Maverick:"
."FLAMINGO:"
."CUL_WS:"
."Revolt:"
."FS10:"
." :" # Zeilenumbruch
."CUL_FHTTK:"
."Siro:"
."FHT:"
."FS20:"
."CUL_EM:"
."Fernotron:"
."SD_Keeloq:"
."SD_GT:"
."LaCrosse:"
."KOPP_FC:"
."PCA301:"
."SD_Rojaflex:"
."SD_Tool:"
."SIGNALduino_un:"
;
So sieht das auf meinem sonst gelangweilten Rpi2B+ aus, wo der freeze sich durch die tausenden zusätzlichen Logzeilen auf 25s ausgedehnt hat:
2022.01.09 18:39:13 5: Sduino Dispatch: P61#B2CAB32D2C, test ungleich: disabled
2022.01.09 18:39:13 4: Sduino Dispatch: P61#B2CAB32D2C, -61.5 dB, dispatch
2022.01.09 18:39:13 5: Sduino: dispatch P61#B2CAB32D2C
2022.01.09 18:39:13 5: SYSTEM: run dispatch
2022.01.09 18:39:13 5: SYSTEM: run dispatch not duplicate
2022.01.09 18:39:13 5: SYSTEM: run dispatch no clientArray
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray no ClientsKeepOrder
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray outer foreach Global
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach IT
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach CUL_TCM97001
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach SD_RSL
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach OREGON
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach CUL_TX
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach SD_AS
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach Hideki
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach SD_WS07
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach SD_WS09
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach SD_WS
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach RFXX10REC
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach Dooya
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach SOMFY
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach SD_BELL
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach SD_UT
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach SD_WS_Maverick
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach FLAMINGO
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach CUL_WS
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach Revolt
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach FS10
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach CUL_FHTTK
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach Siro
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach FHT
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach FS20
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach CUL_EM
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach Fernotron
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach SD_Keeloq
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach SD_GT
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach LaCrosse
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach KOPP_FC
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach PCA301
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach SD_Rojaflex
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach SD_Tool
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach SIGNALduino_un
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray outer foreach CM11
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach
2022.01.09 18:39:13 5: SYSTEM: run dispatch computeclientArray inner foreach IT
.
.
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray outer foreach myUtils
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach IT
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach CUL_TCM97001
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach SD_RSL
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach OREGON
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach CUL_TX
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach SD_AS
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach Hideki
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach SD_WS07
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach SD_WS09
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach SD_WS
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach RFXX10REC
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach Dooya
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach SOMFY
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach SD_BELL
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach SD_UT
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach SD_WS_Maverick
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach FLAMINGO
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach CUL_WS
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach Revolt
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach FS10
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach CUL_FHTTK
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach Siro
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach FHT
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach FS20
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach CUL_EM
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach Fernotron
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach SD_Keeloq
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach SD_GT
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach LaCrosse
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach KOPP_FC
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach PCA301
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach SD_Rojaflex
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach SD_Tool
2022.01.09 18:39:38 5: SYSTEM: run dispatch computeclientArray inner foreach SIGNALduino_un
2022.01.09 18:39:38 5: SYSTEM: run dispatch clientArray computed
2022.01.09 18:39:38 5: SYSTEM: run dispatch not duplicate
2022.01.09 18:39:38 5: Sduino: FS10_Parse Protocol 61, rawData B2CAB32D2C
2022.01.09 18:39:38 5: Sduino: FS10_Parse rawBitData 1011001011001010101100110010110100101100 (40)
2022.01.09 18:39:38 5: Sduino: FS10_Parse preamble 0 bit, bitData=1011001011001010101100110010110100101100 (40 bit)
2022.01.09 18:39:38 4: Sduino: FS10_Parse P61#B2CAB32D2C - ERROR parity/bit5 8 errors
2022.01.09 18:39:38 5: SYSTEM: run dispatch module found
2022.01.09 18:39:38 5: SYSTEM: run dispatch: inform raw
2022.01.09 18:39:38 4: Sduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2022.01.09 18:39:38 5: Sduino: regex ((?:)((?:10|10){50,})) did not match, aborting
2022.01.09 18:39:38 4: Sduino: Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2022.01.09 18:39:38 5: Sduino: regex ((?:)((?:10|10){59,})) did not match, aborting
2022.01.09 18:39:38 4: Sduino: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2022.01.09 18:39:38 5: Sduino: regex ((?:)((?:10|10){50,})) did not match, aborting
2022.01.09 18:39:38 4: Sduino: Fingerprint for MU Protocol id 78 -> BeSmart_Sx matches, trying to demodulate
2022.01.09 18:39:38 5: Sduino: regex ((?:4)((?:10|10){19,}(?:1)?)) did not match, aborting
2022.01.09 18:39:38 4: Sduino: Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2022.01.09 18:39:38 5: Sduino: regex ((?:)((?:12|10){104,})) did not match, aborting
2022.01.09 18:39:38 4: Sduino: Fingerprint for MU Protocol id 95 -> Techmar matches, trying to demodulate
2022.01.09 18:39:38 5: Sduino: regex ((?:12)((?:10|10){50,})) did not match, aborting
2022.01.09 18:39:38 4: Sduino: Fingerprint for MU Protocol id 99 -> Navaris 44344.04 matches, trying to demodulate
2022.01.09 18:39:38 5: Sduino: regex ((?:10)((?:10|10){24,})) did not match, aborting
2022.01.09 18:39:38 2: [Freezemon] freezedetect: possible freeze starting at 18:39:14, delay is 24.531 possibly caused by: tmr-FW_closeInactiveClients(N/A)
Lässt sich da was machen ? Muss Rudi evtl. ran ?
Grüße Markus
Mit der Dispatch-Funktion habe ich mich noch nicht näher befasst, da kann ich leider nicht weiterhelfen
ZitatMit der Dispatch-Funktion habe ich mich noch nicht näher befasst
Ich aber jetzt. ;)
Das
ZitatGeht das über clientArray
ist der Schlüssel. Das hat Rudi schon eingebaut. Im Internal .clientArray stehen nach der 1. Ermittlung(also ein einziger freeze) die clients.
Das Problem ist, dass das Internal unter gewissen Umständen gelöscht wird und danach gibt es wieder einen freeze.
Das sieht dann bei mir permanent durch den IT V3 Bwm so aus
2022.01.09 20:32:47 3: Sduino IT: IT_V3_d892149 off->on
2022.01.09 20:32:47 3: Sduino IT: message "i569A56596559968" (16) too short!
2022.01.09 20:32:47 3: Sduino IT: message "i569A56596559968" (16) too short!
2022.01.09 20:32:47 2: SYSTEM : clientArray deleted
2022.01.09 20:32:47 3: Sduino: Unknown code i569A56596559968, help me!
2022.01.09 20:32:48 2: SYSTEM : run dispatch no clientArray ==> computeclientArray(cause for freezes) .clientArray:
2022.01.09 20:32:51 3: Sduino IT: message "i569A56596559969" (16) too short!
2022.01.09 20:32:51 3: Sduino IT: message "i569A56596559969" (16) too short!
2022.01.09 20:32:51 2: SYSTEM : clientArray deleted
2022.01.09 20:32:51 3: Sduino: Unknown code i569A56596559969, help me!
2022.01.09 20:32:51 2: SYSTEM : run dispatch no clientArray ==> computeclientArray(cause for freezes) .clientArray:
2022.01.09 20:32:55 3: Sduino IT: IT_V3_d892149 on->on
2022.01.09 20:32:55 3: Sduino IT: IT_V3_d892149 on->on
2022.01.09 20:32:55 3: [Freezemon] freezedetect: possible freeze starting at 20:32:52, delay is 3.764 possibly caused by: no bad guy found :-(
2022.01.09 20:32:55 3: Sduino IT: message "i569A56596559969" (16) too short!
2022.01.09 20:32:55 3: Sduino IT: message "i569A56596559969" (16) too short!
2022.01.09 20:32:55 2: SYSTEM : clientArray deleted
2022.01.09 20:32:56 3: Sduino: Unknown code i569A56596559969, help me!
2022.01.09 20:32:59 2: SYSTEM : run dispatch no clientArray ==> computeclientArray(cause for freezes) .clientArray:
2022.01.09 20:33:09 3: Sduino IT: IT_V3_d892149 on->off
2022.01.09 20:33:09 3: Sduino IT: message "i569A56596559959" (16) too short!
2022.01.09 20:33:09 3: Sduino IT: message "i569A56596559959" (16) too short!
2022.01.09 20:33:09 2: SYSTEM : clientArray deleted
2022.01.09 20:33:09 3: Sduino: Unknown code i569A56596559959, help me!
2022.01.09 20:33:10 2: SYSTEM : run dispatch no clientArray ==> computeclientArray(cause for freezes) .clientArray:
2022.01.09 20:33:13 3: Sduino IT: IT_V3_d892149 off->off
2022.01.09 20:33:14 3: Sduino IT: IT_V3_d892149 off->off
2022.01.09 20:33:14 3: Sduino IT: message "i569A56596559959" (16) too short!
2022.01.09 20:33:14 3: Sduino IT: message "i569A56596559959" (16) too short!
2022.01.09 20:33:14 2: SYSTEM : clientArray deleted
2022.01.09 20:33:14 3: Sduino: Unknown code i569A56596559959, help me!
2022.01.09 20:33:14 2: SYSTEM : run dispatch no clientArray ==> computeclientArray(cause for freezes) .clientArray:
2022.01.09 20:33:18 3: Sduino IT: IT_V3_d892149 off->off
2022.01.09 20:33:18 3: [Freezemon] freezedetect: possible freeze starting at 20:33:15, delay is 3.208 possibly caused by: no bad guy found :-(
Wir müssten dem Sduino bzw. dem IT-Modul also die Meldung abgewöhnen(der Bwm ist ein Original IT). Dazu ne Idee ?
Edit: Warum auch immer werden die letzten 4 bits "verschluckt" i569A565965599596
Kommt diese Meldung auch beim dispatch vom oregon Modul?
2022.01.09 20:32:47 2: SYSTEM : clientArray deleted
Was muß ich machen damit die SYSTEM Meldungen im log angezeigt werden?
ZitatKommt diese Meldung auch beim dispatch vom oregon Modul?
Ich denke nicht. Dass ich eingangs ein Bsp. für einen freeze beim Oregon hatte, lag sicherlich nur daran, dass zuvor vom Bwm das Internal gelöscht wurde.
ZitatWas muß ich machen damit die SYSTEM Meldungen im log angezeigt werden?
Ich hab vor dem bedingten call der Funktion eine zusätzliche Logging-Zeile
sub
Dispatch($$;$$)
{
my ($hash, $dmsg, $addvals, $nounknown) = @_;
my $module = $modules{$hash->{TYPE}};
my $name = $hash->{NAME};
if(GetVerbose($name) == 5) {
Log3 $hash, 5, escapeLogLine("$name: dispatch $dmsg");
}
my ($isdup, $idx) = CheckDuplicate($name, $dmsg, $module->{FingerprintFn});
return rejectDuplicate($name,$idx,$addvals) if($isdup);
my @found;
my $parserMod="";
my $clientArray = $hash->{".clientArray"};
# ################### additional logging
Log3 $hash, 2, "SYSTEM $hash->{'name'}: run dispatch no clientArray ==> computeclientArray(cause for freezes) .clientArray: $hash->{'.clientArray'}" if(!$clientArray);
$clientArray = computeClientArray($hash, $module) if(!$clientArray);und dann eine vor dem delete
foreach my $m (@{$clientArray}) {
# The message is not for this module
next if($dmsg !~ m/$modules{$m}{Match}/s);
if( my $ffn = $modules{$m}{FingerprintFn} ) {
($isdup, $idx) = CheckDuplicate($name, $dmsg, $ffn);
return rejectDuplicate($name,$idx,$addvals) if($isdup);
}
no strict "refs"; $readingsUpdateDelayTrigger = 1;
my @tfound = &{$modules{$m}{ParseFn}}($hash,$dmsg);
use strict "refs"; $readingsUpdateDelayTrigger = 0;
$parserMod = $m;
if(int(@tfound) && defined($tfound[0])) {
if($tfound[0] && $tfound[0] eq "[NEXT]") { # not a goodDeviceName, #95446
shift(@tfound);
push @found, @tfound; # continue feeding other modules
} else {
push @found, @tfound;
last;
}
}
}
if((!int(@found) || !defined($found[0])) && !$nounknown) {
my $h = $hash->{MatchList};
$h = $module->{MatchList} if(!$h);
if(defined($h)) {
foreach my $m (sort keys %{$h}) {
if($dmsg =~ m/$h->{$m}/s) {
my ($order, $mname) = split(":", $m);
if(AttrVal("global", "autoload_undefined_devices", 1)) {
my $newm = LoadModule($mname);
$mname = $newm if($newm ne "UNDEFINED");
if($modules{$mname} && $modules{$mname}{ParseFn}) {
no strict "refs"; $readingsUpdateDelayTrigger = 1;
my @tfound = &{$modules{$mname}{ParseFn}}($hash,$dmsg);
use strict "refs"; $readingsUpdateDelayTrigger = 0;
$parserMod = $mname;
if(int(@tfound) && defined($tfound[0])) {
if($tfound[0] && $tfound[0] eq "[NEXT]") {
shift(@tfound);
push @found, @tfound;
} else {
push @found, @tfound;
last;
}
}
} else {
Log 0, "ERROR: Cannot autoload $mname";
}
} else {
Log3 $name, 3, "$name: Unknown $mname device detected, " .
"define one to get detailed information.";
return undef;
}
# ################### additional logging
Log3 $hash, 2, "SYSTEM $hash->{'name'}: clientArray deleted";
delete($hash->{".clientArray"});
}
}
}
if((!int(@found) || !defined($found[0])) && !$nounknown) {
DoTrigger($name, "UNKNOWNCODE $dmsg");
Log3 $name, 3, "$name: Unknown code $dmsg, help me!";
return undef;
}
}
################
# Inform raw
if(!$module->{noRawInform}) {
foreach my $c (keys %inform) {
if(!$defs{$c} || $defs{$c}{NR} != $inform{$c}{NR}) {
delete($inform{$c});
next;
}
next if($inform{$c}{type} ne "raw");
syswrite($defs{$c}{CD}, "$hash->{TYPE} $name $dmsg\n");
}
}
# Special return: Do not notify
return undef if(!defined($found[0]) || $found[0] eq "");
foreach my $found (@found) {
if($found =~ m/^(UNDEFINED.*)/) {
DoTrigger("global", $1);
return undef;
} else {
if($defs{$found}) {
if(!$defs{$found}{".noDispatchVars"}) { # CUL_HM special
$defs{$found}{MSGCNT}++;
my $avtrigger = ($attr{$name} && $attr{$name}{addvaltrigger});
if($addvals) {
foreach my $av (keys %{$addvals}) {
$defs{$found}{"${name}_$av"} = $addvals->{$av};
push(@{$defs{$found}{CHANGED}}, "$av: $addvals->{$av}")
if($avtrigger);
}
}
$defs{$found}{"${name}_MSGCNT"}++;
$defs{$found}{"${name}_TIME"} = TimeNow();
$defs{$found}{LASTInputDev} = $name;
}
delete($defs{$found}{".noDispatchVars"});
DoTrigger($found, undef);
} elsif(defined($found) && ($found eq "" || $found eq "[NEXT]")) {
return undef;
} else {
Log 1, "ERROR: >$found< returned by the $parserMod ParseFn is invalid,".
" notify the module maintainer";
return undef;
}
}
}
$duplicate{$idx}{FND} = \@found
if(defined($idx) && defined($duplicate{$idx}));
return \@found;
}in die fhem.pl eingebaut.
2022.01.09 20:32:47 3: Sduino IT: IT_V3_d892149 off->on
2022.01.09 20:32:47 3: Sduino IT: message "i569A56596559968" (16) too short!
2022.01.09 20:32:47 3: Sduino IT: message "i569A56596559968" (16) too short!
2022.01.09 20:32:47 2: SYSTEM : clientArray deleted
2022.01.09 20:32:47 3: Sduino: Unknown code i569A56596559968, help me!
2022.01.09 20:32:48 2: SYSTEM : run dispatch no clientArray ==> computeclientArray(cause for freezes) .clientArray:
2022.01.09 20:32:51 3: Sduino IT: message "i569A56596559969" (16) too short!
2022.01.09 20:32:51 3: Sduino IT: message "i569A56596559969" (16) too short!
2022.01.09 20:32:51 2: SYSTEM : clientArray deleted
2022.01.09 20:32:51 3: Sduino: Unknown code i569A56596559969, help me!
Bitte ändere mal im IT Modul das "return undef" in return ''
if (length($msg) != 7 && length($msg) != 12 && length($msg) != 17 && length($msg) != 19 && length($msg) != 20) {
Log3 $hash,3,"$ioname IT: message \"$msg\" (" . length($msg) . ") too short!";
return undef;
}
Wenn einfach das nächste client-Modul "befragt" werden soll: [NEXT] zurückgeben.
ZitatWenn einfach das nächste client-Modul "befragt" werden soll: [NEXT] zurückgeben.
ZitatBitte ändere mal im IT Modul das "return undef" in return ''
Ändert leider beides nichts am Verhalten. .clientArray wird gelöscht.
Ich frag mich die ganze Zeit, ob da nun irgendein Konstruktionsfehler in fhem.pl oder Signalduino/IT vorliegt. Könnte vermutlich nur Rudi beantworten.
Grüße Markus
Na ja, sieht mir nach Absicht aus:
fhem.pl - Dispatch() schiebt das durch alle registrierten Module, bis eines meldet "hab's" (Devicename wird zurückgegeben).
Kommt was anderes, wird am Ende .clientArray gelöscht (#4143), damit beim nächsten Mal wieder alle möglichen Optionen neu ermittelt werden.
Ergo müßte man sicherstellen, dass sich für "kaputte" Meldungen ein exisiterendes Device "zuständig" fühlt (das könnte z.B. auch das IO-Device mit einem Fehler-Reading sein).
Zitatfhem.pl - Dispatch() schiebt das durch alle registrierten Module, bis eines meldet "hab's" (Devicename wird zurückgegeben).
wird es auch durch alle registrierten Module durchgeschoben, wenn das IT Modul im Fehlerfall anstatt "return undef" nur ein return "" zurückgibt?
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).
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. :'(
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).
Wird demnach, wenn anstatt return "" ein return "beliebiger Text" zurückgegeben wird, das .clientArray nicht gelöscht?
Nope. Ein gültiger Device-Name muss es sein!
Zitat von: Beta-User am 10 Januar 2022, 12:27:37
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).
ZitatDaher der Vorschlag, einen Fehler am IO zu melden...
Finde ich nicht verkehrt. Ich probier mal was passiert...
das sieht gut aus. Kein delete, keine freezes mehr. Der Fehler wird wie gehabt gelogged und im Signalduino steht die "fehlerhafte" message unter dmesg.
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
ZitatDaher der Vorschlag, einen Fehler am IO zu melden...
Mir ist nicht klar wie das gemacht wird
Zitat von: Ralf9 am 10 Januar 2022, 16:57:02
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).
Ähmm, ich habs einfacher gemacht. Anstatt dem return undef;ein 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.
...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. :P .
Zitat von: KölnSolar am 10 Januar 2022, 17:45:16
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.
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
return undef;
durch dies ersetze
return "";
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:
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 deleted2022.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 deletedZitatPrinzipiell 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
Zitat von: KölnSolar am 11 Januar 2022, 10:56:24
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.
Zitat
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).
Zitat(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....
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
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.
ZitatWeiß 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.
Zitat von: Ralf9 am 11 Januar 2022, 13:29:44
Wenn ich den Code in der dispatch Routine der fhem.pl richtig verstehe, dann müsste eigentlich die Rückgabe eines Leerstrings ausreichen.
Nach nochmaligem Blick in den Code stimme ich dem zu.
Zitat
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.
Soweit klar, was Signalduino angeht. Prinzipiell sind aber andere IO's denkbar (angefangen bei CUL), so dass das Ergebnis nicht zwingend dasselbe sein muss (vermutlich hier aber keine Abweichungen bestehen).
Was den Mechanismus an sich angeht, ist der vermutlich mit einer der ältesten Teile von FHEM. Da wäre ich mit Änderungen eher vorsichtig, auch wenn das notfalls Nacharbeit an den Client-Modulen bedeutet...
Hier treffen mAn mehrere Probleme aufeinaner.
#1 Ich habe nicht damit gerechnet, dass ein Modul kaputte Messages weitergibt.
#2 Bei der erneuten Suche nach verfuegbaren Modulen werden auch bereits geladene (und damit schon befragte) Module erneut gefragt (d.h. ParseFn wird aufgerufen), und clientArray wird sinnlos geloescht.
#3 Bei vielen Clients ist computeClientArray ohne weitere Optimierung leider langsam: Im Fall von SIGNALduino bedeutet das 565 Module * 35 Clients => 19775 Pruefungen.
Zu den Loesungen dieser Probleme:
#1. Ich meine das IT Modul sollte bei kaputten Daten "" (Leerstring) zurueckliefern. Wenn irgendwer ein IT_DOKTOR Modul baut, dann kann man das IT Modul wieder zurueckdrehen.
#2. Habe ich gerade gefixt. Das sollte computeClientArray in diesen Faellen vermeiden, bleibt aber weiterhin eine sinnlose Schleife ueber 29 matchList Eintraegen, falls das IT Modul nicht geaendert wird.
#3. Module mit vielen Clients sollten ClientsKeepOrder setzen und "versprechen", dass der Clients Eintrag alle Modulnamen komplett und in der richtigen Parsefn-Aufrufreihenfolge enthaelt. Im Fall von SIGNALduino reduziert das den Erstellungsaufwand von clientArray von 19775 auf 35.
ZitatIch habe nicht damit gerechnet, dass ein Modul kaputte Messages weitergibt.
#1. Ich meine das IT Modul sollte bei kaputten Daten "" (Leerstring) zurueckliefern
Das kommt bei vielen Clientmodulen vor, daß bei den vom IO weitergereichten Nachrichten auch kaputte dabei sind, da die Prüfung meistens erst im Clientmodul erfolgt.
Ja das IT Modul sollte bei kaputten Daten einen (Leerstring) zurückliefern.
Bis dies auch im svn geändert ist, kann noch etwas dauern, aber dies ist ein anderes Thema (siehe unten)
Es gibt vermutlich auch noch andere Module wo es geändert werden sollte. Z.B. das 10_SOMFY Modul
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_SOMFY.pm#L559
Zitat#3. Module mit vielen Clients sollten ClientsKeepOrder setzen und "versprechen", dass der Clients Eintrag alle Modulnamen komplett und in der richtigen Parsefn-Aufrufreihenfolge enthaelt. Im Fall von SIGNALduino reduziert das den Erstellungsaufwand von clientArray von 19775 auf 35.
Da muß demnach dann "$hash->{ClientsKeepOrder}" definiert werden und dann müssen die match- und clientliste die selbe Reihenfolge haben.
Darf das " :" für einen Zeilenumbruch drinbleiben?
my %matchListSIGNALduino = (
"1:IT" => "^i......",
"2:CUL_TCM97001" => "^s[A-Fa-f0-9]+",
"3:SD_RSL" => "^P1#[A-Fa-f0-9]{8}",
"5:CUL_TX" => "^TX..........",
"6:SD_AS" => "^P2#[A-Fa-f0-9]{7,8}",
"4:OREGON" => "^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*",
...
my $clientsSIGNALduino = ":IT:"
."CUL_TCM97001:"
."SD_RSL:"
."CUL_TX:"
."SD_AS:"
."OREGON:"
...
." :" # Zeilenumbruch
...
Beim Signalduino gibt's eine Protokollliste wo bei jedem Protokoll Id Eintrag das eindeutig zugeordnete Clientmodul drinsteht.
Da müsste es doch auch möglich sein vor dem Dispatch Aufruf, das der Protokoll Id zugeordnete Clientmodul in den $hash->{".clientArray"} zu schreiben, oder übersehe ich da was?
z.B.
"i400015" hat die Protooll Id 3 und in der Protokollliste steht, daß bei der ID 3 das Clientmodul "IT" verwendet wird
wenn $dmsg = "i400015" und $m = "IT"
my @a = ();
if ($modules{$m}{LOADED}) {
push @a, $m
}
$hash->{".clientArray"} = \@a;
Dispatch($hash, $dmsg, \%addvals);
Der maintainer für die Module CUL_TCM97001 und IT ist @bjoernh, er schaut in letzter Zeit nur recht sporatisch ins Forum rein. Sein letzter Login war am 13 April 2021
Ich hab Ihn mal per email angeschrieben (die komplette email schicke ich Euch per pm)
Zitat
> Hallo Björn,
>
> bist Du in fhem nicht mehr aktiv?
>
> Ich habe Dir übers fhem Forum eine persönliche Nachricht geschrieben
prinzipiell schon.
Ich komme bloß gerade nicht dazu mich um das Modul zu kümmern.
...
Wenn Du willst, können wir auch gerne mit Rudolf bzgl. der parallelen
Pflege des Moduls antriggern.
Ich schau mal, dass ich mir das bei Gelegenheit anschaue, muss aber erst
noch einiges für den Verein aufarbeiten.
Die Frage ist ob es noch Sinn macht, daß er weiterhin der maintainer ist.
Wenn mir jemand hilft, könnte ich auch den maintainer für die Module machen
Gruß Ralf
ZitatDa muß demnach dann "$hash->{ClientsKeepOrder}" definiert werden und dann müssen die match- und clientliste die selbe Reihenfolge haben.
Darf das " :" für einen Zeilenumbruch drinbleiben?
Die Reihenfolge entspricht eigentlich dem ORDER, das ist die zweistellige Zahl vor dem Client-Modulnamen. Ist aber vmtl. in deinem Fall irrelevant.
Zeilenumbruch stoert nicht wirklich, die Komplexitaet waechst von 29 auf 31, immer noch besser als 17k+.
Dein Vorschlag fuer .clientArray ist vmtl. richtig, allerdings will ich nicht versprechen, dass das in der Zukunft sich nicht mehr aendert => bitte nicht weiter optimieren.
Falls Du den Maintainer uebernehmen willst, mein OK hast Du.
Zitat von: rudolfkoenig am 11 Januar 2022, 16:36:31
#1 Ich habe nicht damit gerechnet, dass ein Modul kaputte Messages weitergibt.
Du meinst damit, dass das physische Modul Daten an ein logisches Modul weitergibt, welches es eventuell nicht verarbeiten kann?
Zitat von: rudolfkoenig am 11 Januar 2022, 16:36:31
#3 Bei vielen Clients ist computeClientArray ohne weitere Optimierung leider langsam: Im Fall von SIGNALduino bedeutet das 565 Module * 35 Clients =>
19775 Pruefungen.
Ich blicke hier gerade nicht durch, wieso computeClientArray überhaupt so oft aufgerufen wird. Das Ergebnis dürfte sich für einen hash doch nie ändern, solange der clientArray nicht geändert wird.
Wie dem aber auch sei, eine simple Optimierung liegt im Vergleich 2000% schneller, wenn wir anstatt einer Regex einfach ein "eq" operator verwenden
:
if($m eq $re) {
push @a, $m if($modules{$m}{Match});
last;
}
regexMatch 21.3/s -- -96%
equalCompare 502/s 2252% --
Falls die Regex irgendwie wichtig ist, was ich nicht annehme, dann könnte man sicherlich auch deutlich schneller werden, wenn sie einmalig und nicht bei jedem durchlauf erzeugt wird, aber das sprengt hier den Rahmen, hatte ich aber schon mal an anderer Stelle angeregt.
Zitat von: rudolfkoenig am 11 Januar 2022, 16:36:31
Zu den Loesungen dieser Probleme:
#1. Ich meine das IT Modul sollte bei kaputten Daten "" (Leerstring) zurueckliefern. Wenn irgendwer ein IT_DOKTOR Modul baut, dann kann man das IT Modul wieder zurueckdrehen.
Damit wird die Verarbeitung für andere Module ja unterbunden. Bislang habe ich das so verstanden, dass ein Modul entweder den Namen der Definition zurück liefert oder ein UNDEFINED... für autocreate.
In allen anderen Fällen, muss doch ein undef geliefert werden, damit dispatch überhaupt in der Lage ist an weitere Module verteilen zu können.
Zitat von: rudolfkoenig am 11 Januar 2022, 16:36:31
#3. Module mit vielen Clients sollten ClientsKeepOrder setzen und "versprechen", dass der Clients Eintrag alle Modulnamen komplett und in der richtigen Parsefn-Aufrufreihenfolge enthaelt. Im Fall von SIGNALduino reduziert das den Erstellungsaufwand von clientArray von 19775 auf 35.
Ich habe eine grobe Ahnung was das bewirkt, bzw. dass es bewirkt dass keine Sortierung vorgenommen wird, allerdings wüsste ich nicht wie sich die "richtige" ParseFn-Aufrufreihenfolge definiert.
Eine Aufschlussreiche Dokumentation habe ich dazu leider auch nicht finden können und so bin ich mir da unsicher, was das für einen Effekt zwischen die Datenübergabe zwischen physischem und logischem Modul hat.
Grüße Sidey
ZitatDu meinst damit, dass das physische Modul Daten an ein logisches Modul weitergibt, welches es eventuell nicht verarbeiten kann?
Natuerlich nicht, das soll das physische Modul doch gar nicht beurteilen koennen.
Es geht darum, dass das logische Modul (hier IT) kaputte Messages "an den Naechsten" weitergibt, und hier kein Naechster gibt.
ZitatIch blicke hier gerade nicht durch, wieso computeClientArray überhaupt so oft aufgerufen wird.
Wegen dem Bug in Dispatch (aka #2):
- das IT Modul meint, ein anderes Modul soll das kaputte Paket bearbeiten
- Dispatch sucht daraufhin matchList nach nach diesem "anderen" Modul durch
- findet IT (=>FEHLER)
- ruft IT->ParseFn nochmal auf (jaja, weiss ich, schon gut).
- da jetzt ja ein "weiteres" Modul geladen wurde, muss clientArray neu berechnet werden.
Das habe ich gefixt.
Zitat... wenn wir anstatt einer Regex einfach ein "eq" operator verwenden
Das ist klar, leider "verspricht" die urspuengliche Client Verarbeitung ist, dass es regexp sein darf.
Wenn man ClientsKeepOrder setzt, dann sagt das Modul, es ist kein Regexp, und die Reihenfolge ist auch ok => da wird die Berechnung auch deutlich schneller durchgefuehrt.
Urspruenglich war ClientsKeepOrder fuer dynamische / per Attribut setzbare Modulreihenfolgen gedacht, passt aber hier auch perfekt.
Kurze Rückmeldung, da man mich betr. der Maintainerfrage (mit) per pm angeschrieben hatte: Ich habe da keine Aktien drin; falls jemand was zum "Einpacken" wissen will, helfe ich gerne, soweit die Kenntnisse reichen (was nicht übermäßig viel ist).
Da alle (potentiellen) CUL/Signalduino-Maintainer grade hier so einträchtig versammelt sind, vielleicht eine Bitte eher aus der User-Perspektive: Das Feld "verfügbare Versionen von firmwares und Modulen" (und deren sinnvolle Kombinationsmöglichkeiten) erscheint mir ziemlich undurchsichtig. Falls man das in diesem Zuge irgendwie (kommunikativ oder) im Code wieder was vereinfachen könnte, fände vermutlich nicht nur ich das klasse!
Zitat von: rudolfkoenig am 12 Januar 2022, 09:31:12
Es geht darum, dass das logische Modul (hier IT) kaputte Messages "an den Naechsten" weitergibt, und hier kein Naechster gibt.
Da habe ich ein abweichendes Verständnis. Das IT Modul (und das Versrändniss trifft auch auf fast alle anderen logischen Module zu) gibt eine Rückmeldung an die Dispatch Funktion ob ParseFN die Meldung verarbeiten konnte.
Das logische Modul gibt somit keinerlei Daten an ein anderes logisches Modul sondern überlässt dies der Dispatch Funktion (wo es auch hingehört).
Die Funktion ist auch praktisch, weil es ja durchaus möglich ist, dass es ein anderes logisches Modul gibt, welches diese Daten verarbeiten kann.
Wenn das logische Modul zweifelsfrei feststellen kann, dass etwas nicht weiter verarbeitet werden muss, dann könnte man vielleicht ein [STOP] zurückgeben. Damit wäre dann zumindest eher erkennbar dass es hier nicht weitergeht. Die Bewertung Entscheidung in ein logisches Modul zu legen skaliert aber meines Erachtens nicht in Kombination mit dem aktuellen Maintainer Vorgehen.
Zitat von: rudolfkoenig am 12 Januar 2022, 09:31:12
Das ist klar, leider "verspricht" die urspuengliche Client Verarbeitung ist, dass es regexp sein darf.
Wäre zu einfach gewesen. Ich kann mich gerne an einen Patch setzen, der zumindest die regex so optimiert, dass diese weniger häufig compiliert werden muss. Das würde dann grundsätzlich allen zugute kommen.
Die Variante mit der Regex sollten wir vielleicht mal auf deprecated setzen. Ein Modulauthor sollte schon wissen, an welche logischen Module er was übergeben möchte und in der MatchList muss er es ja in der Regel auch hinterlegen.
Zitat von: rudolfkoenig am 12 Januar 2022, 09:31:12
Wenn man ClientsKeepOrder setzt, dann sagt das Modul, es ist kein Regexp, und die Reihenfolge ist auch ok => da wird die Berechnung auch deutlich schneller durchgefuehrt.
Urspruenglich war ClientsKeepOrder fuer dynamische / per Attribut setzbare Modulreihenfolgen gedacht, passt aber hier auch perfekt.
Bedeutet, die richtige Reihenfolge gibt das physiche Modul vor, da gibt es kein festgelegtes "richtig" oder "falsch" ?
In diesem konkreten Fall, ist das Zusätzliche Internal die effizienteste und am einfachsten umzusetzende Variante.
ZitatWenn das logische Modul zweifelsfrei feststellen kann, dass etwas nicht weiter verarbeitet werden muss, dann könnte man vielleicht ein [STOP] zurückgeben.
GIbts schon, und ist ein Leerstring.
Zitat von: rudolfkoenig am 12 Januar 2022, 23:02:34
GIbts schon, und ist ein Leerstring.
Das hatte ich ehrlich gesagt durchaus schon gesehen aber eigentlich immer als "Fehlerhaft" angesehen.
PS: Also mit einer Codezeile mehr könnten wir so die 700% beschleunigen.
Mir ist nicht klar welche Auswirkungen es hat, wenn die Reihenfolge vom $hash->{Clients} nicht passt.
Das ist wahrscheinlich erst interessant, wenn es in der matchList für eine $dmsg mehrere Clientmodule gibt die matchen können, dann sollte die clientlist die gleiche Reihenfolge haben wie die matchlist.
Wenn es aber wie beim Signalduino für jede $dmsg in der matchlist nur einen Eintrag gibt bei dem die regex match, dürfte die Reihenfolge in der Clientliste eigentlich egal sein.
Es liese sich wahrscheinlich noch ein klein wenig optimieren, wenn in der Clientlist die Module für Sensoren weiter vorne stehen und die Module für Funkrolladen und Funksteckdosen weiter hinten.
Ich habs mir nochmals angeschaut, demnach wird ohne ClientsKeepOrder in der sub computeClientArray das .clientArray alphabetisch sortiert.
Demnach ist die Parsefn-Aufrufreihenfolge die alphabetische Sortierung.
Zitat#3. Module mit vielen Clients sollten ClientsKeepOrder setzen und "versprechen", dass der Clients Eintrag alle Modulnamen komplett und in der richtigen Parsefn-Aufrufreihenfolge enthaelt
Mir ist nicht klar warum das so wichtig ist, daß in der $hash->{Clients} die Einträge alphabetisch sortiert sind.
Da beim Dispatch die matchlist alphabetisch sortiert wird, ist es wahrscheinlich besser bei der Nummerierung 1-9 eine 0 davor zu schreiben
Anstatt so
my %matchListSIGNALduino = (
"1:IT"
"2:CUL_TCM97001"
"3:SD_RSL"
"5:CUL_TX"
"6:SD_AS"
"4:OREGON"
"7:Hideki"
"9:CUL_FHTTK"
"10:SD_WS07"
"11:SD_WS09" dann so
my %matchListSIGNALduino = (
"01:IT"
"02:CUL_TCM97001"
"03:SD_RSL"
"05:CUL_TX"
"06:SD_AS"
"04:OREGON"
"07:Hideki"
"09:CUL_FHTTK"
"10:SD_WS07"
"11:SD_WS09"
Die Reihenfolge geht nach ORDER, das ist die zweistellige Nummer vor dem Modulnamen. Ist de facto irrelevant.
Wenn Signalduino in der Client Liste alle Module vollständig benennt, dann reicht den o.g. ClientsKeepOrder zu setzen.
Zitat von: rudolfkoenig am 13 Januar 2022, 20:29:59
Wenn Signalduino in der Client Liste alle Module vollständig benennt, dann reicht den o.g. ClientsKeepOrder zu setzen.
Die sind alle gesetzt. Man könnte die Clientliste vor dem Dispatch Aufruf sogar auf die relevanten reduzieren.
Bist Du an einer CPU Optimierten computeClientArray interessiert?
ZitatMan könnte die Clientliste vor dem Dispatch Aufruf sogar auf die relevanten reduzieren.
Das ist nicht sinnvoll, da die Liste nur nach Laden neuer Module berechnet wird. Aus dem Gleichen Grund ist eine Optimierung nur begrenzt wichtig. Aber wenn es nich wesentlich länger oder unleserlich wird: warum nicht.
@KölnSolar
ich hab erstmal bei mir auf dem github beim IT Modul die "return undef" durch return '' ersetzt
https://github.com/Ralf9/10_IT/blob/master/FHEM/10_IT.pm
https://github.com/Ralf9/10_IT/commit/2b42dc60bfb573397c4738dfa197cb8da0439ea4#diff-31ce4f5175b925aa615d7dd8138f71f31c7cabd3e4f352a8386b91af91ae809b
Außerdem habe ich noch bei meiner Variante der 00_SIGNALduino.pm
- Das ClientsKeepOrder gesetzt
- Die Sortierung der Clientlist optimiert, die Module für Temperatursenoren und Wetterstationen stehen nun am Anfang, da bei denen regelmässig ca jede Minute was empfangen wird
- Bei aktiver Whitelist, werden nun nur noch die Clientmodule der IDs die in der Whitelist stehen in die $hash->{Clients} kopiert
Wenn z.B. in der whitelist die folgenden IDs stehen:
0 - CUL_TCM97001
3 - IT
9 - SD_WS09 Weatherstation WH1080, WH3080 ...
12 - Hideki
18 - Oregon
61 - FS10
Dann steht im Internal Clients nur noch:
:CUL_TCM97001:SD_WS09:Hideki:OREGON:IT:FS10:
https://github.com/Ralf9/RFFHEM/blob/dev_clientlist/FHEM/00_SIGNALduino.pm
https://github.com/Ralf9/RFFHEM/blob/dev_clientlist/FHEM/lib/signalduino_protocols.pm
Gruß Ralf
Zitat von: rudolfkoenig am 14 Januar 2022, 07:21:03
Das ist nicht sinnvoll, da die Liste nur nach Laden neuer Module berechnet wird. Aus dem Gleichen Grund ist eine Optimierung nur begrenzt wichtig. Aber wenn es nich wesentlich länger oder unleserlich wird: warum nicht.
Verstehe. Ich habe ein wenig getestet. Ab drei geladenen Modulen ist die Variante mit den Vorberechnung der Regex schon schneller. Mit mehr Modulen oder einer größeren Clientliste wird der Effekt stärker, das dürfte also in den allermeisten Fällen immer etwas bringen und somit CPU Ressourcen zum 0-Tarif schenken.
Die Lesbarkeit ist für denjenigen, der es geschrieben hat ja meist kein Problem, aber es ist nur ein map hinzugekommen.
Noch effizienter wäre es natürlich, wenn man die Regex der Clientliste vorcompiliert speichert, aber das erschien mir zunächst komplexer zu werden.
Grüße Sidey
Erst einmal mein Dank an Euch.
@Ralf hab alle 3 Module eingespielt,keine whitelist und shutdown/restart. In freezemon bin ich runter auf threshold=0.5 und alles bleibt friedlich. 8)
Grüße Markus
Zitat#2 Bei der erneuten Suche nach verfuegbaren Modulen werden auch bereits geladene (und damit schon befragte) Module erneut gefragt (d.h. ParseFn wird aufgerufen), und clientArray wird sinnlos geloescht.
#2. Habe ich gerade gefixt. Das sollte computeClientArray in diesen Faellen vermeiden,
Das passt noch nicht ganz.
Siehe hier im Kommentar:
https://svn.fhem.de/trac/browser/trunk/fhem/fhem.pl#L4106
if((!int(@found) || !defined($found[0])) && !$nounknown) {
my $h = $hash->{MatchList};
$h = $module->{MatchList} if(!$h);
if(defined($h)) {
foreach my $m (sort keys %{$h}) { ## <- in $m steht der Modulname mit der Nummer am Anfang z.B. "07:Hideki"
next if($modules{$m}{LOADED}); ## <- hier wird aber nur der Modulname benötigt
if($dmsg =~ m/$h->{$m}/s) {
my ($order, $mname) = split(":", $m);So funktionierts:
if((!int(@found) || !defined($found[0])) && !$nounknown) {
my $h = $hash->{MatchList};
$h = $module->{MatchList} if(!$h);
if(defined($h)) {
foreach my $m (sort keys %{$h}) {
my (undef, $mname) = split(":", $m); ## neu
next if($modules{$mname}{LOADED}); # checked in the loop above, #125292
if($dmsg =~ m/$h->{$m}/s) {
#my ($order, $mname) = split(":", $m); ## altAufgefallen ist's mir am 14_Hideki.pm Modul, da ist die match regex fehlerhaft
$hash->{Match} = "^P12#75[A-F0-9]{17,30}Diese regex ist genauer als die regex in der Matchlist:
'07:Hideki' => '^P12#75[A-F0-9]+',Z.B. diese dmsg "P12#75E80635C7405C63" ist für die Match regex im Hideki Modul zu kurz, deshalb gibt's kein match im clientarray
@Sidey, es wäre schön, wenn Du die regex im Hideki Modul fixen könnstet
Gruß Ralf
ZitatDas passt noch nicht ganz.
Wo Du Recht hast...
Habs gesendert und eingecheckt.
Zitat von: Sidey am 16 Januar 2022, 01:55:30
Die Lesbarkeit ist für denjenigen, der es geschrieben hat ja meist kein Problem, aber es ist nur ein map hinzugekommen.
Noch effizienter wäre es natürlich, wenn man die Regex der Clientliste vorcompiliert speichert, aber das erschien mir zunächst komplexer zu werden.
Offenbar war der Anhang nicht dabei. Jetzt sollte er dabei sein.
Zitat von: rudolfkoenig am 17 Januar 2022, 22:02:54
Wo Du Recht hast...
Habs gesendert und eingecheckt.
Beim Autocreate passt's noch nicht ganz.
Ein Autocreate von einem Device funktioniert nur, wenn sich das Clientmodul im ".clientArray" befindet.
Wenn man das erste Device von einem Modul per Autocreate erzeugen will, wird das Modul zwar geladen, es wird aber das ".clientArray" nicht gelöscht.
Ich habs mal mit einem FS10 Device getestet. Nachdem nach dem ersten Dispatch Aufruf per Matchlist das FS10 Modul geladen wurde, habe ich das ".clientArray" gelöscht damit das ".clientArray" neu erzeugt wurde.
Danach war das FS10 Modul im ".clientArray" und das autocreate hat funktioniert.
Zitat von: rudolfkoenig am 17 Januar 2022, 22:02:54
Wo Du Recht hast...
Habs gesendert und eingecheckt.
Seit dieser Änderung laufen einige meiner Test nicht mehr durch.
Z.B. autocreate geht nicht mehr.
Ob meine Module jetzt fehlerhaft sind, oder die Anpassung, das habe ich nicht durchleuchtet.
@rudi
Ich habe den Fehler in fhem.pl gefunden. Folgender Patch beseitigt ihn aus meiner Perspektive.
Erste tests haben dies bestätigt.
Edit:
Ich habe eine Nacht darüber geschlafen und glaube der Patch ist noch nicht fertig. Da fehlt eine explizite Bedingung, ob ein neues Modul nachgeladen wurde.
So wird computeClientArray auch ausgeführt wenn das Modul über die Clientliste geladen wurde. :(
Irgendwas endscheidendes scheint sich geändert zu haben. Das KLF200 Modul, das jahrelang ohne Probleme lief, hat nun Probleme (evtl. mit autoCreate und/oder Netzwerkverbindungen)
Siehe https://forum.fhem.de/index.php/topic,92907.msg1201966.html#msg1201966
Leider habe ich momentan null Kapazität, den Ursachen nachzugehen.
ZitatOffenbar war der Anhang nicht dabei. Jetzt sollte er dabei sein.
Danke, habs eingecheckt. Bei CUL ist der Zeitersprarnis 80% wenn ein Modul neu geladen wurde.
ZitatSeit dieser Änderung laufen einige meiner Test nicht mehr durch.
Z.B. autocreate geht nicht mehr.
Zur Klarstellung: autocreate funktioniert allgemein, jedenfalls habe ich gerade bei MQTT2_SERVER und CUL kein autocreate Problem feststellen koennen.
Statt patch zu bauen waere viel sinnvoller einen Testfall zu konstruiren, womit ich das Problem nachstellen kann.
Das Autocreate funktioniert nicht, wenn man das erste Device von einem Modul per Autocreate erzeugen will. Das Modul wird dann zwar geladen, aber das ".clientArray" wird nicht gelöscht.
Da das geladene Modul nicht im ".clientArray" steht, wird es bei den folgenden dispatch in der .clientArray Schleife nicht aufgerufen und in der matchlist Schleife durch "next if($modules{$mname}{LOADED});" übersprungen.
Ich habs mit 2 log Ausgaben in der fhem.pl getestet
foreach my $m (@{$clientArray}) {
# The message is not for this module
Log3 $hash, 2, "SYSTEM $name: clientloop0 m=$m"; ## <--
next if($dmsg !~ m/$modules{$m}{Match}/s);
if( my $ffn = $modules{$m}{FingerprintFn} ) {
($isdup, $idx) = CheckDuplicate($name, $dmsg, $ffn);
return rejectDuplicate($name,$idx,$addvals) if($isdup);
}
no strict "refs"; $readingsUpdateDelayTrigger = 1;
my @tfound = &{$modules{$m}{ParseFn}}($hash,$dmsg);
Log3 $hash, 2, "SYSTEM $name: clientloop1 m=$m tfound=@tfound"; ## <--
use strict "refs"; $readingsUpdateDelayTrigger = 0;
$parserMod = $m;
if(int(@tfound) && defined($tfound[0])) {
if($tfound[0] && $tfound[0] eq "[NEXT]") { # not a goodDeviceName, #95446
shift(@tfound);
push @found, @tfound; # continue feeding other modules
} else {
push @found, @tfound;
last;
}
}
}
Ich habs mit dem CUL_WS Modul und der folgenden dmsg = K11130200 getestet:
- dispatch 1:
das CUL_WS Modul wird in der matchlist Schleife geladen
in der events und fhemlog Ausgabe steht nun
CUL_WS UNDEFINED temp/hum sensor detected, code 2
Global global UNDEFINED CUL_WS_2 CUL_WS 2
Da das ".clientArray" nicht gelöscht wurde, steht das CUL_WS Modul nicht im ".clientArray"
- folgende dispatch Aufrufe:
Da das geladene Modul nicht im ".clientArray" steht, wird es in der .clientArray Schleife nicht aufgerufen und in der matchlist Schleife durch "next if($modules{$mname}{LOADED});" übersprungen.
- löschen des ".clientArray"
- dispatch
es wird computeClientArray aufgerufen und das CUL_WS Modul steht im ".clientArray"
im log steht nun
2022.01.20 18:03:36.507 2 : SYSTEM sduinoD: clientloop0 m=CUL_WS
2022.01.20 18:03:36.507 1 : CUL_WS UNDEFINED temp/hum sensor detected, code 2
2022.01.20 18:03:36.507 2 : SYSTEM sduinoD: clientloop1 m=CUL_WS tfound=UNDEFINED CUL_WS_2 CUL_WS 2
2022-01-20 18:03:36.509 Global global UNDEFINED CUL_WS_2 CUL_WS 2
Bei den folgenden dispatch erfolgt nun das Autocreate
ZitatIch habs mit dem CUL_WS Modul und der folgenden dmsg = K11130200 getestet:
Danke, das reicht mir.
Ich habe mit FHT und MQTT2_DEVICE getestet, hier wird IODev gesetzt, was clientArray auch zuruecksetzt, deswegen habe ich keine Probleme gesehen.
Ich habe das jetzt durch verschieben der delete Zeile auch fuer "IODev-lose" Geraete gefixt.
Zitat von: rudolfkoenig am 20 Januar 2022, 17:09:51
Danke, habs eingecheckt. Bei CUL ist der Zeitersprarnis 80% wenn ein Modul neu geladen wurde.
Top. Ich hätte da noch die ein oder andere ähnliche gelagerte Idee
Zitat von: rudolfkoenig am 20 Januar 2022, 17:09:51
Statt patch zu bauen waere viel sinnvoller einen Testfall zu konstruiren, womit ich das Problem nachstellen kann.
Ja das stimmt. Ich hatte einen meiner Autocreate Tests um ein Print vom Clientarray ergänzt, ich kann aber durchaus mal ein Test erstellen.
ZitatBei CUL ist der Zeitersprarnis 80% wenn ein Modul neu geladen wurde.
Andererseits werden Module nicht so haeufig geladen, und auf meinem Rechner war der Unterschied pro geladenes Modul unter 2ms :)
Zitatich kann aber durchaus mal ein Test erstellen.
Ich hoffe das hat sich mit der vorherigen Aenderung erledigt.
Zitat von: rudolfkoenig am 20 Januar 2022, 20:27:34
Andererseits werden Module nicht so haeufig geladen, und auf meinem Rechner war der Unterschied pro geladenes Modul unter 2ms :)
Ich kenne die Rechenleistung von deinem Rechner nicht, aber in 2 millisekunden sind für einen Computer einige Rechenoperationen. :)
Ich habe da allerdings noch eine andere Stelle im Blick, wo der Effekt meines Erachtens in der Summe eher relevant sein könnte.
Zitat von: rudolfkoenig am 20 Januar 2022, 20:27:34
Ich hoffe das hat sich mit der vorherigen Aenderung erledigt.
Meine Tests sehen bislang gut aus.
Einen Test für Dispatch anzulegen kann aber nicht schaden. Ich bau mal ein Gerüst, wobei ich hier anmerken muss, die "Einheit" Dispatch ist ziemlich umfangreich für einen Test. Ich würd mal schauen, ob ich es zunächst auf den return Wert limiteren kann.
Zitat von: Ralf9 am 20 Januar 2022, 18:46:20
Da das geladene Modul nicht im ".clientArray" steht, wird es bei den folgenden dispatch in der .clientArray Schleife nicht aufgerufen und in der matchlist Schleife durch "next if($modules{$mname}{LOADED});" übersprungen.
Das scheint in recht vielen Modulen Probleme zu machen...
Hab's nicht im Detail angesehen, aber neben dem bereits weitgehend geklärten HM485- und LaCrosse-GW-Modulen das hier klingt auch danach:
https://forum.fhem.de/index.php/topic,125614.0/topicseen.html (https://forum.fhem.de/index.php/topic,125614.0/topicseen.html)
- Unifi
- Esera-IO
Gibt es evtl. eine Idee, wie man sowas proaktiv auffinden kann, damit man den betr. Maintainern ggf. schon vorab einen Hinweis zukommen lassen könnte...?
ZitatGibt es evtl. eine Idee, wie man sowas proaktiv auffinden kann
Dies lässt sich rausfinden durch vergleich der match regex in den Clientmodulen mit der matchliste im IO Modul, diese sollten gleich sein
ZitatEsera-IO
Die Clientmodule hab ich gefunden "66_Esera.." ist weiß aber nicht wie das IO Modul heißt
ZitatUnifi
da sind die regex gleich, evtl war es das Autocreate problem?
Das 14_Hideki.pm Modul ist auch davon betroffen, da gibts jetzt ein Temperatursensor der nicht mehr funktioniert (Sidey weiß schon davon)
Zitat von: Ralf9 am 21 Januar 2022, 10:23:39
Dies lässt sich rausfinden durch vergleich der match regex in den Clientmodulen mit der matchliste im IO Modul, diese sollten gleich sein
...klingt nicht danach, als wäre das per einfachem "grep" über das FHEM-Verzeichnis zu ermitteln...
Zitat
Die Clientmodule hab ich gefunden "66_Esera.." ist weiß aber nicht wie das IO Modul heißt
Würde auf 66_EseraOneWire.pm tippen:
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/66_EseraOneWire.pm#L24
Zitatda sind die regex gleich, evtl war es das Autocreate problem?
Wie gesagt: ich habe nur erst mal versucht, die Infos zu verknüpfen, damit ggf. schnell reagiert werden kann, ohne mich mit den Hintergründen zu befassen.
Zitat
Das 14_Hideki.pm Modul ist auch davon betroffen, da gibts jetzt ein Temperatursensor der nicht mehr funktioniert (Sidey weiß schon davon)
Thx für die Info, mal sehen, wie viele sich dazu melden werden...
ZitatWürde auf 66_EseraOneWire.pm tippen:
EseraDimmer kann nicht funktionieren, da er in der Clientlist fehlt
$hash->{Clients} = ":EseraDigitalInOut:EseraTemp:EseraMulti:EseraAnalogInOut:EseraIButton:EseraCount:EseraShutter:";
Thx, habe es mal eingekippt, dann sollten die Beteiligten das selbst checken/reparieren (lassen) können.
Dies passt auch nicht mit der Matchlist zusammen
66_EseraDigitalInOut.pm
$hash->{Match} = "DS2408";
66_EseraMulti.pm
$hash->{Match} = "DS2438";
$hash->{MatchList} = { "1:EseraDigitalInOut" => "^DS2408|^11220|^11233|^11228|^11229|^11216|^SYS1|^SYS2",
"2:EseraTemp" => "^DS1820",
"3:EseraMulti" => "^DS2438|^11121|^11132|^11133|^11134|^11135",
"4:EseraAnalogInOut" => "^SYS3",
"5:EseraIButton" => "^DS2401",
"6:EseraCount" => "^DS2423",
"7:EseraShutter" => "^11231|^11209",
"8:EseraDimmer" => "^11221|^11222"};
ZitatGibt es evtl. eine Idee, wie man sowas proaktiv auffinden kann, damit man den betr. Maintainern ggf. schon vorab einen Hinweis zukommen lassen könnte...?
Todo:
- IO-Modul laden. Problem: Perl-Module muessen installiert sein.
- MatchList abfragen. Problem: Manche Module setzen je nach Attribut einen unterschiedlichen MatchList.
- aus Matchlist die logischen Module laden, und deren Match mit dem MatchList Eintrag vergleichen. Problem: Regex vs. Regex Vergleich.
Perfekt zu loesen ist mW nicht moeglich, insb. wegen dem letzten Punkt.
Ob das, was machbar ist, praktisch einen Nutzen hat, weiss ich nicht.
Nun ja, wie wir erleben, taucht das meiste dann doch eher schneller, von daher ist es halt lästig, aber meistens dann auch recht schnell zu fixen...
Zitat von: Ralf9 am 17 Januar 2022, 20:21:20
@Sidey, es wäre schön, wenn Du die regex im Hideki Modul fixen könnstet
Hast Du auch eine passende RawMsg?
Grüße Sidey
ZitatHast Du auch eine passende RawMsg?
Hatte ich hier bereits gepostet:
https://forum.fhem.de/index.php/topic,58397.msg1200961.html#msg1200961
Gruß Ralf
ZitatRevision 25560: 14_Hideki.pm: fix match regex
- avoid "Unknown code ...
14_Hideki.pm: fix match regex
- avoid "Unknown code P12#751CBA4A31BFC751F4, help me!" errors in logfile
- forum:#125679
Source: Revision 25560: 14_Hideki.pm: fix match regex
- avoid "Unknown code ...
http://svn.fhem.de/trac/changeset/25560/trunk
Hallo Sidey,
damit wird der Fehler mit den "Unknown code P12#xxx, help me!" errors in logfile" nicht zu 100% behoben.
Ich hätte es besser gefunden, wenn Du so wie auch bei allen anderen Clientmodulen, die match regex gleich gemacht hättest, wie in der Matchliste:
'7:Hideki' => '^P12#75[A-F0-9]+',Gruß Ralf
Zitat von: Ralf9 am 26 Januar 2022, 10:06:52
Ich hätte es besser gefunden, wenn Du so wie auch bei allen anderen Clientmodulen, die match regex gleich gemacht hättest, wie in der Matchliste:
Um welche Nachrichten exakt geht es? Ich kenne aktuell keine, welche eine derartige Meldung erzeugen.
Die Regex dient als Filter und Nachrichten beliebiger Lange können vom Modul doch nicht verarbeitet werden.
Es geht um fehlerhafte MC Nachrichten die evtl eine dmsg von weniger als 14 Zeichen nach der "75" ergeben.
Hi Rudi,
(oder vielleicht auch Ralf oder Sidey) ich bin ja begeistert, dass Ihr das freeze-Problem beim Signalduino gelöst habt.
Leider hab ich nun ein Problem mit der fhem.pl, dass das Dispatch nicht mehr mein logisches Modul oder Matchbegriff findet. Ich hab es soweit analysieren können, dass der Fehler behoben ist, wenn ich die Zeile next if($modules{$mname}{LOADED}); # checked in the loop above, #125292auskommentiere.
Ich hab ja eher an einen Fehler in meinen Modulen geglaubt, aber nun bin ich mir sicher, dass es das nicht ist.
Vielleicht fällt Euch ja was auf.
Physisches Modul
$hash->{Clients} = "DLNAController";
$hash->{MatchList} = { "1:DLNAController" => "^(RenderingControl|AVT|Speak|Sess)" ,
};
Logisches Modul $hash->{Match} = { "1:DLNAController" => "^(RenderingControl|AVT|Speak|Sess)",
};
Im Ursprung hatte ich 4 einzelne Einträge im Hash, aber die Änderung brachte es nicht. Ebensowenig, dass ich den zu matchenden Begriff komplett(RenderingControl anstatt nur Ren) aufgenommen habe. Jetzt hätte ich nur noch die Idee, dass das Problem bei mir auftritt, weil es nur 1 logisches Modul gibt ? :-\
Grüße
Markus
ZitatLogisches Modul
$hash->{Match} = { "1:DLNAController" => "^(RenderingControl|AVT|Speak|Sess)",
};
Das passt so nicht, da darf nur die regex stehen
$hash->{Match} = "^(RenderingControl|AVT|Speak|Sess)";[/quote]
Supi, Danke. Und so schnell. Spitze.
Vorher funktionierte es aber so.
Ich ändere es und gebe über ein Edit dieses Posts Erfolgsmeldung....
Edit: Yes, das war es. Danke.
Der Aufbau der Variable {Match} im logischen Modul ist falsch.
Dort muss entweder ein String hinterlegt werden, welcher zur Laufzeit als Regex compiliert werden kann oder Du hinterlegst gleich einen Typ Regex, der dann nur beim Laden des Moduls compiliert werden muss
Beispiel siehe hier:
https://github.com/RFD-FHEM/RFFHEM/commit/93392febf8a97e5d997df9f22290b0980179fc00#diff-3ad745e973be1e3a19b9bb7b64bee7059d104fd0ed9e3a0acc56c058b6377600
ZitatVorher funktionierte es aber so.
Klar, aber sinnlos ineffizient. Pro IODev Dispatch-Aufruf wurde:
- wg falschen Match-Regexp das logische Modul nicht gefunden
- ueber die MatchList des IOModuls das logische Modul nochmal gesucht
- das logische Modul nochmal "geladen" (auch wenn das eigentliche Perl-Laden nicht mehr stattfand)
- alle NotifyFn-Zuordnungen neu berechnet (bei vielen Instanzen sehr teuer, so haben wir den Bug gefunden)
Das gibts seit dem Fix nicht mehr: wenn ein geladenes Modul per eigenen Match sich nicht zustaendig fuehlt, wird der oben beschriebene Rest gespart.
Hallo Zusammen,
ich bin durch die Nutzung des 36_KVPUDP.pm und 36_Keyvalueprotocol.pm vermutlich über das gleiche Problem gestolpert.
Ich habe in dem entsprechendem Thread vom Lacross Modul schon meldung gemacht.
https://forum.fhem.de/index.php/topic,125603.msg1207114.html#msg1207114 (https://forum.fhem.de/index.php/topic,125603.msg1207114.html#msg1207114)
Ich hoffe es ist das gleiche problem - und ich hoffe HCS kann auch für sein Keyvalueprotocoll.pm eine Lösung anbieten.
2022-02-09 21:17:48 KVPUDP UDPServer UNKNOWNCODE OK VALUES ESP GardenDoor state=UDP-Client angemeldet,T=X,D=X
2022-02-09 21:18:37 KVPUDP UDPServer UNKNOWNCODE OK VALUES ESP GardenDoor state=UDP-Client angemeldet,T=X,D=X
2022-02-09 21:18:40 KVPUDP UDPServer UNKNOWNCODE OK VALUES ESP Toniebox State=UDP-Client TonieBox angemeldet,P=X,V=X
2022-02-09 21:19:51 KVPUDP UDPServer UNKNOWNCODE OK VALUES ESP MainDoor state=UDP-Client MainDoor angemeldet,T=X,D=X
Sorry das es so lange gedauert hat den Fehler zu finden, ich habe das Familiäre gejammer über nicht funktionierende Türöffner und mp3-player wohl zu lange ignoriert.
Bitte poste mal ein List vom KVPUDP
Gerne.
Internals:
FD 14
FUUID 5c4470fe-f33f-68f5-5258-307c1e8892fe5246
MSGCNT 792
NAME UDPServer
NR 119
RAWMSG OK VALUES ESP MainDoor state=alive
STATE Opened
TIME 2022-02-10 00:14:37
TYPE KVPUDP
MatchList:
1:KeyValueProtocol ^OK\sVALUES\s
PEERS:
192.168.1.149:
IP 192.168.1.149
MSGCNT 3
RAWMSG OK VALUES ESP Toniebox State=UDP-Client TonieBox angemeldet,P=X,V=X
TIME 2022-02-09 21:18:40
192.168.1.153:
IP 192.168.1.153
MSGCNT 16
RAWMSG OK VALUES ESP GardenDoor state=UDP-Client angemeldet,T=X,D=X
TIME 2022-02-09 21:18:37
192.168.1.172:
IP 192.168.1.172
MSGCNT 773
RAWMSG OK VALUES ESP MainDoor state=alive
TIME 2022-02-10 00:14:37
Attributes:
DbLogExclude .*
group Server
room 99-Controller
verbose 2
Da passt was nicht beim 36_KVPUDP.pm Modul, bei Internals fehlt der Eintrag "Clients :KeyValueProtocol:"
und nach dem ersten Dispatch muß es einen Eintrag ".clientArray: KeyValueProtocol" geben
Ok - dann sollte wohl
# $Id: 00_KVPUDP.pm 7911 2015-12-10 21:11:31Z habeIchVergessen $
################################################################
#
# Copyright notice
#
# (c) 2014 Copyright: Dr. Boris Neubert
Dr. Boris Neubert dabei schauen - eigenartig das im Header die rede von 00_KVPUDP ist, das Modul selbst aber als 36_KVPUDP.pm abgelegt ist.
Ich verstehe ja nochnichtmal was mit Dispatch überhaupt gemeint ist.
Kann aber erkennen das da was auskommentiert ist.
$hash->{TCPDev}= $socket;
$hash->{FD} = $socket->fileno();
# $hash->{Clients} = ":KeyValueProtocol";
$hash->{MatchList} = \%matchlist;
Grundsätzlich verstehe ich aber nicht was das Modul überhaupt macht. Ich weiß das es dazu nötig ist das ich mit dem Keyvalueprotocol UDP nachrichten senden und empfangen kann. Genau die funktion ist nicht mehr gegeben. Oder sagen wir mal durch das "UNKNOWN" gestört, meine weiterverarbeitung in FHEM spricht nicht mehr an.
ZitatIch verstehe ja nochnichtmal was mit Dispatch überhaupt gemeint ist.
Mit der FHEM Framework-Funktion Dispatch() bietet ein IO- bzw. physisches Modul die empfangenen Nachrichten den logischen Modulen an.
Fuer die Zuordnung physisch <-> logisch gibt es zwei Mechanismen.
- fuer bereits geladene logische Module: $io->{Clients} enthaelt die Liste der logischen Modulnamen, und $client->{Match} enthaelt den Regexp fuer die akzeptierten Nachrichten. Dieser Mechanismus ist "verpflichtend"
- optional, wenn man autocreate des logischen Moduls haben will: $io->{MatchList} enthaelt eine Liste mit "<reihenfolge>:<ClientModulname>:<NachrichtenRegexp>", also de-fakto die vorherigen Informationen.
Wegen dem in dieser Diskussion erwaehnten Bug wurde MatchList auch fuer bereits geladene Module abgearbeitet, was in bestimmten Konfigurationen zu laengeres Blockieren (aka freeze) fuehrte.
Seit dem Fix muessen aber die oben erwaehnten Variablen sowohl vorhanden, wie auch richtig befuellt sein.
Bei 36_KVPUDP.pm ist $io->{Clients} nicht befuellt, bzw. der Eintrag ist auskommentiert.
$io->{MatchList} ist auch auskommentiert, sie wird aber spaeter dynamisch befuellt. Deswegen hat das Modul bis zum Fix funktioniert.
Ok Rudi, Danke für die ausführliche erklärung - ich glaube teile davon habe ich verstanden ;)
Wie stuppsen wir nun Dr. Boris Neubert darauf sich das mal anzuschauen und zu korrigieren?
Ich hab Boris mal eine PM geschrieben und hierher verwiesen...
Das 36_KVPUDP.pm ist von habeIchVergessen, es gibt davon eine neuere Version
# $Id: 36_KVPUDP.pm 0 2017-11-00 00:00:00Z habeIchVergessen $
https://forum.fhem.de/index.php/topic,45545.msg889384.html#msg889384
und die löst das Problem..? Warum liegt die nicht im update bereit?
Die 36_KVPUDP.pm ist nicht im SVN
https://svn.fhem.de/trac/search?q=KVPUDP
Evtl muss beim $hash->{Clients} Eintrag noch ein":" hinten dran
#$hash->{Clients} = ":KeyValueProtocol:";
Es läuft auch so mit der neuen Datei...
Tausend Dank - hätte nicht gedacht das irgendwo im Forum eine neuere Version rumfliegt.
Hallo,
ich kenne das Modul 00_KVPUDP.pm nicht und ich habe auch keine Urheberrechte an dem Modul. Dass mein Name in der Copyright Notice steht, scheint ein Kopierfehler des Autors (habeIchVergessen?) zu sein, der das bitte ändern möchte.
Viele Grüße
Boris