59_Weather.pm - Vorschläge

Begonnen von betateilchen, 12 Januar 2019, 20:34:24

Vorheriges Thema - Nächstes Thema

betateilchen

Zuerst: Danke für die Überarbeitung an alle Beteiligten.

Heute habe ich umgestellt auf das neue Modul + DarkSkyApi, funktioniert soweit auch ganz gut. Zwei Dinge hätte ich für die Wunschliste.


  • Luftdruckangabe in hPa fände ich zeitgemäßer als mbar (im Reading state)
  • ein Attribut "expert" (analog zu HomeMatic) mit dem man den Umfang der dargestellten Readings einstellen kann. In manchen Fällen brauche ich gar keine forecast, in anderen Fällen nur die nächsten zwei Tage. Gab es nicht früher ein solches Attribut in dem Modul?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

satprofi

wie umgestellt?
dachte erst morgen?
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

marvin78

Per FHEM Update ab morgen. Im SVN wird es schon liegen.

CoolTux

Hallo Udo,

Ein expert Mode finde ich gut. Das deaktivieren des Forcast ist ohne weiteres Möglich, wenn man den Code entsprechend an passt.
Ein beschränken des Forcast nur bedingt. Der Forcast kann Stunden sein (wie bei OpenWeatherMap) oder eben Tage. Müsste man mal schauen. Im Grunde würde man nur sagen wie viel Forecast Datensätze geschrieben werden sollen. Egal ob Tage oder Stunden gemeint sind.
Das von Dir gemeinte Attribut ist bestimmt das welches Du beim erstellen des Weblinks als 2 Parameter an die Funktion mit übergibst.

Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

betateilchen

Ja, kann sein, dass ich das mit dem weblink verwechsle.

Ob forecast sich auf Stunden oder Tage bezieht, ist mir eigentlich wurscht. Wenn ich expert = 3 setze, möchte ich gern drei Datensätze haben. Wenn ich expert = 0 setze, gar keine. Wenn das Attribut fehlt = alle anzeigen.

Zwei Dinge sind mir in der commandref aufgefallen


  • bei den readings steht .locense statt .license
  • die Tabellen zu den API sind sehr unübersichtlich, insbesondere weil bei openweathermap plötzlich darkskyapi drinsteht
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

CoolTux

Zitat von: betateilchen am 12 Januar 2019, 20:52:35
Ja, kann sein, dass ich das mit dem weblink verwechsle.

Ob forecast sich auf Stunden oder Tage bezieht, ist mir eigentlich wurscht. Wenn ich expert = 3 setze, möchte ich gern drei Datensätze haben. Wenn ich expert = 0 setze, gar keine. Wenn das Attribut fehlt = alle anzeigen.

Zwei Dinge sind mir in der commandref aufgefallen


  • bei den readings steht .locense statt .license
  • die Tabellen zu den API sind sehr unübersichtlich, insbesondere weil bei openweathermap plötzlich darkskyapi drinsteht

Vielen Dank für die Bug Meldung.
Bei Deinem Beispiel würde ich nicht auf das Attribut expert kommen sondern eher als Attribut forecast nehmen.
forecast 3
Drei Datensätze für Forecast. Bei Null keine und wenn kein Attribut alle.

Was hälst davon? Oder verstehe ich Dich da nicht richtig?


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Benni

Vielleicht wäre es besser, das Attribut eher forecast oder forecastCount oder noch besser forecastLimit zu nennen, statt expert. Es handelt sich ja nicht um einen Expertenmodus im eigentlichen Sinn.

gb#


Edit: 2 Dumme ein Gedanke  ;D

CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

betateilchen

nenne es, wie Du willst :) 

Es geht wieder um das unlösbare Thema "Standardisierung" in FHEM, darüber will ich nicht schon wieder diskutieren.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

CoolTux

Zitat von: betateilchen am 12 Januar 2019, 21:07:56
nenne es, wie Du willst :) 

Es geht wieder um das unlösbare Thema "Standardisierung" in FHEM, darüber will ich nicht schon wieder diskutieren.
Gerade bei Standardisierung bin ich voll bei Dir.
Expert ist schön und gut, sagt aber erstmal nur aus das man mehr Möglichkeiten hat. Entweder mehr setter oder mehr getter, oder mehr Attribute die Sichtbar werden. So wäre zu mindest meine Auffassung.

Ich werde morgen mal was vorbereiten mit forecastLimit und es in mein Git schupsen. Würde mich freuen wenn Du es dann testen magst. Ich gebe Bescheid wenn es soweit ist.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

KernSani

Tschuldigung, wenn ich da kurz einhake (bitte ignorieren wenn ich falsch liege) - ich bin mir nicht ganz sicher, ob das selbe Verständnis bezüglich forecastLimit besteht
* Udo hätte gerne die Möglichkeit "den Umfang der dargestellten Readings " einzustellen - bei gleichbleibender Funktionalität (kompletter Forecast wird geladen)
* Unter forecastLimit  würde ich verstehen, dass nur n Datensätze geladen werden (Proplanta kann das)

Ich fände beide Funktionalitäten gut, wobei ich - ehrlich gesagt - sehr selten in das Modul reinschaue, außer ich will irgendwas basteln  - meistens bekomme ich alles was ich häufig brauche über readingsgroup/weblink...
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

CoolTux

Zitat von: KernSani am 12 Januar 2019, 21:36:54
Tschuldigung, wenn ich da kurz einhake (bitte ignorieren wenn ich falsch liege) - ich bin mir nicht ganz sicher, ob das selbe Verständnis bezüglich forecastLimit besteht
* Udo hätte gerne die Möglichkeit "den Umfang der dargestellten Readings " einzustellen - bei gleichbleibender Funktionalität (kompletter Forecast wird geladen)
* Unter forecastLimit  würde ich verstehen, dass nur n Datensätze geladen werden (Proplanta kann das)

Ich fände beide Funktionalitäten gut, wobei ich - ehrlich gesagt - sehr selten in das Modul reinschaue, außer ich will irgendwas basteln  - meistens bekomme ich alles was ich häufig brauche über readingsgroup/weblink...

Da stehe ich gerade auf dem Schlauch.
Wo ist da jetzt der Unterschied? Aber um es mal kurz zu sagen. Es werden immer alle Forecastdaten vom Anbieter geladen und auch im erstellten API Object als Cache vorgehalten. Nur das scheiben der Readings wird begrenzt auf die Anzahl welche angegeben ist. So wäre meine Idee.
Bei den jetzigen API's ginge das noch nicht mal das nur n Forcast Datensätze geladen werden.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

LuckyDay


KernSani

Zitat von: CoolTux am 12 Januar 2019, 21:49:49
Da stehe ich gerade auf dem Schlauch.
Wo ist da jetzt der Unterschied? Aber um es mal kurz zu sagen. Es werden immer alle Forecastdaten vom Anbieter geladen und auch im erstellten API Object als Cache vorgehalten. Nur das scheiben der Readings wird begrenzt auf die Anzahl welche angegeben ist. So wäre meine Idee.
Bei den jetzigen API's ginge das noch nicht mal das nur n Forcast Datensätze geladen werden.
Ok, dann bitte ignorieren ;-) Ich habe dein Forecast-Limit so verstanden, wie das bei Proplanta der Fall ist - dass einfach weniger Daten geladen werden. Einen "expert" level dagegen so, dass nicht nur die Anzahl der angezeigten FC-days, sondern möglicherweise auch die Art der readings in der Anzeige eingeschränkt wird.
   
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

betateilchen

Mir geht es darum, dass nur eine bestimmte Anzahl von readings aus den vom Wetterdienst geladenen Daten erzeugt wird.

Welchen Sinn es hat, den gesamten Datenbestand im Cache vorzuhalten, verstehe ich nicht. Muss ich aber auch nicht.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Christoph Morrison

Ich hätte gerne (Wünschdirwas!) einen Filter, z.B. per Regex oder so, mit dem ich sagen kann: Bitte erzeuge nur die Readings für die Bewölkung / den UV-Index / whatever, gerne kombiniert mit einem Limit auf die vorhergesagten Tage. Proplanta z.B. erzeugt Myriaden an Readings, die bestimmt irgendwie interessant sind, die ich aber aktuell nicht brauche - aber vielleicht in Zukunft und deshalb sollte das konfigurierbar sein. Proplanta erzeugt aktuell rund 720 Readings, von denen ich maximal 10 oder so benutze.

cbl

Auch ich habe heute umgestellt. Vielen Dank für eure Arbeit!

Eine Frage habe ich, die mir die (neue) CommandRef nicht beantwortet. Wie im alten Modul gibt es "Code" als Reading für die aktuellen Wetterverhältnisse. Bislang habe ich diesen Yahoo-Code als einen Baustein meiner Beschattung ausgewertet. Im überarbeiteten Modul gibt es den Code weiterhin als Reading. In der DarkSkyAPI-Beschreibung taucht "code" nicht auf. Übersetzt das neue Modul verschiedene Informationen von DarkSky in die alten Yahoo-Codes? Dann wäre ein Hinweis irgendwo darauf ganz nützlich.

Ob ich den Code noch länger verwenden muss, prüfe ich gerade, da das neue Modul ja eine Reihe Readings liefert, die Yahoo nicht hatte (oder ich dort zumindest nie wahrgenommen habe, als ich danach gesucht habe im letzten Sommer).

Gruß
Christian

CoolTux

Zitat von: cbl am 13 Januar 2019, 11:58:21
Auch ich habe heute umgestellt. Vielen Dank für eure Arbeit!

Eine Frage habe ich, die mir die (neue) CommandRef nicht beantwortet. Wie im alten Modul gibt es "Code" als Reading für die aktuellen Wetterverhältnisse. Bislang habe ich diesen Yahoo-Code als einen Baustein meiner Beschattung ausgewertet. Im überarbeiteten Modul gibt es den Code weiterhin als Reading. In der DarkSkyAPI-Beschreibung taucht "code" nicht auf. Übersetzt das neue Modul verschiedene Informationen von DarkSky in die alten Yahoo-Codes? Dann wäre ein Hinweis irgendwo darauf ganz nützlich.

Ob ich den Code noch länger verwenden muss, prüfe ich gerade, da das neue Modul ja eine Reihe Readings liefert, die Yahoo nicht hatte (oder ich dort zumindest nie wahrgenommen habe, als ich danach gesucht habe im letzten Sommer).

Gruß
Christian

Hallo Chris,

Wir haben versucht so weit wie möglich kompatibel zu Yahoo zu bleiben, daher werden die Informationen der API versucht in Yahoo Codes zu übersetzen.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

didi-fritz

ich habe auf OpenWeatherMapAPI umgestellt.

ich bekomme jetzt 3-stundenreadings (hfc1_.. - hfc40_..)

kann ich irgendwie die alten Tages-readings (fc1_.. - fc10_..) bekommen?

CoolTux

Aktuell nur mit der DarkSky API
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Gisbert

Ich habe sowohl die DarkSkyAPI als auch die OpenWeatherMapAPI in Benutzung.

Ich erhalte folgende codes und conditions:
Bei OpenWeatherMap:
code
35
2019-01-13 13:50:42
condition
Mäßiger Regen
2019-01-13 13:50:42

Bei DarkSky:
code
11
2019-01-13 13:40:40
condition
Leichter Regen und Wind
2019-01-13 13:40:40


Das ist inhaltlich sicher ähnlich, aber nicht identisch. Da ich die Yahoo-Wettercodes für einen Schutz einer Verschattungsanlage gegen "Schlechtwetter" eingesetzt habe, ist mir dran gelegen, zuverlässige und verbindliche codes und/oder conditions zu bekommen.

Gibt es eine Liste oder ist eine geplant dieser codes oder conditions? Kann ich unterstützend tätig werden?

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

CoolTux

