[g]Seit dem Update am 18.01.22 funktioniert LaCrosse(Gateway) nicht mehr richtig

Begonnen von frober, 20 Januar 2022, 19:38:50

Vorheriges Thema - Nächstes Thema

frober

Hallo zusammen,

leider blieb meine Ursachenforschung erfolglos und mein vorheriges Update ist zu lange her.
Dank eines anderen Users könnte ich den Zeitraum auf 23.12.21 - 17.01.22 eingrenzen.

Mit mir haben sich 3 User gemeldet im Originalthread (letzte 5 Posts) vom LaCrosseGateway.
https://forum.fhem.de/index.php/topic,43672.0.html


Bezgl. LaCrosse bzw. Gateway wurde indem Zeitraum nichts geändert.

Nach dem Update wurden die Werte des interne Sensor bei mir nicht mehr aktualisiert.
2022.01.20 18:30:38 5: LaCrosseGateway: dispatch OK WS 0 4 4 190 47 255 255 255 255 255 255 255 255 0 4 5 255 255 255 255 255 255 255 255 255
2022.01.20 18:30:38 3: LaCrosseGateway: Unknown code OK WS 0 4 4 190 47 255 255 255 255 255 255 255 255 0 4 5 255 255 255 255 255 255 255 255 255, help me!


Ich habe die Sicherung zurückgespielt und nun funktioniert es wieder.

022.01.20 19:15:00 5: LaCrosseGateway: dispatch OK WS 0 4 4 190 47 255 255 255 255 255 255 255 255 0 4 5 255 255 255 255 255 255 255 255 255

setstate BME280 2022-01-20 19:06:39 IODev LaCrosseGateway
setstate BME280 2022-01-20 19:36:59 battery ok
setstate BME280 2022-01-20 19:06:46 dewpoint 9.6
setstate BME280 2022-01-20 19:36:59 error 0
setstate BME280 2022-01-20 19:36:59 humidity 46
setstate BME280 2022-01-20 19:36:59 pressure 1029
setstate BME280 2022-01-20 19:36:59 state T: 21.4 H: 46
setstate BME280 2022-01-20 19:36:59 temperature 21.4



Danke und Grüße
Bernd
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

rudolfkoenig


frober

Zitat von: rudolfkoenig am 20 Januar 2022, 20:30:19
Kannst Du das bitte mit dem gerade eingecheckten fhem.pl nochmal testen?
Siehe https://forum.fhem.de/index.php/topic,125292.msg1202195.html#msg1202195

Danke Rudi, das wars leider nicht:
2022-01-20 20:53:31 LaCrosseGateway LaCrosseGateway UNKNOWNCODE OK WS 0 4 4 193 48 255 255 255 255 255 255 255 255 0 4 5 255 255 255 255 255 255 255 255 255

P.S. ich finde auch keine Fehler im Log beim Startprozess.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

rudolfkoenig


Ralf9

Ich hab mir mal die match regex vom 36_LaCrosse.pm Modul angeschaut:
$hash->{Match}     = "^(\\S+\\s+9 | OK\\sWS\\s)";
diese ist nicht gleich wie in der Matchlist:
'30:LaCrosse'         => '^(\\S+\\s+9 |OK\\sWS\\s)',

Ich habs mal mit einem dummySduino simuliert, wenn ich bei der regex vom 36_LaCrosse.pm Modul das Leerzeichen vor dem OK entferne, funktionierts

Gruß Ralf



FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

frober

Hmm, bin mir nicht sicher, wie ich das tuen soll...

Auf der Platine des LaCrosseGateway gibt es direkte Sensoren z.B. BME280, DHT22 etc.
Diese Daten werden als LaCrosse gesendet nur nicht als OK 9, wie die TX29, sondern als OK WS und das ist, zumindest bei mir das einzige, was nicht mehr funktioniert.  OK 24 wird von PCA301 über den LGW empfangen und funktioniert.
Ein nanaCUL der auch am LGW hängt funktioniert auch.


