GDS verursacht massive Blockaden von Fhem

[Michi240281]

Hallo zusammen,

da mein HMLAN sich ständig neu verbindet, habe ich mir jetzt mal perfmon installiert und dabei das GDS-Modul als bösen Übeltäter entdeckt:

Code Auswählen Erweitern

2015.02.23 21:00:01.988 5: HMLAN_Parse: HMLAN1 R:RB8066415 stat:0002 t:00000000 d:FF r:7FFF     m:76 8002 23A6D7 27DEB8 01014D00
2015.02.23 21:00:01.989 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852411 d:23A6D7 O:23A6D7 t:14B90332 IDcnt:0016
2015.02.23 21:00:05.009 5: exec at command readGDS
2015.02.23 21:00:05.010 5: Cmd: >get gds rereadcfg<
2015.02.23 21:00:05.019 4: GDS gds: searching for gds/specials/observations/tables/germany/* on DWD server
2015.02.23 21:00:05.549 4: GDS gds: ftp connection established.
2015.02.23 21:00:06.556 4: GDS gds: filelist found.
2015.02.23 21:00:06.565 4: GDS gds: retrieving SXDL99_DWAV_20150223_1914
2015.02.23 21:00:06.566 4: GDS gds: using FTP for retrieval
2015.02.23 21:00:06.913 4: GDS gds: updating readings.
2015.02.23 21:00:06.919 4: GDS gds: searching for gds/specials/warnings/xml/PVW/Z_CAP* on DWD server
2015.02.23 21:00:07.057 4: GDS gds: ftp connection established.
2015.02.23 21:00:07.632 4: GDS gds: filelist found.
2015.02.23 21:00:07.635 4: GDS gds: retrieving Z_CAP_C_EDZW_20150223195057_PVW_STATUS.xml
2015.02.23 21:00:07.636 4: GDS gds: using HTTP for retrieval
2015.02.23 21:00:09.943 4: GDS gds: updating readings.
2015.02.23 21:00:25.401 5: redefine at command readGDS as +*00:10:00 get gds rereadcfg
2015.02.23 21:00:25.406 1: Perfmon: possible freeze starting at 21:00:05, delay is 20.405

Kann das jmd bestätigen? Was kann ich dagegen machen?

[betateilchen]

Kann das jmd bestätigen?

ja.

Was kann man da machen?

nicht benutzen.

[smurfix]

nicht benutzen.

Oder so umschreiben, dass es asynchron arbeitet.

Das ist leider bei Weitem nicht die einzige Stelle, an der FHEM blockierende externe Zugriffe macht ...

[betateilchen]

Oder so umschreiben, dass es asynchron arbeitet.

Es gab schon eine Version, die nonblocking arbeitet. Aber da viele Anwender dieses Moduls aufgrund ihrer fehlenden Bereitschaft, die Doku zum Modul zu lesen, geistig völlig damit überfordert zu sein scheinen aus dem Modul die Daten zu bekommen, die sie möchten, gab es damals noch viel größere Probleme...

[Motivierte linke Hände]

So ein Unverständnis kann auch an einer Kombination von Sender und Empfänger liegen, nicht immer ist nur der Empfänger schuld/faul/doof. Garbage in/Garbage out kann auch beitragen.

Ich habe versucht, die über Commandref und Threads verstreuten, evolvierenden Informationen in einem Wiki-Eintrag zu konsolidieren. Vielleicht hilft's. Was mir noch helfen würde, wäre eine Beschreibung der Readings. Z.B. die c_ Readings mit Zeitangabe, sind das Messwerte der vergangenen  Zeiträume oder Prognosen für die kommende Zeit. Z.B. c_rain1h - letzte Stunde oder nächste?

[betateilchen]

Was mir noch helfen würde, wäre eine Beschreibung der Readings. Z.B. die c_ Readings mit Zeitangabe

Manchmal reicht auch einfach ein Blick ins Modul selbst...

Code Auswählen Erweitern


1318 ####################################################################################################
1319 #
1320 # Further informations
1321 #
1322 # DWD's data format is unpleasant to read,
1323 # since the data columns change depending on the available data
1324 # (e.g. the SSS column for snow disappears when there is no snow).
1325 # It's also in ISO8859-1, i.e. it contains non-ASCII characters. To
1326 # avoid problems, we need some conversion subs in this program.
1327 #
1328 # Höhe  : m über NN
1329 # Luftd.: reduzierter Luftdruck auf Meereshöhe in hPa
1330 # TT    : Lufttemperatur in Grad Celsius
1331 # Tn12  : Minimum der Lufttemperatur, 18 UTC Vortag bis 06 UTC heute, Grad Celsius
1332 # Tx12  : Maximum der Lufttemperatur, 18 UTC Vortag bis 06 UTC heute, Grad Celsius
1333 # Tg24  : Temperaturminimum 5cm ¸ber Erdboden, 22.05.2014 00 UTC bis 24 UTC, Grad Celsius
1334 # Tn24  : Minimum der Lufttemperatur, 22.05.2014 00 UTC bis 24 UTC, Grad Celsius
1335 # Tm24  : Mittel der Lufttemperatur, 22.05.2014 00 UTC bis 24 UTC, Grad Celsius
1336 # Tx24  : Maximum der Lufttemperatur, 22.05.2014 00 UTC bis 24 UTC, Grad Celsius
1337 # Tmin  : Minimum der Lufttemperatur, 06 UTC Vortag bis 06 UTC heute, Grad Celsius
1338 # Tmax  : Maximum der Lufttemperatur, 06 UTC Vortag bis 06 UTC heute, Grad Celsius
1339 # RR1   : Niederschlagsmenge, einstündig, mm = l/qm
1340 # RR12  : Niederschlagsmenge, 12st¸ndig, 18 UTC Vortag bis 06 UTC heute, mm = l/qm
1341 # RR24  : Niederschlagsmenge, 24stündig, 06 UTC Vortag bis 06 UTC heute, mm = l/qm
1342 # SSS   : Gesamtschneehöhe in cm
1343 # SSS24 : Sonnenscheindauer 22.05.2014 in Stunden
1344 # SGLB24: Tagessumme Globalstrahlung am 22.05.2014 in J/qcm
1345 # DD    : Windrichtung
1346 # FF    : Windgeschwindigkeit letztes 10-Minutenmittel in km/h
1347 # FX    : höchste Windspitze im Bezugszeitraum in km/h
1348 # ---   : Wert nicht vorhanden
1349 #
1350 ####################################################################################################

[Motivierte linke Hände]

Es reicht immer ein Blick an die richtige Stelle! Man muss nur wissen, wo diese ist.  Von daher danke, dass Du mich draufgestoßen hast.

Wenn ich dann trotzdem nochmal nachfragen darf: In der Kommentierung verwendest Du häufig den 22.05.2014. Ist das als "Vortag" oder als "heute" zu verstehen?

Wäre es korrekt, wenn ich ins Wiki schriebe, dass diese Werte alle gemessene, rückblickende Werte und keine Prognosen sind?

[betateilchen]

Die Werte werden alle über "conditions" abgebildet und nicht als "forecast".
Demnach sind es logischerweise tatsächlich gemessene Werte.
Damit erübrigt sich auch Deine Frage nach dem erwähnten Datum.

[Motivierte linke Hände]

Vielen Dank für Deine freundliche Hilfe.

[Michi240281]

Mir ist gerade in den Sinn gekommen, das GDS Modul auf die Fritzbox (auf der ich eine Mini-Instanz zur Anwesenheitserkennung laufen habe) zu tranferieren und die Daten dann per Fhem2Fhem abrufe! Habe dazu 2 Fragen:

1. Würde das überhaupt was bringen?
2. Wie müsste ich das umsetzen? (nutze Fhem2Fhem bislang wie gesagt nur für die Anwesenheit) --> müsste ich mir im HauptFhem Dummies für jedes einzelne Reading vom GDS (dann auf der FB) erzeugen und die Daten an diese übergeben oder kann man auch alle Readings in einen einzigen Dummy schreiben lassen?

Danke vielmals!!

[betateilchen]

Gegenvorschlag:

• Das Perl Modul Coro::LWP installieren (auf debian basierten Systemen: apt-get install libcoro-perl)
• Das morgige update des GDS Moduls abwarten.
• Nochmal testen.

[Michi240281]

Gegenvorschlag:

• Das Perl Modul Coro::LWP installieren (auf debian basierten Systemen: apt-get install libcoro-perl)
• Das morgige update des GDS Moduls abwarten.
• Nochmal testen.

Ok, werde ich testen!

OT: Gerade den Umzug auf RPi2 beendet! --> jetzt rennt Fhem ohne Ende!

[Hollo]

Um nochmal auf den Anfang des Threads zurück zu kommen...
Das GDS-Modul ist 1 Modul, dass dazu beitragen kann, dass die keepalive-Nachricht nicht rechtzeitig beim HMLAN ankommt.

Gerade beim Raspi kommt aber auch noch die Anbindung des Ethernetports über den USB-Controller hinzu.
Mit mehreren USB-Devices kann das auch zu Timingproblemen führen.

Der/das HMLAN selbst ist aber auch recht pingelig, um nicht zu sagen... doof.

Ich habe daher:
- GDS-Updates nur tagsüber stündlich und nachts gar nicht
- den Raspi B durch einen Banana Pro ersetzt
- den HMLAN am Switch fest auf 10MBit Halbduplex eingestellt

Damit sind die Timeouts von "bei jeder GDS-Aktualisierung + x" auf ca. 1-2x am Tag gesunken.

[betateilchen]

Auf dem Cubietruck hatte ich auch noch nie Verzögerungen von 20 Sekunden.