and (([?weatherStahnsdorfYahoo:code] >= 0 and [?weatherStahnsdorfYahoo:code] < 5) or ([?weatherStahnsdorfYahoo:code] > 22 and [?weatherStahnsdorfYahoo:code] < 25)

So habe ich das bei mir als Beispiel seit Jahren in Verwendung. Für Regen!
Aktuell kann ich nichts anderes anbieten. Unterschiedliche Meldungen ergeben unterschiedliche Mappings.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Gisbert

Ok verstehe.

Im Moment habe ich bei OpenWeatherMap:
code  9  2019-01-13 15:23:22
condition  Nieselregen  2019-01-13 15:23:22

d.h. dann müsstest du deine Bedingungen ändern, falls du Regen feststellen möchtest (ich nehme mal an, dass Nieselregen auch unter Regen fällt).
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

mi.ke

So, hab auch problemlos (vielen Dank) umgestellt

Zitat von: betateilchen am 12 Januar 2019, 20:34:24

  • Luftdruckangabe in hPa fände ich zeitgemäßer als mbar (im Reading state)

Fände ich auch besser.

Ich weiss, ich bin jetzt bestimmt pingelig. :-\
Und bitte wie bei den anderen Wettermodulen auch verwendet 'H' und nicht 'F' für Luftfeuchtigkeit

Cheers
mi.ke
FHEM 5.9 | RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 4 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301, arlo, Aqara

PNinBB

1. Dank an die "Macher"; ich bin gerade dabei es einzurichten.
2. Zwei ganz kleine Hinweise zur deutschen Dokumentation:
Define
    define <name> Weather [API=<API>[,<apiotions>]] [apikey=<apikey>] [location=<location>] [interval=<interval>] [lang=<lang>]
    Die Parameter haben die folgende Bedeutung:
. . . .

Bei "apiotions' fehlt das 'p'.
Ein kleines Stück darunter zu 'API-spezifischen Dokumentation':

OpenWeatherMap
API DarkSkyAPI

Müsste dort dann nicht statt 'DarkSkyAPI' 'OpenWeatherMapAPI' stehen ?
Schönen Abend
Peter
Raspi 4B + RaZberry2 (Deb 10), FritzBox 7490;
AEOTec: KeyFobGen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGK: 10x: 3x; FGBS: 001: 8x, 222: 1x; FGMS001: 2x; FGR: 222: 3x, 223: 2x; FGRGBWM-441: 1x; FGBS: 222: 2x, 223: 2x,224: 1x;
Philio: PAN06-1A: 3x;

Felix_86

Ich habe das neue Wetter-Modul nun doch mit OpenWeather zum Laufen gebracht.

Wäre es möglich im State zwischen dem Typ und dem Wert ein Leerzeichen zu setzen?
Also anstatt:
T:8°C F:87% W:11km/h P:1002mbar
eher
T: 8°C F: 87% W: 11km/h P: 1002mbar

Das wäre in meinen Augen besser lesbar und würde in einem Plot die Regexp erleichtern (dort heißt die Regexp nun nämlich "Wetter.T:8°C" und lässt sich nicht darstellen).

Die Yahoo API hat seinerzeit keinen Maßeinheit aufgeführt, wäre für mich und den Plot auch ok
T: 0  H: 92  W: 8  P: 992
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 320 Device
SIGNALduino (TCM, TX, IT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS

CoolTux

Zitat von: PNinBB am 13 Januar 2019, 17:05:25
1. Dank an die "Macher"; ich bin gerade dabei es einzurichten.
2. Zwei ganz kleine Hinweise zur deutschen Dokumentation:
Define
    define <name> Weather [API=<API>[,<apiotions>]] [apikey=<apikey>] [location=<location>] [interval=<interval>] [lang=<lang>]
    Die Parameter haben die folgende Bedeutung:
. . . .

Bei "apiotions' fehlt das 'p'.
Ein kleines Stück darunter zu 'API-spezifischen Dokumentation':

OpenWeatherMap
API DarkSkyAPI

Müsste dort dann nicht statt 'DarkSkyAPI' 'OpenWeatherMapAPI' stehen ?
Schönen Abend
Peter

Danke Dir. Das werde ich noch korrigieren.




Zitat von: Felix_86 am 13 Januar 2019, 17:22:06
Ich habe das neue Wetter-Modul nun doch mit OpenWeather zum Laufen gebracht.

Wäre es möglich im State zwischen dem Typ und dem Wert ein Leerzeichen zu setzen?
Also anstatt:
T:8°C F:87% W:11km/h P:1002mbar
eher
T: 8°C F: 87% W: 11km/h P: 1002mbar

Das wäre in meinen Augen besser lesbar und würde in einem Plot die Regexp erleichtern (dort heißt die Regexp nun nämlich "Wetter.T:8°C" und lässt sich nicht darstellen).

Die Yahoo API hat seinerzeit keinen Maßeinheit aufgeführt, wäre für mich und den Plot auch ok
T: 0  H: 92  W: 8  P: 992

Ich denke darüber lässt sich reden. Also das mit dem Leerzeichen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

macs

Mir ist was aufgefallen bei der Windgeschwindigkeit: Anstatt km/h müssten es m/s sein. Ich habe es mit der Webseite verglichen. Immerhin ein Faktor 3,6 Unterschied ;-)

CoolTux

Zitat von: macs am 13 Januar 2019, 18:06:27
Mir ist was aufgefallen bei der Windgeschwindigkeit: Anstatt km/h müssten es m/s sein. Ich habe es mit der Webseite verglichen. Immerhin ein Faktor 3,6 Unterschied ;-)

Cool hatte mich schon gewundert das das so gering ist, aber bei mir war das immer recht Windstill. Bei ich heute Abend um, oder besser erweitere ich.

Danke
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux

Ich habe eben noch mal geschaut. Zu mindest für DarkSky sind es km/h
Zitat
except that windSpeed and windGust are in kilometers per hour
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux

bei OpenWeatherMap sind es m/s
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Frank_Huber

Zitat von: CoolTux am 13 Januar 2019, 18:28:47
Ich habe eben noch mal geschaut. Zu mindest für DarkSky sind es km/h
Bei mir liefern aber beide APIs nahezu gleiche Werte.
Diese kommen mir aber in der Tat etwas klein vor.
hmmm....

mi.ke

Zitat von: CoolTux am 13 Januar 2019, 18:28:47
Ich habe eben noch mal geschaut. Zu mindest für DarkSky sind es km/h

Aktuell über DarkSkyApi zeigt es "wind_speed 12" und
condition "Frische Brise und überwiegend bewölkt" an.

Laut Definition:
Starker Wind 10,8 - 13,8 m/s    | 39 - 49 Km/h | 22 - 27 Knt  | 6 Bft

scheinen es doch m/s zu sein.

Cheers
mi.ke
FHEM 5.9 | RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 4 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301, arlo, Aqara

CoolTux

Also ich kann gerne pro forma ein 3.6 Faktor einbauen. Alternativ kann bitte jemand mit der Webansicht vergleichen?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

rischbiter123

Moin,

es sind tatsächlich m/s in den Readings. In Wilhelmshaven lt. Reading 11, lt. Website 39.

LG

Andreas
4*Raspi, Max Thermostate und Fensterkontakte, FB7590, Mysensors und NanoCUL, IT und Sonoff, zigbee2mqtt2

CoolTux

Zitat von: rischbiter123 am 13 Januar 2019, 19:11:29
Moin,

es sind tatsächlich m/s in den Readings. In Wilhelmshaven lt. Reading 11, lt. Website 39.

LG

Andreas

Danke Dir. Ich habe auch gerade mal geschaut und kann das bestätigen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Gisbert

Wie ist das weitere Vorgehen bei den Windgeschwindigkeiten bei DarkSky und bei OpenWeatherMap? Ich wäre für km/h in Fhem.
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

CoolTux

Ich auch. Vorerst werde ich es auch so einsetzen.
Müssen schauen wie es mit Leuten ist die in Gegenden leben wo milen eine Rolle spielt.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Frank_Huber

Zitat von: CoolTux am 13 Januar 2019, 19:41:26
Ich auch. Vorerst werde ich es auch so einsetzen.
Müssen schauen wie es mit Leuten ist die in Gegenden leben wo milen eine Rolle spielt.
könnte man nicht über die System locale prüfen welche Einheiten ein System verwendet?

CoolTux

Nein. Entscheidend ist wie der Lieferant die Daten liefert. Aktuell ist bei beiden APIs auto aktiv, es wird also anhand der Location entsprechend geliefert.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

bastelfeak

Hallo,
erst einmal vielen Dank für dei schnelle Änderung des Moduls.
Mit DarkSky, einer Wegwerf-Mailadresse und 10 Minuten frickeln, konnte alles anpassen.

Eine kleine Anmerkung meinerseits: Die Wochentage werden leider trotz Spracheinstellung lang=de gekürzt auf Englisch übergeben.

Wenn ich mir die Vorhersage anschaue, bin ich auch nicht sonderlich glücklich:
Condition= Vormittag frische Brise und Nachmittag Nebel.
precipProbability=0.91

Also für mich eigentlich Regenwetter.
Kann man daran noch was machen oder ist man auf die Daten von DarkSky angewiesen?



PNinBB

Ich bin gerade beim Einrichten von OpenWeatherMap und wundere mich über Details des eingerichteten Gerätes.

define WetterOpenWetter Weather api=OpenWeatherMapAPI,cachemaxage:600 apikey=xxxxxxxxxxxxxxxxxxx interval=3600 language=de

In der eingerichteten Instanz wird als API allerdings DarkSkyAPI ausgewiesen.

