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

Begonnen von betateilchen, 03 August 2013, 17:34:17

Vorheriges Thema - Nächstes Thema

betateilchen

could not find ParserDetails.ini in /usr/local/share/perl/5.14.2/XML/SAX

Diese Meldung kommt bei mir übrigens auch - aber das scheint nichts dramatisches zu sein.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

TeeVau

Hallo,

habe es zum laufen bekommen. Das Problem betraf auch einmal jemanden, der das HUE Modul verwendet hat. utf8_heavy.pl versucht auf .\unicore\Heavy.pl zuzugreifen, die war nicht vorhanden. Habe mir die Datei runtergaladen und auf die fbf gepackt, nun geht das gds auch.

Die /tmp/conditions wurde beim vorherigen Versuch angelegt und hatte Inhalt --> Net::FTP geht
Am XML::Simple habe ich nichts geändert, von daher gehe ich davon aus, dass alles ok ist.

Soll ich die Heavy.pl noch mal löschen, um den Fehler zu provozieren und deine geänderte Version testen?
FHEM 5.8 dev (virtualisiert) / FBF 7390 (CUL 868MHz V 1.51 / panStick (AVR1))
FS20: fs20di,fs20pira,fs20sm8,fs20st2,fs20tfk,fs20ue1,fs20ws1
panStamp (AVR1): RGB Multi von ext23, 1W-DSxxxx, I/O Sketch, Spritzpumpe
Multimedia: Panasonic TV (VIERA), Kodi, Yamaha RX-V781, LMS
Sonstiges: XiaomiFlowerSen

justme1968

klasse. endlich hat jemand das unicode problem auf der fritzbox gelöst.

es scheint so zu sein das die perl version auf den fritzboxen unvollständig ist das aber nur auffällt sobald Encode oder Decode auf daten trifft die wirklich unicode bzw utf8 sind. das schlägt natürlich auch dann zu wenn ein modul das Encode/Decode nicht direkt verwendet sondern nur indirekt wie z.b. bei hue über JSON, beim ituns modul über DAAP::DMAP und bei dem swap modul und scheinbar bei gds über XML::Simple.

magst du das vielleicht noch im wiki auf dokumentieren ?

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

betateilchen

nein, wenn es jetzt läuft, brauchst Du nicht zu testen. Die Version hat einfach ein paar zusätzlich Logmeldungen, keine neue Funktionalotät.

Die utf8_heavy.pl hängt mit XML::Simple zusammen. Von daher scheint das Decodieren jetzt zu laufen. Wenn Du bei get "conditions" und get "alerts" jetzt gefüllte Dropdownlisten hast, sollte alles ok sein.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

TeeVau

Gds funktioniert jetzt wunderbar, ich teste es die Tage mal und vergleiche die gelieferten Werte mit owo, yahoo und den eigenen Messwerten.
Was mir noch aufgefallen ist, ich habe bei mir keine Auswahl für die get Befehle, trotzt aktuellem fhem. In den anderen Modulen sind die get-Befehle, soweit unterstützt, vorhanden.

ein get myGsd ? liefert aber korrekt:

