Modul für DWD Open Data

Begonnen von jensb, 21 Januar 2018, 14:38:48

Vorheriges Thema - Nächstes Thema

jensb

@curt
Was du da bezüglich des Weblink-Hilfetexts feststellst ist richtig. Er ist weit davon entfernt selbsterklärend zu sein. Aber bitte berücksichtigen, dass das Modul ursprünglich nur für den Eigenbedarf programmiert wurde und das sich weder das Programmieren noch das Dokumentieren von allein erledigen. Ich möchte diese Ansage auch nicht regelmäßig wiederholen, aber das hier ist mindestens das 3. Mal in diesem Thread.

Jeder darf mithelfen das Vorhandene zu verbessern. Das haben auch beim DWD-OpenData-Modul mehrere getan, durch Verbesserungsvorschläge, Hintergrundinformationen, genaue Fehlerbeschreibungen oder konkrete Fragen.

Ich weiß, dass nicht jeder FHEM-Nutzer selbst gut programmieren kann und das einigen das Englisch schwer fällt. Deshalb ist das Modul explizit nicht für Anfänger gedacht (das steht allerdings in der Commandref und die muss man ja nicht lesen ::) ). Wer es doch wagt, muss sich ein bisschen investieren - und Lesen ist der erste Schritt.

Hier ein Beispiel aus dem Weblink-Modul (ca. ab Zeile 560):

=item DWDOD_AsHtmlH($;$$)

  create forecast display as a horizontal CSS table with two icons per day

  @param   device name, scalar
  @param   number of days, scalar, optional, default 4 (including today)
  @param   flag to use minimum of ground and minimum temperature, scalar, optional, default 0
 
  @return  HTML string, scalar

=cut


Da steht "number of days, scalar, optional, default 4 (including today)" was deine Feststellung mit der Anzahl erklärt. Man müsste also im Hilfetext "icons" mit "days" ersetzen. Aber man sieht das ja scheinbar auch durch ein Experiment, wie du es gemacht hast.

minimum of ground and minimum temperature = min(Tg, Tn)

Darauf könnte man auch kommen, wenn man die Beschreibung der Readings in der Commandref lesen würde, denn da werden die gleichen Begriffe verwendet.

ZitatUnd über commandref will ich nichtmal nachdenken: Wenn man als Neuling da ran muss, ist das eigentlich immer Stochern im Nebel.

Das ist meiner Meinung nach der falsche Ansatz. Wenn ich etwas Neues machen will, dann mach ich mich schlau - selbst wenn ich nicht alles sofort verstehe. Und wenn es anfängt zu funktionieren, dann bringt ein zweiter Schlaumach-Durchgang den einen oder anderen Aha-Effekt. Dazu ist bei FHEM die Commandref da. Die Wiki kann das allein nicht leisten.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

curt

Erstens (das ist mir wichtig): Danke für Deine Arbeit.

Zweitens: Ich verstehe Deine Sicht, die wohl die offizielle FHEM-Sicht ist, jedenfalls begegnet sie mir oft. Allein - ich teile diese Sicht nicht. Das hat mehrere Gründe, die ich Dir gern erkläre: Ich bin durchaus berufstätig (übrigens in der Branche). Die Zeit, mich mit FHEM zu beschäftigen ist beschränkt. Gleichwohl bringe ich mich im Rahmen meiner bescheidenen Möglichkeiten bei mehreren Modulen aktiv ein. Vielleicht erinnerst Du Dich, dass u.a. der Tipp mit dem AGS von mir kam.

Bei einem Modul wie dem von Dir gestalteten ist der Hauptzweck durchaus klar, die Masse der künftigen Nutzer wird einige Möglichkeiten nutzen - welche das sind, ist vorhersehbar. Von daher muss eigentlich nicht jeder das Rad neu erfinden - das ist aber die Quintessenz Deines Beitrags.

Es gibt ein weiteres Problem (nicht nur bei Deinem Modul - aber auch da): Als neuer Nutzer kann man überhaupt nicht abschätzen, was das Modul eigentlich alles sinnvolles erledigen kann. Wenn es ideal läuft, findet man Schnipsel in der Diskussion. Oft läuft es weniger ideal: Jemand frug genau die Frage, die man selbst hat. Die Antwort ist das sybillische "guck commandref". Der Fragende meldete sich nicht wieder - und man weiß nicht: Hat er es geschafft, wie hat er es geschafft? Oder hat er es nicht geschafft?