Internals:
   API        DarkSkyAPI
   APIKEY     xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   APIOPTIONS cachemaxage:600
   DEF        api=OpenWeatherMapAPI,cachemaxage:600 apikey=xxxxxxxxxxxxxxxxxxxxx interval=3600 language=de
   INTERVAL   3600
   LANG       de
   LOCATION   xx.yyyyyy,xx.yyyyyyyy
   NAME       WetterOpenWetter
   NOTIFYDEV  global
   NR         524
   NTFY_ORDER 50-WetterOpenWetter
   STATE      API Maintainer: Leon Gaultier (<a href=https://forum.fhem.de/index.php?action=profile;u=13684>CoolTux</a>) ErrorMsg: DarkSky Weather decode JSON err malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "permission denied\n") at FHEM/DarkSkyAPI.pm line 192.

   TYPE       Weather

Ist das so in Ordnung ??
Danke für einen Hinweis.
Peter
Raspi 4B + RaZberry2 (Deb 10), FritzBox 7490;
AEOTec: KeyFobGen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGK: 10x: 3x; FGBS: 001: 8x, 222: 1x; FGMS001: 2x; FGR: 222: 3x, 223: 2x; FGRGBWM-441: 1x; FGBS: 222: 2x, 223: 2x,224: 1x;
Philio: PAN06-1A: 3x;

marvin78

Wie vielerorts beschrieben, muss API groß geschrieben werden.

Lippie

Hallo,

für die WebLink-Anzeige der stündlichen Vorhersage habe ich folgenden Änderungsvorschlag sub WeatherAsHtmlH ( ab Zeile 549 ):

  my $ret = '<table class="weather">';
  my $fc = ( (defined($h->{READINGS}->{fc1_day_of_week}) and $h->{READINGS}->{fc1_day_of_week}) ? 'fc' : 'hfc' );
  my $DayHour = ($fc eq 'fc' ? '_day_of_week' : '_pubDate' );
 
  # icons
  $ret .= sprintf('<tr><td class="weatherIcon" width=%d>%s</td>', $width, WeatherIconIMGTag(ReadingsVal($d, "icon", "")));
  for(my $i=1; $i<$items; $i++) {
    $ret .= sprintf('<td class="weatherIcon" width=%d>%s</td>', $width, WeatherIconIMGTag(ReadingsVal($d, "${fc}${i}_icon", "")));
  }
  $ret .= '</tr>';

  # condition
  $ret .= sprintf('<tr><td class="weatherDay">%s</td>', ReadingsVal($d, "condition", ""));
  for(my $i=1; $i<$items; $i++) {
    $ret .= sprintf('<td class="weatherDay">%s: %s</td>', ReadingsVal($d, "${fc}${i}$DayHour", ""),
        ReadingsVal($d, "${fc}${i}_condition", ""));
  }
  $ret .= '</tr>';


Damit wird nicht nur der Tag angezeigt.

gleiches für WeatherAsHtmlV (ab Zeile 513):

my $fc = ( (defined($h->{READINGS}->{fc1_day_of_week}) and $h->{READINGS}->{fc1_day_of_week}) ? 'fc' : 'hfc' );
  my $DayHour = ($fc eq 'fc' ? '_day_of_week' : '_pubDate' );
 
  for(my $i=1; $i<$items; $i++) {
    $ret .= sprintf('<tr><td class="weatherIcon" width=%d>%s</td><td class="weatherValue"><span class="weatherDay">%s: %s</span><br><span class="weatherMin">min %s°C</span> <span class="weatherMax">max %s°C</span></td></tr>',
        $width,
        WeatherIconIMGTag(ReadingsVal($d, "${fc}${i}_icon", "")),
        ReadingsVal($d, "${fc}${i}$DayHour", ""),
        ReadingsVal($d, "${fc}${i}_condition", ""),
        ReadingsVal($d, "${fc}${i}_low_c", ""), ReadingsVal($d, "${fc}${i}_high_c", ""));
  }


Beste Grüße
Lippie

PNinBB


Wie vielerorts beschrieben, muss API groß geschrieben werden.

Danke für den Tipp; gleich ging es !
Noch ein Fehler in der deutschen Dokumentation: dort ist 'api' in den Beispielen klein geschrieben. Von dort hatte ich es kopiert und angepasst !
Schönen Abend.
Peter
Raspi 4B + RaZberry2 (Deb 10), FritzBox 7490;
AEOTec: KeyFobGen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGK: 10x: 3x; FGBS: 001: 8x, 222: 1x; FGMS001: 2x; FGR: 222: 3x, 223: 2x; FGRGBWM-441: 1x; FGBS: 222: 2x, 223: 2x,224: 1x;
Philio: PAN06-1A: 3x;

CoolTux

Zitat von: bastelfeak am 13 Januar 2019, 20:07:32
Hallo,
erst einmal vielen Dank für dei schnelle Änderung des Moduls.
Mit DarkSky, einer Wegwerf-Mailadresse und 10 Minuten frickeln, konnte alles anpassen.

Eine kleine Anmerkung meinerseits: Die Wochentage werden leider trotz Spracheinstellung lang=de gekürzt auf Englisch übergeben.

Wenn ich mir die Vorhersage anschaue, bin ich auch nicht sonderlich glücklich:
Condition= Vormittag frische Brise und Nachmittag Nebel.
precipProbability=0.91

Also für mich eigentlich Regenwetter.
Kann man daran noch was machen oder ist man auf die Daten von DarkSky angewiesen?

Das liegt an Deiner locale Einstellung von der linux distrie wo das FHEM drauf läuft. Die ist bei Dir englisch.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Lippie

in der DarkSkyAPI werden für die daily-forecasts werte wie partly-cloudy-night und clear-night ausgegeben. Das sieht etwas unschön aus bei der täglichen Wettervorhersage.
ich habe die Zuordnung bei mir folgendermaßen geändert:
my %codes_day = (
    'clear-day'           => 32,
    'clear-night'         => 32,
    'rain'                => 11,
    'snow'                => 16,
    'sleet'               => 18,
    'wind'                => 24,
    'fog'                 => 20,
    'cloudy'              => 26,
    'partly-cloudy-day'   => 30,
    'partly-cloudy-night' => 30,
    'hail'                => 17,
    'thunderstorm'        => 4,
    'tornado'             => 0,
);


Dazu noch zu Lookup-Funktion für daily-Abfragen:
'code' => $codes_day{ $data->{daily}->{data}->[$i]->{icon} }

Grüße
Lippie

didi-fritz

#47
Da ich nach der Umstellung auf OpenWeatherMapAPI  jetzt nur 3-stundenreadings (hfc1_.. - hfc40_..) bekomme, hab ich mir eine function in 99_myUtils gebaut, die die alten Tages-readings (fc1_.. - fc10_..) und den pressure_trend_txt so gut wie möglich nachbaut...


sub calcWeather
{
    my ($w, $rest) = @_;

    Log 2, "calcWeather(\"$w\")";

    my $hfcCnt=0;
    my $fcCnt=0;

    my $Dday="";
    my $Ddate="";
    my $Dcode="";
    my $Dcondition="";
    my $Dpressure="";
    my $Dhigh_c=0;
    my $Dlow_c=0;
    my $Dicon="";
    my $p1=0;
    my $p2=0;

    #my $pubDate=ReadingsVal($w, "hfc${hfcCnt}_pubDate",0);
    #my $d=substr($pubDate,0,3);

    for ($hfcCnt=1; $hfcCnt<=40; $hfcCnt++)
    {
        my $pubDate  =ReadingsVal($w, "hfc${hfcCnt}_pubDate",0);
        my $code     =ReadingsVal($w, "hfc${hfcCnt}_code",0);
        my $condition=ReadingsVal($w, "hfc${hfcCnt}_condition",0);
        my $pressure =ReadingsVal($w, "hfc${hfcCnt}_pressure",0);
        my $icon     =ReadingsVal($w, "hfc${hfcCnt}_icon",0);
        my $high_c   =ReadingsVal($w, "hfc${hfcCnt}_high_c",0);
        my $low_c    =ReadingsVal($w, "hfc${hfcCnt}_low_c",0);
       
        my $day =substr($pubDate,0,3);
        my $date=substr($pubDate,5);

        if ( $day ne $Dday )
{

    if ($fcCnt > 0)
    {
fhem( "setreading $w fc${fcCnt}_high_c $Dhigh_c; setreading $w fc${fcCnt}_low_c $Dlow_c; setreading $w fc${fcCnt}_icon $Dicon; setreading $w fc${fcCnt}_code $Dcode; setreading $w fc${fcCnt}_condition $Dcondition; setreading $w fc${fcCnt}_date $Ddate; setreading $w fc${fcCnt}_day_of_week $Dday; setreading $w fc${fcCnt}_pressure $Dpressure; ");
    }

    $fcCnt++;

    $Dday      =$day ;
    $Ddate     =$date;
    $Dcode     =$code;
    $Dcondition=$condition;
    $Dpressure =$pressure;
    $Dicon     =$icon;
    $Dhigh_c   =$high_c;
    $Dlow_c    =$low_c;

            $p1=$pressure if ($fcCnt==1);
            $p2=$pressure if ($fcCnt==2);
}else{
    $Dhigh_c = $high_c  if ( $high_c > $Dhigh_c );
    $Dlow_c  = $low_c   if ( $low_c < $Dlow_c );
    if ( $date =~ /12:00/ )
            {
        $Ddate     =$date;
        $Dcode     =$code;
        $Dcondition=$condition;
        $Dpressure =$pressure;
        $Dicon     =$icon;

                $p1=$pressure if ($fcCnt==1);
                $p2=$pressure if ($fcCnt==2);
    }
}

    }

    my $fcCntNext=$fcCnt+1;

    fhem( "setreading $w fc${fcCnt}_high_c $Dhigh_c; setreading $w fc${fcCnt}_low_c $Dlow_c; setreading $w fc${fcCnt}_icon $Dicon; setreading $w fc${fcCnt}_code $Dcode; setreading $w fc${fcCnt}_condition $Dcondition; setreading $w fc${fcCnt}_date $Ddate; setreading $w fc${fcCnt}_day_of_week $Dday; setreading $w fc${fcCnt}_pressure $Dpressure; deletereading $w fc${fcCntNext}_.*;  ");

    my $Dp= $p2 - $p1;
    my $pTxt="";
    if ( $Dp > 24 )
  {  $pTxt="stark steigend"; }
    elsif ( $Dp > 6 )
  {  $pTxt="steigend"; }
    elsif ( $Dp > -6 )
  {  $pTxt="gleichbleibend"; }
    elsif ( $Dp > -24 )
  {  $pTxt="fallend"; }
    else
  {  $pTxt="stark fallend"; }

    fhem( "setreading $w pressure_trend_txt $pTxt ");

}


ich triggere diese function mit einem notify.

def n_WetterVorschau notify  WetterVorschau:current_date_time.* { calcWeather($NAME) }


könnt ihr diese function in die OpenWeatherMapAPI  übernehmen?

danke
didi

PNinBB

Noch eine kleine Frage zum 'update'.
Werden diese Abfragen 'non-blocking' ausgeführt? Ich vermute doch: ja.  Ich habe aber weder in den Einstellungen noch in den Attributen etwas zum Einstellen gefunden.
Wenn ich 'update' anstosse, sieht man auch keinen weiteren Prozess.
Nochmals besten Dank
Peter
Raspi 4B + RaZberry2 (Deb 10), FritzBox 7490;
AEOTec: KeyFobGen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGK: 10x: 3x; FGBS: 001: 8x, 222: 1x; FGMS001: 2x; FGR: 222: 3x, 223: 2x; FGRGBWM-441: 1x; FGBS: 222: 2x, 223: 2x,224: 1x;
Philio: PAN06-1A: 3x;

CoolTux

Zitat von: didi-fritz am 14 Januar 2019, 07:22:25
Da ich nach der Umstellung auf OpenWeatherMapAPI  jetzt nur 3-stundenreadings (hfc1_.. - hfc40_..) bekomme, hab ich mir eine function in 99_myUtils gebaut, die die alten Tages-readings (fc1_.. - fc10_..) und den pressure_trend_txt so gut wie möglich nachbaut...


sub calcWeather
{
    my ($w, $rest) = @_;

    Log 2, "calcWeather(\"$w\")";

    my $hfcCnt=0;
    my $fcCnt=0;

    my $Dday="";
    my $Ddate="";
    my $Dcode="";
    my $Dcondition="";
    my $Dpressure="";
    my $Dhigh_c=0;
    my $Dlow_c=0;
    my $Dicon="";
    my $p1=0;
    my $p2=0;

    #my $pubDate=ReadingsVal($w, "hfc${hfcCnt}_pubDate",0);
    #my $d=substr($pubDate,0,3);

    for ($hfcCnt=1; $hfcCnt<=40; $hfcCnt++)
    {
        my $pubDate  =ReadingsVal($w, "hfc${hfcCnt}_pubDate",0);
        my $code     =ReadingsVal($w, "hfc${hfcCnt}_code",0);
        my $condition=ReadingsVal($w, "hfc${hfcCnt}_condition",0);
        my $pressure =ReadingsVal($w, "hfc${hfcCnt}_pressure",0);
        my $icon     =ReadingsVal($w, "hfc${hfcCnt}_icon",0);
        my $high_c   =ReadingsVal($w, "hfc${hfcCnt}_high_c",0);
        my $low_c    =ReadingsVal($w, "hfc${hfcCnt}_low_c",0);
       
        my $day =substr($pubDate,0,3);
        my $date=substr($pubDate,5);

        if ( $day ne $Dday )
{

    if ($fcCnt > 0)
    {
fhem( "setreading $w fc${fcCnt}_high_c $Dhigh_c; setreading $w fc${fcCnt}_low_c $Dlow_c; setreading $w fc${fcCnt}_icon $Dicon; setreading $w fc${fcCnt}_code $Dcode; setreading $w fc${fcCnt}_condition $Dcondition; setreading $w fc${fcCnt}_date $Ddate; setreading $w fc${fcCnt}_day_of_week $Dday; setreading $w fc${fcCnt}_pressure $Dpressure; ");
    }

    $fcCnt++;

    $Dday      =$day ;
    $Ddate     =$date;
    $Dcode     =$code;
    $Dcondition=$condition;
    $Dpressure =$pressure;
    $Dicon     =$icon;
    $Dhigh_c   =$high_c;
    $Dlow_c    =$low_c;

            $p1=$pressure if ($fcCnt==1);

}else{
    $Dhigh_c = $high_c  if ( $high_c > $Dhigh_c );
    $Dlow_c  = $low_c   if ( $low_c < $Dlow_c );
    if ( $date =~ /12:00 pm/ )
            {
        $Ddate     =$date;
        $Dcode     =$code;
        $Dcondition=$condition;
        $Dpressure =$pressure;
        $Dicon     =$icon;

                $p1=$pressure if ($fcCnt==1);
                $p2=$pressure if ($fcCnt==2);
    }
}

    }


    fhem( "setreading $w fc${fcCnt}_high_c $Dhigh_c; setreading $w fc${fcCnt}_low_c $Dlow_c; setreading $w fc${fcCnt}_icon $Dicon; setreading $w fc${fcCnt}_code $Dcode; setreading $w fc${fcCnt}_condition $Dcondition; setreading $w fc${fcCnt}_date $Ddate; setreading $w fc${fcCnt}_day_of_week $Dday; setreading $w fc${fcCnt}_pressure $Dpressure; ");

    my $Dp= $p2 - $p1;
    my $pTxt="";
    if ( $Dp > 24 )
  {  $pTxt="stark steigend"; }
    elsif ( $Dp > 6 )
  {  $pTxt="steigend"; }
    elsif ( $Dp > -6 )
  {  $pTxt="gleichbleibend"; }
    elsif ( $Dp > -24 )
  {  $pTxt="fallend"; }
    else
  {  $pTxt="stark fallend"; }

    fhem( "setreading $w pressure_trend_txt $pTxt ");

}


ich triggere diese function mit einem notify.

def n_WetterVorschau notify  WetterVorschau:current_date_time.* { calcWeather($NAME) }


könnt ihr diese function in die OpenWeatherMapAPI  übernehmen?

danke
didi

Hallo,

Deine Funktion kann ich so nicht übernehmen. Sie ist inkompatibel.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux

Zitat von: PNinBB am 14 Januar 2019, 07:35:31
Noch eine kleine Frage zum 'update'.
Werden diese Abfragen 'non-blocking' ausgeführt? Ich vermute doch: ja.  Ich habe aber weder in den Einstellungen noch in den Attributen etwas zum Einstellen gefunden.
Wenn ich 'update' anstosse, sieht man auch keinen weiteren Prozess.
Nochmals besten Dank
Peter

Werden non-blocking ausgeführt.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Felix_86

#51
Zitat von: CoolTux am 13 Januar 2019, 17:36:03
Ich denke darüber lässt sich reden. Also das mit dem Leerzeichen.
Danke, das Leerzeichen zwischen dem Typ und dem Wert ist nun mit dem heutigen Update drin. Da die Maßeinheit allerdings nicht vom Wert getrennt ist (state T: 3°C F: 93% W: 13km/h P: 1010hPa), findet der Plot keine Werte.

Ich habe mir nun ein userReading gebaut, dass mir das gewünschte Logging-Format erzeugt und schiebe dieses Reading ins Log, anstatt dem echten state-Reading (wie zuvor mit der Yahoo API):
attr WetterAtHome userReadings state4Log {"T: ". ReadingsVal($name,"temperature","")." H: ". ReadingsVal($name,"humidity","")." W: ". ReadingsVal($name,"wind","")." P: ". ReadingsVal($name,"pressure","")}
state4Log T: 3 H: 93 W: 13 P: 1010
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 320 Device
SIGNALduino (TCM, TX, IT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS

CoolTux

Zitat von: Felix_86 am 14 Januar 2019, 10:50:35
Danke, das Leerzeichen zwischen dem Typ und dem Wert ist nun mit dem heutigen Update drin. Da die Maßeinheit allerdings nicht vom Wert getrennt ist (state T: 3°C F: 93% W: 13km/h P: 1010hPa), findet der Plot keine Werte.

Ich habe mir nun ein userReading gebaut, dass mir das gewünschte Logging-Format erzeugt und schiebe dieses Reading ins Log, anstatt dem echten state-Reading (wie zuvor mit der Yahoo API):
attr WetterAtHome userReadings state4Log {"T: ". ReadingsVal($name,"temperature","")." H: ". ReadingsVal($name,"humidity","")." W: ". ReadingsVal($name,"wind","")." P: ". ReadingsVal($name,"pressure","")}
state4Log T: 3 H: 93 W: 13 P: 1010

Also wenn das beim alten Weather so war kann ich das sehr gerne auch noch so umbauen. Ist ja nun kein Hexending :-)
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

eddie1104

Ich hoffe, hier bin ich jetzt richtig. CoolTux hat mich zu 59_Weather weiterverwiesen.

In Verbindung mit Open Weather liefert WeatherAsHtmlH bzw. WeatherAsHtmlHV Stundenwerte. Das ist ganz interessant aber man möchte ja auch die tägliche Vorschau verfolgen können. Könnte man das nicht so machen, dass es zwei Spalten, bzw. Zeilen gibt? Eine wäre dann für die Stundenwerte und die andere für die tägliche Vorschau für z.B. die nächsten 7 Tage.




CoolTux

Zitat von: Felix_86 am 14 Januar 2019, 10:50:35
Danke, das Leerzeichen zwischen dem Typ und dem Wert ist nun mit dem heutigen Update drin. Da die Maßeinheit allerdings nicht vom Wert getrennt ist (state T: 3°C F: 93% W: 13km/h P: 1010hPa), findet der Plot keine Werte.

Ich habe mir nun ein userReading gebaut, dass mir das gewünschte Logging-Format erzeugt und schiebe dieses Reading ins Log, anstatt dem echten state-Reading (wie zuvor mit der Yahoo API):
attr WetterAtHome userReadings state4Log {"T: ". ReadingsVal($name,"temperature","")." H: ". ReadingsVal($name,"humidity","")." W: ". ReadingsVal($name,"wind","")." P: ". ReadingsVal($name,"pressure","")}
state4Log T: 3 H: 93 W: 13 P: 1010

Ich habe das state nun entsprechend formatiert.

Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Lippie

Hallo,

habe noch eine Änderungsanregung:

Ich habe die WeatherAsHtml... erweitert um einen weiteren Eingangsparameter: (daily | hourly) um die bevorzugte Anzeige der Vorhersage der Funktion übergeben zu können.
Außerdem habe ich für die Anzahl der Vorhersagen abgesichert, so dass die for-Schleife abgebrochen wird, wenn es keine Vorhersage mehr gibt.

Mögliche Weblink-Aufrufe sind damit:

htmlCode { WeatherAsHtmlD("Wetter_UF",["daily"|"hourly"],[Items]) }

hier nun der Quellcode:

sub WeatherAsHtmlV($;$;$)
{

  my ($d,$f,$items) = @_;
  $d = "<none>" if(!$d);
  $f = "daily" if(!$f);
  $items = 9 if( !$items );
  return "$d is not a Weather instance<br>"
        if(!$defs{$d} || $defs{$d}->{TYPE} ne "Weather");

  my $h = $defs{$d};
  my $width= int(ICONSCALE*ICONWIDTH);

  my $test_reading = ($f eq "daily" ? "fc1_day_of_week" : "hfc1_day_of_week");
  my $fc1 = ($f eq "daily" ? "fc" : "hfc");
  my $fc2 = ($f eq "daily" ? "hfc" : "fc");
 
  my $ret = '<table class="weather">';
  $ret .= sprintf('<tr><td class="weatherIcon" width=%d>%s</td><td class="weatherValue">%s<br>%s°C  %s%%<br>%s</td></tr>',
        $width,
        WeatherIconIMGTag(ReadingsVal($d, "icon", "")),
        ReadingsVal($d, "condition", ""),
        ReadingsVal($d, "temp_c", ""), ReadingsVal($d, "humidity", ""),
        ReadingsVal($d, "wind_condition", ""));

  my $fc = ( (defined($h->{READINGS}->{$test_reading}) and $h->{READINGS}->{$test_reading}) ? $fc1 : $fc2 );
  my $DayHour = ($fc eq 'fc' ? '_day_of_week' : '_pubDate' );
 
  for(my $i=1; $i<$items; $i++) {
    if(defined($h->{READINGS}->{"${fc}${i}_icon"}) and $h->{READINGS}->{"${fc}${i}_icon"}){
       $ret .= sprintf('<tr><td class="weatherIcon" width=%d>%s</td><td class="weatherValue"><span class="weatherDay">%s: %s</span><br><span class="weatherMin">min %s°C</span> <span class="weatherMax">max %s°C</span></td></tr>',
         $width,
         WeatherIconIMGTag(ReadingsVal($d, "${fc}${i}_icon", "")),
         ReadingsVal($d, "${fc}${i}$DayHour", ""),
         ReadingsVal($d, "${fc}${i}_condition", ""),
         ReadingsVal($d, "${fc}${i}_low_c", ""), ReadingsVal($d, "${fc}${i}_high_c", ""));
}
  }

  $ret .= "</table>";
  return $ret;
}

sub WeatherAsHtml($;$;$)
{
  my ($d,$f,$i) = @_;
  $f = "daily" if(!$f);
  WeatherAsHtmlV($d,$f,$i);
}

sub WeatherAsHtmlH($;$;$)
{

  my ($d,$f,$items) = @_;
  $d = "<none>" if(!$d);
  $f = "daily" if(!$f);
  $items = 9 if( !$items );
  return "$d is not a Weather instance<br>"
        if(!$defs{$d} || $defs{$d}->{TYPE} ne "Weather");

  my $h = $defs{$d};
  my $width= int(ICONSCALE*ICONWIDTH);

  my $test_reading = ($f eq "daily" ? "fc1_day_of_week" : "hfc1_day_of_week");
  my $fc1 = ($f eq "daily" ? "fc" : "hfc");
  my $fc2 = ($f eq "daily" ? "hfc" : "fc");

  my $format= '<td><table border=1><tr><td class="weatherIcon" width=%d>%s</td></tr><tr><td class="weatherValue">%s</td></tr><tr><td class="weatherValue">%s°C %s%%</td></tr><tr><td class="weatherValue">%s</td></tr></table></td>';

  my $ret = '<table class="weather">';
  my $fc = ( (defined($h->{READINGS}->{$test_reading}) and $h->{READINGS}->{$test_reading}) ? $fc1 : $fc2 );
  my $DayHour = ($fc eq 'fc' ? '_day_of_week' : '_pubDate' );
 
  # icons
  $ret .= sprintf('<tr><td class="weatherIcon" width=%d>%s</td>', $width, WeatherIconIMGTag(ReadingsVal($d, "icon", "")));
  for(my $i=1; $i<$items; $i++) {
    if(defined($h->{READINGS}->{"${fc}${i}_icon"}) and $h->{READINGS}->{"${fc}${i}_icon"}){
       $ret .= sprintf('<td class="weatherIcon" width=%d>%s</td>', $width, WeatherIconIMGTag(ReadingsVal($d, "${fc}${i}_icon", "")));
}else{
   $items = $i;
}
  }
  $ret .= '</tr>';

  # condition
  $ret .= sprintf('<tr><td class="weatherDay">%s</td>', ReadingsVal($d, "condition", ""));
  for(my $i=1; $i<$items; $i++) {
    $ret .= sprintf('<td class="weatherDay">%s: %s</td>', ReadingsVal($d, "${fc}${i}$DayHour", ""),
        ReadingsVal($d, "${fc}${i}_condition", ""));
  }
  $ret .= '</tr>';

  # temp/hum | min
  $ret .= sprintf('<tr><td class="weatherMin">%s°C %s%%</td>', ReadingsVal($d, "temp_c", ""), ReadingsVal($d, "humidity", ""));
  for(my $i=1; $i<$items; $i++) {
    $ret .= sprintf('<td class="weatherMin">min %s°C</td>', ReadingsVal($d, "${fc}${i}_low_c", ""));
  }
  $ret .= '</tr>';

  # wind | max
  $ret .= sprintf('<tr><td class="weatherMax">%s</td>', ReadingsVal($d, "wind_condition", ""));
  for(my $i=1; $i<$items; $i++) {
    $ret .= sprintf('<td class="weatherMax">max %s°C</td>', ReadingsVal($d, "${fc}${i}_high_c", ""));
  }
  $ret .= "</tr></table>";

  return $ret;
}

sub WeatherAsHtmlD($;$;$)
{
  my ($d,$f,$i) = @_;
  $f = "daily" if(!$f);

if($FW_ss) {
    WeatherAsHtmlV($d,$f,$i);
  } else {
    WeatherAsHtmlH($d,$f,$i);
  }
}


viele Grüße
Lippie

CoolTux

Hallo Lippie,

Das ist Recht umfangreich. Kannst Du das bitte als Patch oder als Pull Request auf GitHub geben? Was wäre super.

Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Lippie

hab mit GIT noch nicht gearbeitet, muss ich mich dazu irgendwo anmelden oder freischalten lassen?

CoolTux

Nur bei GitHub. Es reicht aber auch wenn Du hier einfach einen Patch oder diff postest.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Lippie

Es gibt Arbeit im fhem-mirror :-)
Hab alles fleißig übertragen.

