Informationen von High-End-Wetterstationen kostenlos in das Smart Home einbinden
Für zahlreiche Anwendungen im Smart Home sind Informationen zu Wetterdaten von zentraler Bedeutung. Rolläden beschatten das Zuhause bei hoher UV-Strahlung, Fenster können bei Wind oder Niederschlag automatisch geschlossen werden. Gute Wetterstationen, die zahlreiche Umweltfaktoren messen, kosten jedoch viel Geld. „BMS Quadra“, „Davis Vantage“ oder andere KNX-Wetterstationen kosten zwischen 500 und 1000 Euro.
In diesem Howto wird gezeigt, wie mit einem FHEM Smart Home Server Wetterinformationen von High-End-Wetterstationen, die sich in eurer Nähe befinden, komplett kostenlos erhoben und an den Loxone Miniserver Go (Affiliate-Link) weitergegeben werden, damit professionelle und „smarte“ Automatikprogramme im Smart Home realisiert werden können.Die Einbindung erfolgt über den Online-Dienst wunderground.com (Weather Underground), an den man Wetterdaten als Betreiber bzw. Besitzer einer Wetterstation automatisiert übermitteln kann. Da die Dichte an Stationen in den letzten Jahren massiv zugenommen hat, seitdem unter anderem auch Netatmo-Geräte die Anbindung an wundergound.com unterstützen, ist die Lösung in dem hier gezeigten Howto mittlerweile wirklich praxistauglich geworden.
Geeignete Wetterstation finden
Auf der Webseite http://www.wunderground.com wird im ersten Schritt die Location gesucht (1), woraufhin auf der Karte zahlreiche Wetterstationen erscheinen. Hier kann dann zunächst die Wetterstation ausgesucht werden, die dem eigenen Wohnort am Nähesten ist (2). Ein Klick auf den Stationsnamen (3) ermöglicht es, weitere, wichtige Informationen zur Station einzuholen.
Hierfür muss zunächst in der Detailansicht wieder auf den Namen der Station geklickt werden.
Zu Beginn wird hier die interne wunderground-ID der Wetterstation angezeigt (1), die später für die Anbindung an das Smart Home benötigt wird. Ferner kann man sich hier ansehen, um was für eine Station es sich handelt. Dazu muss auf den Link „About this PWS“ (2) geklickt werden.
Das daraufhin erscheinende „Popup“ liefert diese gewünschten Detail-Informationen zur Wetterstation. In meinem Fall steht keine 200 Meter von meinem Zuhause entfernt eine High-End-Wetterstation „Davis Vantage Pro2 Plus Wireless“, die im Minutenintervall neue Wetterinformationen liefert.
Natürlich hat man nicht immer Glück und die nächste, etwas bessere Station ist ein Stückchen weiter entfernt. Am Besten sucht man sich bei der Wahl der Wetterstation einen Kompromiss aus Entfernung zum eigenen Smart Home und Art der Wetterstation aus. Logischerweise messen nicht alle in wunderground verfügbaren Stationen die gleichen Daten. Manche Stationen messen z.B. lediglich Temperatur und Luftfeuchtigkeit, manche hingegen bis zu zehn Werte, wie z.B. Windrichtung, Niederschlag, Luftdruck, UV-Strahlung etc.
Wetterstation in FHEM einbinden
Die gefundene Wetterstation kann dann anhand der wunderground-ID in FHEM eingebunden werden.
FHEM ist ein quelloffener Smart Home Server, dessen Installation z.B. hier beschrieben ist: FHEM-Server auf dem Raspberry Pi in weniger als einer Stunde einrichten
Zur Einbindung wird zunächst der nachfolgende Code verwendet, der in der FHEM-Kommandozeile am oberen Bildrand des Webinterfaces abgesendet wird:
define wetter_eigheim HTTPMOD http://api.wunderground.com/weatherstation/WXCurrentObXML.asp?ID=IBAYERNF17 30
Wie zu erkennen ist, wird die wunderground-ID der Wetterstation am Ende des Codes angefügt (hier: IBAYERN17), um das Wetterdatenobjekt (hier: wetter_eigheim) anzulegen. Die „30“ am Ende des Codes gibt das Update-Intervall in Sekunden an.
Abschließend wird die Konfiguration über einen Klick auf „Save Config“ dauerhaft gespeichert.
Um alle relevanten Readings, also alle relevanten Messwerte aus der Wetterstation im Smart Home Server auszulesen, wird ferner folgender Code in der Datei „fhem.cfg“ hinzugefügt.
attr wetter_eigheim userattr event-on-change-reading readingsName_cloudiness readingsName_date readingsName_dewpointTemperature readingsName_fog readingsName_heatindex readingsName_humidity readingsName_precip1hrmetric readingsName_preciptodaymetric readingsName_pressure readingsName_solarRadiation readingsName_solarUV readingsName_temperature readingsName_time readingsName_windChill readingsName_windDegrees readingsName_windDirection readingsName_windGust readingsName_windSpeed readingsRegex_cloudiness readingsRegex_date readingsRegex_dewpointTemperature readingsRegex_fog readingsRegex_heatindex readingsRegex_humidity readingsRegex_precip1hrmetric readingsRegex_preciptodaymetric readingsRegex_pressure readingsRegex_solarRadiation readingsRegex_solarUV readingsRegex_temperature readingsRegex_time readingsRegex_windChill readingsRegex_windDegrees readingsRegex_windDirection readingsRegex_windGust readingsRegex_windSpeed attr wetter_eigheim event-on-change-reading dewpointTemperature,humidity,preciptodaymetric,pressure,solarRadiation,solarUV,temperature,windDegrees,windGust,windSpeed,precip1hrmetric attr wetter_eigheim readingsName_cloudiness cloudiness attr wetter_eigheim readingsName_date date attr wetter_eigheim readingsName_dewpointTemperature dewpointTemperature attr wetter_eigheim readingsName_fog fog attr wetter_eigheim readingsName_heatindex heatindex attr wetter_eigheim readingsName_humidity humidity attr wetter_eigheim readingsName_precip1hrmetric precip1hrmetric attr wetter_eigheim readingsName_preciptodaymetric preciptodaymetric attr wetter_eigheim readingsName_pressure pressure attr wetter_eigheim readingsName_solarRadiation solarRadiation attr wetter_eigheim readingsName_solarUV solarUV attr wetter_eigheim readingsName_temperature temperature attr wetter_eigheim readingsName_time time attr wetter_eigheim readingsName_windChill windChill attr wetter_eigheim readingsName_windDegrees windDegrees attr wetter_eigheim readingsName_windDirection windDirection attr wetter_eigheim readingsName_windGust windGust attr wetter_eigheim readingsName_windSpeed windSpeed attr wetter_eigheim readingsRegex_cloudiness cloudiness id="NN" percent="([\d\.]+) attr wetter_eigheim readingsRegex_date date date" content="([\d\.]+) attr wetter_eigheim readingsRegex_dewpointTemperature <dewpoint_c>([\d\.]+) attr wetter_eigheim readingsRegex_fog fog id="FOG" percent="([\d\.]+) attr wetter_eigheim readingsRegex_heatindex <heat_index_c>([\d\.]+) attr wetter_eigheim readingsRegex_humidity <relative_humidity>([\d\.]+) attr wetter_eigheim readingsRegex_precip1hrmetric <precip_1hr_metric>([\d\.]+) attr wetter_eigheim readingsRegex_preciptodaymetric <precip_today_metric>([\d\.]+) attr wetter_eigheim readingsRegex_pressure <pressure_mb>([\d\.]+) attr wetter_eigheim readingsRegex_solarRadiation <solar_radiation>([\d\.]+) attr wetter_eigheim readingsRegex_solarUV <UV>([\d\.]+) attr wetter_eigheim readingsRegex_temperature <temp_c> ([-]*[\d\.]+) attr wetter_eigheim readingsRegex_time time Zeit([\d\:]+) attr wetter_eigheim readingsRegex_windChill <windchill_c>([\d\.]+) attr wetter_eigheim readingsRegex_windDegrees <wind_degrees>([\d\.]+) attr wetter_eigheim readingsRegex_windDirection <wind_dir>([\d\.]+) attr wetter_eigheim readingsRegex_windGust <wind_gust_mph>([\d\.]+) attr wetter_eigheim readingsRegex_windSpeed <wind_mph>([\d\.]+)
Sobald dieser Code in FHEM gespeichert wurde, werden einzelne Readings der Wetterstation in lesbarer Form dargestellt.
Die Informationen können nun in FHEM so verwendet werden, als ob sie über einen lokalen Sensor in das Smart Home eingebunden wären.
Wetterinformationen an Loxone weitergeben
Loxone hat sich in den letzten Jahren zu einem für Jörg und mich nicht mehr wegzudenkenden Smart-Home-System entwickelt. Mit dem kleinen, grünen Miniserver – ich nutze den Loxone Miniserver Go (Affiliate-Link) – kommt man als Smart-Home-Enthusiast voll auf seine Kosten: eingebaute Logik, graphische Programmierung mittels Logikbausteinen, automatische Visualisierung etc. pp. Wer sich mit Loxone noch nicht beschäftigt hat, sollte sich einmal diesen Blogpost durchlesen: 5 Gründe zur Erweiterung deines FHEM-Servers mit Loxone + Howto.
Um die Wetterinformationen per FHEM zu erfassen und in Loxone auszuwerten, sollte die grundsätzliche Verbindung beider Welten (FHEM-Server und Loxone Miniserver) so, wie im oben verlinkten Blogpost erklärt, umgesetzt sein. Diese Verbindung ist Grundvoraussetzung für das weitere Vorgehen.
Dieses beginnt damit, dass FHEM-seitig in die Datei „fhem.cfg“ der folgende Code eingefügt wird:
define WetterdatenToLoxone notify wetter_eigheim {WetterdatenToLoxone("$NAME")}
Der Name des Wetterdaten-Objektes in FHEM (hier: wetter_eigheim) muss dabei an den eigenen, in FHEM gewählten Namen angepasst werden.
Zusätzlich wird in der Datei „99_myUtils.pm“ noch folgende Codezeile hinzugefügt, die für den Datenaustausch in Richtung Loxone per UDP verantwortlich zeichnet:
#WetterdatenToLoxone
sub WetterdatenToLoxone($)
{
my ($device) = @_;
my $regenaktuell=ReadingsVal("$device","precip1hrmetric","-1");
my $regenheute=ReadingsVal("$device","preciptodaymetric","-1");
my $luftdruck=ReadingsVal("$device","pressure","-1");
my $windrichtung=ReadingsVal("$device","windDegrees","-1");
my $windspeed=ReadingsVal("$device","windSpeed","-1");
my $windboehe=ReadingsVal("$device","windGust","-1");
my $uvstrahlung=ReadingsVal("$device","solarUV","-1");
my $solarleistung=ReadingsVal("$device","solarRadiation","-1");
UDP_Msg("192.168.178.76" , "7000" , "$device: $regenaktuell $regenheute $luftdruck $windrichtung $windspeed $windboehe $uvstrahlung $solarleistung");
}
Jedes mal, wenn in FHEM die Wetterdaten aktualisiert werden, wird eine UDP-Nachricht mit allen Werten an den Loxone Miniserver versendet.
Um diese Informationen in Loxone auszuwerten, gilt es, unterhalb des für die Verbindung zwischen FHEM und Loxone nötigen UDP-Eingangsknoten einen neuen „Virtuellen UDP Eingang Befehl“ anzulegen.
Dieser Schritt wird für jeden Wert wiederholt. Dabei wird in der Befehlserkennung unterschieden, welcher Wert abgefragt wird. Die Windrichtung wird beispielsweise mit folgendem Code in Loxone empfangen:
wetter_eigheim: \# \# \# \v
Das liegt daran, dass vom FHEM-Device „wetter_eigheim“ der vierte Wert der UDP-Nachricht die Informationen zur Windgeschwindigkeit enthält. Die Reihenfolge ergibt sich aus dem UDP-Code, der zuvor in FHEM angelegt wurde. Hier noch einmal die relevante Zeile zur Erinnerung:
...
UDP_Msg("192.168.178.76" , "7000" , "$device: $regenaktuell $regenheute $luftdruck $windrichtung $windspeed $windboehe $uvstrahlung $solarleistung");
...
Wie zu erkennen ist, wird zuerst die aktuelle Regenmenge übertragen, anschließend die kumulierte Regenmenge des Tages, dann der Luftdruck, die Windrichtung, die Windgeschwindigkeit usw.
In Loxone steht ein „\#“ für das Überspringen eines Wertes, sodass z.B. der zweite Wert in der Befehlserkennung mit „\# \v“ abgefragt wird, der dritte Wert mit „\# \# \v“ usw.
So werden alle relevanten Informationen Schritt für Schritt unterhalb des UDP-Eingangsknotens angelegt.
Wetterdaten, die nicht näher bearbeitet werden müssen, können in der Loxone Config Software auf einer neuen Programmierseite z.B. direkt an einen „Virtueller-Status„-Baustein angehängt werden. Hierbei wird dann lediglich im Eigenschaftenbereich (links) die Einheit entsprechend angegeben (z.B. für Windgeschwindigkeit in km/h, siehe Screenshot).
Werte, die hingegen noch etwas „aufgehübscht“ werden sollen, werden besser an den „Status„-Baustein angehängt. Dieser bietet die Möglichkeit, Ein- und Ausgabewert regelbasiert zu ersetzen.
Die Windrichtung wird z.B. – von FHEM kommend – in Gradzahlen angegeben. Ich möchte aber viel lieber wissen, ob der Wind aus Nord, Nordost, Süd, usw. kommt, also rechne ich die Werte über den Status-Baustein vorher um. Dies funktioniert so, wie auf dem nachfolgenden Bild zu sehen und kann beliebig fein aufgegliedert werden. Ich habe eine relativ simple Einteilung vorgenommen: 0-90 Grad = Nordost (NO), 90-180 Grad = Südost (SO) usw.
Gleiches mache ich bei der Anzeige der aktuellen Regenmenge. Bei Werten über „0“ soll die Anzeige „Regen“ lauten, bei „0“ dann „Kein Regen“. Dies wird ebenfalls mit dem Status-Baustein entsprechend der gleichen Logik wie für die Windrichtung umgesetzt.
Die Visualisierung in Loxone stellt die empfangenen Werte dann recht übersichtlich dar.
Aus meinem täglichen Leben
Ich nutze die Werte nicht nur zur Information, sondern vor allem zur Automatisierung im Smart Home. Beispielsweise nutze ich den Wert des UV-Levels, um meine Rolläden zu steuern. Das hatte ich bereits hier erklärt: Smart-Home-Rolladensteuerung mit FHEM und Loxone: Howto und Praxistipps für Nachrüster. Windböhen und Windgeschwindigkeit möchte ich entsprechend auch bald in die Rolladensteuerung integrieren. Da bei mir Aluminium-Rolläden verbaut sind, sollen diese im Fall eines Unwetters (hohe Windböhen und starker aktueller Niederschlag) das Glas meiner Balkontüren vor herumfliegenden Gegenständen schützen und deshalb herunterfahren. Wer hingegen Raffstoren verbaut hat, kann diese anhand der Wetterdaten bei Unwettern hochfahren, um sie selbst vor starken Winden zu schützen.
So möchte ich in nächster Zeit weitere Wetterdaten-Szenarien mit dem Loxone Miniserver Go (Affiliate-Link) realisieren.
48 Kommentare
Hallo Christoph,
kann man die Wetterdaten nicht direkt in den Miniserver bekommen? Ohne Umweg mit FHEM?
doch die Möglichkeit ist hier beschrieben
http://www.loxwiki.eu/display/LOX/Weather+Underground+%28Wunderground%29+direkt+in+Loxone+einbinden
In meiner Nähe gibts nur Netatmo Wetterstationen……nix High End
Hallo Ralf,
das geht ganz einfach über den „Virtuellen Http Eingang“ von Loxone. Einfach die Http Stationsseite von einer Wunderground Wetterstation in deiner Nähe auslesen. Und schon hast du alle benötigten Wetterwerte in deinem Miniserver.
Ich lese z.B. bei mir die aktuellen Wetterwerte aus meiner Vantage Pro 2 über ein Skript mit Weewx (Vantage Pro 2 -> seriell (USB) -> Raspi (Weewx)) in Loxone ein, und die Wettervorhersagen von Wunderground über meine Stationsseite bei Wunderground, wo ich meine Wetterdaten mit Weewx auch alle fünf Minuten hochlade.
Gruß,
Andi
Ganz herzlichen Dank. Werde ich mir gleich in den GO einbauen.
Hab 3 Raspi, die machen schon Sklavendienste und spielen schön Musik‘-)
Grüße
Ralf
Super vielen Dank.
Ich habe so meinen WS1600 direkt über Fhem eingebunden.
ICh habe nur ein kleines Problem.
Der Ws1600 gibt die Windrichtung, also z.b. „SW“schon direkt an. Dieses wird aber von Loxone nicht genommen.
Genau wie der Batteriestatus „Ok“. Auch hier wird der Wert nicht genommen.
Nimmt Loxone nur Zahlen?
Per UDP verarbeitet Loxone nur Ziffern, richtig. Du musst deine Werte also vor dem Übertragen in Nummern überführen.
So mache ich das bspw. für die Übertragung vom Plex Media Player:
Hier ein Auszug meiner 99_myUtils.pm:
#PMPToLoxone
#device:
#1 presence (present, absent)
#2 state (disappeared, stopped, paused, playing)
sub PMPToLoxone($)
{
my ($device) = @_;
my $presence = ReadingsVal(„$device“,“presence“,“-1″);
if ($presence eq „absent“) {
$presence = „0“;
}
if ($presence eq „present“) {
$presence = „1“;
}
my $state = ReadingsVal(„$device“,“state“,“-1″);
if ($state eq „disappeared“) {
$state = „0“;
}
if ($state eq „stopped“) {
$state = „1“;
}
if ($state eq „video:paused“) {
$state = „2“;
}
if ($state eq „video:buffering“) {
$state = „3“;
}
if ($state eq „video:playing“) {
$state = „4“;
}
UDP_Msg(„192.168.3.11“ , „7000“ , „$device:plex $presence $state“);
}
Grüße und viel Erfolg
Jörg
hallo Stefan,
kannst du bitte mal posten, wie du deine Wetterstation direkt eingebunden hast?! Ich möchte meine vorhandene Vantge Pro ebenfalls im fhem einbinden, hab aber noch nichts „how to“ gefunden..
Besten Dank
Axel
Hi,
zunächst vielen Dank für den tollen Artikel.
Ich bin ein Anfänger und konnte dennoch mit Eurer Hilfe folgende Readings konfigurieren:
dewpointTemperature
humidity
precip1hrmetric
preciptodaymetric
pressure
temperature
windDegrees
windGust
windSpeed
Meine Newbi-Frage nun: wie kann ich die einzelnen Readings in richtige Einträge einem Raum – z.b. Außenbereich zuordnen?
Vielen lieben Dank für die Info.
BB
Hi Ricardo,
hier mal an einem Reading verdeutlicht:
Erstmal legst du in der fhem.cfg jeweils einen Dummy für ein gewünschtes Reading an. Der Dummy repräsentiert dann einen „Eintrag“ im gewünschten Raum.
define TE.Taupunkt dummy
attr TE.Taupunkt room Terrasse
Und dann wird über ein notify das gewünschte Reading vom Ursprungsdevice bei einer Änderung ausgelesen und in den neuen Dummy geschrieben:
define WriteReadingInDummy notify TE.Wetterstation.* { \
my $dewpointTemperature = ReadingsVal(„$NAME“, „dewpointTemperature“, „0“);; \
fhem(„set $NAME TE.Taupunkt $dewpointTemperature“);; \
}
Hoffe das hilft dir erstmal weiter.
Grüße
Jörg
Hallo,
mir geht es genau so.
die Readings bekomme ich alle rein.
Aber dann komme ich auch nicht mehr weiter.
Ich möchte alle Werte extra in einem Raum anzeigen.
Einen Dummy wenn ich anlege ist es ein Schalter, aber kein z.B. Temperatur Wert.
Danke Stefan
Hallo Jörg,
Ich habe da mal zwei Fragen.
1. Warum wird von Euch immer noch das direkte bearbeiten der fhem.cfg praktiziert, obwohl das nicht mehr empfohlen wird?
2. Warum empfiehlst Du Ricardo nicht readingsProxy statt des komplizierten Dummy Notify Geflechts?
Grüße
Hi Leon,
zu deinen Fragen:
1. Vermutlich weil wir das so jahrelang gewöhnt sind. Kürzere Einträge realisieren wir jetzt meist auch über die FHEM-Kommandozeile, längere Einträge werden jedoch immer noch direkt in der fhem.cfg gepackt. Gibt es dazu denn eine brauchbare Alternative?
2. Mit dem readingsProxy bin ich noch nicht vertraut, deshalb das altbekannte dummy-Konstrukt. Wenn du weisst, wie es besser geht, dann sag doch einfach wie… Würde mich freuen. 🙂
Grüße
Jörg
Hallo zusammen,
ich habe eine Wetterstation in meiner Nähe im FHEM „eingebunden“, aber was ich einfach nicht hinbekommen ist die Ausgabe der Readings.
Unter „buf“ stehe die ganze Werte und es scheint sich auch etwas zu ändern.
Könnt ihr mir vielleicht sagen, wo da das Problem liegen kann.
Ist bestimmt ein ganz doofer Fehler.
Hi Christoph,
danke für den interessanten Artikel, jedoch schließe ich mich Jörg Wu. an, die Readings sind auf FHEM seite zu sehen.
Der notify scheint aber nicht wirklich ausgeführt zu werden (Zeitstempel).
Kannst bitte nochmal nachsehen – irgendwo „fehlt“ vermutlich noch was…
thnx
Jimly
Hallo Leute,
habe es hinbekommen – wer aufmerksam liest kommt zur Erleuchtung!
Trotzdem habe ich noch eine Frage:
Wie bekommt man es hin, daß FEHM nur eine UDP Message sendet?
In meinem FHEM Log, bzw. im UDP-Monitor in LOXONE ist zu sehen, daß mindestes 8 identische Zeilen liefert – vermutlich pro geändertem Reading das Ereignis WetterdatenToLoxone aufruft.
Hier die Version mit der aktuellen Readings-Schreibweise ab 2013:
(Bei alter Schreibweise noch kein Problem, fliegt aber irgendwann raus und produziert derzeit nur LOG Einträge)
99_myUtils.pm
#UDP Befehle senden
sub UDP_Msg($$$)
{
my ($dest,$port,$cmd) = @_;
my $sock = IO::Socket::INET->new(
Proto => ‚udp‘,
PeerPort => $port,
PeerAddr => $dest
) or die „Could not create socket: $!\n“;
$sock->send($cmd) or die „Send error: $!\n“;
return „send $cmd“;
}
#WetterdatenToLoxone
sub WetterdatenToLoxone($)
{
my ($device) = @_;
my $regenaktuell=ReadingsVal(„$device“,“precip1hrmetric“,“-1″);
my $regenheute=ReadingsVal(„$device“,“preciptodaymetric“,“-1″);
my $luftdruck=ReadingsVal(„$device“,“pressure“,“-1″);
my $windrichtung=ReadingsVal(„$device“,“windDegrees“,“-1″);
my $windspeed=ReadingsVal(„$device“,“windSpeed“,“-1″);
my $windboehe=ReadingsVal(„$device“,“windGust“,“-1″);
my $uvstrahlung=ReadingsVal(„$device“,“solarUV“,“-1″);
my $solarleistung=ReadingsVal(„$device“,“solarRadiation“,“-1″);
UDP_Msg(„192.168.2.18“ , „7002“ , „$device: $regenaktuell $regenheute $luftdruck $windrichtung $windspeed $windboehe $uvstrahlung $solarleistung“);
}
1;
fhem.cfg
# =====
define HMS100TF_0000 HMS 0000
attr HMS100TF_0000 IODev CUL
attr HMS100TF_0000 room HMS
define FileLog_HMS100TF_0000 FileLog ./log/HMS100TF_0000-%Y.log HMS100TF_0000:T:.*
attr FileLog_HMS100TF_0000 logtype temp4hum6:Temp/Hum,text
attr FileLog_HMS100TF_0000 room HMS
define SVG_HMS100TF_0000 SVG FileLog_HMS100TF_0000:SVG_HMS100TF_0000:CURRENT
attr SVG_HMS100TF_0000 label „HMS100TF_0000 Min $data{min1}, Max $data{max1}, Last $data{currval1}“
attr SVG_HMS100TF_0000 room Plots
define wetter_eigheim HTTPMOD http://api.wunderground.com/weatherstation/WXCurrentObXML.asp?ID=IBAYERNF17 30
attr wetter_eigheim userattr event-on-change-reading .*
attr wetter_eigheim reading01Name cloudiness
attr wetter_eigheim reading01Regex cloudiness id=“NN“ percent=“([\d\.]+)
attr wetter_eigheim reading02Name date
attr wetter_eigheim reading02Regex date date“ content=“([\d\.]+)
attr wetter_eigheim reading03Name dewpointTemperature
attr wetter_eigheim reading03Regex ([\d\.]+)
attr wetter_eigheim reading04Name fog
attr wetter_eigheim reading04Regex fog id=“FOG“ percent=“([\d\.]+)
attr wetter_eigheim reading05Name heatindex
attr wetter_eigheim reading05Regex ([\d\.]+)
attr wetter_eigheim reading06Name humidity
attr wetter_eigheim reading06Regex ([\d\.]+)
attr wetter_eigheim reading07Name precip1hrmetric
attr wetter_eigheim reading07Regex ([\d\.]+)
attr wetter_eigheim reading08Name preciptodaymetric
attr wetter_eigheim reading08Regex ([\d\.]+)
attr wetter_eigheim reading09Name pressure
attr wetter_eigheim reading09Regex ([\d\.]+)
attr wetter_eigheim reading10Name solarRadiation
attr wetter_eigheim reading10Regex ([\d\.]+)
attr wetter_eigheim reading11Name solarUV
attr wetter_eigheim reading11Regex ([\d\.]+)
attr wetter_eigheim reading12Name temperature
attr wetter_eigheim reading12Regex ([\d\.]+)
attr wetter_eigheim reading13Name time
attr wetter_eigheim reading13Regex time Zeit([\d\:]+)
attr wetter_eigheim reading14Name windChill
attr wetter_eigheim reading14Regex ([\d\.]+)
attr wetter_eigheim reading15Name windDegrees
attr wetter_eigheim reading15Regex ([\d\.]+)
attr wetter_eigheim reading16Name windDirection
attr wetter_eigheim reading16Regex ([\d\.]+)
attr wetter_eigheim reading17Name windGust
attr wetter_eigheim reading17Regex ([\d\.]+)
attr wetter_eigheim reading18Name windSpeed
attr wetter_eigheim reading18Regex ([\d\.]+)
attr wetter_eigheim room Wetter
define WetterdatenToLoxone notify wetter_eigheim {WetterdatenToLoxone(„$NAME“)}
Hallo Jimly, das ist genau die Logik, die ich so haben möchte. Sobald sich ein Reading aktualisiert, sollen alle Status-Werte neu gesetzt werden. Wenn du das nicht möchtest, brauchst du für jedes Reading eine eigene UDP-Message mit separatem Inhalt, also separatem Code in der 99_myUtils.
VG
Christoph
Hi Christoph,
das ist klar, nur so wie es jetzt ist, ändert sich z.B. reading01 wird eine UDP Block gesendet. Ändert sich aber im selben Moment auch reading02, so wird wieder eine UDP Block gesendet.
Besser wäre alle Readings verarbeiten und dann bei Änderung einen Block mit allen Daten senden.
So wie jetzt verursacht das bei 10 Readings 10 UDP Messages auf einmal.
Ich glaube das ist nicht so gewollt…. 😉
Hallo,
vielen Dank für diesen und die anderen hilfreichen Artikel.
Ich habe eine Wetterstation in meiner Nähe eingebunden und sehe auch keine Werte in den Readings.
Dafür finde ich im Logfile aber Einträge wie diesen bei eigentlich allen Readings:
the attribute readingsRegex_temperature should no longer be used. Please use reading01Regex syntax instead
Hat sich da etwas geändert?
Danke für die tolle Idee der Einbindung von Crowd-Daten !
ReadingsProxy geht so:
define CW_Temperature readingsProxy CrowdWeather:temperature
attr CW_Temperature alias Aussentemperatur
attr CW_Temperature group CrowdWeather
attr CW_Temperature room 0.Außen
attr CW_Temperature stateFormat { sprintf(„%.1f °C“, ReadingsVal(„CrowdWeather“,“temperature“,0));; }
„CrowdWeather“ ist mein device statt „wetter_eigheim“
VG ak323
Hallo ak323,
nice! Das werde ich mir direkt mal reinziehen!
Danke!
VG
Christoph
Hallo!
Ist mein Verständnis richtig, dass dieser ReadingsProxy für alle relevanten Messwerte, z.B. windSpeed, separat angelegt werden muss?
THX
Hallo Leute
Ich stehe auf dem Schlauch, bekomme das einfach nicht hin…..
Ich moechte als Test einfach nur einmal die Temperature von meinem Eltako MS via UDP an den Loxone MS schicken, dafuer habe ich folgendes aus Euren Tutorials:
:::: 99_myUtils.pm :::::
#UDP Befehle senden
sub UDP_Msg($$$)
{
my ($dest,$port,$cmd) = @_;
my $sock = IO::Socket::INET->new(
Proto => ‚udp‘,
PeerPort => $port,
PeerAddr => $dest
) or die „Could not create socket: $!n“;
$sock->send($cmd) or die „Send error: $!n“;
return „send $cmd“;
}
#WetterdatenToLoxone
sub WetterdatenToLoxone($)
{
my ($device) = @_;
my $temperature=ReadingsVal(„$device“,“temperature“,“-1″);
UDP_Msg(„10.x.x.x“ , „7000“ , „$device: $temperature“);
}
::::: fhem.cfg :::::
# Wetterstation Eltako MS FWS61-24V
#
#
define EnO_019D1402 EnOcean 019D1402
attr EnO_019D1402 IODev TCM_ESP3_0
attr EnO_019D1402 eep A5-13-01
attr EnO_019D1402 manufID 00D
attr EnO_019D1402 room Aussenbereich
attr EnO_019D1402 subType environmentApp
define FileLog_EnO_019D1402 FileLog ./log/EnO_019D1402-%Y.log EnO_019D1402
#
#
# Diese Daten werden an Loxone gesendet via UDP
#
define WetterdatenToLoxone notify FileLog_EnO_019D1402 {WetterdatenToLoxone(„$NAME“)}
attr EnO_019D1402 readingsRegex_temperature ([\d\.]+)
#
……
Koennt Ihr mir BITTE helfen, ohne Eure Hilfe komme ich hier nicht weiter 🙁
Vielen Dank
Dein notify geht auf das FileLog, nicht auf das Device.
VG
Christoph
Hallo ich bräuchte mal dringend Hilfe, da steht „Zusätzlich wird in der Datei „99_myUtils.pm“ noch folgende Codezeile hinzugefügt“ wo finde ich die Datei 99_myUtils.pm
mfg Jens
Hallo Jens
– Im Fhem auf der linken Seite im Menü auf edit files klicken.
– Dann das default file „99_utils.pm“ anklicken.
– Änderungen hinzufügen.
– und jetzt wichtig, als 99_myUtils.pm abspeichern
– zum Schluss noch reload 99_myUtils.pm
Dann sollte das laufen
was mache ich bzw was habe ich aber falsch gemacht wenn die datei da nicht steht ??
siehe dort:
http://www.fhemwiki.de/wiki/99_myUtils_anlegen
Hey,
schönen Dank für die gute Beschreibung! Ich habe mir eine Wetterstation (auch aus Fürth 🙂 erfolgreich in FHEM (ohne Loxone) eingebunden.
Allerdings stelle ich bei dem aktuellen Wetter fest, dass die negativen Temperaturen nicht angezeigt werden. Kann es sein, dass bei der RegEx das Vorzeichen nicht ausgewertet wird? Kenn mich leider mit regulären Ausdrücken nicht aus.
Viele Grüße
Thorsten
Hallo Thorsten,
das kann eigentlich nicht sein. Bei mir klappt alles reibungslos. Habe es extra heute morgen noch einmal gecheckt und dir einen Screenshot geschossen. https://meintechblog.de/wordpress/wp-content/uploads/2016/12/IMG_0390.png
VG
Christoph
Hallo Christoph,
sehr komisch, ich habe mit regexe.de die Respones von der API und die Regex getestet. Bei mir funktioniert es jetzt so:
([-]*[\d\.]+)
Habe es eben nochmal zurückgestellt auf:
([\d\.]+)
Da findet er wieder nicht die negativen Werte, temperature wird wieder nicht aktualisiert.
Viele Grüße
Thorsten
Ich schließe mich Thorsten an. Ich habe eben eine Wetterstation (Netatmo) eingebunden und das Regex für Temperatur hat ebenfalls nicht reagiert. Erst als ich Thorstens Variante mit dem Vorzeichen getestet habe ging es.
Hallo Thorsten,
ich habe deine Syntax jetzt mal für den Wert „temperature“ in den Blogpost oben integriert. Danke für deine Hinweise!
VG
Christoph
@Jens Stapel
http://www.fhemwiki.de/wiki/99_myUtils_anlegen
zu meiner eigenen Sache: Ich habe auch die Änderungen unter buf. In den readings steht alles auf 1.0. Wo liegt der Fehler ?
Ich möchte es gerne ohne Loxone einrichten. Aber mir geht es immer noch wie Jörg Wu. Wie sieht es mit einer Lösung aus ?
Was sagt denn das Log?
Also ich habe das jetzt 3x probiert.
Ich bekomme von der Station IWALDKRA2 den Taupunkt, den Druck und die Feuchtigkeit, aber keine Temperatur ?!?
dewpointTemperature
2.0
2017-01-12 23:40:22
heatindex
1.0
2017-01-12 23:25:34
humidity
100
2017-01-12 23:40:22
precip1hrmetric
1.0
2017-01-12 23:25:34
preciptodaymetric
1.0
2017-01-12 23:25:34
pressure
996.8
2017-01-12 23:40:22
solarRadiation
1.0
2017-01-12 23:25:34
solarUV
1.0
2017-01-12 23:25:34
temperature
1.0
2017-01-12 23:25:34
windChill
1.0
2017-01-12 23:25:34
windDegrees
1.0
2017-01-12 23:25:34
windDirection
1.0
2017-01-12 23:25:34
windGust
1.0
2017-01-12 23:25:34
windSpeed
1.0
2017-01-12 23:25:34
Das gilt sowohl für den Original Code als auch für den upgegradeten Code
mit der Sytax reading01Regex zu.
Was mach ich denn falsch ?
ok, Fehler gefunden. Beim Regular-Expression ist ein Leerzeichen rein gerutscht.
Hallo hab noch ne Frage:
Kriege alle Werte in FHEM rein, doch die Regenwerte (preciptodaymetric und precip1hrmetric) sind beide genau um den Faktor 10 zu klein. Wie kann ich das bitte korrigieren?
Es handelt sich um die Station ITICINOG5
Hallo!
Die Readings werden nicht korrekt dargestellt:
http://www.directupload.net/file/d/4641/kaq8y64g_png.htm
Liegt das an der Konfiguration?
THX
Hallo, danke für den tollen Blog. Habe heute mal Zeit gefunden und die Wetterdaten in mein FHEM eingebunden. Ich bekam jedoch nie die Temperatur angezeigt, erst als ich das Leerzeichen bei, ([-]*[\d\.]+), entfernt habe, also so, ([-]*[\d\.]+)
Hoffe ich habe es etwas verständlich erklärt. Vielen Dank euch allen und ein schönes Wochenende.
Hallo, ich bin Anfänger/Einsteiger bei FHEM. Ich habe den Programmschnipsel Wetter underground erfolgreich implementiert.
Leider kann ich die Werte nicht auslesen. Kann mir jemand (Nach-)Hilfe geben?
Hallo,
mein Wettermodul in FHEM (Twilight) gibt mir zusätzlich noch die Uhrzeit von Sonnenaufgang und Sonnenuntergang an.
Der Wert ist z.B.: 05:26:00. Im Loxone UDP Monitor sieht alles gut aus.
Scheinbar Aufgrund des Doppelpunktes bekomme ich diese Werte aber nicht in Loxone einem Eingang zugewiesen. Loxone macht dann 00:00:05 daraus.
Hat schon mal jemand Uhrzeiten per UDP übertragen und einen Tip für mich, wie die korrekte Befehlskennung aussehen müsste?
Oder wäre der Weg: Stunde, Minute und Sekunde einzeln zu übermitteln.
Da hapert es gerade bei dem Umbau des Readings bei mir 🙁
Vielen Dank falls jemand einen Tip hat und ein schönes Wochenende.
Hallo Jens,
besten Dank für den Artikel. Ich habe eine Vantage Pro 2 an einem Raspi 3 mit weewx am laufen. Auf einem zweiten Raspi 3 läuft fhem mit Anbindung an fritzBox, Homatatic, KNX, Cul etc. Meine Frage wie bekomme ich die Vantage Pro Daten auf den Raspi auf dem fhem läuft. fhem2fhem oder kann ich das Httpmod Komando verwenden, und wie?
Besten Dank für Deine/eure Unterstützung
Hallo,
ich habe eine Station, wie oben beschrieben, in Fhem eingebunden. Leider werden keine Werte angezeigt. Im Log steht: „wetter_eigheim: Read response to update didn’t match any Reading“.
Hat jemand einen Tipp?
Der Code ist schwer fehlerhaft! Diese attr Zeile (nur der Anfang) ist nonsens! Weder userattr ist dort sinnvoll und event-on-change-reading muss durch Komma getrennt werden!
attr wetter_eigheim userattr event-on-change-reading readingsName_cloudiness readingsName_date
Die Abfrage von Webseiten im 30 sec Takt macht vor allem bei Wetter keinen Sinn und ihr würdet euch bedanken wenn 1000ende von User Bots eure Webseite im 30 sec Takt abziehen würden!
Gruß Otto
Hallo,
ich möchte hier mitteilen, dass Weather Underground die API seit März 2019 eingestellt hat und dementsprechend nicht mehr funktioniert.
LG Karl