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!
QuoteKö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).
QuoteIch 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!
QuoteIst 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
Andreas,
zumindest ich sehe Deine Innentemperatur nicht!
Die Zusatzsensoren jedoch schon. Aber warum sollte man das auch verhindern wollen?
Oliver
Hi!
Werden die unterschiedlichen Sprachfassungen auch nicht nach manueller Sprachauswahl genutzt?
Oliver
Hi!
Du kannst offenbar die Benennung der Sensoren in den verschiedenen - durch die Flagge symbolisierten - Sprachen eintragen.
So verstehe ich das zumindest ohne eine Anleitung gelesen zu haben.
Oliver
Hi!
Quoteich 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:
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
Hi!
Bitte auch hier mitteilen, ich hab kein Stationsweb ...
Danke!
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 :
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":
QuoteDer "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:
ID=id
PASSWORD=key
indoortempf=66.9
tempf=33.3
dewptf=32.0
windchillf=33.3
indoorhumidity=36
humidity=95
windspeedmph=0.0
windgustmph=1.1
winddir=249
absbaromin=30.529
baromin=30.680
rainin=0.000
dailyrainin=0.000
weeklyrainin=0.000
monthlyrainin=2.681
yearlyrainin=2.681
solarradiation=0.00
UV=0
AqPM2.5=26.0
temp2f=34.5
humidity2=87
temp3f=67.1
humidity3=37
temp4f=66.9
humidity4=36
temp5f=33.4
humidity5=94
temp6f=34.0
humidity6=93
temp7f=33.4
humidity7=95
temp9f=66.0
soilmoisture=83
soilmoisture2=42
soilmoisture3=47
soilmoisture4=46
soilmoisture5=45
soilmoisture6=45
soilmoisture7=45
soilmoisture8=48
soiltempf=38.8
soiltemp2f=66.6
soiltemp3f=67.1
soiltemp4f=67.6
leafwetness=18
dateutc=2023-01-23%2018:10:10
softwaretype=EasyWeatherV1.6.5
action=updateraw
realtime=1
rtfreq=5Fuer 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