CoolTux

Zitat von: Lippie am 16 Januar 2019, 23:11:05
Es gibt Arbeit im fhem-mirror :-)
Hab alles fleißig übertragen.

Hallo,

Leider gehört der mir nicht. Du musst das wenn an mein Git schicken.

https://github.com/LeonGaultier/fhem-weather



Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Lippie

OK, dort habe ich schon mal die APIs bearbeitet. Das andere kommt noch

CoolTux

Zitat von: Lippie am 16 Januar 2019, 23:23:09
OK, dort habe ich schon mal die APIs bearbeitet. Das andere kommt noch

Habe ich gesehen. Und Dir auch schon Kommentare hinterlassen.
Wenn Du Fragen hast dann einfach Fragen.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Felix_86

Zitat von: CoolTux am 14 Januar 2019, 18:22:40
Ich habe das state nun entsprechend formatiert.
Besten Dank.
Habe gestern geupdated und wieder auf den Ursprungszustand zurück gebaut. Funktioniert weiterhin alles bestens :daumenhoch:
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 320 Device
SIGNALduino (TCM, TX, IT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS

Benni

#64
Hallo Leon,

So, ich habe nun auch endlich die Aktualisierung über die Bühne gebracht, war ja einfach  ;D!

So weit läuft alles einwandfrei, allerdings sind mir auch noch ein paar Kleinigkeiten aufgefallen.
Zum einen eben das Sprach-Problem bei den Wochentagen, zu dem du folgendes geschrieben hast:

Zitat von: CoolTux am 13 Januar 2019, 20:53:32
Das liegt an Deiner locale Einstellung von der linux distrie wo das FHEM drauf läuft. Die ist bei Dir englisch.

Da habe ich jetzt aber irgendwie so meine Zweifel und zwar aus folgendem Grund.
Meine aktuellen locale-Einstellungen sind auf dem FHEM-Rechner nämlich auf Deutsch eingestellt:


LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=


LC_TIME und/oder LC_LANG dürften die relevanten Einstellungen sein.
Nichts desto trotz sieht mein Weather Device wie folgt aus:


Internals:
   API        DarkSkyAPI
   APIKEY     *****d5039
   APIOPTIONS
   DEF        API=DarkSkyAPI apikey=******d5039 lang=de
   INTERVAL   3600
   LANG       de
   LOCATION   48.557,9.199
   NAME       yaw
   NOTIFYDEV  global
   NR         1159
   NTFY_ORDER 50-yaw
   STATE      T: 5 °C F: 68 % W: 18 km/h P: 1010 hPa
   TYPE       Weather
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1547743341.92971
           VALUE      Initialized
   READINGS:
     2019-01-17 17:42:22   .license        Based on data from EUMETNET - MeteoAlarm [https://www.meteoalarm.eu/]. Time delays between this website and the MeteoAlarm website are possible; for the most up to date information about alert levels as published by the participating National Meteorological Services please use the MeteoAlarm website.
     2019-01-17 17:42:22   apiMaintainer   Leon Gaultier (<a href=https://forum.fhem.de/index.php?action=profile;u=13684>CoolTux</a>)
     2019-01-17 17:42:22   apparentTemperature 2
     2019-01-17 17:42:22   cloudCover      52
     2019-01-17 17:42:22   code            29
     2019-01-17 17:42:22   condition       Leicht bewölkt
     2019-01-17 17:42:22   current_date_time Thu, 17 Jan 2019 17:42
     2019-01-17 17:42:22   dewPoint        0
     2019-01-17 17:42:22   fc1_apparentTempHigh 6
     2019-01-17 17:42:22   fc1_apparentTempHighTime Thu, 17 Jan 2019 09:00
     2019-01-17 17:42:22   fc1_apparentTempLow -4
     2019-01-17 17:42:22   fc1_apparentTempLowTime Fri, 18 Jan 2019 04:00
     2019-01-17 17:42:22   fc1_cloudCover  62
     2019-01-17 17:42:22   fc1_code        29
     2019-01-17 17:42:22   fc1_condition   Nachmittags überwiegend bewölkt.
     2019-01-17 17:42:22   fc1_day_of_week Thu
     2019-01-17 17:42:22   fc1_dewPoint    1
     2019-01-17 17:42:22   fc1_high_c      8
     2019-01-17 17:42:22   fc1_humidity    71
     2019-01-17 17:42:22   fc1_icon        partly_cloudy_night
     2019-01-17 17:42:22   fc1_iconAPI     partly-cloudy-night
     2019-01-17 17:42:22   fc1_low_c       0
     2019-01-17 17:42:22   fc1_moonPhase   0.36
     2019-01-17 17:42:22   fc1_ozone       305.76
     2019-01-17 17:42:22   fc1_precipIntensity 0.0559
     2019-01-17 17:42:22   fc1_precipIntensityMax 0.1676
     2019-01-17 17:42:22   fc1_precipIntensityMaxTime Thu, 17 Jan 2019 22:00
     2019-01-17 17:42:22   fc1_precipProbability 0.48
     2019-01-17 17:42:22   fc1_precipType  rain
     2019-01-17 17:42:22   fc1_pressure    1010
     2019-01-17 17:42:22   fc1_pubDate     Thu, 17 Jan 2019 00:00
     2019-01-17 17:42:22   fc1_sunriseTime Thu, 17 Jan 2019 08:10
     2019-01-17 17:42:22   fc1_sunsetTime  Thu, 17 Jan 2019 16:58
     2019-01-17 17:42:22   fc1_tempHigh    8
     2019-01-17 17:42:22   fc1_tempHighTime Thu, 17 Jan 2019 08:00
     2019-01-17 17:42:22   fc1_tempLow     0
     2019-01-17 17:42:22   fc1_tempLowTime Fri, 18 Jan 2019 06:00
     2019-01-17 17:42:22   fc1_uvIndex     1
     2019-01-17 17:42:22   fc1_uvIndexTime Thu, 17 Jan 2019 11:00
     2019-01-17 17:42:22   fc1_visibility  10
     2019-01-17 17:42:22   fc1_wind        12
     2019-01-17 17:42:22   fc1_windGust    61
     2019-01-17 17:42:22   fc1_windGustTime Thu, 17 Jan 2019 07:00
     2019-01-17 17:42:22   fc1_wind_condition Wind: SW 12 km/h
     2019-01-17 17:42:22   fc1_wind_direction 233
     2019-01-17 17:42:22   fc1_wind_speed  12

<... Restliche fc_ und hfc_ gekürzt ...>

     2019-01-17 17:42:22   humidity        68
     2019-01-17 17:42:22   icon            partly_cloudy_night
     2019-01-17 17:42:22   iconAPI         partly-cloudy-night
     2019-01-17 17:42:22   lastError       
     2019-01-17 17:42:22   lat             **.***
     2019-01-17 17:42:22   long            *.***
     2019-01-17 17:42:22   ozone           318.78
     2019-01-17 17:42:22   precipIntensity 0.0305
     2019-01-17 17:42:22   precipProbability 0.16
     2019-01-17 17:42:22   pressure        1010
     2019-01-17 17:42:22   pubDate         Thu, 17 Jan 2019 17:42
     2019-01-17 17:42:22   state           T: 5 °C F: 68 % W: 18 km/h P: 1010 hPa
     2019-01-17 17:42:22   status          ok
     2019-01-17 17:42:22   temp_c          5
     2019-01-17 17:42:22   temperature     5
     2019-01-17 17:42:22   timezone        Europe/Berlin
     2019-01-17 17:42:22   uvIndex         0
     2019-01-17 17:42:22   validity        up-to-date
     2019-01-17 17:42:22   visibility      15
     2019-01-17 17:42:22   wind            18
     2019-01-17 17:42:22   windGust        46
     2019-01-17 17:42:22   wind_condition  Wind: WSW 18 km/h
     2019-01-17 17:42:22   wind_direction  256
     2019-01-17 17:42:22   wind_speed      18
   fhem:
     allowCache 1
     interfaces temperature;humidity;wind
Attributes:
   DbLogExclude .*
   event-on-change-reading .*
   room       Umwelt


Das ist übrigens auch bei OpenWeatherMapAPI so.

Btw.: Mein altes Yahoo-Weather-Device hatte die Tage korrekt angezeigt:


Internals:
   API        YahooWeatherAPI
   APIOPTIONS transport:https,cachemaxage:600
   DEF        ****** 3600 de
   INTERVAL   3600
   LANG       de
   LOCATION   ********
   NAME       yaw
   NOTIFYDEV  global
   NR         240
   NTFY_ORDER 50-yaw
   STATE      T: 0  H: 88  W: 7  P: 986
   TYPE       Weather
   UNITS      c
   .attraggr:
   .attrminint:
   READINGS:
     2019-01-03 23:06:29   city            P***n
     2019-01-03 23:06:29   code            14
     2019-01-03 23:06:29   condition       leichte Schneeschauer
     2019-01-03 23:06:29   country         Germany
     2019-01-03 23:06:29   current_date_time Thu, 03 Jan 2019 10:00 PM CET
     2019-01-03 23:06:29   day_of_week     Do
     2019-01-03 23:06:29   description     Yahoo! Weather for P***n, BW, DE
     2019-01-03 23:06:29   fc10_code       28
     2019-01-03 23:06:29   fc10_condition  überwiegend wolkig
     2019-01-03 23:06:29   fc10_date       12 Jan 2019
     2019-01-03 23:06:29   fc10_day_of_week Sa
     2019-01-03 23:06:29   fc10_high_c     0
     2019-01-03 23:06:29   fc10_icon       mostlycloudy
     2019-01-03 23:06:29   fc10_low_c      -2
     2019-01-03 23:06:29   fc1_code        16
     2019-01-03 23:06:29   fc1_condition   Schnee
     2019-01-03 23:06:29   fc1_date        03 Jan 2019
     2019-01-03 23:06:29   fc1_day_of_week Do
     2019-01-03 23:06:29   fc1_high_c      1
     2019-01-03 23:06:29   fc1_icon        snow
     2019-01-03 23:06:29   fc1_low_c       -5
     2019-01-03 23:06:29   fc2_code        26
     2019-01-03 23:06:29   fc2_condition   wolkig
     2019-01-03 23:06:29   fc2_date        04 Jan 2019
     2019-01-03 23:06:29   fc2_day_of_week Fr
     2019-01-03 23:06:29   fc2_high_c      2
     2019-01-03 23:06:29   fc2_icon        cloudy
     2019-01-03 23:06:29   fc2_low_c       0
     2019-01-03 23:06:29   fc3_code        5
     2019-01-03 23:06:29   fc3_condition   Regen und Schnee
     2019-01-03 23:06:29   fc3_date        05 Jan 2019
     2019-01-03 23:06:29   fc3_day_of_week Sa
     2019-01-03 23:06:29   fc3_high_c      3
     2019-01-03 23:06:29   fc3_icon        rainsnow
     2019-01-03 23:06:29   fc3_low_c       1
     2019-01-03 23:06:29   fc4_code        5
     2019-01-03 23:06:29   fc4_condition   Regen und Schnee
     2019-01-03 23:06:29   fc4_date        06 Jan 2019
     2019-01-03 23:06:29   fc4_day_of_week So
     2019-01-03 23:06:29   fc4_high_c      3
     2019-01-03 23:06:29   fc4_icon        rainsnow
     2019-01-03 23:06:29   fc4_low_c       1
     2019-01-03 23:06:29   fc5_code        26
     2019-01-03 23:06:29   fc5_condition   wolkig
     2019-01-03 23:06:29   fc5_date        07 Jan 2019
     2019-01-03 23:06:29   fc5_day_of_week Mo
     2019-01-03 23:06:29   fc5_high_c      2
     2019-01-03 23:06:29   fc5_icon        cloudy
     2019-01-03 23:06:29   fc5_low_c       0
     2019-01-03 23:06:29   fc6_code        5
     2019-01-03 23:06:29   fc6_condition   Regen und Schnee
     2019-01-03 23:06:29   fc6_date        08 Jan 2019
     2019-01-03 23:06:29   fc6_day_of_week Di
     2019-01-03 23:06:29   fc6_high_c      1
     2019-01-03 23:06:29   fc6_icon        rainsnow
     2019-01-03 23:06:29   fc6_low_c       -1
     2019-01-03 23:06:29   fc7_code        5
     2019-01-03 23:06:29   fc7_condition   Regen und Schnee
     2019-01-03 23:06:29   fc7_date        09 Jan 2019
     2019-01-03 23:06:29   fc7_day_of_week Mi
     2019-01-03 23:06:29   fc7_high_c      1
     2019-01-03 23:06:29   fc7_icon        rainsnow
     2019-01-03 23:06:29   fc7_low_c       0
     2019-01-03 23:06:29   fc8_code        14
     2019-01-03 23:06:29   fc8_condition   leichte Schneeschauer
     2019-01-03 23:06:29   fc8_date        10 Jan 2019
     2019-01-03 23:06:29   fc8_day_of_week Do
     2019-01-03 23:06:29   fc8_high_c      0
     2019-01-03 23:06:29   fc8_icon        chance_of_snow
     2019-01-03 23:06:29   fc8_low_c       -1
     2019-01-03 23:06:29   fc9_code        28
     2019-01-03 23:06:29   fc9_condition   überwiegend wolkig
     2019-01-03 23:06:29   fc9_date        11 Jan 2019
     2019-01-03 23:06:29   fc9_day_of_week Fr
     2019-01-03 23:06:29   fc9_high_c      -1
     2019-01-03 23:06:29   fc9_icon        mostlycloudy
     2019-01-03 23:06:29   fc9_low_c       -3
     2019-01-03 23:06:29   humidity        88
     2019-01-03 23:06:29   icon            chance_of_snow
     2019-01-03 23:06:29   isConverted     0
     2019-01-04 13:04:11   lastError       DNS: Cant find host
     2019-01-03 23:06:29   lat             **.******
     2019-01-03 23:06:29   long            *.******
     2019-01-03 23:06:29   pressure        986
     2019-01-03 23:06:29   pressure_trend  0
     2019-01-03 23:06:29   pressure_trend_sym =
     2019-01-03 23:06:29   pressure_trend_txt gleichbleibend
     2019-01-03 23:06:29   pubDate         Thu, 03 Jan 2019 10:00 PM CET
     2019-01-13 08:05:14   pubDateComment  disabled by attribute
     2019-01-03 23:06:29   pubDateRemote   Thu, 03 Jan 2019 10:00 PM CET
     2019-01-03 23:06:29   pubDateTs       1546549200
     2019-01-03 23:06:29   region           BW
     2019-01-03 23:06:29   state           T: 0  H: 88  W: 7  P: 986
     2019-01-03 23:06:29   temp_c          0
     2019-01-03 23:06:29   temperature     0
     2019-01-13 08:05:14   validity        stale
     2019-01-03 23:06:29   visibility      16
     2019-01-03 23:06:29   wind            7
     2019-01-03 23:06:29   wind_chill      -1
     2019-01-03 23:06:29   wind_condition  Wind: NW 7 km/h
     2019-01-03 23:06:29   wind_direction  305
     2019-01-03 23:06:29   wind_speed      7
   fhem:
     allowCache 0
     interfaces temperature;humidity;wind
Attributes:
   DbLogExclude .*
   alias      Yahoo Wather
   disable    1
   room       Umwelt
   verbose    2


Desweiteren noch die Frage, ob der API-Key nicht als "sensibles" Datum (ähnlich wie Login-Credentials) aus dem Device herausgehalten werden sollte?
Sprich Verwaltung mittels setKeyValue und getKeyValue im Key-File?

Ansonsten: Wirklich Top Arbeit!  8)
Danke!

gb#





CoolTux

Hallo Benni,

Das mit der locale schaue ich mir gerne noch mal an. Kann ich morgen in Ruhe testen.
Was den API Key an geht gebe ich Dir Recht und es existiert auch schon ein entsprechendes Designkonzept. Vorrang hatte aber erstmal das weiter laufen des Modules und neue Quellen  ;D
Habe heute die Freigabe von Boris bekommen an Weather einige Umsetzungen durch zu führen. Es wird also im Laufe der Tage das ein oder andere an Betatester raus gehen.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Benni

Zitat von: CoolTux am 17 Januar 2019, 18:53:09
Das mit der locale schaue ich mir gerne noch mal an. Kann ich morgen in Ruhe testen.

Keine Eile, es pressiert nicht!  ;)

Bevor übrigens die Frage kommt ....

linux liefert mir in der shell mit date das erwartete Ergebnis:


$date
Do 17. Jan 19:28:29 CET 2019


CoolTux

Kannst Du das bitte einmal auf dem FHEM Server ausführen

usr/bin/perl -e "use POSIX; print strftime(\"%a\",localtime(time)) . \"\\n\";"


Also bitte in der Shell.

Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Benni

#68
Zitat von: CoolTux am 17 Januar 2019, 19:41:46
Kannst Du das bitte einmal auf dem FHEM Server ausführen

usr/bin/perl -e "use POSIX; print strftime(\"%a\",localtime(time)) . \"\\n\";"



$ perl -e "use POSIX; print strftime(\"%a\",localtime(time)) . \"\\n\";"
Do


Hmmm ....
in FHEM bekomme ich auf der Commandline folgendes Ergebnis


{strftime("%a",localtime(time))}
Thu



language - Attribut im global device steht auf DE

CoolTux

Kannst Du den bash Befehl bitte einmal als User fhem ausführen. Eventuell ist da was anders.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Benni

 :-\ Passt auch:


$sudo -u fhem perl -e "use POSIX; print strftime(\"%a\",localtime(time)) . \"\\n\";"
Do


Locales sind auch i.O.:


$ sudo -u fhem locale
LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=


CoolTux

Zitat von: Benni am 17 Januar 2019, 20:49:17
:-\ Passt auch:


$sudo -u fhem perl -e "use POSIX; print strftime(\"%a\",localtime(time)) . \"\\n\";"
Do


Locales sind auch i.O.:


$ sudo -u fhem locale
LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=


Sehr seltsam. Ich schaue morgen noch mal genauer.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Benni

Folgendes in der Commandref beim DWD-Modul
in den Installationsanweisungen gefunden:

Zitat
The weekday of the forecast will be in the language of your FHEM system. Enter {$ENV{LANG}} into the FHEM command line to verify. If nothing is displayed or you see an unexpected language setting, add export LANG=de_DE.UTF-8 or something similar to your FHEM start script, restart FHEM and check again. If you get a locale warning when starting FHEM the required language pack might be missing. It can be installed depending on your OS and your preferences (e.g. dpkg-reconfigure locales, apt-get install language-pack-de or something similar).

habe den entsprechenden Varaiblen-export im Startskript von FHEM hinzugefügt, nachdem bei mir bei Ausführung von {$ENV{LANG}} nichts angezeigt wurde.
Jetzt bekomme ich nach einem Neustart folgendes Ergebnis:


{$ENV{LANG}}
de_DE.UTF-8


Jetzt liefert mir auch folgendes den korrekten Wert:


{strftime("%a",localtime(time))}
Do


Und siehe da, im Weather-Device sind die Daten nun korrekt in Deutsch:


Internals:
   API        DarkSkyAPI
   APIKEY     ***d5039
   APIOPTIONS
   DEF        API=DarkSkyAPI apikey=***d5039 lang=de
   INTERVAL   3600
   LANG       de
   LOCATION   ***
   NAME       yaw
   NOTIFYDEV  global
   NR         927
   NTFY_ORDER 50-yaw
   STATE      T: 2 °C F: 89 % W: 34 km/h P: 1014 hPa
   TYPE       Weather
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   READINGS:
     2019-01-17 21:10:10   .license        Based on data from EUMETNET - MeteoAlarm [https://www.meteoalarm.eu/]. Time delays between this website and the MeteoAlarm website are possible; for the most up to date information about alert levels as published by the participating National Meteorological Services please use the MeteoAlarm website.
     2019-01-17 21:10:10   apiMaintainer   Leon Gaultier (<a href=https://forum.fhem.de/index.php?action=profile;u=13684>CoolTux</a>)
     2019-01-17 21:10:10   apparentTemperature -3
     2019-01-17 21:10:10   cloudCover      71
     2019-01-17 21:10:10   code            24
     2019-01-17 21:10:10   condition       Leichter Wind und überwiegend bewölkt
     2019-01-17 21:10:10   current_date_time Do, 17 Jan 2019 21:10
     2019-01-17 21:10:10   dewPoint        1
     2019-01-17 21:10:10   fc1_apparentTempHigh 6
     2019-01-17 21:10:10   fc1_apparentTempHighTime Do, 17 Jan 2019 09:00
     2019-01-17 21:10:10   fc1_apparentTempLow -4
     2019-01-17 21:10:10   fc1_apparentTempLowTime Fr, 18 Jan 2019 05:00
     2019-01-17 21:10:10   fc1_cloudCover  62
     2019-01-17 21:10:10   fc1_code        24
     2019-01-17 21:10:10   fc1_condition   Nachmittag leicht bewölkt und Abend leichter Wind.
     2019-01-17 21:10:10   fc1_day_of_week Do
     2019-01-17 21:10:10   fc1_dewPoint    1
     2019-01-17 21:10:10   fc1_high_c      8
     2019-01-17 21:10:10   fc1_humidity    73
     2019-01-17 21:10:10   fc1_icon        windy
     2019-01-17 21:10:10   fc1_iconAPI     wind
     2019-01-17 21:10:10   fc1_low_c       0
     2019-01-17 21:10:10   fc1_moonPhase   0.36
     2019-01-17 21:10:10   fc1_ozone       302.36
     2019-01-17 21:10:10   fc1_precipIntensity 0.0584
     2019-01-17 21:10:10   fc1_precipIntensityMax 0.1397
     2019-01-17 21:10:10   fc1_precipIntensityMaxTime Do, 17 Jan 2019 13:00
     2019-01-17 21:10:10   fc1_precipProbability 0.48
     2019-01-17 21:10:10   fc1_precipType  rain
     2019-01-17 21:10:10   fc1_pressure    1010
     2019-01-17 21:10:10   fc1_pubDate     Do, 17 Jan 2019 00:00
     2019-01-17 21:10:10   fc1_sunriseTime Do, 17 Jan 2019 08:10
     2019-01-17 21:10:10   fc1_sunsetTime  Do, 17 Jan 2019 16:58
     2019-01-17 21:10:10   fc1_tempHigh    8
     2019-01-17 21:10:10   fc1_tempHighTime Do, 17 Jan 2019 08:00
     2019-01-17 21:10:10   fc1_tempLow     0
     2019-01-17 21:10:10   fc1_tempLowTime Fr, 18 Jan 2019 07:00
     2019-01-17 21:10:10   fc1_uvIndex     1
     2019-01-17 21:10:10   fc1_uvIndexTime Do, 17 Jan 2019 11:00
     2019-01-17 21:10:10   fc1_visibility  9
     2019-01-17 21:10:10   fc1_wind        13
     2019-01-17 21:10:10   fc1_windGust    61
     2019-01-17 21:10:10   fc1_windGustTime Do, 17 Jan 2019 07:00
     2019-01-17 21:10:10   fc1_wind_condition Wind: WSW 13 km/h
     2019-01-17 21:10:10   fc1_wind_direction 245
     2019-01-17 21:10:10   fc1_wind_speed  13

< .... und so weiter und so fort ... >


CoolTux

Danke Dir Benni,

Das werde ich mal ausleihen für die Commandref von 59_Weather
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

moonsorrox

das Thema mit den englischen und deutschen Tagen hatte ich ja gestern auch schon angeschnitten. Heute habe ich es genauso, dass einige Tage in Deutsch sind und einige in englisch also alles gemischt.

Ein "{strftime("%a",localtime(time))}" in der Konsole  fhem ergibt bei mir ein "Fri"
Intel-NUC i5: FHEM-Server 6.1 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

Benni

Zitat von: moonsorrox am 18 Januar 2019, 12:58:26
das Thema mit den englischen und deutschen Tagen hatte ich ja gestern auch schon angeschnitten. Heute habe ich es genauso, dass einige Tage in Deutsch sind und einige in englisch also alles gemischt.

Ein "{strftime("%a",localtime(time))}" in der Konsole  fhem ergibt bei mir ein "Fri"

Und das da hast du schon geprüft und versucht?

https://forum.fhem.de/index.php/topic,95746.msg890080.html#msg890080

Gruß Benni.


CoolTux

Zitat von: moonsorrox am 18 Januar 2019, 12:58:26
das Thema mit den englischen und deutschen Tagen hatte ich ja gestern auch schon angeschnitten. Heute habe ich es genauso, dass einige Tage in Deutsch sind und einige in englisch also alles gemischt.

Ein "{strftime("%a",localtime(time))}" in der Konsole  fhem ergibt bei mir ein "Fri"
Probiere mal bitte Benni sein Lösungsvorschlag aus.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

RappaSan

 :)
Dieser fix hat auch auf meiner Synology die Lösung für die englischen Bezeichnungen gebracht.
Dort gibt es kein "export LANG=de_DE.utf8" im startscript.

CoolTux

Habe ich in der Commandref mal so festgehalten.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

eddie1104

Zitat von: Benni am 18 Januar 2019, 13:05:08
Und das da hast du schon geprüft und versucht?

https://forum.fhem.de/index.php/topic,95746.msg890080.html#msg890080

Gruß Benni.

Es hatte mich in der Vergangenheit nicht gestört ob die Anzeige Deutsch oder Englisch war. Aber mit diesem Lösungsansatz ist jetzt bei mir auch alles in Deutsch. Komisch ist aber trotzdem, dass auf der Shell locale ein richtiges Ergebnis liefert und in FHEM die Sprache verloren geht.

moonsorrox

#80
EDIT:// ich habe es am Anfang eingefügt und nun geht es in deutsch..!!!  ;)
Danke

An welcher Stelle muss ich im Startscript was eingeben..? wollte da nicht sinnlos rum pfuschen  ;)
Hier mein Startscript:
# if you need to start hmland for use with
# Homematic, please start the hmland daemon
# like this (please use correct path and port,
# depending on your installation!)
#
       /opt/hmcfgusb/hmland -d -p 1234 -r 0
#

        perl fhem.pl fhem.cfg

# if you want to use configDB for configuration,
# use this command to start fhem:
#
#       perl fhem.pl configDB
#
# and remove/comment the above line including fhem.cfg

        RETVAL=$?
        ;;
'stop')
        echo "Stopping fhem..."