Um die Haupteinsatzmöglichkeiten abschätzen zu können, gehören die eigentlich (optisch!) in den Wiki-Artikel. Da sieht der Nutzer "oh sowas schönes kann ich damit machen!". Nein, ich kann den Wiki-Artikel nicht erweitern, ich überschaue es derzeit ja nicht.

Anderes Beispiel: Offenbar besteht oft die Frage, wie man etwas (den Mover) in Abhängigkeit von angesagtem Regen in die Garage schicken kann - oder das Licht einschalten, was weiß ich. Das ist offensichtlich eine Haupteinsatzmöglichkeit. Und weil es eine ist, sollte man die erklären. - Es wird nicht erklärt. Sondern commandref lesen. Und Thread lesen, in der Hoffnung, dass da nicht nur "lies commandref" steht. Das ist oft durchaus frustrierend. Also werde ich das Rad zum freiunddrölfzigsten Mal neu erfinden. Ich werde überlegen, ab wieviel mm Regen und welcher Regenwahrscheinlichkeit ich "es kommt Regen" setzen sollte. Ich werde überlegen, wie man das mit DOIF oder diesem Hilfsmodul dafür oder weißderGeierwie macht. Und ich werde vermutlich scheitern. Mich maßlos ärgern.

Dabei existiert das grundsätzliche Problem seit gut 30 Jahren. Damals hieß IT noch EDV, in einigen Landstrichen ADV. Aber es hat sich über die Zeit nie geändert. Nur stolpert jede neue Generation von Codern dort.

Ich weiß nicht, ob Du es mitbekommen hast: Inzwischen haben sich Anfänger zusammengetan und schreiben erste solche Artikel, nachvollziehbare Artikel. Und es gibt Weblogs, die extern mit Beispielen zeigen, wie man ein ganz konkretes Problem bei FHEM angeht.

Tut mir leid - ich finde, dass musste gesagt werden. Weil ich an dieser Stelle erstmal aufgebe. Verhaltenseffizienz: Ich mache die Dinge, die Erfolg versprechen. Sehr viele Dinge, die in FHEM mir vermutlich sehr nützlich wären, sehe ich gar nicht, werde ich nie sehen. Das geht weit über Dein Modul hinaus, das ist offensichtlich ein Problem des Klimas der FHEM-Community.

Ich wiederhole:
Erstens (das ist mir wichtig): Danke für Deine Arbeit.
RPI 4 - Jeelink HomeMatic Z-Wave

jensb

@curt
Danke für die klaren Worte und danke für deinen Dank.

Aus der Anwenderperspektive hast du zu 100 % recht. Dass man im Forum oft Richtung Commandref geschickt wird, stimmt auch, da die Commandref die meisten Details bietet, denn sie wird vom Programmierer zusammen mit dem Modul gepflegt. Und es liegt auch daran, dass Programmierer nicht so gern Wiki-Texte schreiben. Das ist nichts neues, denn du schreibst ja selbst "Dabei existiert das grundsätzliche Problem seit gut 30 Jahren. ... Nur stolpert jede neue Generation von Codern dort."

Wenn du vom Fach bist, weißt du, dass für ein perfektes Ergebnis sehr viele koordiniert zusammen arbeiten müssen. Diese Voraussetzung ist aber bei einer nichtkommerziellen Lösung wie FHEM im Bezug auf ein einzelnes Modul nicht gegeben oder ergibt sich nur in Ausnahmefällen. Ich habe hier im Thread mehrfach um Mithilfe gebeten, da ich das Modul eigentlich nicht als offizielles Modul einbringen wollte, sondern "nur" meinen Eigenbau auch anderen zur Verfügung stellen wollte, damit das Rad nicht neu erfunden werden muss. Die gesuchte Hilfe gab es hier und da, und darüber habe ich mich sehr gefreut. Aber es kam genauso vor, dass sie großmundig versprochen wurde und als es um konkrete Arbeiten ging plötzlich Sendepause war.

