Danke Oliver für die Info und den Tipp. Die Idee ist mir zu kompliziert und werde wohl so damit Leben müssen in der Hoffnung, dass sich in dieser Richtung etwas bewegt. LG Olaf
Zusatzsensoren dnt Weather Screen Pro Wetterstation
-
Olliander -
October 28, 2022 at 7:26 PM -
Thread is Resolved
-
-
Hi Olaf,
ich habe bei Ecowitt explizit nachgefragt und melde mich, wenn es Neuigkeiten dazu gibt.
Zur Ecowitt-Kompatibilität von Awekas wird bestimmt othi etwas sagen können.
Oliver
-
ich habe bei Ecowitt explizit nachgefragt und melde mich, wenn es Neuigkeiten dazu gibt.
Zur Ecowitt-Kompatibilität von Awekas wird bestimmt othi etwas sagen können.
...ah, ok. Danke!
-
- Official Post
Zur Ecowitt-Kompatibilität von Awekas wird bestimmt othi etwas sagen können.
Wir haben schon 2 mal bei Ecowitt zwecks Kooperation angefragt. Leider wurde es jedes Mal abgelehnt. Vielleicht nutzt es wenn Ihr User da anfragt...
-
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
-
- Official Post
Kooperation klingt irgendwie etwas groß.
Wir würden ja nur technisch versierte Ansprechpartner brauchen und nicht den Support für die Jungs machen wollen.
QuoteOur device supports uploading to your server:
At custom mode, we have WU protocol for uploading. What they need to do: fill up your server URL, id and password.
Dann sollen Sie sich auch rumplagen wenn deren Stationen die Werte nicht übertragen. Wir unterstützen das WU Protokoll. Wnn die es nicht sauber bedienen - deren Schuld. Wenn von dort kein Entgegenkommen kommt, kommt auch von uns keins.
-
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 - v2Weather Company Data | PWS Observations - Current Conditions - v2 Domain Portfolio: Observations | Domain: Current Conditions | API Name: PWS Observations…docs.google.comGruss, Oliver
-
- Official Post
Hallo Oliver
Danke der Nachfrage bei Ecowitt. Ich kann deren Aussage aber nicht bestätigen. Du selber hast das offizielle Dokument der WU Spezifikation im vorangegangenen Dokument angefügt. Dort gibt es sehrwohl die besagten Sensoren. Auch ich hab es in einem vorangegangenen Posting angemerkt.
Code
Display Moretempf - [F outdoor temperature] * for extra outdoor sensors use temp2f, temp3f, and so on rainin - [rain inches over the past hour)] -- the accumulated rainfall in the past 60 min dailyrainin - [rain inches so far today in local time] baromin - [barometric pressure inches] weather - [text] -- metar style (+RA) clouds - [text] -- SKC, FEW, SCT, BKN, OVC soiltempf - [F soil temperature] * for sensors 2,3,4 use soiltemp2f, soiltemp3f, and soiltemp4f soilmoisture - [%] * for sensors 2,3,4 use soilmoisture2, soilmoisture3, and soilmoisture4 leafwetness - [%]
Auch andere Stationen senden im WU Protokoll. Bei denen geht das ja auch. Aus meiner Sicht will Ecowitt nur den schwarzen Peter einer Firmwareaktualisierung an die Dienstanbieter abwälzen und eine Implementierung IHRES Standards zwingen.
Ich habe wirklich nichts gegen eine Implementierung des Ecowitt Standards. Aber wenn jeder Hersteller meint sein Protokoll ist das richtige, dann kommt jeder daher und will sein Protokoll.AWEKAS ist in Europa das größte Wettermessnetz mit über 15000 aktiven Stationen. Da sollten wir schon etwas Gehör bekommen. Wer sich selber aber nicht an die Spezifikationen anderer hält, braucht nicht erwarten das wir sein Protokoll implementieren.
-
Othmar,
nur um Missverstaendnisse auszuschliessen:
QuoteDort 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
-
- Official Post
Wir driften da etwas vom Thema ab. Es ging nicht ob WU oder wir 20 Temperatursensoren oder Lärmdaten verwalten können oder nicht. Es geht nur darum das Ecowitt 4 Temperatursensoren überträgt oder nicht. Die Angabe "tempf - [F outdoor temperature] * for extra outdoor sensors use temp2f, temp3f, and so on" impliziert die Sensoren tempf1 bis tempf4 das sind genau die 4 Sensoren die hier benötigt werden. Ich verstehe nicht warum Ecowitt da sagt das es keine Spezifizierung gibt und darum die Sensoren nicht übertragen werden.
Wir können auch keine 20 Temperatursensoren verwalten und werden dies auch mangels Anforderung kurzfristig auch nicht ändern.
0,6% der Stationen haben 4 Temperatursensoren in Verwendung. Da kann man ja nicht gerade von Marktdurchdringung reden.
-
Sorry, für mich ist nicht alles verständlich, aber egal. Trotzdem Danke für eure Mühen!
Fakt ist das ich trotz der fehlenden Funktion eure AwekaApp die beste für mich ist. In der Hoffnung, dass sich da mal etwas ändert muss ich eben die Werte der Zusatzsensoren bei ecowitt holen.
LG Olaf
-
Moin,
Ecowitt hat reagiert und bei den ersten Stationen werden nun auch weitere Sensoren per custom server (etwa an Awekas) uebertragen:
Code
Display MoreID=myID PASSWORD=myKey tempf=42.44 humidity=99 dewptf=42.26 windchillf=42.44 winddir=209 windspeedmph=0.67 windgustmph=3.36 rainin=0.000 dailyrainin=0.000 weeklyrainin=0.000 monthlyrainin=0.157 yearlyrainin=19.193 solarradiation=16.39 UV=0 indoortempf=65.84 indoorhumidity=47 baromin=29.716 temp2f=43.52 humidity2=88 temp3f=68.72 humidity3=44 temp4f=64.04 humidity4=49 temp5f=42.62 humidity5=98 temp6f=42.98 humidity6=97 temp7f=42.44 humidity7=99 temp9f=65.12 soiltempf=48.74 soiltemp2f=64.22 soiltemp3f=65.12 soiltemp4f=65.66 leafwetness=99 AqPM2.5=5.0 soilmoisture=86 soilmoisture2=41 soilmoisture3=28 soilmoisture4=31 soilmoisture5=28 soilmoisture6=32 soilmoisture7=71 soilmoisture8=30 lowbatt=0 dateutc=now softwaretype=GW1100A_V2.2.0 action=updateraw realtime=1 rtfreq=5
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
-
Super Olicat!
-