Internals:
DEF 49.35 8.69
NAME Leimen
NR 14
STATE active
TYPE geodata
Helper:
WUQUERY /q/zmw:00000.27.10734
Readings:
2014-02-23 14:31:38 altitude_m 117
2014-02-23 14:31:38 city Leimen
2014-02-23 14:31:38 country DL
2014-02-23 14:31:38 country_iso DE
2014-02-23 14:31:38 country_name Germany
2014-02-23 14:31:38 dewpoint_c 2
2014-02-23 14:31:38 humidity 49%
2014-02-23 14:31:37 latitude 49.35
2014-02-23 14:31:37 longitude 8.69
2014-02-23 14:31:38 moon_age_days 23
2014-02-23 14:31:38 moon_phase 40
2014-02-23 14:31:38 state active
2014-02-23 14:31:38 sunrise 7:19
2014-02-23 14:31:38 sunset 17:58
2014-02-23 14:31:38 temp_feels_c 12.5
2014-02-23 14:31:38 temperature_c 12.5
2014-02-23 14:31:38 tz_long Europe/Berlin
2014-02-23 14:31:38 tz_offset +0100
2014-02-23 14:31:38 tz_short CET
2014-02-23 14:31:38 visibility_km 10.0
2014-02-23 14:31:38 wuTerms http://www.wunderground.com/weather/api/d/terms.html
2014-02-23 14:31:38 wuVersion 0.1
Attributes:
Die Definition besteht nur aus Angebe von Längen-/Breitengrad. Der Rest wird per API von wunderground gelesen und bereitgestellt., natürlich noch längst nicht vollständig, was die Inhalte angeht. Aus Kompatibilitäsgründen werden die globalen Attribute (longitude,latitude,altitude) von diesem Modul aus gleich mit gesetzt.
Technische Voraussetzungen:
- XML::Simple (was aber auf allen Plattformen möglich sein sollte)
- ein kostenloser API key von wunderground
Meinungen?
Ich habe kein Problem damit, ich wuerde es aber wunderground und nicht geodata nennen.
Mir gehts nicht um die Wettermeldungen, die habe ich inzwischen komplett entfernt Mir geht es hauptsächlich um standortbezogene Daten, die sich aus Längen-/Breitengraden ermitteln lassen. (sunrise/sunet, timezone-Infos usw.)
Zitat
Readings:
2014-02-23 18:03:35 altitude_m 117
2014-02-23 18:03:35 city Leimen
2014-02-23 18:03:35 country DL
2014-02-23 18:03:35 country_iso DE
2014-02-23 18:03:35 country_name Deutschland
2014-02-23 18:03:34 latitude 49.35
2014-02-23 18:03:34 longitude 8.69
2014-02-23 18:03:35 moon_age_days 23
2014-02-23 18:03:35 moon_phase 39
2014-02-23 18:03:35 nextAirportCity Mannheim
2014-02-23 18:03:35 nextAirportICAO EDFM
2014-02-23 18:03:35 observation 1393174900
2014-02-23 18:03:35 state active
2014-02-23 18:03:35 sunrise 7:19
2014-02-23 18:03:35 sunset 17:58
2014-02-23 18:03:35 tz_long Europe/Berlin
2014-02-23 18:03:35 tz_offset +0100
2014-02-23 18:03:35 tz_short CET
2014-02-23 18:03:35 wuTerms http://www.wunderground.com/weather/api/d/terms.html
2014-02-23 18:03:35 wuVersion 0.1
Ausserdem verwendet das Modul nicht nur wunderground (das ist nur das Modul mit den meisten Daten mittels eines simpel zu bekommenden apiKeys) sondern benutzt zusätzlich auch noch diverse Google-APIs, sofern ein Google-Api-Key als Attribut hinterlegt wird.
Grunddaten können auch von openweathermap bezogen werden, da ist für den Abruf gar kein Key zwingend erforderlich.
Für mich ergibt sich dabei folgende "Rangfolge"
- zuerst wird openweathermap gelesen
- falls ein wunderground-APIkey als Attribut vorhanden ist, werden zusätzlich Daten von wunderground gelesen
- falls ein Google-APIkey als Attribut vorhanden ist, werden zusätzlich Daten von Google gelesen
Google liefert die mit Abstand genauesten Daten, aber nicht jeder mag mit Google arbeiten.
Hallo betateilchen,
gerade eben bin ich über das Posting hier gestolpert und finde das richtig gut.
Denn derzeit bin ich dabei meine Rollos zu steuern. Dabei verwende ich den Ertrag meiner PV Anlage. Ist halt nur ein wenig schwierig, dies als einziges Merkmal zu nehmen, da die Fenster zu unterschiedlichen Himmelsrichtungen stehen.
Jetzt habe ich schon länger gesucht, wie ich anhand von longitude und latitude und des aktuellen Datums und Zeit den Sonnenstand berechnen kann.
Bin auch fündig geworden, wie man das mit perl berechnen kann.
Aber das hier sollte dies ja dann auch leisten oder?
Wenn ja, dann Daumen hoch für solch ein Modul.
Dann müsste ich das Rad nicht noch mal erfinden. ;)
Zitat von: maxritti am 23 August 2014, 19:07:38
Jetzt habe ich schon länger gesucht, wie ich anhand von longitude und latitude und des aktuellen Datums und Zeit den Sonnenstand berechnen kann.
Bin auch fündig geworden, wie man das mit perl berechnen kann.
Du musst das Rad nicht neu erfinden, das was Du suchst, macht das Modul 99_SUNRISE_EL.pm das in jeder fhem-Installation standardmäßig vorhanden und geladen ist. Du musst einfach mal in die commandref schauen.
http://fhem.de/commandref.html#SUNRISE_EL
Ich möchte den Azimut zum einem bestimmten Datum/Zeit berechnen, damit ich weiss wie stark die unterschiedlich ausgerichteten Fenster der Sonne ausgesetzt sind.
D.h. als Ergebnis soll eine Gradzahl rauskommen, die ich dann auswerten kann.
Das Modul berechnet doch "nur" den Sonnenaufgang und -untergang.
schau dir das Twilight modul an. das liefert unter anderem azimut und elevation.
auch das steht in der commandref.
gruss
andre
Was es nicht alles gibt. :)
Danke Dir.
wie oft sollen denn die Daten aktualisiert werden?
IMHO gehört azimuth und elevation bei einem entsprechend kurzem Intervall auch hier mit hinein...
In letzter Zeit hat sich meine FHEM Installation in unregelmässigen Abständen einfach beendet. Da es langsam lästig wurde, habe ich versucht der Sache auf den Grund zu gehen und bin zu folgendem Stacktrace gekommen:
File does not exist: read timeout at /usr/share/perl5/LWP/Protocol/http.pm line 452.
at /usr/share/perl5/XML/Simple.pm line 958
XML::Simple::find_xml_file('XML::Simple=HASH(0x2ca9b70)', 'read timeout at /usr/share/perl5/LWP/Protocol/http.pm line 452.\x{a}') called at /usr/share/perl5/XML/Simple.pm line 236
XML::Simple::parse_file('XML::Simple=HASH(0x2ca9b70)', 'read timeout at /usr/share/perl5/LWP/Protocol/http.pm line 452.\x{a}', 'KeyAttr', '') called at /usr/share/perl5/XML/Simple.pm line 216
XML::Simple::XMLin('XML::Simple=HASH(0x2ca9b70)', 'read timeout at /usr/share/perl5/LWP/Protocol/http.pm line 452.\x{a}', 'KeyAttr', '') called at /opt/fhem/FHEM/98_geodata.pm line 131
main::_wu_geolookup('HASH(0x2190c58)', 'LWP::UserAgent=HASH(0x2ba3650)', '9cc9381da1a6f317') called at /opt/fhem/FHEM/98_geodata.pm line 104
main::geodata_collectData('HASH(0x2190c58)') called at fhem.pl line 2520
main::HandleTimeout() called at /usr/share/perl5/XML/Simple.pm line 958
XML::Simple::find_xml_file('XML::Simple=HASH(0x2ca9b70)', 'read timeout at /usr/share/perl5/LWP/Protocol/http.pm line 452.\x{a}') called at /usr/share/perl5/XML/Simple.pm line 236
XML::Simple::parse_file('XML::Simple=HASH(0x2ca9b70)', 'read timeout at /usr/share/perl5/LWP/Protocol/http.pm line 452.\x{a}', 'KeyAttr', '') called at /usr/share/perl5/XML/Simple.pm line 216
XML::Simple::XMLin('XML::Simple=HASH(0x2ca9b70)', 'read timeout at /usr/share/perl5/LWP/Protocol/http.pm line 452.\x{a}', 'KeyAttr', '') called at /opt/fhem/FHEM/98_geodata.pm line 131
main::_wu_geolookup('HASH(0x2190c58)', 'LWP::UserAgent=HASH(0x2ba3650)', '9cc9381da1a6f317') called at /opt/fhem/FHEM/98_geodata.pm line 104
main::geodata_collectData('HASH(0x2190c58)') called at fhem.pl line 2520
main::HandleTimeout() called at fhem.pl line 530
Tatsächlich steht um Zeile 452 von /usr/share/perl5/LWP/Protocol/http.pm:
if (my $timeout = ${*$self}{io_socket_timeout}) {
die "read timeout" unless $self->can_read($timeout);
}
Das geodata Modul hatte ich schon vor längerer Zeit in mein Produktivsystem aufgenommen, kurioserweise tritt das Problem aber erst auf, seit ich das System von einem Intel-basiertem Rechner auf einen Cubietruck umgezogen habe. Kann natürlich Zufall sein.
Gibt es eine einfache Lösung des Problems?
Grüße,
Andy.