Voor vragen en hulp m.b.t. de instructies om mee te doen. Hulp bij installeren van upload files
#75119
Cumulus is een ‘gemeenschapszin-software’ die verder ontwikkelt in handen van gebruikers via hun gebruikersgroep,
en eigenlijk zouden de aanhangende hulpfiles moeten mee-ontwikkelen om optimaal aangesloten te blijven.
Inderdaad staat bij de HWA-handleidingen dat de template-files (aka masker-files) niet aangepast mogen worden,
maar die tekst is vooral bedoeld om wildgroei te dempen.

Bij voldoende kennis van Cumulus staat echter niets je in de weg om een aangepaste template-file met aansturing te gaan maken:
integendeel, de toevoeging/invulling van velden voor licht en UV is zondermeer welkom, evenals invulling van velden die nu ‘leeg’ zijn.
Let bij ‘upgrade’ op dat je maatregelen neemt in de aansturing voor als een PWS sommige velden cq soms via Cumulus niet kan vullen:
dan is de ‘no_data’-invulling —- (= 3* koppelteken) van toepassing, wat aan de HWA-server doorgeeft zo’n veld over te slaan.
In de velddefinitielijsten kun je al zien welke velden door de HWA-server nu wel of niet worden bekeken en waarvoor.

De HWA-server neemt voor windpiekwaarde over wat onder veld hiwindspeed wordt overgestuurd,
dus neem het de HWA-server niet kwalijk, maar kijk of de Cumulus-invulling cf de bedoeling is, die in de velddefinitielijsten staat.

Als je Cumulus ‘experimenteel’ gaat laten uploaden, geef dan bij voorkeur vooraf een waarschuwing, zodat we kunnen meekijken hoe het overkomt.

Met inachtnemen van voldoende voorzichtigheid is in de bovengeschetste context uiteraard ook geen bezwaar dat de template-files/maskerfiles van andere software-pakketten worden verbeterd door ter zake kundige forumleden!!!!!
#75146
De experimentele HWA-file voor Cumulus staat nu ruim een week online, en de juiste data wordt consequent op de website getoond.

De volgende webtags zijn aangepast voor de windvlaag:

$hiWindSpeed = "<#wgustTM>";
$hiWindSpeedTime = "<#TwgustTM>";

Alleen als je weerstation een zonne-energiesensor (meting in W/m2) en een uv-sensor heeft kun je ook de volgende tags aanpassen:

$solarRad = "<#SolarRad>";
$hiSolarRad = "<#solarTH>";
$hiUV = "<#UVTH>";
$hiUVTime = "<#TUVTH>";
#75590
Als je een 'ongelukje' met je meteo-software kunt corrigeren door herstart van die software, destebeter, natuurlijk incl. generatie van een HWA-file.
Echter de laatste tijd een paar keer gezien dat sommige software herstart met als default de amerikaanse datum-notatie in layout mm/dd/yyyy of mm-dd-yyyy
De HWA-server kijkt echter in de HWA-file uit naar een Europese datum-notatie in layout dd-mm-yy of dd-mm-yyyy
Door combinatie van herstart met die Amerikaanse datum-notatie en de HWA-zoekverwachting krijg je dan dus soms de situatie dat er een HWA-file is, die correct lijkt,
maar die niet wordt geaccepteerd door de HWA-server, als hij bijv. een mm ziet >12,
of met totaal verkeerde datum, omdat in de praktijk dd en mm van plaats zijn gewisseld.
Overkomt je dat, denk dan even aan dit aspect en controleer daarop je software ....

Ook de variant dd/mm/yyyy liefst vermijden, want acceptatie daarvan door de HWA-server is niet stabiel.
#75593
mm/dd/yyyy juist ongewenst, want dat is Amerikaanse datum-notatie,
maar de HWA-server vindt ook / in een (Europese) datumstring dd/mm/yyyy niet altijd lekker
(proefondervindelijk ondervonden i.v.m. een fout in de Meteotemplate-addon ssHWAFeed)
#75925
Bij diverse organisaties kun je tegenwoordig meer dan de ‘standaard’-meteowaarden uploaden.
Bijv. T&H op +10cm voor ‘klomphoogte’-waarden.
Hoewel niet altijd duidelijk is wat met de extra inputs wordt gedaan.

Kleine moeite om benodigde velden toe te voegen in de definitie van de HWA-file, maar natuurlijk wel een redelijke hoeveelheid werk om dat voor data-verzending te verwerken in de diverse templates, en dan (voor Luc) na data-ontvangst in een implementatie in database en in vertoning van de HWA-server.
Bij dat laatste lijkt het minimum per station te bestaan uit
- vermelding in de webpagina ActueelWeer
- (bij voldoende aanleverende stations) mogelijk in de statistieken,
- met vervolg in een extra temperatuurgrafiek, en
- ultiem met extra, globale temperatuurisopleetkaart(en).

Zou zoiets interessant zijn voor de HWA-stationsbeheerders die nu data aanleveren?
#76043
Getriggerd door dit 'Even voorstellen'- bericht, gekeken wat in de HWA-file voor data-overdracht voor temperatuur+10cm toegevoegd zou moeten worden.

OutsideTemp wordt nu op de volgende regels van de voorbeeld-HWA-file-definitie bij de HWA-server naar binnen gesluisd.

$outsideTemp = "1,2";
$hiOutsideTemp = "3,3";
$lowOutsideTemp = "0,6";
$lowOutsideTempTime = "00:00";
$hiOutsideTempTime = "13:54";

Noem het beestje helder bij de naam:
GrassTemp = temperatuur op +10cm t.o.v. maaiveld aka 'klomphoogte'.
Voor invoer van de basiswaarde voldoet 1 hoofdregel, maar op basis van analogie zou je kunnen denken aan volgende 5 extra regels in de HWA-file

$GrassTemp = "1,2";
$hiGrassTemp = "3,3";
$lowGrassTemp = "0,6";
$lowGrassTempTime = "00:00";
$hiGrassTempTime = "13:54";

Inbouwen in de software die de HWA-file genereert door een koppeling met een aantal waarden uit het software-pakket naar de generator van de HWA-file.
Vermoedelijk voor die software vergelijkbaar met de functie voor opsturen van grastemperatuur naar o.a. MetOffice_WOW, WUnderground en/of VWK_Sylphide.

Opmerking:
De betreffende sensor op +10cm zal bijna altijd een combinatie van T&H leveren.
Technisch heeft data-overdracht naar HWA voor ook GrassHumidity niet meer om het lijf dan nog 1 of 5 vergelijkbare regels erbij.
Zou me kunnen voorstellen dat je in de graslaag bijv. 's morgens vroeg soms heel veel dauw ziet,
en in een zomermiddag juist heel weinig vocht, sterk afwijkend van de waarde op +1,5m.
Tot mijn verwondering zie ik bijv. bij MetOffice_WOW wel een 1regel-invoer/upload, maar nergens een toepassing van de Vochtwaarde op +10cm.
Wat is de reden van weglaten van GrassHumidity?