Zitat
Ich weiß nicht, ob Du es mitbekommen hast: Inzwischen haben sich Anfänger zusammengetan und schreiben erste solche Artikel, nachvollziehbare Artikel. Und es gibt Weblogs, die extern mit Beispielen zeigen, wie man ein ganz konkretes Problem bei FHEM angeht.
Das ist mir durchaus bekannt. Ich halte das sogar für den besten Ansatz, dass jemand, der ein Modul mit Mühe zum Laufen bekommen hat, einen Artikel schreibt. Denn der kann das aus einer ganz anderen Perspektive als der Programmierer, und das ist für den nächsten Einsteiger die bessere Hilfe. Wenn der Artikel nicht nur in einem Blog sondern auch in der FHEM-Wiki landet, hat auch die FHEM-Community was davon. Die Blogger haben nämlich meist kein Problem damit sich hier im Forum schlau zu machen. Wenn sie dann auch für FHEM und nicht nur für sich schreiben, dann stimmt das Verhältnis von geben und nehmen. Das hier gesagt trifft natürlich nicht auf jeden zu, also bitte nicht missverstehen.

ZitatSehr viele Dinge, die in FHEM mir vermutlich sehr nützlich wären, sehe ich gar nicht, werde ich nie sehen.
Ja, die Details kommen einem nicht entgegen, da FHEM nicht eine auf bestimmte Funktionen beschränkte Lösung mit einer anwenderoptimierten Oberfläche ist sondern genau das Gegenteil: eine technisch offene Lösung mit einer minimalistischen Standardoberfläche für Enthusiasten. Wer es einfach haben will, muss sich bei den kommerziellen Lösungen umsehen, Testberichte lesen und sich entscheiden, auf welche technologische Monokultur(en) er sich einlassen will. Wer seine Möglichkeiten ausloten will und nach mehr Flexibilität und Interoperabilität sucht, der ist bei FHEM richtig. Der Preis dafür ist die Aufwand, sich mit der heterogenen Dokumentation auseinanderzusetzen und zum Teil lange zu experimentieren, bis etwas so funktioniert wie man es sich vorstellt. So lernt man Programmiersprachen und so lernt man FHEM. Wer etwas anderes erwartet hat die Einleitung der Pflichtlektüre nicht gelesen.

Zitat... das ist offensichtlich ein Problem des Klimas der FHEM-Community
Da liegt sicherlich ein sehr kleines und nicht FHEM-spezifisches Körnchen Wahrheit drin, aber es stimmt meiner Meinung nach in dieser allgemeinen Form nicht. Hier investieren viele viel Zeit in die Programmierung und den Support bei einem Stundensatz von - richtig - 0 EUR. Und die FHEM Infrastruktur kostet jeden Monat echtes Geld. Zur Community gehören auch die Anwender die - richtig - 0 EUR für das Produkt FHEM und den Support zahlen. Es ist aber jedem überlassen, ob er nur Fragen stellt oder auch Antworten für andere hat. Trotzdem gibt es viele Anwender, die anderen Anwendern helfen und nur so kann es auch funktionieren.

ZitatWeil ich an dieser Stelle erstmal aufgebe.
Das finde ich sehr bedauerlich, aber aus deiner Perspektive nachvollziehbar. Falls du es dir noch mal anders überlegst empfehle ich konkrete Fragen wie die Steuerung eines Rasenmähers über einen eigenen Thread zu klären, sofern du das noch nicht versucht hast, denn nur so bekommst du Diskussionsteilnehmer, die sich genau für diese Fragestellung interessieren.

Deshalb hier noch mal mein Wunsch: Helft alle mit - jeder bei dem Thema zu dem er sich berufen fühlt. Aber bitte erwartet nicht, dass es schon die anderen machen werden. Man muss übrigens kein Programmierer sein, um einen Wiki-Artikel zu schreiben oder zu überarbeiten (Details zum Wiki-Benutzerkonto finden sich hier).

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

curt

Hallo Jens,

danke für Deine freundliche Antwort (wir werden zunehmend offtopic, aber vielleicht ist es notwendig). Du bist da aus meiner Sicht die große Ausnahme, gerade bin ich (bei einem anderen Modul/Entwickler) fröhlich auf die Nase gefallen. Ich hatte mich da aktiv eingebracht.

Insgesamt halte ich das Forum in wesentlichen Teilen für wenig nutzerfreundlich. Natürlich ist das eine vereinfachte Darstellung, aber das ist schon meine Empfindung. Ich weiß nicht, wie ich das am besten beschreibe, ich versuche es: Es sind mehrere Faktoren: Das fängt mit dem beliebten "lies commandref" an, welches AUCH Machtdemonstration ist: Du doof, ich wissend. Dabei wäre in der gleichen Zeit ein Auszug der eigenen fhem.conf machbar.

