55_GDS.pm - es muss nicht immer Yahoo, openweathermap usw. sein

[betateilchen]

Füge mal bitte in Zeile 834 folgendes ein:

Code Auswählen Erweitern

Log 3, "$line - extracting: ".$item;

und poste die Ausgabe im Logfile, vielleicht hast Du ja ein neues reading entdeckt *g*

[mcfly71]

Hmm das habe ich gemacht, jetzt kommt der "Fehler" nicht mehr....

Hat sich wohl erledigt

Wann kommt denn diese Meldung im Log-File ?

configfile: gds_web_DW already defined, delete it first

In der cfg steht das ganze nur 1 mal ???

[betateilchen]

Wann kommt denn diese Meldung im Log-File ?

Wenn Du z.B. ein get <name> conditions <region> aufrufst.

configfile: gds_web_DW already defined, delete it first
In der cfg steht das ganze nur 1 mal ???

Ja, Und genau das "in der cfg stehen" ist das Problem :o) Stör Dich nicht dran, die Meldung stellt kein Problem dar.

[TeeVau]

Hallo,

wie wäre denn der Ablauf um etwas zu automatisieren, wenn alerts für die eigene Region vorliegen?!
Bei mir ist es so, dass sich die alerts nicht automatisch update, das muss ich selber anstoßen per rereadcfg. Zudem müsste ich dann selber auch die alerts für die gesuchte Region pollen.
Gibt es einen Weg das mit dem Modul automatisch zu machen, oder muss man die Daten zyklisch per at abholen und dann entsprechend auswerten?
Bevor ich es umständlich mache, frage ich lieber mal nach einem einfachen Weg :-)

[betateilchen]

Eine automatische Aktualisierung ist derzeit nicht vorgesehen, dazu werden die Warnungen von seiten des DWD einfach zu häufig aktualisiert (alle 5 Minuten). Ein rereadcfg würde ich Dir auch nicht empfehlen, das aktualisiert und parst ja immer auch die kompletten conditions.

Meine Vorgehensweise:

1. "get gds alerts 105116000" (sucht Warnmeldungen für Mönchengladbach und füllt die readings entsprechend, sofern etwas gefunden wurde)
2. danach prüfen, ob das reading a_valid = 1 (wenn ja, gibt es eine aktuell gültige Wetterwarnung)

Bei mir läuft (1.) als at Definition alle 30 Minuten. Eine eventuell vorhandene Wetterwarnung wird in fhem per RSS bereitgestellt, der automatisch aktualisiert wird.

[betateilchen]

da hat sich heute ein Fehler eingeschlichen (kommt davon, wenn man sowas schreibt, während man keinen Zugriff auf die eigene Konfiguration hat)

Man muss natürlich tatsächlich erst ein "get gds rereadcfg" machen, bevor die Warnmeldung für eine bestimmte Region extrahiert werden kann.

[TeeVau]

Danke! Dann mach ich mich dran :-)

[betateilchen]

Die automatische Aktualisierung der alerts wurde übrigens aus Performancegründen absichtlich nicht eingebaut. So ein alerts-File kann durchaus einmal mehrere MB groß sein. Das verursacht massive Netzwerklast und das Parsen einer solch großen Datei dauert auch etwas. Ich fand (und finde nach wie vor) die flexible Lösung per at einfach sinnvoller.

[TeeVau]

Ist ja kein Problem, man muss es nur wissen.
Was mir aufgefallen ist, dass manchmal gds nicht mehr aktualisiert, obwohl per set conditions xyz eine Wetterstation gesetzt wurde.
Ein set rereadcfg behebt das Problem wieder. Kannst du vielleicht temporär dein at mal deaktivieren, damit nicht alle 30 Minuten ein rereadcfg gemacht wird?! Das sollte zum nachstellen reichen. Ich glaube das Problem tritt u.a. auf, wenn FHEM ein restart macht.

Code Auswählen Erweitern


