[wvdkuil]

. . .
Of zit er niets anders op dan te wachten tot het CL-systeem ingrijpt op de calibratie?

Hoe is trouwens de gebruikers-ervaring met het CL-systeem bij Weatherflow?

zie ook https://community.weatherflow.com/t/cl- ... ained/2496
Het duurt even (volgens sommige berichten een paar dagen) voordat de WeatherFlow/Tempest de juiste kalibratie heeft op de centrale server.

Ik weet dat de aangepaste waardes worden gebruikt bij het terug geven van de data via http en voor het afbeelden op de WF-kaart/website.

Geen idee of het station zelf ook de calibratie terug gemeld krijgt.
De neerslag wordt ook "bijgewerkt" op de WeatherFlow-website maar blijkbaar niet terug gegeven aan het station. Tenminste dat lijkt de conclusie te zijn in de discussies op het WF-forum

Wim

P.S. Het json voorbeeld in deze post Toulon7559 @ Tempest Weerstation is niet voor een tempest maar voor een AIr. Dat is een deel van het vorige WeatherFlow station. Een Tempest is "alles in 1" . De data die vroeger door de "air" en "sky" apart doorgegeven werd komt nu van 1 onderdeel.

[Toulon7559]

Wim,

Dank voor je ervarings-info, en je aanwijzing wat wel/niet toepasselijk is voor Tempest.

Beroepsmatig niet onbekend met auto-calibratie van systeemketens.
Een Auto-calibratie-functie is mooi & makkelijk, maar kost (zoals ook in dit voorbeeld) tijd voor het inloopproces:
kwaliteit vraagt tijd. Je kunt dat beter maar weten bij het opstarten van het systeem ......
Dat inlopen is strijdig met het gebruikelijke verlangen snel resultaat te krijgen.
In mijn vakgebied hadden we dan ook het begrip 'Automatik, mit Bedienerübergriff', tweeledig:
- handmatig het systeem op pad helpen en het laatste stukje verfijning zelf laten doen,
- laten lopen en handmatig bijsturen als het systeem de verkeerde kant op dreigt te gaan.
Je hoeft handingreep niet te gebruiken, maar je bent zo sneller bij je doel.
Zoiets had ik voor Tempest ook gehoopt .........
Bij een PWS is voor luchtdruk, temperatuur, vocht en neerslag vaak een bruikbare referentie in de buurt.
Voor andere waarden kun je waarschijnlijk maar beter het systeem de boel laten uitzoeken, en is hun methode OK cq 'minst slecht'.

Je vermoeden dat er geen correctie-tellbacks zijn naar het station betekent dat de data in de UDP-messages per definitie mogelijk niet correct is.
Echter, op zich is hun opzet niet vreemd of ongebruikelijk (= dat ze niet terugkoppelen naar de bron/sensor):
- we zijn toch van de 'voorgaande/oudere' weerstations niet anders gewend?
- daarmee voorkom je een 'lange' regellus die stabiel gemaakt/gehouden moet worden met een bepaalde kwaliteit
- gebruik zelf ook die opzet om de uitkomsten voor meerdere sensoren in mijn configuratie parallel op te lijnen [zie dit stukje van mijn website, met deze achtergrond]

Bijna alle oudere weerstations van welk merk & type dan ook leveren vanuit de sensoren ruwe data af, die daarna in Consoles of software worden rechtgetrokken met calibratie-gegevens om bij de 'echte' waarden te komen.