Bsp mit verbose 5 beim LGW, funktionieren:
2022.01.20 19:15:49 5: LaCrosseGateway: dispatch OK 9 38 1 4 170 49
2022.01.20 19:15:51 5: LaCrosseGateway: dispatch OK 24 2 4 1 161 196 0 0 0 3 253
2022.01.20 19:15:51 5: LaCrosseGateway: dispatch OK 24 1 4 0 244 126 1 0 3 1 160
2022.01.20 19:15:54 5: LaCrosseGateway: dispatch OK 9 3 1 4 181 49
2022.01.20 19:15:54 5: LaCrosseGateway: dispatch OK 9 20 1 4 17 72
2022.01.20 19:15:55 5: LaCrosseGateway: dispatch OK 9 10 1 4 8 80
2022.01.20 19:15:58 5: LaCrosseGateway: dispatch OK 9 38 1 4 170 49
2022.01.20 19:15:58 5: LaCrosseGateway: dispatch OK VALUES LGW 14286823 UpTimeSeconds=748,UpTimeText=0Tg. 0Std. 12Min. 28Sek. ,WIFI=XBox10SH,ReceivedFrames=452,FramesPerMinute=34,RSSI=-70,FreeHeap=29248,LD.Min=0.34,LD.Avg=0.36,LD.Max=31.82,OLED=none
2022.01.20 19:15:59 5: LaCrosseGateway: dispatch OK WS 0 4 4 190 47 255 255 255 255 255 255 255 255 0 4 5 255 255 255 255 255 255 255 255 255
2022.01.20 19:16:03 5: LaCrosseGateway: dispatch OK 9 3 1 4 181 49
2022.01.20 19:16:03 5: LaCrosseGateway: dispatch OK 9 12 1 3 252 106
2022.01.20 19:16:03 5: LaCrosseGateway: dispatch OK 9 20 1 4 17 72


beim Fehler:
2022.01.20 18:29:37 5: LaCrosseGateway: dispatch OK 9 3 1 4 179 50
2022.01.20 18:29:37 5: LaCrosseGateway: dispatch OK WS 0 4 4 190 47 255 255 255 255 255 255 255 255 0 4 5 255 255 255 255 255 255 255 255 255
2022.01.20 18:29:37 3: LaCrosseGateway: Unknown code OK WS 0 4 4 190 47 255 255 255 255 255 255 255 255 0 4 5 255 255 255 255 255 255 255 255 255, help me!
2022.01.20 18:29:37 5: LaCrosseGateway: dispatch OK 9 38 1 4 169 49
2022.01.20 18:29:38 5: LaCrosseGateway: dispatch OK 9 20 1 4 21 72
2022.01.20 18:29:39 5: LaCrosseGateway: dispatch OK 9 12 1 3 249 106


jetzt hat gerade Ralf9 geschrieben, werde ich testen, danke
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

frober

Das funktioniert und in LaCrosseGateway steht es richtig drin.

Aber wieso hat es die ganze Zeit funktioniert?
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

frober

Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Ralf9

Durch die fehlerhafte match regex im 36_LaCrosse.pm Modul haben die "OK WS ..." Nachrichten auch vor der Optimierung in der fhem.pl nicht wie gewünscht funktioniert, es ist nur nicht aufgefallen.

Mir ist aber nicht klar warum das Leerzeichen vor dem OK so viel ausmacht. Ein Dispatch "OK ..." funktioniert, aber Dispatch "OK WS .." funktioniert nicht.
Ich verstehe das regex nicht
"^(\\S+\\s+9 |OK\\sWS\\s)"
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

frober

Danke für die Erläuterung.

Wenn es im Update ist, setze ich den Thread auf gelöst.

Danke und Grüße
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

rcmcronny

Hi,

ich  hänge mich mal mit ran, bei mir tritt es auch auf, aber beim LaCrosseGateway, da hilft der Patch aber nicht, oder ich habe was übersehen:


2022-01-21 11:24:19 LaCrosseGateway LaCrosseGW2 UNKNOWNCODE OK 9 22 1 4 66 62
2022-01-21 11:24:19 LaCrosseGateway LaCrosseGW1 UNKNOWNCODE OK 9 22 1 4 66 62
2022-01-21 11:24:21 LaCrosseGateway LaCrosseGW1 UNKNOWNCODE OK VALUES LGW 2543930 UpTimeSeconds=270591,UpTimeText=3Tg. 3Std. 9Min. 51Sek. ,WIFI=Sabersoft-IoT,ReceivedFrames=112017,FramesPerMinute=21,RSSI=-57,FreeHeap=26304,LD.Min=0.51,LD.Avg=0.53,LD.Max=12.85,OLED=none
2022-01-21 11:24:24 LaCrosseGateway LaCrosseGW1 UNKNOWNCODE OK 9 45 1 3 234 83
2022-01-21 11:24:24 LaCrosseGateway LaCrosseGW2 UNKNOWNCODE OK VALUES LGW 2273964 UpTimeSeconds=653626,UpTimeText=7Tg. 13Std. 33Min. 46Sek. ,WIFI=Sabersoft-IoT,ReceivedFrames=91954,FramesPerMinute=7,RSSI=-
2022-01-21 11:24:24 LaCrosseGateway LaCrosseGW1 UNKNOWNCODE OK 9 32 1 4 156 52
2022-01-21 11:24:27 LaCrosseGateway LaCrosseGW1 UNKNOWNCODE OK 9 22 1 4 66 62
2022-01-21 11:24:27 LaCrosseGateway LaCrosseGW2 UNKNOWNCODE OK 9 22 1 4 66 62


