Posts by Stefanpf


    Jaein, wenn ich das richtig in Erinnerung habe, neigen die ganzen "Maker" Sensoren zu Korrosion, so dass eine vergoldete Variante schon fast Pflicht ist.

    Mag aber auch sein, dass ich das mit Bodenfeuchtesensoren verwechsel (die ja tendenziell mehr Feuchtigkeit abbekommen).


    Ich nutze einen nackten (kein nodemcu oder ähnliches) ESP8266 mit 18650 und kleiner Solarzelle fast wartungsfrei als zusätzlichen 'Solarsensor'. Der ist allerdings 10min im Deepsleep und wacht dann nur kurz auf was für einen Regensensor eher suboptimal wäre.

    Ursprünglich nur mit kleinen Laufzeit- Optimierungen (wie statischer IP statt DHCP). Inzwischen nutze ich ESPNow als Protokoll was die Verbindungszeit noch einmal massiv verkürzt hat.


    Der ESP8266 kann afaik nicht per GPIO Interrupt (Regentropfen) aufgeweckt werden.

    Da müsste man vermutlich etwas herumbasteln oder auf einen ESP32 ausweichen. Der braucht zwar wieder mehr Strom aber vielleicht kann man die Logik in den Coprozessor auslagern und den ESP nur zum Alarmieren aufwecken

    Habe ja auch so eine China-Kiste (Conrad EFWS).

    Allerdings ist mir das mit der Rainrate in der Art noch nicht aufgefallen (mit den großen Schritten).


    Ausschlaggebend für die Genauigkeit ist ja die Größe der Wippe (bzw. des Löffels) im Verhältnis zu der Fläche des Trichters.


    Angenommen der Löffel kippt bei 2ml Inhalt (2000mm³) und der Trichter hat 100mm Durchmesser (7854 mm²) , so entspräche ein Impuls einer "Wassersäule" von

    2000mm³ / 7854 mm² = 0.254mm².


    Um bei deinem Beispiel zu bleiben:

    Bei konstantem Niederschlag von 0,1mm gibt es nach 2,5h den ersten Impuls.


    Oder der Löffel ist beim letzten Schauer bereits zu 95% voll gelaufen und jetzt reichen schon ein paar Tropfen für einen Impuls...

    Es wäre also sinnvoll die Rate erst zu "bestimmen" wenn mindestens 2 Impulse in einem zusammenhängenden Zeitfenster gezählt wurden.


    Dazu kommen noch verschiedene Toleranzen

    wie Messungenauigkeiten beim Kippen der Wippe/des Löffels, "Wasserverlust" aufgrund des flachen Trichters durch herausspringende Tropfen, ...


    Kurzum: das Messprinzip taugt meiner Meinung nach bestenfalls für "langfristige', kumulierte Beobachtungen und keinesfalls für Momentaufnahmen (Rate).

    Bei der HA vielleicht als Kriterium für den Einsatz des Rasensprengers verwendbar, aber keinesfalls zum Einfahren von Markiesen oder ähnlichen Gegenständen die nicht naß werden sollen.

    Von daher musst du wissen, ob dich dieses lange Aktualisierungsintervall überhaupt interessiert.....


    Eigentlich benötigst du eher einen Regensensor anstelle eines Regenmengenmessers.


    Ich liebäugel seit geraumer Zeit mit dem Sensor der hier verbaut ist:

    https://www.stall.biz/project/…n-fuer-die-hausautomation

    Weewx unterstützt diverse "Services".

    Entweder Out of the box oder per Erweiterung (meist auf GitHub zu finden).

    Awekas ist direkt mit an Board.(wenn ich mich richtig erinnere).

    Ob die weiteren Sensoren unterstützt werden weiß ich leider nicht (kenne die Bresser nicht).


    Den Umfang definiert afaik das Protokoll bzw. dessen Implementierung.

    Ich kann beim Custom Server z.B. zwischen WU und Ecowitt Protokoll wählen.

    Ich weiss nicht mehr warum, nutze aber letzteres (könnte wohl mehr?).


    Alsbald die Attribute im Request enthalten sind, kann man sie weiter verwenden.

    Falls sie nicht im Driver enthalten sind, bastelt man da etwas an dem Python Skript herum (kann selbst kein Python, aber so kleine Änderungen bekommt man ja meist doch hin).


    Leider ist matthewwall (der Betreuer des Interceptors) derzeit wohl ziemlich busy, so dass er im repo im Moment nicht aktiv ist.


    Möchte man nicht vorgesehene Werte in der Weewx Datenbank speichern, so besteht die Möglichkeit der Schemaerweiterung...

    Da ist nach Einarbeitung wohl einiges möglich.

    Ich nutze Interceptor als Treiber

    https://github.com/matthewwall/weewx-interceptor


    Dieser bietet zwei Möglichkeiten:

    - eine Art sniffer: per dns Eintrag wird z.B. die Kommunikation zu Weatherunderground auf den Host des Interceptors umgeleitet, dieser schneidet die Pakete mit und leitet sie an WU weiter

    - falls die Station einen Custom Server Eintrag unterstützt kann spart man sich den Voodoo und verwendet den Webserver des Interceptors als Gegenstelle. Dies funktioniert ohne bei mir bislang ohne murren.


    Meine Heimautomatisierung soll auch von so wenig externe Server wie eben möglich abhängig sein (aktuell wehrt sich nur der Rasenmäher).

    Da fummelt irgendwer an der Api rum oder sperrt den Account und schwupps bleiben die Rollläden unten... nein danke :-)

    Sorry, dann fällt mir da nicht mehr viel zu ein ausser die Koordinaten Richtung Osten zu fallen.

    Awekas wird den dort konfigurierten Standort verwenden und ist davon nicht betroffen.


    Einen habe ich vielleicht noch (ist aber ziemlich weit hergeholt):

    Verwendest die eventuell noch Weewx oder andere Anbindungen gleichzeitig?

    Der Weewx Interceptor gibt als Result auf den Get Requests nämlich eine statische Zeitzone zurück, welche bei meiner Station (EFWS-2900) immer die vorher konfigurierte Zeitzone verstellte.

    Mag es sein, dass du vor deinem Längengrad ein Minus eingegeben hast?

    -11.xxx statt 11.xxx packt dich dann etwa auf die Länge der Kanaren, was ziemlich genau der "Zeitverschiebung" entspricht.


    Falls nicht:

    Wenn du die Ursache nicht findest, verschiebe deine Koordinaten Richtung Osten.

    Wenn man nicht rechnen mag sind Apps

    wie Sun Locator Lite geeignet um den richtigen Längengrad durch try and Error zu ermitteln.


    Oder benutzt die Station die Koordinaten auch um andere Vorhersagen zu ermitteln?


    Edith: gerade mal die Anleitung heruntergeladen: da gibt es kein +/- sondern East/West --> sollte East sein.

    Ah, danke für die schnelle Antwort.

    Hatte immer Probleme die meine original Kurve auf die Werte zu reflektieren.

    Macht aber ja auch Sinn :-)

    Zumindest bei schwankenden Bedingungen wie heute erklärt das dann auch die Abweichung zu den BFS Werten zum Teil.

    Eine technische Frage hätte ich da noch:

    Die Vergleichswerte sind liegen ja "nur" stündlich vor.

    Handelt es sich dabei um einen Mittelwert/Median... über die letzte Stundr oder ist das nur eine Momentaufnahme des letzten Messwertes?

    Hallo zusammen,


    ich habe mir heute eine Sperre wegen zu hoher UV Werte eingehandelt.
    Die steht auch nicht zur Diskussion - dass die Werte tatsächlich zu hoch waren ist mir bereits vorher aufgefallen. Ich wollte allerdings bislang aufgrund des sehr wechselhaften Wetters in den letzten Tagen nicht einfach schlagartig mit riesigen Korrekturfaktoren um mich schlagen und es lieber nach und nach korrigieren.

    Auch ist noch fraglich ob ich dauerhaft über Korrekturen den Misstand beseitigen kann oder ob der Sensor selbst einfach ungeeignet ist....


    Was mich eigentlich primär stört bzw. wo ich ein Verbesserungspotential erkenne ist die Hörigkeit gegenüber der eigenen "Vergleichswerte" mit denen in der Kommunikation mit dem Admin Team argumentiert wird.


    Hier einmal die UV Werte der Stationen in meiner Nähe.



    Dazu habe ich ca. eingezeichnet

    "1" mein Standort

    "2" UV Station des Bundesamtes für Strahlenschutz in Osnabrück-Belm


    Dazu einmal die aktuellen Werte aus Belm:



    Sorry, aber wenn ich wie folgt darum Bitte diese Vergleichswerte nicht als Referenz zu verwenden


    ----------------------------------


    dann finde ich die Antwort schon so naja....

    Quote

    nun ja einen Vergleich hat man hier u.a.:

    https://www.awekas.at/de/qualc…te=1598698800&distance=20

    Hier kann man schön sehen, dass die Werte zu hoch sind. Diese Vergleichswerte sind u.a. schon zuverlässig und entsprechen auch dem DWD Wert für heute.



    In meiner Vergleichsliste (20km) stehen 3 Stationen zur Verfügung.

    Die nächste Station liefert seit 3 Tagen maximal einen UV Index 1.x (schafft es also nie über die 2 hinaus), während das BFS alleine heute bei ~5.3 peaked.

    Alleine diese Station dürfte den Mittelwert des Vergleichswertes derart herunterziehen, dass dieser genau genommen nur Mist ergibt.
    Natürlich verfälscht mein zu hoher Wert den Mittelwert genauso - wobei vielleicht korrigiert er ja auch nur diesen Missstand :-)


    Der prognostizierte UV Index lt. DWD liegt übrigens in unserer Region bei 4 (bzw. 5 auf einem Fleck ~10 km südlich von mir)


    Auch da ist der erwähnte Vergleichswert "leicht vorbeigeglitten".


    Bitte nicht gleich auf Angriffsmodus umschalten - eigentlich möchte ich nur konstruktiv an der Vorgehensweise arbeiten.


    Grüsse


    Stefan


    P.S. In den automatisch genierten Administrationsmeldungen fehlt ein Content-Type bzw. ein Encoding Hinweis.

    Man kann die Mail mit den ganzen Umlauten nur sehr schwer lesen.

    P.P.S. Ich habe die historischen Werte um den gleichen Korrekturfaktor (-23%) angepasst, den ich aktuell in der Station eingegeben habe.


    P.P.P.S.

    Gerade entdeckt: auf meiner Instrumentenseite wird für heute ein MAX UV von 7 angezeigt. Solch ein Wert ist aber in den Einzelwerten überhaupt nicht enthalten (auch vor der Korrektur nicht).

    Mag es sein, dass die Neuberechnung im Zuge des Importes da etwas durcheinander bringt?