Hun statistiek voor Tempest zal beter zijn dan de mijne (i.v.m. kennis van hun sensoren), en nacorrectie op hun resultaten is dubbelop (met alle risico's vandien).
Een eigen correctiefunctie maken voor 'bijtrekken' van de UDP-datainhoud wordt ander, dubbel/parallel werk, maar niet ongebruikelijk met de voorgaande alinea in gedachten.

Dus beter/makkelijker even aankijken wat gebeurt (met argusogen),
voordat ik kies welk correctiemechanisme ik inzet (en waar) ........

[Toulon7559]

Check, recheck .....

Voor Weatherflows' meting van Licht & UV geldt deze info uit hun forum.
Heeft iemand ergens een beschrijving gezien of & hoe dit geldt voor Tempest?

[Toulon7559]

Via de 'lange route' over de Weatherflow server en over WUndergrond kun je Domoticz voorzien van een basis-set voor meteowaarden: eenvoudige & snelle invulling.
Klein nadeel is de externe afhankelijkheid van minstens 2 servers in serie.

In een 'draadje' van het Domoticz-Forum ook een voorbeeld Python-script gezet waarmee je voor je Tempest-station de JSON-file kunt opvragen van de Weatherflow-server en kunt vertalen naar info voor Domoticz o.i.d..
Als feasability-demo is dit naast de extractie uit WUnderground een voorbeeldscript voor ophalen van een klein aantal waarden.
Voor extractie van alle 29 waarden uit de JSON-file moet voor Domoticz het script verbeterd worden naar een recursieve opzet voor waarde-extractie, eventueel gevolgd door compilatie voor bijbehorende Virtual Devices in Domoticz.

[Toulon7559]

Meten = Weten

We kunnen wel wat aannemen over de auto-calibratie van Weatherflow, maar bewijs is beter.
JSON-uitlezing en WU-uitlezing naar Domoticz heb ik al gemaakt.
UDP-uitlezing hebben ze al geregeld in de zeer actieve Weewx-community:
https://www.domoticz.com/forum/viewtopi ... 14#p263014 vat dit samen.
'Koppelstukje' naar Domoticz bouwen en daarna een lopende vergelijking opzetten tussen de uitkomsten van die 2 uitlezingen voor de kernwaarden voor meteo:
dan meten we wat Weatherflow uitvoert op de sensorwaarden.

Tenzij ik iets mis, is eigenlijk bij de Weatherflow-opzet het enige 'hinderlijke' aspect, dat er nergens vooraan in de flow van Weatherflow een ingreepmogelijkheid is voor een Gebruikers-correctie:
pas op het eind van die flow kun je als Gebruiker in eigen regie iets toevoegen, maar zonder te weten wat de auto-calibratie doet, is dat een onzeker verhaal.
2 Keer achter elkaar corrigeren is meestal geen goed idee, zeker als de eerste correctie onbekend & dynamisch is en de tweede correctie statisch.

Nu eerst meten ........

[Toulon7559]

Meerdere PWSen om het huis en in de tuin geeft vergelijkingsmateriaal.
Omdat ik toch al online vergelijkingen heb lopen voor licht, UV en Wind, die uitgebreid met de Tempest-uitlezing:
de Tempest-waarden zijn uit WUnderground en uit de Weatherflowserver.
Voorzichtige conclusie:
de visuele displays (= Consoles en Weatherflow-website) mogen vergelijkbare getallen vertonen, maar de data-interfaces vertellen via de vergelijkingsgrafieken een ander verhaal, vooral voor wind.
De vraag is dan: wat is de reden/achtergrond (behalve verschil in schaalwaarden)?
Het belang van praktische kennis van de systeemketen en van calibratie is mij weer overduidelijk geworden.
Zal uit nieuwsgierigheid de set met neerslagmeters en barometers ook maar eens in het vergelijk gaan brengen:
meten = weten

[Toulon7559]

Een nieuw systeem moet zich bewijzen.

Hoe zijn bij Tempest-gebruikers in het HWA-Forum nu de ervaringen?

Bij mij lijkt de data-vergelijking genoemd in mijn vorige bericht zinvol te worden om 2 redenen:
- Mijn Tempest loopt nu sinds eind november, maar de gerapporteerde luchtdruk is nog niet zichtbaar geautocalibreerd, want er zit nog steeds een verschil van +3 hPa t.o.v. KNMI [= AWS Twente op ca. 5km afstand]
[=> Weatherflow/WUnderground daardoor dus systematisch fout, maar voor AWEKAS gelukkig Domoticz ertussen voordat ik de luchtdrukwaarde (met handmatige, statische bijstelling) upload naar AWEKAS]
- Bij mijn speurtocht naar een goede UDP-sniffer (om het dataverkeer vanuit de sensor naar de Weatherflow-server te kunnen meelezen) kwam ik het onderstaande commentaar tegen van een weewx-gebruiker die - al geruime tijd geleden - een UDP-sniffer heeft gebouwd voor alle Weatherflow-configuraties, incl. upload-optie naar MQTT en naar Influxdb [zie https://github.com/vinceskahan/weatherflow-udp-listener voor meer informatie]

De laatste opmerking van zijn commentaar stelt me gerust, en de opmerking over lightning strikes maakt me ook niet van streek, maar de opmerking over neerslag geeft wel te denken, en maakt voor mij nu ook Tjeerd's opmerking begrijpelijk.
Op internet wordt van alles beweerd, dus niet alles geloven, maar eerst controleren:
heeft iemand een recente, onafhankelijke melding elders gezien m.b.t. die opmerking over Weatherflow-neerslagverwerking, of een andere bewering daarover?

### IMPORTANT NOTE ABOUT WEATHERFLOW UDP BROADCAST DATA
It is important to understand your reasonable expectations regarding this
software working via listening to the local UDP broadcasts of observations and
events emitted by the Hub. The following are limitations of the WeatherFlow
gear itself and how it is implemented by the vendor.
* you can not expect 'rain' readings to be accurate. WeatherFlow adjusts the
accumulated rain for a calendar day via their proprietary RainCheck algorithms,
which run in a batch job on the morning of the 'next' calendar day based on
midnight at your location. While you can trust that the rain start 'event'
you see is truth as your station's sensors saw when rain started, you can 'not'
reasonably trust rain accumulation or rain rate based on the UDP broadcasts by
your Hub.
* you can not expect 'lightning' to be accurate. WeatherFlow essentially
crowd-sources and calculates an aggregated lightning reading for your station as
you would see it their web page or mobile app. While the UDP lightning data
from your station 'is' used by the WeatherFlow servers as part of this
aggregation on their end, you are not the 'sole' source of lightning data
reported for your station (as viewed on their web or mobile app).
* all other data reported from the UDP broadcasts on your LAN 'can' be assumed
to match up with what you would see if you used the WeatherFlow web page, mobile
app, REST, or Websockets APIs which all connect to WeatherFlow servers on
Internet.
---

[Toulon7559]

De afgelopen 2 dagen met overvloedige neerslag geeft voldoende data voor vergelijking van mijn regenmeters Nexus, WS7000 en Tempest.
Met het voorgaande bericht in gedachten geeft de onderstaande grafiek dan aanleiding tot overpeinzing.

Vergelijk_ 3Regenmeters_20201224
piVergelijk1Rain [640x480].png (137.96 KiB) 8738 keer bekeken

De 'echte' regenmeter (=glasbeker), Nexus en WS7000 zijn het eens over de totale hoeveelheid neerslag_today, de lasthour-lijnen verlopen volgens vergelijkbaar patroon, maar Tempest ziet wel erg veel meer mm, zowel over de dag als over het laatste uur.

De grafieklijn voor WS7000_today toont trouwens in dit snapshot 2 merkwaardige dips op ca. 02:00uur en 05:00uur:
'Terugzakken' in een neerslag-daggrafiek is nooit in orde.
Op die tijdstippen in de lasthour-grafieken en in de WsWin-grafieken voor WS7000 en Nexus de tekenen voor een hevige stortbui met rust daarna.
Zonder die dips zou de WS7000_today-lijn min of meer kunnen gelijklopen met de Nexus_today-lijn.
Effect niet in de WsWin-grafieken voor Nexus en WS7000, en niet voor de keten Nexus>RFLink>Domoticz, dus lijkt dit een 'uniek probleem' van de keten WS7000>RFLink>Domoticz.
Aangezien de WS7000-grafiek gemaakt in WsWin via de PC-interface geen probleem heeft, zijn [?] de linkberichten vanuit de WS7000-regenmeter in orde.
Heeft de RFLink-uitlezing van de WS7000-regenmeter misschien een probleem als te grote tellerstappen worden aangeboden?

Ontdekkingen als gevolg van bijzondere omstandigheden zijn interessant, maar had in dit geval toch liever gelijklopende lijnen gezien ......
Het onderschrijft weer de stelling dat het nagenoeg onmogelijk is om een configuratie vooraf & op alle aspecten te testen:
er blijft altijd wel iets buiten beeld dat pas later in de praktijk onvoorzien tevoorschijn komt.

[Toulon7559]

Vanochtend en vanmiddag ging het ook weer tekeer, zodat meer neerslagmeetwaarden ter beschikking komen.
.

Vergelijk_3regenmeters_20201227
piVergelijk2Rain [640x480].png (123.32 KiB) 8739 keer bekeken

.
[De 'breuk' in de lijnen voor WS7000 en Nexus is vanwege een experiment met de betreffende Domoticz-processor: vulling van een regendag ......]
.
In dit plaatje opvallend (behalve weer de hoge tellerstanden van Tempest), dat in Domoticz de dagteller voor WS7000 weer negatief uitslaat, en tegelijk de lasthour-waarde voor Nexus: dat riekt bijna naar een gemeenschapppelijke fout in de RFLink-uitlezing.
Op de PWS-Consoles, in WsWin en in de Domoticz-grafieken zie je zulke effecten niet.
Puzzels, vermoedelijk m.b.t. verschillen in uitleesintervallen, filters e.d., maar hoe kom je als 'buitenstaander' daarachter?

Weatherflow biedt aan om Tempest te helpen calibreren tegen dichtbij beschikbare referentie-neerslagmeters [ zie https://help.weatherflow.com/hc/en-us/a ... 0046411573 ], maar dan moeten die referenties natuurlijk zelf wel betrouwbaar zijn.

[Toulon7559]

Omdat de luchtdrukrapportage voor mijn Tempest onveranderd zichtbaar te hoog blijft t.o.v. de Info van KNMI AWS Twente, ook gekeken naar de andere Weatherflow-stations in Twente.
Die Weatherflow-stations hebben structureel ook vergelijkbaar te hoge luchtdrukwaarden.
Als ik (voor deze verzameling stations) kijk naar de stations-druk en de msl-druk van die stations, dan lijkt daar ook iets mis in de verrekening:
vraag me af hoe Weatherflow omgaat met de hoogte-informaties uit de kaart (bodem t.o.v. msl) en uit de gebruikersopgave (sensor t.o.v. bodem) en of/hoe dat doorwerkt in de auto-calibratie.
.
Hoe zijn in dit opzicht de luchtdrukwaarden elders bij Weatherflow PWSen?