Irgendjemand eine Idee, was noch anzupassen ist. Das LaCrosseModul habe ich angepaßt, beim LaCrosseGateway Modul war der Regex passend.

Danke,
Ronny

HCS

Hallo zusammen,

ich habe das Topic auf der Agenda, wird aber erst am Wochenende was werden.
@frober: habe deine PM gelesen

Generell - nach dem Update konnte ich bei mir nur das "OK WS" - Problem reproduzieren, der Rest, also die "echten" Sensoren ("OK 9") haben bei mir noch funktioniert.

Zitat von: Ralf9 am 20 Januar 2022, 21:49:01
Durch die fehlerhafte match regex im 36_LaCrosse.pm Modul haben die "OK WS ..." Nachrichten auch vor der Optimierung in der fhem.pl nicht wie gewünscht funktioniert, es ist nur nicht aufgefallen.
Den verstehe ich noch nicht so recht. Ich habe jetzt jahrelang "OK WS" - Daten von meiner WS1600 und vom LGW bekommen.
Was war den eigentlich die "Optimierung" die jetzt zu dem Problem geführt hat?


rcmcronny

Hallo,

also bei mir passt alles, der Sensor mit der OK 9 ist sicher was vom Nachbarn, was sonst nie auffiel.
Das einzige,was offen ist, sind die Datenzeilen:

2022-01-21 11:24:24 LaCrosseGateway LaCrosseGW2 UNKNOWNCODE OK VALUES LGW 2273964 UpTimeSeconds=653626,UpTimeText=7Tg. 13Std. 33Min. 46Sek. ,WIFI=Sabersoft-IoT,ReceivedFrames=91954,FramesPerMinute=7,RSSI=-


Ronny

Ralf9

Zitatich  hänge mich mal mit ran, bei mir tritt es auch auf, aber beim LaCrosseGateway, da hilft der Patch aber nicht, oder ich habe was übersehen:
2022-01-21 11:24:24 LaCrosseGateway LaCrosseGW1 UNKNOWNCODE OK 9 45 1 3 234 83

Ich habe die Nachrichten mal mit dem sduino getestet, der dispatch zum LaCrosse Modul funktioniert damit.

Ich habe in der fhem.pl in der Dispatch Routine 2 Debug Log Ausgaben "SYSTEM..." eingebaut
https://forum.fhem.de/index.php/topic,125292.msg1202188.html#msg1202188

2022.01.21 16:05:38.174 4 : sduinoD/msg get dispatch: OK 9 45 1 3 234 83
2022.01.21 16:05:38.174 2 : SYSTEM sduinoD: clientloop0 m=CUL_TCM97001
2022.01.21 16:05:38.174 2 : SYSTEM sduinoD: clientloop0 m=SD_WS
2022.01.21 16:05:38.174 2 : SYSTEM sduinoD: clientloop0 m=SD_WS07
2022.01.21 16:05:38.174 2 : SYSTEM sduinoD: clientloop0 m=SD_WS09
2022.01.21 16:05:38.174 2 : SYSTEM sduinoD: clientloop0 m=Hideki
2022.01.21 16:05:38.174 2 : SYSTEM sduinoD: clientloop0 m=LaCrosse
2022.01.21 16:05:38.174 2 : SYSTEM sduinoD: clientloop1 m=LaCrosse tfound=LaCrosse_0b
2022-01-21 16:05:38.176 LaCrosse LaCrosse_0b battery: ok
2022-01-21 16:05:38.176 LaCrosse LaCrosse_0b temperature: 0.2
2022-01-21 16:05:38.176 LaCrosse LaCrosse_0b humidity: 83


ZitatWas war den eigentlich die "Optimierung" die jetzt zu dem Problem geführt hat?
Durch die Optimierung werden in der Matchlist Schleife die schon geladenen Module, die ja schon in der .clientarray Schleife auf ein match geprüft wurden, übersprungen

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

rcmcronny

Hi,