2013.08.26 19:25:08 1: configfile: gds_web_myGds already defined, delete it first
2013.08.26 19:24:54 3: GDS myGds: using HTTP for retrieval
2013.08.26 19:24:54 3: GDS myGds: retrieving Z_CAP_C_EDZW_20130826172001_PVW_STATUS.xml
2013.08.26 19:24:53 3: GDS myGds: searching for gds/specials/warnings/xml/PVW/Z_CAP* on DWD server
2013.08.26 19:24:53 3: GDS myGds: using FTP for retrieval
2013.08.26 19:24:53 3: GDS myGds: retrieving SXDL99_DWAV_20130826_1714
2013.08.26 19:24:52 3: GDS myGds: searching for gds/specials/observations/tables/germany/* on DWD server
2013.08.26 19:24:37 3: Registering HTTPSRV gds_web_myGds for URL /myGds...
2013.08.26 19:24:37 3: GDS myGds: tempDir=/tmp/
2013.08.26 19:24:37 3: GDS myGds: created
2013.08.26 19:24:36 3: owo myOwo: created
2013.08.26 19:24:32 2: VIERA: defined with host: 192.168.178.31 and interval: 30
2013.08.26 19:24:32 2: FB_CALLMONITOR: FBF read 193 contacts from FritzBox phonebook
2013.08.26 19:24:32 2: FB_CALLMONITOR: FBF found FritzBox phonebook /var/flash/phonebook
2013.08.26 19:24:32 3: FBF device opened
2013.08.26 19:24:32 3: Opening FBF device 192.168.178.1:1012
2013.08.26 19:24:30 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2013.08.26 19:24:30 3: CUL_0 device opened
2013.08.26 19:24:30 3: Setting CUL_0 baudrate to 9600
2013.08.26 19:24:29 3: Opening CUL_0 device /dev/ttyACM0
2013.08.26 19:24:28 3: WEBtablet: port 8085 opened
2013.08.26 19:24:28 3: WEBphone: port 8084 opened
2013.08.26 19:24:28 3: WEB: port 8083 opened
2013.08.26 19:24:27 3: telnetPort: port 7072 opened
2013.08.26 19:24:26 1: Including fhem.cfg
2013.08.26 19:24:22 0: Server shutdown


Es gab danach aber keine aktualisierung mehr. Erst ein rereadcfg hat geholfen:

Code Auswählen Erweitern


2013.08.27 11:26:41 3: GDS myGds: using FTP for retrieval
2013.08.27 11:26:41 3: GDS myGds: retrieving SXDL99_DWAV_20130827_0914
2013.08.27 11:26:40 3: GDS myGds: searching for gds/specials/observations/tables/germany/* on DWD server
2013.08.27 11:26:40 3: GDS myGds: Retrieving conditions data
2013.08.27 10:26:40 3: GDS myGds: using FTP for retrieval
2013.08.27 10:26:40 3: GDS myGds: retrieving SXDL99_DWAV_20130827_0814
2013.08.27 10:26:39 3: GDS myGds: searching for gds/specials/observations/tables/germany/* on DWD server
2013.08.27 10:26:39 3: GDS myGds: Retrieving conditions data



Edit:
Hab mich vertan, es reicht kein rereadcfg, es muss ein neues set conditions sein.
c_nextUpdate bleibt bei dem Fehler auch auf dem alten Update stehen (Heute stand es z.B. auf dem 27. Aug, 12 Uhr irgendwas)

[betateilchen]

hast Du mal das set conditions direkt in die fhem.cfg geschrieben?

edit: probier das nicht[/b] *grummel*


du kannst aber in die fhem.cfg folgende at-Definition aufnehmen:

Code Auswählen Erweitern

define gdsDummy at +00:00:30 set gds conditions Helgoland

Damit wird 30 Sekunden nach dem FHEM-Start das set automatisch durchgeführt.
Und das hat bei mir auch ein "shutdown restart" überlebt.

[justme1968]

du kannst ein notify an global INITIALIZED hängen. das wird getriggert wenn fhem gestartet hat. das ist besser als die zeit zu schätzen.

das kannst du übrigens auch im modul code direkt per NotifyFn und dann dinge tun die du nach dem fhem start ein mal tun möchtest.

ach ja. noch etwas: hast du dir mal BlockingCall angeschaut? das wäre vielleicht etwas um zumindest das ftp im hintergrund zu machen. ein beispiel findest du z.b. im speedtest modul.

gruss
  andre

[betateilchen]

Hallo Andre,

das kannst du übrigens auch im modul code direkt per NotifyFn und dann dinge tun die du nach dem fhem start ein mal tun möchtest.

Das Problem dabei ist, dass das Modul selbst ja gar nicht weiss, was es tun soll ;) Die Sache mit dem notify auf INITIALIZED wäre eine Option, aber ich bin grundsätzlich kein Freund von notify, die nur ein einziges Mal ausgeführt werden.

Zur Sache mit dem FTP im Hintergrund: Normalerweise stellt die Dauer der FTP Übertragung kein Problem dar. Die DWD Server sind ausreichend schnell und die Dateigrößen halten sich in Grenzen.
Die conditions-Datei ist generell unter 10kB groß, die alerts-Datei im Durchschnitt unter 500kB. Aktuell ist sie 502 Byte groß, weil es derzeit keine Unwetterwarnungen im Bundesgebiet gibt.
Ausnahmesituationen wie eine bundesweite Unwetterlage mit über 300 gleichzeitig gültigen Meldungen kommen ja nicht jeden Tag vor.

[rudolfkoenig]

> ich bin grundsätzlich kein Freund von notify, die nur ein einziges Mal ausgeführt werden.

Man kann NotifyFn nach der Benutzung :) auch entfernen, damit sollte sie keine zusaetzliche Last verursachen, das macht auch Telnet so.

[betateilchen]

Natürlich.

Das ändert aber immer noch nichts daran, dass mir das im vorliegenden Fall überhaupt nichts nützen würde, weil die einmalig auszuführende Aufgabe nicht vom Modul selbst festgelegt ist, sondern vom Anwender bestimmt wird.

[TeeVau]

Hallo,

ich habe mit bereits mit einem notify abhilfe geschaffen, dennoch danke für den Hinweis.
Wollte von dem Verhalten berichten, denn in meinen Augen ist es ein Bug im Modul.
Wenn man ein set conditions macht sollte diese Station gespeichert werden (reading oder helper) und einen restart überleben, ohne dass der Nutzer nach einem restart erneut ein set conditions machen muss.