# if you want to stop hmland during fhem stop:
        pkill hmland

        pkill -U fhem perl
        RETVAL=$?
        ;;
'status')
        cnt=`ps -ef | grep "fhem.pl" | grep -v grep | wc -l`
        if [ "$cnt" -eq "0" ] ; then
                echo "fhem is not running"
        else
                echo "fhem is running"
        fi
        ;;
*)
        echo "Usage: $0 { start | stop | status }"
        RETVAL=1
        ;;
esac
exit $RETVAL


Intel-NUC i5: FHEM-Server 6.1 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

Benni

Zitat von: moonsorrox am 18 Januar 2019, 14:33:04
An welcher Stelle muss ich im Startscript was eingeben..? wollte da nicht sinnlos rum pfuschen  ;)
Auch wenn du's schon selbst gefunden hast ...

Es muss auf jeden fall vor dem eigentlichen Start von FHEM mit perl sein.

Beispiel:

export LANG=de_DE.UTF-8

perl fhem.pl fhem.cfg



moonsorrox

Zitat von: Benni am 18 Januar 2019, 16:43:06
Auch wenn du's schon selbst gefunden hast ...

Es muss auf jeden fall vor dem eigentlichen Start von FHEM mit perl sein.

Jou Benni, ich hatte es nämlich einmal am Ende eingefügt und es ging natürlich nicht  :-\
Aber vielen Dank für den Hinweis...!  ;)
Intel-NUC i5: FHEM-Server 6.1 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