danke Ralf, also die ID 0b, das ist ein Sensor bei mir, der etwas weiter weg ist. (Ein Kartoffelkeller, wobei 0.2 Grad echt wenig sind. ABer da ist auch die Batterie fast leer)
Irgendwie kommt vom LaCrossGateway nix rein, das scheint alles bei den Sensoren von einem Jeelink zu kommen bei mir (gemäß:
LASTInputDev) . Der ist nur noch am Raspi mit FHEM dran, weil er nicht stört und als Backup dient :).

Nebenbei: Auch bei den HUE Updates gabs Probleme, Lichter gehen, Sensoren aber nicht mehr im FHEM (beide Module von vor dem Update, läufts.) Heute war echt der Wurm drin :)

EDIT:
2022-01-21 11:24:24 LaCrosseGateway LaCrosseGW2 UNKNOWNCODE OK VALUES LGW 2273964 UpTimeSeconds=653626,UpTimeText=7Tg. 13Std. 33Min. 46Sek. ,WIFI=Sabersoft-IoT,ReceivedFrames=91954,FramesPerMinute=7,RSSI=-
Ich habe das Atribute kvp auf readings gesetzt, nun werden die Daten im LaCrossGW Device angelegt und keine Fehler im Log mehr, scheint das das dispatch zum kvp nicht mehr passiert, warum auch immer und daher die Meldung kommt. Find ich so aber gar nicht schlecht, könnte man ja das KVP Device einsparen :)

Gruß Ronny

Ralf9

Zitatdanke Ralf, also die ID 0b,
Hab nochmals nachgeschaut, LaCrosse_0b ist nur der Name, eines schon definierten Sensors, der zufällig gepasst hat. Die ID ist  2D.

Die ID ist die Zahl nach dem OK 9 nach Hex gewandelt
OK 9 45 1 3 234 83  ID 2D
OK 9 32 1 4 156 52  ID 20
OK 9 22 1 4 66 62   ID 16
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

rcmcronny

Hi Ralf,

Zitat von: Ralf9 am 21 Januar 2022, 20:08:37
Hab nochmals nachgeschaut, LaCrosse_0b ist nur der Name, eines schon definierten Sensors, der zufällig gepasst hat. Die ID ist  2D.

Die ID ist die Zahl nach dem OK 9 nach Hex gewandelt
OK 9 45 1 3 234 83  ID 2D
OK 9 32 1 4 156 52  ID 20
OK 9 22 1 4 66 62   ID 16

Ok, alle 3 habe ich in Nutzung ;) 2D, 20 und auch die 16.

Auch nach Anpassung des Regex bleibt es bei "2022-01-21 11:24:24 LaCrosseGateway LaCrosseGW1 UNKNOWNCODE OK 9 45 1 3 234 83" Meldungen. Ich habe es nun erstmal mittels filter Atribut ausgefiltert, dann wird mein Log nicht im Minuten Takt aufgebläht, der Jeelink bekommt die Daten ja noch ins System.

Ronny

dyna

Hallo Zusammen,

ich nutze viele TX29 DTH-IT als Sensoren für die Themostate. Diese sind über einen JeeLink und LaCrosseGateway in fhem eingebunden.
Wenn ich aktuell update, dann funktioniert die Einbidung der TX29 DTH-IT in fhem nicht mehr.
Es gibt die gleiche Fehlermeldung mit "OK 9 ...".

Ist 36_LaCrosse.pm aus dem SVN schon upgedatet oder sollte ich die hier aus dem Post #7 benutzen?

Grüße
dyna

HCS

Zitat von: dyna am 25 Januar 2022, 12:33:18
Ist 36_LaCrosse.pm aus dem SVN schon upgedatet oder sollte ich die hier aus dem Post #7 benutzen?
Ist aktuell in SVN: # $Id: 36_LaCrosse.pm 25537 2022-01-21 17:54:29Z HCS $

dyna

Danke für die Info.

Wenn ich update und neu starte bekomme ich sofort wieder die Fehlermeldung "UNKNOWNCODE OK 9 16 1 4 30 90 ...
Wenn ich das Backup einspiele, ist der Fehler wieder weg.

Grüße
dyna

rcmcronny

Hallo,

eben getestet, ist bei mir genauso mit meinen 2 LaCrosseGateways.

Ronny

HCS

Gerade nochmal ein update gemacht - funktioniert.

Verwendet ihr das LaCrosseGateway-Modul oder noch das JeeLink-Modul um das LGW anzubinden?

rcmcronny

Hi,

