Posts by olicat

    Hi!


    Lt. Anleitung gibt es keine Konfigurationsoption fuer einen eigenen Server. Im Einstellungsmenue kann man die WU- und WC-Credentials eintragen. Der Bereich fuer die Konfiguration eines eigenen Servers fehlt jedoch.

    Sehr boese ist jedoch die Erwaehnung von Awekas in der Anleitung:

    Quote

    35 AWEKAS Wetterdaten abrufen

    1. Um die Live-Daten Ihres Multisensors in einem Webbrowser anzuzeigen, besuchen Sie bitte
    http://www.awekas.at und melden Sie sich unter „Mein AWEKAS“ mit Ihren Zugangsdaten dort an.


    Ich frage mich, wieviele Nutzer diese Station wohl im Vertrauen, damit auch Awekas fuettern zu koennen, kaufen ...

    Und nun unzufrieden sind ...


    Vielleicht ist die Anleitung falsch. Vielleicht wird der selbst zu konfigurierende Server ja per Firmware-Update nachgeliefert.

    Frag mal bei Bresser nach oder zieh einen Umtausch in Erwaegung, sofern noch moeglich.


    Oliver

    Hi!


    Vielleicht hilft es, bei der "Bresser 5in1" nach der genauen Modellbezeichnung zu suchen. Um welches Modell geht es denn?

    Kann diese Station an einen frei definierbaren Server Daten senden? Wenn ja - dafuer gibt es hier bereits ein HowTo.

    Geht es um diese Station? In der Anleitung taucht zumindest Awekas auf. Wenn ich auch nicht sehe, wie man das einrichten soll.


    Oliver

    Moin,


    Ecowitt hat reagiert und bei den ersten Stationen werden nun auch weitere Sensoren per custom server (etwa an Awekas) uebertragen:

    Nachdem Ecowitt mich offenbar ueber mehrere Mails nicht verstanden hat, kam - nach erneuter Erklaerung (und dem Hinweis, dass CCL/Bresser das besser macht) diese Aenderung nun doch sehr ploetzlich.

    Bisher gilt dies nur fuer das GW1100 und GW2000 mit der aktuellen Firmware-Version v2.2.0. Ich gehe aber davon aus, das diese Erweiterung auch mit einem Firmware-Update bei den anderen Stationen erfolgen wird. Somit sollte das dann in Kuerze auch die dnt-Station koennen.


    Gruss, Oliver

    Othmar,


    nur um Missverstaendnisse auszuschliessen:

    Quote

    Dort gibt es sehrwohl die besagten Sensoren.

    Ich stelle nicht in Abrede (auch Ecowitt nicht), dass die tempNf-Keys im WU-Standard enthalten sind.

    Aber obwohl diese Keys enthalten sind, werden entsprechende Uploads bei WU nicht angezeigt - WU selbst unterstuetzt diese Keys nicht - weder bei der Anzeige noch beim API-Zugriff. Somit sind die Testmoeglichkeiten fuer Ecowitt begrenzt. Aber genau bei dieser Argumentation setze ich an - was standardisiert ist, sollte auch durch Ecowitt unterstuetzt werden.


    Und:

    Fuer viele Sensoren gibt es im WU-Format-Standard schlicht keine definierten Keys. Die letzte Ueberarbeitung (zumindest des oeffentlichen Dokuments) ist knapp 3 Jahre alt.

    Also selbst wenn Ecowitt nun die Firmware hinsichtlich tempNf und soiltempN und leafwetness anpasst, wird das dann in Kuerze doch wieder auf die Notwendigkeit eines anderen Uebertragungsformats (EW-Format!) hinauslaufen. Denn IBM kann mit dem WU-Format nicht mit der Entwicklungsgeschwindigkeit neuer Sensoren durch Ecowitt mithalten. Der Innovator muss den Standard entwickeln - nicht ein Verwalter!

    Daher entwickelt sich dann ein de Facto-Standard - niemand wird gezwungen, diesen Standard zu unterstuetzen. Aber jeder sieht sich gezwungen, ihn zu unterstuetzen.


    BTW:

    Wieviel Gehoer hast Du denn bei IBM bzgl. des WU-Standards? Hast Du da einen Ansprechpartner? Vielleicht gibt es da ja die Moeglichkeit einer aktiven Mitarbeit, Vorschlaege einzureichen, eine Arbeitsgruppe oder so?

    Fuer CO2 haette ich gern zumindest AqCO2 standardisiert. Auch die Blitzdaten (Anzahl, Entfernung, Zeit) fehlen komplett. Oder humidityN. Oder Kenngroessen fuer Umweltlaerm (etwa LAeq).

    Das gibt es bereits alles im Ecowitt-Format - nur die Laerm-Sachen noch nicht - da fehlt noch der Sensor.


    Gruss, Oliver

    Hi!


    Meine Nachfrage bei Ecowitt fand Gehoer. Wenn auch (noch) nicht in erhoffter Form.

    Ich kann der aktuellen Argumentation von Ecowitt jedoch groesstenteils folgen.

    Sie unterstuetzen das WU-Format so, wie WU selbst das unterstuetzt.


    Und WU zeigt eben auch keine zusaetzlichen Temperaturen oder gar soiltemps an.

    Das Risiko aufgrund von nicht akzeptierten Keys von WU ausgesperrt zu werden ist real. Die Kompatibilitaet zu WU ist aber ein Verkaufsargument - kaum jemand wuerde sich wohl eine Station kaufen, die - als Mindestvoraussetzung - nicht WU-kompatibel ist.

    Und Ecowitt-Stationen sind WU-kompatibel. Daher will man an die Aenderung der bestehenden WU-Unterstuetzung nicht so richtig ran - auch wenn es nur ein kleiner Eingriff waere. Es ist eine Aenderung, die weitreichende Folgen haben KANN.


    Als bessere Loesung sehen sie (und da gebe ich denen vollkommen Recht) die Nutzung des Ecowitt-Formats.

    Bei - subjektiv - gefuehlter 50%-Marktmacht der Ecowitt-Stationen halte ich das auch fuer vertretbar!

    Im Ecowitt-Format sind saemtliche Keys verfuegbar - und der Hersteller der Wetterstation hat und behaelt die Kontrolle ueber das Format und muss sich nicht mit etwaigen Inkompatibilitaeten mit anderen Diensten auseinandersetzen.


    Moechte ein Diensteanbieter seinen Kunden mit Ecowitt-Stationen das Maximum an Sensordaten ermoeglichen, muss er das Ecowitt-Format selbst implementieren und darf nicht erwarten, das der Stationshersteller das fuer ihn erledigt.

    Oder der Diensteanbieter ist stark genug, sein eigenes API-Konzept durchzusetzen - Weathercloud oder auch WOW machen das vor.


    Also:

    Ich habe wenig Hoffnung, das Ecowitt noch Aenderungen am veraltetem WU-Format macht - auch wenn diese eigentlich durch einen "Standard" gedeckt sind.

    Denn selbst der erweiterte "Standard" deckt nicht alle Moeglichkeiten, die das Ecowitt-Format bietet oder Ecowitt-Stationen liefern (etwa CO2, Blitzdaten, Humidity1..8, ...).


    Fuer Awekas heisst das:

    Je nach Sichtweise liegt der schwarze Peter bei Ecowitt (die unterstuetzen den WU-Standard nicht ausreichend) oder bei Awekas (die unterstuetzen kein Ecowitt-Format).

    Damit ist die Schuldfrage klar. Aber es aendert sich dann aber leider auch nichs.


    Die meisten Software-Loesungen haben die Zeichen der Zeit erkannt und unterstuetzen nativ das Ecowitt-Format (WeeWX, CumulusMX, PWSDashboard, MeteoTemplate, ...).

    Bei den Diensteanbietern fehlt bisher noch diese Einsicht. Oder es ist denen schlicht nicht wichtig genug, weil den meisten Nutzern die Moeglichkeiten ausreichen, die das alte WU-Format bietet.

    Oder sie wollen nicht die Buechse der Pandora oeffnen - denn dann fragen die Kunden nach, warum nur 4 statt der moeglichen 8 Kanaele uploadbar sind oder warum die Werte des "bla"-Sensors nicht visualisiert werden - sie werden doch hochgeladen und stehen zur Auswertung zur Verfuegung.

    Oder warum man nicht frei konfigurierbare Vergleichsgrafiken von verschiedenen Temperatursensoren (Ecowitt unterstuetzt beinahe 20 Temperatursensoren!) haben kann.

    Das zieht dann sicherlich auch aufwaendige Aenderungen an den Datenbankstrukturen, dem Platzbedarf, der Verarbeitungskapazitaet etc. nach sich.

    Und kostet Geld ...


    Meine Empfehlung an Awekas waere jedoch, ueber eine zusaetzliche Moeglichkeit des Uploads im EW-Format nachzudenken (mit allen moeglichen Konsequenzen).

    Ich versuche weiter, Ecowitt von der Unterstuetzung des erweiterten WU-Standards zu ueberzeugen.


    Als Referenz:

    https://support.weather.com/s/article/PWS-Upload-Protocol?language=en_US

    Weather Company Data - Enhanced Current Conditions - Current Conditions - PWS Observations - Current Conditions - v2
    Weather Company Data | PWS Observations - Current Conditions - v2 Domain Portfolio: Observations | Domain: Current Conditions | API Name: PWS Observations…
    docs.google.com


    Gruss, Oliver

    Hi Othi,


    was genau erwartest Du denn da? Kooperation klingt irgendwie etwas groß.

    Du musst doch einfach nur das entsprechende Protokoll unterstützen?

    Eine Protokollbeschreibung sollte verfügbar sein. Ansonsten kann man das aber auch leicht bei bereits vorhandenen Lösungen abgucken.


    Oliver

    Hi!


    Wenn die Zusatzsensoren im WU-Protokoll nicht übertragen werden, kann DNT da recht wenig machen.

    Du könntest jedoch bei Ecowitt um eine Änderung der Firmware bitten.


    Ansonsten bleibt erstmal nur, zu warten bis Othi auch den Upload im Ecowitt-Format unterstützt.

    Oder Du nutzt eine Software, die die eingehenden Werte im Ecowitt-Format in das Awekas-API-Format oder nach WU (dann aber mit Zusatzsensoren) konvertiert.

    FOSHKplugin sollte beides können.


    Die Firmware-Versionen Deiner Station sind aber aktuell?


    Oliver

    Hi!


    Deiner Station fehlt noch die WLAN-Anbindung. Du solltest die initiale Einrichtung ggf. nochmal wiederholen.

    Oben links als ca. 4. Icon solltest Du dann ein grünes WLAN-Symboil sehen.

    Dann klappt es auch mit dem Datenversand.


    Nachtrag:

    Womoeglich ist Dein 4. Symbol ja das (alte) WLAN-Symbol und Du hast nur eine veraltete Firmware.

    Du solltest die Firmware-Version der Station mal pruefen - aktuell ist derzeit v1.8.6 fuer die Geraete-Firmware und v1.6.4 fuer die WIFI-Firmware.

    Zahnrad/Zahnrad/Zahnrad/Zahnrad

    Cursor hoch

    Lupe -

    Eine neue Geraete-Firmware wird ueber SD-Karte eingespielt. Die WIFI-Firmware ueber die WS View- bzw. WSView Plus-App.


    Oliver

    Hi!


    Das Ultrasonic-Bundle umfasst einen Windsensor auf Ultraschallbasis - hat also keine mechanischen Bauteile und ist somit weniger wartungsintensiv.

    Außerdem misst er häufiger und genauer. Zusätzlich sind im US-Bundle Einzelsensoren enthalten - Du kannst also die Außentemperatur, den Niederschlag und eben den Wind an den dafür sinnvollsten Positionen messen.

    Das andere Bundle enthält nur einen Kombisensor und ist somit weniger flexibel bzgl. der Aufstellung und daraus resultierend auch weniger genau.


    Wer die bestmögliche Performance haben möchte, sollte das US-Bundle wählen und um ein gutes (!) Radiation Shield für den T/H-Sensor erweitern.


    Bei weniger großen Anspruch reicht durchaus auch der Kombi-Sensor mit aktivierter Temperaturkompensation.


    Beide Stationen lassen sich mit einer beliebigen Anzahl weiterer Konsolen erweitern.


    Oliver

    Hi!


    Bitte nimm nicht die WH3000 von Froggit. Das Display ist sicherlich Geschmackssache. Aber diese Konsole unterstützt NICHT alle aktuellen Sensoren.

    Mit einer HP25xxC-Konsole - also z.B. mit dem HP1000SE Pro-Paket bist Du da für zukünftige Ideen besser aufgestellt.

    Siehe auch das WIKI im Wetterstationsforum.


    Oliver

    Hi!


    Quote

    Wenn es so klappt, sehe ich es richtig, dass ich die Daten dann sowohl über die ecowitt Seite & App abfragen kann (ohne Abokosten)

    als auch als Hauptziel die Daten automatisch an Awekas "gepusht" werden, wenn niemand daheim ist, also die Daten immer extern abgefragt werden können?

    Sofern die Station an Ecowitt.net sendet sind die Stationsdaten bereits weltweit per App und Browser abrufbar. Awekas lässt sich jedoch zusätzlich als benutzerdefiniertes Ziel einrichten.

    Allerdings werden bei Awekas keine Daten des Blitz-Sensors angezeigt (im Gegensatz zu Ecowitt.net wo ALLE Sensoren angezeigt werden).


    Quote

    Funktionieren diese 3 Sensoren mit dem GW2000 oder kann nur ein Regensensor ausgelesen werden?

    Deine Sensorenauswahl ist vernünftig - so sollte sich auch Awekas füttern lassen. Vom Blitzsensor abgesehen.

    Das GW2000 unterstützt den im WS90 verbauten Regensensor und parallel dazu den WH40.


    Quote

    wer ist dann die "Hauptkonsole" da ich ja eigentlich mit dem GW2000 schon eine habe, und nur einen Display für die Datenwiedergabe benötige?

    In der Ecowitt-Welt gibt es so etwas wie eine Hauptkonsole nicht. Sämtliche Konsolen arbeiten autark und verarbeiten parallel alle unterstützen und im Empfangsbereich befindlichen Sensoren.

    An jeder Konsole (ob mit oder ohne Display) kann EIN benutzerdefiniertes Weiterleitungsziel (custom server) eingerichtet werden. Also auch Awekas.

    Ein einfaches Display (also ohne Konsolenfunktion) gibt es bei Ecowitt nicht.

    Wenn es Dir nur um die lokale Anzeige Deiner Daten geht, wäre ggf. Personal Weather Tablet (PWT) eine Möglichkeit, einem alten Android-Tablet eine sinnvolle Aufgabe zu übertragen.


    Oliver

    Hi!


    Quote

    Die Werte werden bei euch laut Paket von ersten Kommentar in mph abgeliefert.

    Die Windwerte werden im WU-Protokoll (im Ecowitt-Protokoll uebrigens auch) IMMER in mph uebermittelt.

    Das ist also ueberhaupt nichts Besonderes und auch keine Eigenheit der Froggit-Stationen.


    Wenn jetzt aber ausschliesslich Deine Wind-Werte bei Awekas so seltsam sind und bei WU und auch lokal vernuenftig aussehen, sollte man den Fehler tatsaechlich auch bei Awekas suchen.

    Vielleicht gibt es da ja wirklich irgendeinen Faktor, mit dem die Eingangswerte angepasst werden, der in Deinem Fall aber nicht passt.

    Da kann dann wohl wirklich nur othi helfen.


    Oliver

    Hi!


    Deine Station sendet doch ganz normal im erwarteten WU-Format?

    Zumindest Dein Bild im Beitrag sieht fuer mich absolut einwandfrei aus - die Station sendet die Windwerte syntaktisch korrekt.

    Wenn die Werte zu hoch sind, stimmt entweder die Kalibrierung des Windsensors nicht oder der Windsensor ist defekt.

    Woraus schliesst Du denn, dass Deine Windwerte zu hoch sind? Welche Referenz?


    Oliver

    Hi!


    Der Sendeintervall hat aber mit dem Messintervall nicht viel zu tun!

    Zwischen den einzelnen Sendungen kann die Station ja durchaus weiter messen und den Maximalwert innerhalb dieses Intervalls beim nächsten Senden mitschicken.


    Zusätzlich gibt es dann aber auch noch den Sendeintervall von der Station zu irgendwelchen Diensten wie Awekas.

    Da ist dann spannend, was die Station mit den Zwischenwerten macht ...


    Wenn es Dir jedoch um eine zeitnahe Anzeige auf der Konsole geht, dann ist der Sendeintervall von Sensor zur Konsole durchaus interessant.


    Oliver