Man kann auch den direkten Vergleich zum Forum von ubuntuusers wählen, dieses wirkt sehr freundlich: Dort wird die Machtposition des Wissenden durch sehr kurze, sehr präzise Fragen/Anweisungen demonstriert. Auch ein Weg, kommt besser.

Insgemsat stört (mich) am Forum, dass bei gelösten Nutzerproblemen niemand schreibt, WIE das Problem denn nun gelöst wurde. Es wird auch nicht darauf gedrungen.

Zu Deiner Anmerkung "mitmachen, Wiki schreiben" usw: Das Forum erzieht die neuen Nutzer. In diesem Fall (aus meiner Sicht) negativ: Der Mensch passt sich Umgebungen an. Das führt dann -ich sage es extrem überhöht- dazu, dass der, der gerade für sich selbst ein Problem löste, auch zum Kreis der Wissenden gehört. Und die sagen nichts. Warum soll nun ausgerechnet ich etwas sagen?

Aber weiter zu Wiki und "mitmachen" - mal ganz konkret an meiner Situation:
Ich bin seit 9 Monaten dabei. Und da ich ansich ja vom Fach komme und zudem vor vielen Jahren auch einige Semester Automatsierungstechnik hörte, fällt es mir wohl leichter, die Hintergründe zu erfassen - will sagen: Ich habe ein ganz ordentliches System zusammengestolpert. Aber, jetzt kommt das große Aber:

Movie soll nicht nass werden. Messenger Signal muss Ende-zu-Ende-verschlüsselt eingebunden werden. Kalender hängt, weil ich ein Script zur Umwandlung meines bisherigen Kalenders schreiben muss, die fünf RPi-Kameras sind nicht in FHEM eingebunden, Alarme dafür gibt es daher auch nicht. Der User xyz hat mir Hilfe für Tab-Oberfläche angeboten (toll übrigens, so ein Angebot), das Modul für meine Weishauptheizung liegt seit einem Monat verpackt auf meinem Schreibtisch. Und so weiter und so weiter.

Die meisten Probleme der Aufzählung wären gelöst, wenn eine freundliche Seele geschrieben hätte "Keule, guck meine fhem.conf, aber mehr kriegst nicht, mach dann selbst weiter". Diese Antwort gibt es selten bis nie - wenn überhaupt eine Antwort kommt, heißt die "lies commandref". Ich will es nochmals sagen: Das ist schwierig, wenn die realen Möglichkeiten des Moduls nicht abschätzen kann.

Das führt nun zum Effekt "Katze beißt sich in den eigenen Schwanz": Wenn ich ein Problem für mich gelöst habe, könnte ich meinen Ansatz und mein Beispiel in das Wiki tun (ich habe Erfahrung mit Wikis). Könnte. Aber: Ich habe keine Zeit dafür. Ich muss mich endlich mal um die Heizung kümmern, Und dann die Kameras. Und dann ... das würde als Problem alles nicht existieren, wenn der Informationsaustausch im Forum freier wäre. Dann wäre ich schneller.

Entwickler-Threads lesen bringt auch wenig. Mal abgesehen davon, dass da faktisch nie Beispiele (gar mit Screenshots) kommen, gibt es da noch ein ganz anderes Problem. Gern erläutert an diesem Thread, der mit 13 Seiten ja noch direkt klein und übersichtlich ist: Du weißt nie, ob das, was Du liest, nicht schon veraltet ist. Von hinten lesen bringt aber auch nichts: Da fehlen immer die Vorinformationen.

Um endlich konstruktiv zu werden: Ich bin auf Seite 5 Deinen Beitrag #62.
Zitat von: jensb am 08 März 2018, 21:22:41
Ab der 2. Tageshälfte steht aber auch schon in der bisherigen Version am 2. Icon das Wetter von 01:00 des nächsten Tages, darunter aber nach wie vor die Min/Max-Temperaturen des aktuellen Tages. Das ist so nicht selbsterklärend und gefällt mir deshalb nicht wirklich. Anderseits ist es die einzige Möglichkeit, die mir eingefallen ist, um die Anzahl und Abfolge der Icons nicht tageszeitabhängig zu verändern. Man könnte alternativ ab Mittag das 2. Icon für den 1. Tag weglassen und mit dem 2. Tag weiter machen, verliert dabei aber die Temperatur für die nächste Nacht.

