[Toulon7559]

Vanuit een databron invullen van de HWA-file e.d. is iedere keer weer een uitdaging om de geschikte koppelingen te maken,
en om te identificeren waar & welk aanvullend rekenwerk vereist is of een default-invulling.
Bij de vraag naar een PHP-script voor uitlezing en -compilatie vanuit BMCB, KNMI en RMI komt als eerste de vraag hoe de beschikbare databronnen te koppelen naar de velden in de HWA-file.
Bijgaand een xls-tabel (in pdf-afdruk) die een mogelijke mapping aangeeft:
let op de benodigde 'vertalingen', want de datetime-layout van de bronnen is vaak niet CET/Europees,
en BMCB werkt bijv. met Kelvin-temperaturen.
Evenals in voorgaande berichten zijn de Basis-velden rood-gemarkeerd, de Optie-velden groen-gemarkeerd, en de 'resterende' velden in blauw.
Bij de script-opzet voor uitlezing ook rekening houden met de timing, want zowel BMCB, KNMI en RMI verversen hun data iedere 10 minuten, en best pas uitlezen & verwerken met een vertraging t.o.v. van dat interval, dus bijv. uitlezen pas op xx:15, xx:25, e.v.
.
Vooruitzien
KNMI heeft in de JSONfile Groundtemperature, en bij BMCB en RMI zit in de JSON-file een veld voor Grass_temp_min:
hoewel misschien toekomstig interessant voor oplijning van HWA daarmee (en misschien met VWK_Sylphide?)
hoogstens als growth potential in te bouwen in een decoderingsscript, want nu bijna overal 'null' als databroninvulling.
Waarom mist trouwens voor een actueel klomphoogte-beeld in die JSON-files van BMCB en RMI de waarde voor Grass-temp?
En waarom nergens een waarde voor Grass-hum?
De meeste klomphoogte-sensoren hebben die actuele data waarschijnlijk al zonder moeite beschikbaar,
tenzij het een thermometer is zoals MetOfficeUK beschrijft voor temperatuurmeting boven gras of beton.

Bij sommige organisaties en in een aantal softwarepakketten zie je ook melding van TempFeel oftewel gevoelstemperatuur.
Interessant, want zo komt het over, maar om werk te vermijden voor Luc en voor al die mensen die een compiler/vertaler onderhouden voor de HWA-interface,
is het niet handig om de benodigde dataset alsnog in de HWA-file toe te voegen.
TempFeel kan lokaal aan de HWA-kant worden berekend met data al beschikbaar in HWA's database voor Temp, RH en Vwind (bijv. met de formula van Australie's BOM).
Hetzelfde geldt voor zoiets als ET als tegenhanger van Neerslag (en dan m.b.v. van het PenmanMonteith-algorithme volgens rapport FAO56) met dezelfde inputs als TempFeel i.c.m. SolarRadiation, aldanniet met aannames voor missende data zoals aangegeven in het FAO-document.
Hoewel voor ET de Temp&RH bij voorkeur voor klomphoogte zou moeten zijn:
dus voor nette implementatie eigenlijk een uitbreiding van de HWA-file nodig.
Ook nog een 'kleinigheidje' regelen dat de ET/station per uur en per dag moet worden opgeteld&bigehouden om te kunnen vergelijken met neerslag/uur resp. neerslag/dag.
.

Domoticz_Cumulus_Interface2.pdf

HWA_file vs databronnen
(147.46 KiB) 21 keer gedownload

[Toulon7559]

Omdat vaak de vraag opkomt welke velden in de HWA-file echt nodig zijn,
even teruggrijpen naar een ouder bericht van Luc over dat onderwerp in een andere thread.
Luc's opsomming is dus een lijst voor een volledige PWS-configuratie, zoals minimaal gewenst als 'basis'-HWA-file.
Is met die opzet toch een sensor niet aanwezig of niet actief, dan moet betreffend dataveld worden ingevuld met "---", waarmee de HWA-server onverbloemd weet dat betreffend veld geen geldige data heeft.
De oude thread waarin dit bericht staat is een discussie wat wel en niet nodig is,
en wat 'misschien zinvol' is voor de toekomst ........