55_GDS.pm - komplett überarbeitet - RC1

jensb · 26 Oktober 2015, 23:35:31

Das Entfernen des 2. GDS-Devices ändert leider nichts, es bleibt bei den vielen Aktualisierungen.

ZitatGDS_CONDITIONS_READ 1445898361
GDS_FORECAST_ABORTED Mon Oct 26 23:27:23 2015
GDS_REREAD 1445898360

c_weather ist allerdings wieder aufgetaucht. Das scheint daran zu liegen, dass bei meiner Station das Feld für weather manchmal nichts oder "---" enthält und dann das Reading gelöscht wird. Habe übrigens noch keine Möglichkeit gefunden einem DOIF beizubringen, mit solchen optionalen Readings zurecht zu kommen, denn die Perl-Funktion "defined" lässt sich dafür scheinbar nicht verwenden.

betateilchen · 27 Oktober 2015, 09:59:17

Zitat von: jensb am 26 Oktober 2015, 23:18:13
Werde eine aus der Konfig löschen und dann noch mal testen. Danke für die Hinweise.

Ab RC6 wird die Möglichkeit, mehrere gds-Devices zu definieren, komplett unterbunden.

Die eigentliche Philosophie von gds war von Anfang an (und ist bis heute), nur Daten zu beschaffen und bereitzustellen. Und das ganze "batchfähig" - also beispielsweise aus beliebigen Funktionen aus der 99_myUtils.pm. Du könntest also mit zwei "get <> conditions <station1>" die readings befüllen, in ein Array lesen und dann mit "get <> conditions <station2>" die Readings neu befüllen und in Deiner myUtils.pm die Mittelwerte errechnen und weiterverwenden.

So ähnlich arbeite ich mit den alerts: Da ich die alerts für mehrere Regionen brauche, wird jeweils mit "get <> alerts <region>" der entsprechende Datensatz in die readings geschrieben und dann die readings ausserhalb von gds weiterverarbeitet.

Das ist übrigens auch der Grund, warum es für die alerts keine automatische Aktualisierung innerhalb des Moduls gibt.

betateilchen · 27 Oktober 2015, 10:03:25

Zitat von: jensb am 26 Oktober 2015, 23:35:31
Das Entfernen des 2. GDS-Devices ändert leider nichts, es bleibt bei den vielen Aktualisierungen.

Ok, die Conditions wurden gelesen, die Forecasts nicht. Definiere Dir mal ein at im 10-Minuten Rhytmus, das ein "get <> rereadcfg" durchführt und beobachte, ob sich das irgendwann beruhigt.

betateilchen · 27 Oktober 2015, 13:01:02

Zitat von: jensb am 26 Oktober 2015, 22:21:34
Die Forecast-Readings _date und _weekday werden mit aktualisiert, allerdings nur einmal

Das ist inzwischen behoben, da war in RC5 noch ein Tippfehler ( s/AttrVall/AttrVal/; )

betateilchen · 27 Oktober 2015, 13:37:23

man beachte die TimeStamps... Aktualisierungen wie erwünscht

