Posts by olicat

    Hi!


    Mit dem gestern veröffentlichten Firmware-Update v1 7.6 sollten jetzt auch GW1000 und WH2650 die erweiterten Sensoren im WU-Protokoll etwa zu Awekas übermitteln können.

    Dazu gehören zusätzliche T/H-Sensoren WH31/WN30, Blattfeuchte-Sensoren WN35 sowie die Temperatur-Sensoren WN34 (liquid, soil).


    Somit sollten jetzt alle aktuellen Stationen von Ecowitt/Fine Offset das erforderliche Update erhalten haben.


    Zum Aktualisieren der Firmware bitte die App WSView Plus nutzen.


    Oliver

    Hi!


    Sofern man ohnehin schon einen 4G-Router einsetzt, benoetigt man eine WS6006 nicht.

    Oder andersrum:

    Bei Einsatz einer WS6006 ist ein zusaetzlicher 4G-Router nicht noetig, da diese die Daten von sich aus ueber 4G versendet.

    Erfahrungen mit diesem Geraet habe ich nicht. Ich weiss nur, dass diese Konsole deutlich teurer und deutlich eingeschraenkter ist als alle anderen Ecowitt-Konsolen (fehlendes WLAN, knifflige Konfiguration, keine Ausgaben im Ecowitt-Format, Unterstuetzung nur weniger Sensoren und Dienste).

    Ich wuerde (wohl) immer erstmal eine Loesung mit einem externen 4G-Router praeferieren.


    Oliver

    Moin!


    Siehe Beitrag 7 - auch Bresser uebertraegt im WU-Format.

    Bresser nutzt dazu sehr wahrscheinlich die Felder AqPM2.5 und AqPM10. Beachte dazu bitte aber auch meine Antwort in Post 10.

    Der PM2.5 wird durch Ecowitt an WU ausgeliefert. Jedoch nur fuer den ersten Kanal der WH41/WH43. Der PM10 wird von Ecowitt grundsaetzlich nicht ausgegeben.

    Fuer die Werte der Luftqualitaets-Innensensoren gibt es keine Entsprechungen im WU-Format.


    Oliver

    Hi!


    Quote

    Könnte ich die Daten separat übertragen, also quasi in zwei Daten-Paketen?

    Das geht meines Wissens nicht. Die Daten muessen komplett innerhalb eines Datensatzes uebermittelt werden. Irgendwo hier hatte Othi das mal so beschrieben. (Zumindest habe ich mir das so gemerkt).


    Quote

    Ich würde dann die Daten separat übertragen über meine zweite Schnittstelle (GW1100) übermitteln.

    Wie soll das gehen? Auch das GW1100 kann diese Werte doch nicht uebertragen:


    Wie ich bereits schrieb: der WH45 ist ein Innensensor mit sehr begrenzter Aussagefähigkeit zu Wetter- oder klimatischen Bedingungen.


    Im WU-Protokoll gibt es keine Möglichkeit, die Werte für Innenwerte von PM2.5 oder PM10 oder gar CO2 zu senden.

    Vgl. hier:

    Da kann Ecowitt selbst relativ wenig machen - der WU-Standard liegt nicht in deren Hand. Ecowitt hat daher ein eigenes Uebertragungsprotokoll entwickelt, das aber von Awekas nicht unterstuetz wird.


    Zwar gibt es die Keys AqPM2.5 und AqPM10 im WU-Protokoll ueber die zumindest PM2.5 und PM10 gesendet werden koennten. Doch diese sind sinnvollerweise fuer entsprechende Aussensensoren zu nutzen.


    Ecowitt hat einen Luftqualitaetssensor fuer Aussen im Programm: den WH41.

    Der sendet jedoch ausschliesslich PM2.5-Werte und diese auch nicht im WU-Format, weil lt. WU-Format genau ein Sensor moeglich waere, Ecowitt jedoch den Betrieb von bis zu 4 Sensoren parallel ermoeglicht.

    Welchen der Sensoren sollte Ecowitt dann im WU-Protokoll senden? Auch Awekas unterstuetzt genau EINEN Sensor fuer PM2.5 und PM10.


    Das WU-Protokoll ist schlicht die falsche Wahl fuer diese Zwecke. Und Awekas ist auch nicht der richtige Ort fuer die Speicherung und Anzeige von Innenwerten.


    Aktuell kann ich nur empfehlen, das Ecowitt.net-Portal zu nutzen. Dort werden ALLE Sensoren von Ecowitt verarbeitet und dargestellt.

    Alternativ koennte man mit geeigneter Software (etwa FOSHKplugin) die von der Wetterstation kommenden Keys konvertieren und remappen - also z.B. den Wert fuer PM2.5 und PM10 vom WH45 auch an Awekas senden.

    Trotzdem muesste man mangels Feld in der Awekas-Datenbank auf CO2 verzichten (man koennte CO2 jedoch auf PM1 mappen - so wuerde der CO2-Wert im Feld PM1 angezeigt).


    Oliver

    Hi!


    Quote

    Ist das die HP1000SE Pro Black Version Single Sensor Edition?

    Nein.

    Es handelt sich hier um das DP2000 genannte Set von Froggit bestehend aus dem GW2000, dem WS68, dem WH40 und dem WH32.

    Der kombinierte Wind/Licht-Sensor wird ueber eine Batterie sowie Solarpanel und Superkondensator versorgt - der SuperCap wird per Solarpanel geladen und erst, wenn kein ausreichender Solarertrag vorhanden und der Supercap leer ist, wird auf die Batterie zurueckgegriffen.

    Daher sind da mit Batterielaufzeiten von mehr als einem Jahr zu rechnen.

    WH40 (Regenmesser) sowie WH32 (T/H-Sensor) arbeiten mit AA-Batterien mit einer erwarteten Batterielaufzeit von ebenfalls mehr als einem Jahr.

    Nach Erfahrunsgberichten sind durchaus auch Laufzeiten von 2 oder 3 Jahren moeglich.

    Naehere Infos zu diesen Geraeten und dem Ecowitt-Oekosystem finden sich hier im WIKI.


    Oliver

    Hi!


    Offenbar hat Awekas zumindest die Datenbankfelder fuer PM1, PM2.5 und PM10.

    Per Awekas-API kann man die auch zu Awekas hochladen (tatsaechlich macht FOSHKplugin das sogar - allerdings fuer den WH41). CO2 fehlt aber in der Awekas-API und somit sehr wahrscheinlich auch in der Datenbank.


    Demnach uebertragen die Bresser-Stationen von PWL aus per Awekas-API zu Awekas.

    othi ?

    Kannst Du das bestaetigen?

    Mir ist noch immer nicht klar, ueber welche Protokolle die Bresser-Stationen die Daten senden koennen - ich lese auch immer wieder mal was von JSON - ist das der Weg, wie diese Stationen die Daten zu PWL senden oder ist das nur den Weg per Awekas-API von Awekas zurueck zum Client?


    Oliver

    Hi!


    Der Bresser-Sensor war ein simpler Temperatur/Luftfeuchte-Sensor, oder?

    Etwas Vergleichbares wie der WH45 (hat Bresser das ueberhaupt?) wurde sicherlich nicht bei Awekas dargestellt.


    Und Awekas unterstuetzt ja durchaus auch T/H-Innensensoren - auch beim Versand von Ecowitt-Konsolen aus.

    Nur eben den T/H-Sensor des WH45 nicht - im WU-Format gibt es keine Moeglichkeit dafuer.


    Oliver

    Hi!


    Hui - da haben wir gleich mehrere "Problemkreise" ...


    1.

    Das WU-Format kennt fuer die Datenpunkte, die der WH45 liefert, keine Entsprechung. Es gibt also schlicht keine Keys im WU-Standard, denen man die Werte zuordnen koennte.


    2.

    Die Awekas-Datenbank hat fuer die meisten WH45-Datenpunkte keine Felder. Also selbst, wenn diese vom Format her eingeliefert werden koennten, wuerden diese nicht in der Awekas-Datenbank erscheinen und waeren somit fuer den Nutzer auch nicht sichtbar.


    3.

    Der WH45 ist - da ein Innensensor - aus meteorologischer Sicht eher uninteressant. Daher rechne ich da auch nicht mit einer zeitnahen Aenderung auf Awekas-Seite.


    Technisch moeglich waere es aber natuerlich.

    Awekas muesste entsprechende Datenbankfelder anlegen und eine Moeglichkeit des Uploads bieten.

    Das WU-Format ist dafuer dann aber nicht geeignet - Awekas-API oder nativ das Ecowitt-Format koennten (oder wuerden) die entsprechenden Felder uebermitteln.

    Aber da kommt dann mein 3. Punkt wieder ins Spiel ...


    Also erfreu Dich am WH45 bei Ecowitt.net oder auf der lokalen Konsole.

    Mehr geht (noch) nicht ...


    Oliver

    Hi!


    Quote

    ich frage mich wie lange sich Bresser mit dieser Krücke noch abgibt

    Das solltest Du besser Bresser fragen.

    Wobei ich nochmals darauf hinweise, dass Bresser einfach nur eine Station vom chinesischen Hersteller CCL verkauft, die mit dem von CCL selbst betriebenen Dienst ProWeatherLive verheiratet ist.

    Bresser kann das einfach nicht aendern!

    Ausser, sie wuerden sehr viel Geld in die Hand nehmen und Wetterstationen selbst entwickeln und noch mehr Geld, um einen vergleichbaren Dienst aus dem Boden zu stampfen.

    Beides sehe ich bei einem "Gemischtwarenhaendler" eher nicht.


    Somit bleibt Dir kaum mehr als abzuwarten, bis der PWL-Dienst seitens des Herstellers (CCL!) endlich stabiler wird. Ich bin mir ziemlich sicher, das wird er ...


    Oliver

    Othi,


    ich wuerde wohl den WU-Standard implementieren und zusaetzlich humidity1 und temp1f akzeptieren.

    Etwa so:

    Code
    if (isset($arr['humidity1']) || isset($arr['temp1f'])) {
      temp1f --> Extra Temperatur 1, temp2f --> Extra Temperatur 2 .... temp4f --> Extra Temperatur 4
      humidity1 --> Extra Feuchte 1 .... humidity4 --> Extra Feuchte 4
    } else {
      temp2f --> Extra Temperatur 1, temp3f --> Extra Temperatur 2 .... temp5f --> Extra Temperatur 4
      humidity2 --> Extra Feuchte 1 .... humidity5 --> Extra Feuchte 4
    }

    Andere Zuordnungen wuerde ich mit Verweis auf den WU-Standard ignorieren.


    Parallel dazu sollte man jedoch die Verursacher (hier wohl Bresser/CCL) ueber die fehlerhafte Implementierung in der Firmware informieren.


    Oliver

    Hi!


    Das scheint mir ein leicht anderes Problem zu sein. Auch ich sehe die Luecke beim Vergleich der Wetterstationen - zwischen 00:00 und 01:00 Uhr gibt es keine Werte und unterbrochene Kurven.

    Allerdings sind im fraglichen Zeitraum KEINE Upload-Schwierigkeiten aufgetreten - jeder Versuch wurde erfolgreich quittiert - ausser einmalig exakt um 01:00 Uhr.


    Oliver

    Hi!


    Welchen Wetterstationstyp habt ihr zwei in den Einstellungen von Awekas eingetragen?

    Vermutlich muss man für die von PWL kommenden Daten (erstmal) eine Ausnahmeregel bauen und das Parsen am Server davon abhaengig machen.

    Othi?

    Laeuft das Parsen in Abhaengigkeit vom gewaehlten Stationstyp?

    Oder machst Du bei eingehenden WU-Format immer das gleiche Mapping?


    Oliver

    Hi!


    Zur Verdeutlichung:


    https.//stationswebtest.awekas.at/index.php?id=15290

    -----------^^^^^^^^^^^^^

    https.//stationsweb.awekas.at/galerie.php?id=15290

    -----------^^^^^^^^^^


    ... im Uebrigen waere ich vorsichtig mit Bildern wie dem ganz rechts - da gab es doch kuerzlich erst Aerger um irgendwelche Bildrechte betreffs Davis ...


    Oliver

    Salut !


    Ta station n'envoie effectivement pas de données à Awekas, comme le montre cette page de vérification.

    Tu devrais vérifier les paramètres de ta station pour l'envoi vers le custom server en suivant ces instructions :

    • active le mode custom server
    • utilise le protocole Wunderground
    • saisis comme serveur : ws.awekas.at
    • utilisez comme chemin : /weatherstation/updateweatherstation.php ? (notez le point d'interrogation à la fin)
    • comme utilisateur : ton nom d'utilisateur Awekas (de l'enregistrement)
    • comme mot de passe, vous devez saisir le mot de passe Awekas (de l'inscription)
    • saisissez 80 comme port
    • et définissez un intervalle raisonnable - environ 300

    Tu peux le faire directement sur la console ou en utilisant l'application WSView Plus sous "Customized".



    Bonne chance !


    Oliver

    Hi!


    Du koenntest zwar mir EAR selbst nachsehen, was Deine Konsole an Awekas schickt.

    Aber nur othi kann serverseitig pruefen, was mit den tatsaechlich eingehenden Daten geschieht und wie die Zuordnung der eingehenden zu den im Stationsweb angezeigten Daten erfolgt.

    Offenbar gibt es da ja noch ein kleines "Missverstaendnis":

    Quote

    Der "Physische Sensor1" wird im Stationsweb als "Sensor2" angezeigt

    Der "Physische Sensor2" wird im Stationsweb als "Sensor3" angezeigt

    Der "Physische Sensor3" wird im Stationsweb als "Sensor4" angezeigt

    Der "Physische Sensor4" wird nicht angezeigt

    Im Stationsweb wird unter "Sensor1" nicht angezeigt, er ist nicht da.

    Ich bin auch sehr gespannt, was dabei herauskommt,


    Oliver

    Hi!


    Dann muss othi sich das nochmal anschauen. Er kann ja nachsehen, welche Keys Deine Station an Awekas liefert.


    Das Gemeine ist, dass im WU-Protokoll der erste Sensor immer KEINE Nummer hat und nur die nachfolgenden Sensoren eine Ziffer zur Unterscheidung erhalten.

    Beispiele:


    leafwet, leafwet2, leafwet3, leafwet4

    soiltempf, soiltempf2, soiltempf3, soiltempf4


    Aber bei den Zusatzsensoren klappt das nicht, denn tempf wie auch humidity sind bereits anderweitig - mit der Aussentemperatur und der Aussenluftfeuchte - belegt.

    Somit ginge technisch/logisch entweder

    temp1f, temp2f, temp3f, temp4f

    oder

    temp2f, temp3f, temp4f, temp5f (was dem dokumentierten Standard entspricht)


    Ecowitt hat das tatsaechlich weitgehend standardkonform implementiert - die Zaehlung beginnt bei 2 und geht bis 9 (weil es eben 8 Zusatzsensoren gibt).

    Ich habe das eben mal hier lokal geprueft:

    Fuer mich sieht das seitens Ecowitt gut aus. Es koennte nun aber sein, dass der Awekas-Server - entgegen der Spezifikation - eingangsseitig temp1f und humidity1 erwartet.

    Das liesse sich aber sicherlich sehr schnell aendern.


    Oliver