Wenn jemand hier Ideen oder Wünsche hat, lasst es mich wissen.

An Ideen und Wünschen mangelt es nun nicht. ;) Kennst Du Yahoo-Wetter bei FHEM? Bei mir sieht die grafische Umsetzung wie folgt aus (gemopst von irgendwo) [Screenshot unten].

Wie man sieht, ist Deine Detailinfo deutlich besser [Screenshot]. Allerdings gibt es die Generalisierung auf "ein Icon + Textinformationen" pro Tag bei Dir nicht. Siehst Du eine Möglichkeit, diese Generalisierung (alternativ) vorzuhalten?

Jens, nochmals:
Ganz abgesehen von Deiner freiwilligen Arbeit - ich empfinde Deinen Diskussionsstil als sachlich, fair, angenehm. Danke!
RPI 4 - Jeelink HomeMatic Z-Wave

curt

#199
Zitat von: jensb am 13 Mai 2018, 22:06:13
Hallo Werner,
...
Du willst die Warnmeldungen wahrscheinlich im Weblink sehen. Zunächst einmal muss aber das DWD_OpenData-Modul richtig eingestellt sein. Wenn Warnungen vorliegen (z.B. auf der DWD-Website nachsehen), dann müssen bei dir "a_n_xxxx Readings" vorhanden sein. Dann sollte aber auch der Weblink (Version ab 02.04.18) am dazugehörigen Icon ein Warnsymbol anzeigen (in der Wiki ist ein Screenshot). Auf das Warnsymbol kann man klicken, um die Warninfos zu lesen.

Ich bin jetzt zwar nicht Werner und weiß auch nicht, ob er mit der Antwort glücklich ist. Aus meiner Sicht ist die Frage nicht beantwortet bzw. mit "nein" beantwortet. Und ich verstehe endlich, warum ich keine Lösung finde, es gibt wohl gar keine im Moment. - Dazu muss ich ganz kurz ausholen:

Ich habe hier momentan alle möglichen und unmöglichen Wetterdienste (leider nicht Kachelmann mit der XL-10-Tage (die wäre genial, aber ich sehe da im Moment keinen Ansatz, da müsste Kachelmann mitspielen [¹])). Das tut auch wenig zur Sache - bei einem dieser Dienste gibt es eine sehr feine Sache, bei der Unwetterzentrale.

Das UWD-Modul (Unwetterzentrale, nutzt meteogroup.com) sind die Warnmeldungen so aufbereitet, dass sie EINZELN als Icon (+Text) zur Verfügung stehen. Im Vergleich dazu sagst Du "bei mir muss man schon klicken".

Ich habe -um es abzuschließen- einen Raum "Die Lage", das ist der taktische Bildschirm und kommt ansatzweise aus dem Militärischen: Da kommt im übertragenen Sinn nur hin "hier brennt es" und "Katastrophe da". Dort stehet bei mir für UWZ entweder "Warnungen: 0" oder das/die Icon(s) für Warnungen. Leider kann ich das im Moment grafisch nicht zeigen, ich habe keine Warnungen.

Es wäre aus meiner Sicht ideal, wenn Dein Modul losgelöst von der Zeitlinie mit "klick auf Warnungen" allein die Warnungen (jede einzeln) grafisch zur Verfügung stellen könnte.

[¹] Kachelmann XL-10 (hier Station Brocken, weil die Station so extrem ist): https://kachelmannwetter.com/de/vorhersage/2943991-brocken/xltrend
RPI 4 - Jeelink HomeMatic Z-Wave

MadMax-FHEM

@curt:

Vielleicht ist diese "Diskussion" (für dich) notwendig/wichtig...
...die Stelle ist es (finde ich) nicht.
Ist menschlich und passiert ist kein Ding!

Wenn es dir wichtig ist, nimm doch deine erste Ausführung (mit Link zu hier) und eröffne einen Thread...

Dann können auch andere ihre Meinung kund tun (ich habe es [bis auf jetzt] vermieden, damit der Thread seinen ursprünglichen Zweck nicht [gänzlich] verliert)...

Danke, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Phiolin

Besteht vielleicht die Möglichkeit, ein Reading für das passende Wetter-Icon für die Vorhersagen zu generieren? Die entsprechenden Mappings und Funktionen sind ja im Weblink praktisch schon vorhanden. Vielleicht lässt sich das ja einfach umsetzen?
Das würde die Darstellung im FTUI vereinfachen. :)