Unknown argument ?, choose one of help:noArg rereadcfg:noArg list:stations,data alerts:Kreis_Altötting,Kreis_Bad_Tölz-Wolfratshausen,Kreis_Berchtesgadener_Land,Kreis_Cham,Kreis_Dachau,Kreis_Deggendorf,Kreis_Dingolfing-Landau,Kreis_Ebersberg,Kreis_Eichstätt,Kreis_Erding,Kreis_Freyung-Grafenau,Kreis_Garmisch-Partenkirchen,Kreis_Miesbach,Kreis_Mühldorf_a._Inn,Kreis_Neuburg-Schrobenhausen,Kreis_Pfaffenhofen_a.d._Ilm,Kreis_Regen,Kreis_Rottal-Inn,Kreis_Straubing-Bogen_und_Stadt_Straubing,Kreis_Traunstein,Kreis_Weilheim-Schongau,Kreis_und_Stadt_Landshut,Kreis_und_Stadt_Passau,Kreis_und_Stadt_Regensburg,Kreis_und_Stadt_Rosenheim,Stadt_Ingolstadt conditions:Aachen,Angermünde,Arkona,Augsburg,Bad_Lippspringe,Bamberg,Berlin-Dahlem,Berlin-Tegel,Berlin-Tempelhof,Bremen-Flh.,Brocken,Cottbus,Cuxhaven,Dresden-Flh.,Düsseldorf-Flh.,Emden,Erfurt,Fehmarn,Feldberg/Schw.,Fichtelberg,Frankfurt/M-Flh.,Freudenstadt,Fritzlar,Fürstenzell,Gera,Gießen/Wettenberg,Greifswald,Grosser_Arber,Görlitz,Hahn-Flh.,Hamburg-Flh.,Hannover-Flh.,Helgoland,Hof,Hohenpeissenberg,Kahler_Asten,Karlsruhe-Rheinst.,Kassel,Kempten,Kiel,Konstanz,Köln/Bonn-Flh.,Lahr,Leipzig-Flh.,Leuchtt._Alte_Weser,Leuchtturm_Kiel,Lindenberg,List/Sylt,Magdeburg,Mannheim,Marnitz,Meiningen,München-Flh.,Münster/Osnabr.-Fl,Neuruppin,Norderney,Nürburg,Nürnberg-Flh.,OF-Wetterpark,Oberstdorf,Potsdam,Regensburg,Rostock,Saarbrücken-Flh.,Schleswig,Schwerin,Straubing,Stuttgart-Flh.,Stötten,Trier,Wasserkuppe,Weiden,Würzburg,Zugspitze,Öhringen warnings:Baden-Württemberg,Bayern,Berlin,Brandenburg,Bremen,Hamburg,Hessen,Mecklenburg-Vorpommern,Niedersachsen,Nordrhein-Westfalen,Rheinland-Pfalz,Saarland,Sachsen,Sachsen-Anhalt,Schleswig-Holstein,Thüringen


@justme
Ja, ich kann mich mal versuchen. Wird aber eine kurze Dokumentation. Den kompletten Hergang des Problems habe ich nicht verstanden, kann aber die Punkte beschreiben, die zur Lösung des Problems geführt haben. Das wird vermutlich für die meisten ausreichen, denke ich.

@betateilchen
Danke für die Unterstützung!
FHEM 5.8 dev (virtualisiert) / FBF 7390 (CUL 868MHz V 1.51 / panStick (AVR1))
FS20: fs20di,fs20pira,fs20sm8,fs20st2,fs20tfk,fs20ue1,fs20ws1
panStamp (AVR1): RGB Multi von ext23, 1W-DSxxxx, I/O Sketch, Spritzpumpe
Multimedia: Panasonic TV (VIERA), Kodi, Yamaha RX-V781, LMS
Sonstiges: XiaomiFlowerSen

betateilchen

Zitat von: TeeVau schrieb am Fr, 09 August 2013 14:34Was mir noch aufgefallen ist, ich habe bei mir keine Auswahl für die get Befehle, trotzt aktuellem fhem. In den anderen Modulen sind die get-Befehle, soweit unterstützt, vorhanden.

ein get myGsd ? liefert aber korrekt:

in GDS funktioniert das aber auch:

