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 (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
Kannst Du das bitte mit dem gerade eingecheckten fhem.pl nochmal testen?
Siehe https://forum.fhem.de/index.php/topic,125292.msg1202195.html#msg1202195
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 255P.S. ich finde auch keine Fehler im Log beim Startprozess.
Kannst mir bitte eine Anweisung zum Nachstellen beschreiben?
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
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
Das funktioniert und in LaCrosseGateway steht es richtig drin.
Aber wieso hat es die ganze Zeit funktioniert?
Anbei der Patch, wenn es in Ordnung ist.
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)"
Danke für die Erläuterung.
Wenn es im Update ist, setze ich den Thread auf gelöst.
Danke und Grüße
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
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?
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
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: 83ZitatWas 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
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
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
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
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
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 $
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
Hallo,
eben getestet, ist bei mir genauso mit meinen 2 LaCrosseGateways.
Ronny
Gerade nochmal ein update gemacht - funktioniert.
Verwendet ihr das LaCrosseGateway-Modul oder noch das JeeLink-Modul um das LGW anzubinden?
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
ZitatAttributes:
Clients 1
Bitte lösche mal das Attribut Clients
Gerade wollte ich es schreiben :-)
Hi,
das wars :) Danke. Das hab ich sicher aber schon seit Ewigkeiten drin :)
Danke fürs zeigen :)
Ronny
Vielen Dank,
das war auch hier die Lösung Attribut Clients gelöscht. Jetzt fehlerfrei.
Grüße
dyna
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..?
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?
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.