(http://up.picr.de/23525605xk.jpg)

(http://up.picr.de/23525606uz.jpg)

(http://up.picr.de/23525607tb.jpg)

(http://up.picr.de/23525608or.jpg)

jensb · 27 Oktober 2015, 20:59:24

Habe weiter getestet und inzwischen eine Idee, warum es bei mir nicht funktioniert:

"sub retrieveData" wird bei "get rereadcfg" 3mal hintereinander aufgerufen und damit forkt FHEM jedesmal, so dass u.U. 3 FTP-Verbindungen gleichzeitig aufgebaut werden, wenn der Verbindungsaufbau und der Transfer mehr als Sekundenbruchteile benötigen. Genau das passiert bei mir (vielleicht weil mein RPi nicht so schnell ist), was ein Aufruf von netstat bestätigt (sehe z.T. mehr als 10 gleichzeitige Verbindungen zu 141.38.3.183:21 im Zustand ESTABLISHED) und bei 2 gleichzeitigen Verbindung ist beim DWD ja leider Schluss.

Die einzelnen _retrieveXXXX müsste man untereinander blockieren, so dass immer nur einer aktiv ist und die anderen warten müssen.

Außerdem wird bei mir retrieveData(FORECAST) im Sekundentakt 16mal hintereinander aufgerufen, was u.a. zu den mehrfachen Logs "Timeout for _retrieveFORECAST reached, terminated process nnnnn" führt. Das ist wohl ein Folgefehler, da GDS_FORECAST_READ bei mir nie gesetzt wird und damit über "sub GDS_GetUpdate" immer wieder neu angefordert wird und auch "getConditions" immer wieder aufgerufen wird.

betateilchen · 27 Oktober 2015, 21:23:00

Zitat von: jensb am 27 Oktober 2015, 20:59:24
"sub retrieveData" wird bei "get rereadcfg" 3mal hintereinander aufgerufen und damit forkt FHEM jedesmal, so dass u.U. 3 FTP-Verbindungen gleichzeitig aufgebaut werden,

Das hab ich doch weiter oben schon genau so geschrieben?

Zitat von: jensb am 27 Oktober 2015, 20:59:24
wenn der Verbindungsaufbau und der Transfer mehr als Sekundenbruchteile benötigen.

Das ist eigentlich kein Problem. Bei mir dauert z.B. das retrieveFORECAST über 15 Sekunden (das sind immerhin bis zu 90 Dateien!) und alles läuft problemlos.

Zitat von: jensb am 27 Oktober 2015, 20:59:24
Genau das passiert bei mir (vielleicht weil mein RPi nicht so schnell ist),

Ich entwickle auf einem RaspberryPi Typ A, langsamer gehts kaum...

Zitat von: jensb am 27 Oktober 2015, 20:59:24
was ein Aufruf von netstat bestätigt (sehe z.T. mehr als 10 gleichzeitige Verbindungen zu 141.38.3.183:21 im Zustand ESTABLISHED) und bei 2 gleichzeitigen Verbindung ist beim DWD ja leider Schluss.

Ich glaube nicht, dass bei Dir 10 Verbindungen gleichzeitig aufgebaut werden, ich vermute aus dem Bauch heraus, dass bei Dir die Verbindungen nicht korrekt abgebaut/geschlossen werden.

Zitat von: jensb am 27 Oktober 2015, 20:59:24
Die einzelnen _retrieveXXXX müsste man untereinander blockieren, so dass immer nur einer aktiv ist und die anderen warten müssen.

Nein, muss man nicht. Sonst hätte ich mir den ganzen Aufwand nämlich sparen können.

Sag mal - ganz was Andere: Du arbeitest nicht zufällig mit einer Fritzbox als Internetzugang?

jensb · 27 Oktober 2015, 21:38:57

Habe in _retrieveForecast ein Start- und ein Ende-Log eingefügt. Die Starts kommen alle, die Enden nicht. Da hängt also was. Da auch das connected Log nicht kommt, hängt wohl der Verbindungsaufbau.

Habe tatsächlich eine FritzBox. Soll ich mal passives FTP ausprobieren?

betateilchen · 27 Oktober 2015, 21:41:07

Zitat von: jensb am 27 Oktober 2015, 21:38:57
Habe tatsächlich eine FritzBox.

Da haben wir das Problem.

Zitat von: jensb am 27 Oktober 2015, 21:38:57
Soll ich mal passives FTP ausprobieren?

Kannst Du gerne testen. Viel Hoffnung hab ich aber nicht.

jensb · 27 Oktober 2015, 21:51:37

Mir ist nicht klar, warum die FritzBox für die neue Modulversion ein Problem ist. Hast du dazu mehr Infos?

betateilchen · 27 Oktober 2015, 21:56:36

ZitatMir ist nicht klar, warum die FritzBox für die neue Modulversion ein Problem ist. Hast du dazu mehr Infos?

Die Fritzbox ist für unzählige Probleme die Ursache. Das kannst Du hier im Forum schon seit Jahren seitenlang nachlesen, das müssen wir hier nicht noch einmal aus dem Urschleim diskutieren. Es ist einfach so.

betateilchen · 27 Oktober 2015, 21:57:54

Falls Du irgendwo die Möglichkeit hast, den Raspberry ohne eine Fritzkotz dazwischen ins Internet zu bringen, teste einfach nochmal.

jensb · 27 Oktober 2015, 22:15:20

ZitatFalls Du irgendwo die Möglichkeit hast, den Raspberry ohne eine Fritzkotz dazwischen ins Internet zu bringen, teste einfach nochmal.

Kurzfristig sehe ich da keine Möglichkeit. Mein alter Speedport ist glaube ich auch eine verkappte FritzBox und kann kein VoIP $:-\$ .

betateilchen · 27 Oktober 2015, 23:17:43

Laß uns mal systematisch vorgehen.

checke morgen den RC6 aus, den ich in Kürze einchecke
lösche die Attribute gdsUseForecasts und gdsUseAlerts
setze das Attribut "gdsUseFritzkotz" auf 1
teste und berichte, ob die Conditions korrekt gelesen werden.

jensb · 27 Oktober 2015, 23:31:56

Hat sich wohl gerade wieder überschnitten. Werde das natürlich trotzdem testen. Hier mein aktueller Stand:

Mit passivem FTP klappt die Übertragung und es gibt keine Blocking-Timeouts mehr.

Während der FTP-Transfer läuft (dauert für Conditions, Alerts und Forecasts bei mir ca. 13 Sekunden) werden im Sekundentakt immer wieder neue retrieveData(FORECAST) angestoßen. Könnte man in GDS_GetUpdate verriegeln, wenn man sich in "sub retrieveData" den jeweiligen Start-Zeitstempel als InternelReading merkt.

Vermisse aktuell allerdings noch einzelne Readings (z.B. die Vorhersage von Freitag früh), konnte aber noch nicht herausfinden, ob der DWD die Daten momentan nicht liefert oder ob die Verarbeitung klemmt. Werde das noch untersuchen.