cotecmania

Wann werden denn die Icons wieder so eingepflegt, dass diese im FTUI wieder funktionieren wie vorher ?
FHEM auf RaspberryPI B (buster)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, FireTAB10 FTUI

CoolTux

Das solltest Du die FTUI Leute fragen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

somansch

Zitat von: cotecmania am 27 Januar 2019, 12:07:17
Wann werden denn die Icons wieder so eingepflegt, dass diese im FTUI wieder funktionieren wie vorher ?

Bin gerade dran, das Weather_Widget für FTUI komplett zu überarbeiten. Erstelle, wenn eine erste Testversion fertig ist, einen neuen Thread im FTUI Forum.

VG
Andreas

UweUwe

Hallo, hab gestern das Webinar verfolgt. Danke für die Vorbereitung und Durchführung. Nächstes Mal bin ich wieder dabei.
Mein Mikrophon war leider defekt und deshalb konnte ich meine Fragen nicht stellen.

1. Ich hatte weather in der Vergangenheit gelöscht und Anfang Januar gelöscht.
Jetzt ist da noch ein Rest übrig geblieben, der mir sporadisch mehrmals am Tag eine Fehlermeldung bringt:
ERROR evaluating {WeatherAsHtml("SIMMERATH_WETTER",7)}: Undefined subroutine &main::WeatherAsHtml called at (eval 56343) line 1
Wie bekomme ich dies weg. 2.  Und mein zweites Anliegen: Ich möchte weather wieder installieren, finde aber keine Doku. Gilt immer noch die alte Wiki https://wiki.fhem.de/wiki/Weather oder wie muss ich vorangehen? Hab schon den Blog durchgeschaut, ohne Erfolg.