hier ein List meines Moduls, aktuell habe ich per filter die OK 9 Sachen abgeschalten, da sonst mein Log voll läuft :)
Sollte das LaCrossGateway Modul sein. (
Ronny


Internals:
   Alive      2022-01-25 13:30:04
   Clients    1
   DEF        10.0.6.75:81
   DeviceName 10.0.6.75:81
   FD         20
   FUUID      5c463430-f33f-e150-9d8a-ab17c18518a8fa70
   LaCrosseGW1_MSGCNT 225
   LaCrosseGW1_TIME 2022-01-25 13:31:46
   NAME       LaCrosseGW1
   NR         50
   NTFY_ORDER 50-LaCrosseGW1
   PARTIAL   
   RAWMSG     OK VALUES LGW 2543930 UpTimeSeconds=2300,UpTimeText=0Tg. 0Std. 38Min. 20Sek. ,WIFI=Sabersoft-IoT,ReceivedFrames=919,FramesPerMinute=20,RSSI=-54,FreeHeap=26456,LD.Min=0.52,LD.Avg=0.53,LD.Max=22.60,OLED=none
   STATE      initialized
   TIMEOUT    0.5
   TYPE       LaCrosseGateway
   model      LaCrosseITPlusReader.Gateway.1.35
   nextOpenDelay 2
   settings   (1=RFM69 f:868300 r:17241) {IP=10.0.6.75}]
   MatchList:
     1:PCA301   ^\S+\s+24
     2:EC3000   ^\S+\s+22
     3:LaCrosse ^(\S+\s+9 |OK\sWS\s)
     4:EMT7110  ^OK\sEMT7110\s
     5:Level    ^OK\sLS\s
     6:KeyValueProtocol ^OK\sVALUES\s
     7:CapacitiveLevel ^OK\sCL\s
   READINGS:
     2022-01-25 13:31:46   FramesPerMinute 20
     2022-01-25 13:31:46   FreeHeap        26456
     2022-01-25 13:31:46   OLED            none
     2022-01-25 13:31:46   RSSI            -54
     2022-01-25 13:31:46   ReceivedFrames  919
     2022-01-25 13:31:46   UpTime          0Tg. 0Std. 38Min. 20Sek.
     2022-01-25 13:31:46   UpTimeSeconds   2300
     2022-01-25 13:31:46   state           initialized
   helper:
Attributes:
   Clients    1
   filter     ^OK 9
   kvp        readings
   mode       WiFi
   room       LaCrosse,IO
   timeout    120
   usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
   watchdog   300


Ralf9

ZitatAttributes:
   Clients    1
Bitte lösche mal das Attribut Clients
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

HCS


rcmcronny

Hi,

das wars :) Danke. Das hab ich sicher aber schon seit Ewigkeiten drin :)
Danke fürs zeigen :)

Ronny

dyna

Vielen Dank,

das war auch hier die Lösung Attribut Clients gelöscht. Jetzt fehlerfrei.

Grüße
dyna

der-Lolo

Guten Abend zusammen,
auch ich stolpere gerade in meiner FHEM installation über das "UNKNOWNCODE" problem.
Ich habe drei ESPs die via UDP ihre nachrichten an FHEM schicken.
Realisiert ist das über das 36_KVPUDP.pm Modul in verbindung mit dem KeyValueProtocol Modul.

Kann es sein das hier der gleiche Fehler vorhanden ist..?

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


Meine weiterverarbeitenden Devices innerhalb FHEM springen nicht mehr an.

Da Du HCS hier ja offensichtlich auch Maintainer bist, kannst Du mir vielleicht sagen ob wir hier über das gleiche problem reden..?
Müsste demnach # $Id: 36_KeyValueProtocol.pm 20300 2019-10-03 18:47:47Z HCS $
die gleiche anpassung erfahren wie das LaCross Modul..?


HCS

Zitat von: der-Lolo am 09 Februar 2022, 23:19:04
Realisiert ist das über das 36_KVPUDP.pm Modul in verbindung mit dem KeyValueProtocol Modul.

36_KeyValueProtocol.pm in Kombination mit 36_LaCrosseGateway.pm hat kein Problem.

Keine Ahnung, was 36_KVPUDP.pm ist, aber es ist nicht von mir und ich sehe auch in SVN kein Modul mit diesem Namen.
Wo kommt das denn her?

der-Lolo

Ich hab auch keine Ahnung wo es herkommt - ralf09 hat irgendwo im Forum aber eine neuere Version gefunden als die die ich benutzt hatte...
Hab die Dateien ausgetauscht - problem behoben.