(http://up.picr.de/15444484ks.png)

Hast Du eventuell noch nicht alle zu den Styles gehörenden Dateien aktualisiert, die von Rudi gestern noch überarbeitet wurden?

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

TeeVau

Das du es in deinem Modul implementiert hast glaube ich dir. Habe es ja in dem Posting gelesen und auch den Screenshot gesehen. Darum verwundert es mich um so mehr, dass es bei mir mit GDS nicht funktioniert.
"update" sagt, dass alles aktuell ist. Habe gerade für die get-Befehle etwas im VIERA Modul angepasst, dort habe ich die get möglichkeiten mit FHEMWEB. Komisch.... Habe auch mal mit dem dark Style getestet, macht aber keinen Unterschied.


(siehe Anhang / see attachement)


(siehe Anhang / see attachement)
FHEM 5.8 dev (virtualisiert) / FBF 7390 (CUL 868MHz V 1.51 / panStick (AVR1))
FS20: fs20di,fs20pira,fs20sm8,fs20st2,fs20tfk,fs20ue1,fs20ws1
panStamp (AVR1): RGB Multi von ext23, 1W-DSxxxx, I/O Sketch, Spritzpumpe
Multimedia: Panasonic TV (VIERA), Kodi, Yamaha RX-V781, LMS
Sonstiges: XiaomiFlowerSen

Steffen

Hallo!

Mit der neuen Version habe ich jetzt keine Abstürze mehr und Conditions und Update klappen, leider scheint bei "Alerts" noch nicht ganz alles so bei mir zu stimmen,
denn ich habe da nur eine sehr kleine Liste von Regionen und bei der letzte Version waren viel mehr dabei z.B.:"dahme-spreewald" noch mit dabei und jetzt nicht mehr.
Ein get GDSRagow alerts 112061000 ergibt:
Kreis Görlitz - Bergland sollte aber laut Liste "Kreis Dahme-Spreewald PD LDS Dahme-Spreewald Dahme-Spreewald 12061 112061000" ergeben oder verstehe ich das noch Falsch?
Habe schon diese Versionen neu installiert: "Net::FTP, List::MoreUtils, XML::Simple",
aber ein rereadcfg bringt keine änderung.

Mfg Steffen

betateilchen

Keine Sorge, es ist grundsätzlich alles in Ordnung.

Zitat von: Steffen schrieb am Fr, 09 August 2013 15:55Ein get GDSRagow alerts 112061000 ergibt:
...
sollte aber laut Liste "Kreis Dahme-Spreewald PD LDS Dahme-Spreewald Dahme-Spreewald 12061 112061000" ergeben oder verstehe ich das noch Falsch?

Ich weiß zwar nicht, welche Liste Du meinst, aber grundsätzlich hast Du schon recht. Was Du aber offenbar noch nicht verstanden hast: Alarmmeldungen können nur angezeigt werden, wenn es welche für die gesuchte Region gibt.

Zitatdenn ich habe da nur eine sehr kleine Liste von Regionen und bei der letzte Version waren viel mehr dabei z.B.:"dahme-spreewald" noch mit dabei und jetzt nicht mehr.

Dann gibt es aktuell für die gesuchte Region "dahme-spreewald" keine Warnmeldung. Als ich das Modul neulich begonnen habe, waren zeitweise über 300 Meldungen ausgegeben, aktuell sind es immer etwa 20.

Ich habe in meinem Modul noch nicht abgefangen, dass jemand eine Region über die WARNCELLID sucht, für die es keine Meldung gibt. Erkennen kannst Du das derzeit nur im Frontend daran, dass die Anzeige komplett verlassen wird und nicht nur eine Aktualisierung stattfindet. Ich habe die Abfrage auf die ToDo-Liste gesetzt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Ok, Problem ist lokalisiert und behoben. Es wird jetzt eine entsprechende Meldung ausgegeben, wenn Warnmeldungen für eine Region gesucht werden, für die es keine gibt. Das wird auch geprüft, wenn die Suche mit der Text-ID einer nicht gewarnten Region ausgeführt wird.

Verfügbar ab #3644
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Der Abruf von bundeslandbezogenen Warnlageberichten kann jetzt auch durch Eingabe der offiziellen Länderkürzel erfolgen, zum Beispiel liefert

get gds warnings nw

die vorhandenen Warnlageberichte für Nordrhein-Westfalen.

Außerdem ist die Texteingabe der Zielregion für den Abruf jetzt nicht mehr case-sensitive. Somit sind folgende Eingaben völlig gleichbedeutend:


get gds warnings Nordrhein-Westfalen
get gds warnings nordrhein-westfalen
get gds warnings NW
get gds warnings nw



-----
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Vorschau in die laufende Entwicklung:

get gds map Deutschland

liefert:

(http://up.picr.de/15454659xt.jpg)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

TeeVau

Hallo betateilchen,

habe heute noch mal etwas nachgeforscht, wieso ich bei mir die Steuerelemente für get im FHEMWEB nicht sehe.
Es scheint an den "alerts" zu liegen. Nach dem heutigen update habe ich die Zeile 312 auskommentiert, damit sehe ich das get Steuerelement.

Per Log habe ich mir mal $aList ausgeben lassen, vielleicht findest du eine ungereimtheit?
Log 2, "DEBUG GDS: " . $aList;

2013.08.10 18:16:22 2: DEBUG GDS: Erzgebirgskreis,Erzgebirgskreis,Kreis_Altenburger_Land,Kreis_Amberg-Sulzbach,Kreis_Barnim,Kreis_Bautzen_-_Bergland,Kreis_Bautzen_-_Tiefland,Kreis_Cham,Kreis_Cuxhaven_-_Küste,Kreis_Dithmarschen_-_Küste,Kreis_Elbe-Elster,Kreis_Friesland_-_Küste,Kreis_Greiz,Kreis_Görlitz_-_Bergland,Kreis_Ludwigslust-Parchim_-_Ost,Kreis_Mecklenburgische_Seenplatte_-_West,Kreis_Meißen,Kreis_Meißen,Kreis_Mittelsachsen_-_Bergland,Kreis_Mittelsachsen_-_Tiefland,Kreis_Märkisch-Oderland,Kreis_Neumarkt_i.d._OPf.,Kreis_Neustadt_a.d._Waldnaab,Kreis_Nordfriesland_-_Küste,Kreis_Oberhavel,Kreis_Oberspreewald-Lausitz,Kreis_Oder-Spree,Kreis_Potsdam-Mittelmark,Kreis_Schwandorf,Kreis_Sächsische_Schweiz-Osterzgebirge_-_Tiefland,Kreis_Sächsische_Schweiz-Osterzgebirge_-_ostelbisches_Bergland,Kreis_Sächsische_Schweiz-Osterzgebirge_-_westelbisches_Bergland,Kreis_Tirschenreuth,Kreis_Uckermark,Kreis_Vorpommern-Greifswald_-_Binnenland_Nord,Kreis_Vorpommern-Greifswald_-_Binnenland_Süd,Kreis_Vorpommern-Greifswald_-_Küste_Nord,Kreis_Vorpommern-Greifswald_-_Küste_Süd,Kreis_Vorpommern-Rügen_-_Insel_Rügen,Kreis_Wittenberg,Kreis_Wittenberg,Kreis_Wittmund_-_Küste,Kreis_Zwickau_-_Bergland,Kreis_Zwickau_-_Tiefland,Land_Berlin,Stadt_Amberg,Stadt_Dessau-Roßlau,Stadt_Dresden,Stadt_Frankfurt_(Oder),Stadt_Weiden_in_der_Oberpfalz,Vogtlandkreis_-_Bergland,Vogtlandkreis_-_Tiefland


Verwendete Version ist # $Id: 55_GDS.pm 3656 2013-08-09 23:59:12Z betateilchen $
FHEM 5.8 dev (virtualisiert) / FBF 7390 (CUL 868MHz V 1.51 / panStick (AVR1))
FS20: fs20di,fs20pira,fs20sm8,fs20st2,fs20tfk,fs20ue1,fs20ws1
panStamp (AVR1): RGB Multi von ext23, 1W-DSxxxx, I/O Sketch, Spritzpumpe
Multimedia: Panasonic TV (VIERA), Kodi, Yamaha RX-V781, LMS
Sonstiges: XiaomiFlowerSen

betateilchen

Ich habe mir jetzt Deine aList in mein fhem kopiert, und damit kommt die Dropdownliste problemlos. Es ist schwierig, einen Fehler zu beheben, den man nicht reproduzieren kann. Kannst Du mir bitte eine /tmp/alerts schicken, mit der bei Dir das Problem auftritt?

Mach mal bitte ein "get <name> rereadcfg" das sollte im Logfile eine Ausgabe nach folgendem Muster erzeugen:


2013.08.10 21:55:28 1: I: 0 A: 14 City: Kreis_Friesland_-_Küste Cell: 903455002
2013.08.10 21:55:28 1: I: 1 A: 0 City: Kreis_Mittelsachsen_-_Tiefland Cell: 914522001
2013.08.10 21:55:28 1: I: 1 A: 1 City: Kreis_Nordsachsen_-_Süd Cell: 914730002
2013.08.10 21:55:28 1: I: 2 A: 0 City: Kreis_Meißen Cell: 114627000


und poste die Logausgabe hier.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

ui ui ui... die nächste Änderung wird etwas umfangreicher als erwartet. Mit Net::FTP bekomme ich keine vernünftige Übertragung von jpg Dateien bewerkstelligt - keine Ahnung wieso. Sämtliche möglichen Objektattribute habe ich durch - ohne Erfolg.

Testweise habe ich den Abruf von Radarbildern auf http umgebaut und siehe da: alle Bilder sind schick. Also werde ich wohl die gesamte Kommunikation auf LWP umstellen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!