Gisbert

Hallo Uwe2,

man konnte sich beim Webinar per Telefon einwählen, habe ich so gemacht, denn ich habe kar kein Auto, äh Mikrofon.

Schau bitte in die commandref zum Modul 59_Weather, da ist eigentlich alles erklärt, was man für die Definition des eigenen Devices benötigt. Ansonsten forste das Forum bei den Wettermodulen mal durch, auch da ist es (auch) haarklein erklärt.

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

somansch

Zitat von: cotecmania am 27 Januar 2019, 12:07:17
Wann werden denn die Icons wieder so eingepflegt, dass diese im FTUI wieder funktionieren wie vorher ?

Ich habe eine neue Version des "Weather_Widgets" zur Darstellung der Icons in FTUI zum Testen bereitgestellt. Diese Version unterstützt DarkSky, OpenWeather, ProPlanta und DWD https://forum.fhem.de/index.php/topic,96954.0.html

Viele Grüße
Andreas

andies

Zitat von: UweUwe am 02 Februar 2019, 09:56:44
Gilt immer noch die alte Wiki https://wiki.fhem.de/wiki/Weather oder wie muss ich vorangehen? Hab schon den Blog durchgeschaut, ohne Erfolg.
Es gibt inzwischen mehrere Einträge im Wiki, die sich mit dem Wetter beschäftigen und zum Teil veraltet und nicht untereinander vernetzt sind. Wie geht man am besten vor, wenn man da aufräumen und gleichzeitig niemandem auf die Füße treten will?
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

holle75

Eine Frage von hier: https://forum.fhem.de/index.php/topic,95823.msg918120.html#msg918120

Ich hätte eine Bitte. Irgendwo wird das von DarkSky gelieferte "_time" in "_pubDate"  (mit den lustigen Umlautproblemen die trotz aller aufgezeigten Fixversuche bei mir immer noch bestehen) gewandelt und ausgeliefert. Damit ich meinen Plot fertig bekomme, und Perl eher Codekopieren statt verstehen bei mir ist, die Frage, wie ich _pubDate in ein logProxy verständliches Format bekomme. Zb -> 2010-05-22 13:43:17

Ich suche seit Stunden/Tagen, aber genau dieses Format wie im Moment _pubDate wird scheinbar internetweit recht selten verwandt.

_pubDate bekomme ich mit meinem Wissensstand nicht formatiert. Bei original DarkSky hatte ich bisher $timestamp mit _time generiert:

($hdmsec, $hdmmin, $hdmhour, $hdmmday, $hdmmon, $hdmyear, $hdmwday, $hdmyday, $hdmisdst) = localtime(ReadingsVal($device, "hfc".$h."_time",undef));

# necessary conversion of $mon and $year
$hdmmon += 1;
$hdmyear += 1900;
   
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $hdmyear, $hdmmon, $hdmmday, $hdmhour, $hdmmin, $hdmsec);


oder ihr liefert als ExtraWert _time wieder mit? Wobei ich nicht weiß, ob andere etwas davon hätten.

Danke und Gruß
H.

mi.ke

Zitat von: holle75 am 14 März 2019, 11:40:55
Ich hätte eine Bitte. Irgendwo wird das von DarkSky gelieferte "_time" in "_pubDate"  (mit den lustigen Umlautproblemen die trotz aller aufgezeigten Fixversuche bei mir immer noch bestehen) gewandelt und ausgeliefert.

Es scheint aber anders zu sein, denn "pubDate" wird nicht von der API geliefert, sondern ist lediglich die Zeit, wann "set $NAME update" readings bekommt. Ich hab mir einfach ein userreading pubDateTs {time()} gemacht, dass exakt identisch ist. Dies verwende ich dann in diversen notifys.

Im "alten" Weathermodul war, sowit ich weiss, das "pubDate" die Zeit, wann die Info vom Dienst bereitgestellt wurde.
Das wäre mir ehrlich gesagt auch lieber.

Die "lustigen Umlautproblemen" waren doch eigentlich gefixt, oder? (zumindst ist es mir eben erst wieder aufgefallen)

Cheers
mi.ke
FHEM 5.9 | RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 4 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301, arlo, Aqara

holle75

Moinsen Mi.ke, ich kenne die Wertbenennungen nur von der DarkSky API direkt über HTTPMOD und weiß nicht genau wie was in WEATHER benannt oder konvertiert wird. Wenn ich die Readings vergleiche, kam ich auf _time als Equivalent zu konvertiertem _pubDate. Das kann auch falsch sein.

Was ich eigentlich suche, ist die Zeit für die das entsprechende Hourly-Reading gilt :) ... hfcxx_pubDate .... und das im logproxy verständlichem Format.