maddinthebrain

Hallo,

Ich habe nun DWD Open Data zusammen mit dem Weblink im Einsatz. Sehr schönes Teil!

Nur ein paar Fragen habe ich dann doch:

- Wie kann ich den Inhalt der Warnungen in Textform in den Weblink integrieren? Ist da schon was vorhanden bzw. vorgesehen?
- Gibt es eine Kartendarstellung der Warnungen vergleichbar dem UWZ plug-in.

Vielen Dank

Martin
Viele Grüße
Martin

Futro mit Proxmox und Debian: FHEM, Signalduino 433MHz & 868MHz, MAX!, WeeWX, FHEM2FHEM,
Raspi 4 mit ConBee mit deCONZ und Phoscon für ZigBee Aktoren und Sensoren

Rudy

Zu den Karten: Auf der Seite des DWD direkt scheint es nur eine interaktive Karte zu geben. Aber auf der Seite von Proplanta werden jedoch Warnkarten des DWD im png-Format angeboten. Für Bayern bspw. unter Link. Die Grafiken könnte man sich dann direkt einbinden.

somansch

Zitat von: Rudy am 03 Juni 2018, 15:57:54
Zu den Karten: Auf der Seite des DWD direkt scheint es nur eine interaktive Karte zu geben. Aber auf der Seite von Proplanta werden jedoch Warnkarten des DWD im png-Format angeboten. Für Bayern bspw. unter Link. Die Grafiken könnte man sich dann direkt einbinden.

Vom DWD gibt es auch Grafiken:

Für Deutschland komplett: https://www.dwd.de/DWD/warnungen/warnapp_gemeinden/json/warnungen_gemeinde_map_de.png
z.B. für Bayern: https://www.dwd.de/DWD/warnungen/warnstatus/SchilderMS.jpg

Tobias

#205
Hi,
sehr schönes Modul :) dazu ein paar Fragen:
* Wie oft werden die Daten aktualisiert? ICh habe nix dazu gefunden. Bei Proplanta habe ich zZ ein 4h Intervall. Kann ich mit diesem Modul genauer zb stündlich kommen?
* Ich habe die alertArea 115003000 für Magdeburg angegeben, der Status des Modul ist seit 30min auf "updating alerts". Ist das normal? Starte ich ein Update erneut kommt nur die Fehlermeldung das der Updateprozess immer noch läuft undich warten soll ;)
* Ich habe die Proplanta-Daten mit der im WEiki beschrieben Lösung mittels Logproxy als sehr schöne Grafik dargestellt. Gibt es hier etwas ähnliches?

Edit:
zu 1) automatisch alle Stunde
zu 2) Neustart half, alledings keine Alert Readings :(
zu 3) https://forum.fhem.de/index.php/topic,89188.msg816745.html#msg816745
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

Tobias

Die Fragen die noch bleiben: Wie komme ich an die Alterts ran? Diese stehen in keinem Reading :(

Ich habe auch noch ein VErsändnisproblem. Die Tageswerte, zb fc1_ev beschreiben laut Doku den Wert des Vortages. Ist das so korrekt? Kann man das im Modul selbst nicht auf den korrekten Tag mappen?? Das macht das plotten bzw die Interpretation viel schwieriger
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

PeterKl

Hallo Jens,
vielen Dank für das schöne Modul DWD_OpenData.
Im Wiki steht, dass man die Datei DWDODweblink.pm herunterladen muss. Ich habe in Wiki, Forum Commandref und SVN die Datei DWDODweblink.pm nicht gefunden. Wo muss ich suchen?
Vielen Dank!
Peter
PS: Ich hoffe, ich habe hier richtig gepostet. Ist mein erster Post im fhem Forum...

Octopus180

Ist doch im 1. Beitrag vorhanden, ganz unten.

PeterKl

Vielen Dank Octopus180!

Das war mein Problem:
Ich hatte immer als Gast (also ohne Anmeldung) im Forum nach der Datei gesucht, und als Gast sieht man die Attachments zu den Forumsbeiträgen nicht.
Als ich mich mit meinem Benutzernamen angemeldet hatte, konnte ich die Datei sehen und herunterladen.

Vermutlich haben alle FHEM-Nutzer, die als Gast im Forum diese Datei suchen, das gleiche Problem.