Und ich glaube, auch bei fcxx_pubDate ist es das, nicht die Update-Zeit

Bei mir mit vorgestrigem Update hat es die Umlautprobleme. Ein locale (und die anderen checks) gibt mir aber de zurück.


CoolTux


GET https://api.darksky.net/forecast/0123456789abcdef9876543210fedcba/42.3601,-71.0589
     
      {
          "latitude": 42.3601,
          "longitude": -71.0589,
          "timezone": "America/New_York",
          "currently": {
              "time": 1509993277,
              "summary": "Drizzle",
              "icon": "rain",
              "nearestStormDistance": 0,
              "precipIntensity": 0.0089,
              "precipIntensityError": 0.0046,
              "precipProbability": 0.9,
              "precipType": "rain",
              "temperature": 66.1,
              "apparentTemperature": 66.31,
              "dewPoint": 60.77,
              "humidity": 0.83,
              "pressure": 1010.34,
              "windSpeed": 5.59,
              "windGust": 12.03,
              "windBearing": 246,
              "cloudCover": 0.7,
              "uvIndex": 1,
              "visibility": 9.84,
              "ozone": 267.44
          },


pubDate ist nichts weiter wie "currently": { "time": 1509993277,    halt in ein humanreadable format gebracht.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

holle75

Über HTTPMOD als JSON abgeftragt liefert die DarkSky API

2019-03-14 13:17:27   hourly_data_01_apparentTemperature 12.79
     2019-03-14 13:17:27   hourly_data_01_cloudCover 0.01
     2019-03-14 13:17:27   hourly_data_01_dewPoint -5.12
     2019-03-14 13:17:27   hourly_data_01_humidity 0.28
     2019-03-14 13:17:27   hourly_data_01_icon clear-day
     2019-03-14 13:17:27   hourly_data_01_ozone 385.6
     2019-03-14 13:17:27   hourly_data_01_precipIntensity 0
     2019-03-14 13:17:27   hourly_data_01_precipProbability 0
     2019-03-14 01:17:27   hourly_data_01_precipType rain
     2019-03-14 13:17:27   hourly_data_01_pressure 1015.02
     2019-03-14 13:17:27   hourly_data_01_summary Clear
     2019-03-14 13:17:27   hourly_data_01_temperature 12.79
     2019-03-14 13:17:27   hourly_data_01_time 1552564800
     2019-03-14 13:17:27   hourly_data_01_uvIndex 4
     2019-03-14 13:17:27   hourly_data_01_visibility 9.88
     2019-03-14 13:17:27   hourly_data_01_windBearing 335
     2019-03-14 13:17:27   hourly_data_01_windGust 15.13
     2019-03-14 13:17:27   hourly_data_01_windSpeed 9.06


Das meine ich. _time/pubDate ist die Zeit für die die entsprechenden Day/Hourly-Readings gelten.... ist auch fortlaufend hochzählend passen zur hourly_data_xx.

.... und wie bekomme ich den Wert jetzt aus dem humanreadable Reading pubDate von WEATHER wieder in so ein Format ... 2010-05-22 13:43:17 ....  gewandelt?

mi.ke

Zitat von: CoolTux am 14 März 2019, 13:50:29
pubDate ist nichts weiter wie "currently": { "time": 1509993277,    halt in ein humanreadable format gebracht.

Wäre es vielleicht eine Idee, es zu lösen, wie Du es beim UWZ-Modul gemacht hast?

Dort ist die Zeitangabe als Reading in time() und per Attribut humanreadable=1 werden zusätzliche Readings erzeugt (_Date _Time).

Hätte den Vorteil, dass die Zeit in "epoch" vorliegt und der User es sich formatieren kann wie er will.
Wer möchte kann sich auch ohne Kenntnis die "humanreadable" anzeigen lassen.
FHEM 5.9 | RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 4 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301, arlo, Aqara

CoolTux

Das kann man machen wenn es sich um ein Frontend Modul handeln würde. Aber DarkSkyAPI ist ein Backend Modul mit einer festen API Beschreibung. Man kann mit Boris mal darüber reden wie man sowas am besten ändern kann. Dann muß die Darstellung aber eben vom Weather Modul geregelt werden. Zu mindest was pubDate an geht.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

ab77

Hallo zusammen,

letztens habe ich auf DarkSky umgestellt, allerdings fehlte mir dann ein LogProxy für das Chart-Widget.
Da ich nirgends eine fertige LogProxy-Funktion finden konnte, habe ich mich mal ans Werk gemacht und was gebastelt.
Meine Lösung ist nicht so universell wie die für ProPlanta, aber sie tut was ich wollte: Sie liefert die 49 Stundenwerte des angegebenen Readings, die unter hcf1 bis hfc49 zu finden sind.

Aufruf:
Func:logProxy_darkskyHours(\\x22<device>\\x22,\\x22<reading>\\x22)
wobei <device> halt der Name des device ist und <reading> der Namensteil des Readings hinter dem ,,hfc_". Z.B.:
Func:logProxy_darkskyHours(\\x22wetter\\x22,\\x22temperature\\x22)
Die Funktion kann beim Chart-Widget direkt in die Definition von data-columnspec eingesetzt werden.

WICHTIG:
die Datum/Zeit-Angaben, die das DarkSkyApi unter PubDate liefert, konnte ich so nicht verarbeiten. Wer dieses LogProxy verwenden will, muss das Modul DarkSkyApi.pm deshalb leider folgendermassen patchen:
An drei Stellen ist der Anfang der jeweiligen Zeile
'pubDate' => strftimeWrapper("%a, %e %b %Y %H:%M", .....
zu ersetzen durch:
'pubDate' => strftimeWrapper("%d.%m.%Y %H:%M", .....
Mir ist klar, dass das Patchen nicht optimal ist, aber vielleicht fällt ja jemandem etwas besseres hierzu ein.

Noch ein paar Worte zum Code:
Ich benutze Perl nur, wenn ich muss. Ich freue mich also über Anmerkungen oder Korrekturen zum Code.

sub logProxy_darkskyHours($$) {
my ($device, $hfcName) = @_;
   
return undef if(!$device);
   
my ($h,$fcDay,$mday,$mon,$year);
my $timestamp;
my $reading;
my $value;
my $ret = "";

for (my $hfc=0;$hfc<=49;$hfc++){
$reading="hfc".$hfc."_".$hfcName;
$value = ReadingsVal($device,$reading,undef);
$reading="hfc".$hfc."_pubDate";
($mday,$mon,$year,$h) = split('\.| |:',ReadingsVal($device,$reading,undef));
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $year, $mon, $mday, $h, 0, 0);
$ret .= "$timestamp $value\n";
    }
return ($ret);
}




holle75

Bei mir sieht das für einen svg-Plot so aus:

############## hdm WetterDarkSkyModule Wetter Plot funktion ##################################
sub logProxy_WetterDarkSkyModule2Plot($$$$;$$) {
my ($device, $fcValue, $from, $to, $fcHour, $expMode) = @_;
    my $regex;
    my @rl;
my $hdmreading;
my $hdmtime;
   
return undef if(!$device);
if ($fcValue =~ s/_$//)
{
$regex = "^hfc[\\d]+_".$fcValue."\$";
}   
    $fcHour = 12 if(!defined $fcHour);
    $expMode = "point" if(!defined $expMode);
#Log3 undef,2, "regex: ".$regex;
if( defined($defs{$device}) ) {
if( $defs{$device}{TYPE} eq "Weather" ) {
            @rl = sort{
                my ($an) = ($a =~ m/hfc(\d+)_.*/);
                my ($bn) = ($b =~ m/hfc(\d+)_.*/);
                $an <=> $bn or $a cmp $b;
                }( grep /${regex}/,keys %{$defs{$device}{READINGS}} );
return undef if( !@rl );
} else {
Log3 undef, 2, "logProxy_WetterDarkSkyModule2Plot: $device is not a Weather device";
return undef;
}
}
#Log3 undef,2, Dumper(@rl);
my $fromsec = SVG_time_to_sec($from);
my $tosec   = SVG_time_to_sec($to);
my $sec = $fromsec;
my ($h,$hdmsec,$hdmmin,$hdmhour,$hdmmday,$hdmmon,$hdmyear,$hdmwday,$hdmyday,$hdmisdst);
my $timestamp;
   
my $reading;
my $value;
my $prev_value;
my $min = 999999;
my $max = -999999;
my $ret = "";

# while not end of plot range reached
while(($sec < $tosec) && @rl) {
#remember previous value for start of plot range
$prev_value = $value;

$reading = shift @rl;
        ($h) = $reading =~ m/^hfc(\d+).*/;
$value = ReadingsVal($device,$reading,undef);


use Date::Parse;
$hdmreading = ReadingsVal($device, "hfc".$h."_pubDate",undef);
$hdmreading =~ s/^....//; #Wochentag weg
$hdmreading =~ s/ä/a/; #März
$hdmreading =~ s/i/y/; #Mai
$hdmreading =~ s/k/c/; #Oktober
$hdmreading =~ s/z/c/; #Dezember
$hdmtime = str2time($hdmreading);


#Log3 undef,2, "hdmreading: ".$hdmreading;
#Log3 undef,2, "hdmtime: ".$hdmtime;


#($hdmsec, $hdmmin, $hdmhour, $hdmmday, $hdmmon, $hdmyear, $hdmwday, $hdmyday, $hdmisdst) = localtime(ReadingsVal($device, "hfc".$h."_time",undef));
($hdmsec, $hdmmin, $hdmhour, $hdmmday, $hdmmon, $hdmyear, $hdmwday, $hdmyday, $hdmisdst) = localtime($hdmtime);






# necessary conversion of $mon and $year
$hdmmon += 1;
$hdmyear += 1900;
   
$timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $hdmyear, $hdmmon, $hdmmday, $hdmhour, $hdmmin, $hdmsec);
#Log3 undef,2, "timestamp: ".$timestamp;
$sec = SVG_time_to_sec($timestamp);
       
# skip all values before start of plot range
next if( SVG_time_to_sec($timestamp) < $fromsec );

# add first value at start of plot range
if( !$ret && $prev_value ) {
$min = $prev_value if( $prev_value < $min );
$max = $prev_value if( $prev_value > $max );
$ret .= "$from $prev_value\n";
}

# done if after end of plot range
last if($sec > $tosec);

$min = $value if( $value < $min );
$max = $value if( $value > $max );

# add actual controll point
$ret .= "$timestamp $value\n";

#Log 3, "$timestamp $value -0- $reading";
}
    if(($sec < $tosec) && !@rl && ($expMode eq "day")) {
    $timestamp = sprintf("%04d-%02d-%02d_%02d:%02d:%02d", $hdmyear, $hdmmon, $hdmmday, 23, 59, 59);
    if(SVG_time_to_sec($timestamp) < $tosec) {
        $ret .= "$timestamp $value\n";
        }
        else {
$ret .= "$to $value\n";
        }
    }
    elsif(($sec > $tosec) && ($expMode eq "day")) {
        $value = $prev_value + ($value - $prev_value)*(86400 + ($tosec - $sec))/86400;
        $ret .= "$to $value\n";
    }
return ($ret,$min,$max,$prev_value);
}
############## end hdm WetterDarkSkyModule Wetter Plot funktion ##################################


aber auch nur zusamengeschustert und mit viel Hilfe hier aus dem Forum umgesetzt.

Spannend der Part:

use Date::Parse;
$hdmreading = ReadingsVal($device, "hfc".$h."_pubDate",undef);
$hdmreading =~ s/^....//; #Wochentag weg
$hdmreading =~ s/ä/a/; #März
$hdmreading =~ s/i/y/; #Mai
$hdmreading =~ s/k/c/; #Oktober
$hdmreading =~ s/z/c/; #Dezember
$hdmtime = str2time($hdmreading);


das modifiziert den Timestamp in nutzbar ohne in der Modul.pm was basteln zu müssen.