[Toulon7559]

Het is normaal dat software een bepaalde opzet van data-invoer verwacht om daarmee een gedefinieerde, bijbehorende data-uitvoer of vertoning te kunnen maken.

HWA_CustomUpload is opgezet gericht op basisvulling voor een HWA-station, dus voor temperatuur, vocht, neerslag en wind, maar de HWA-opsomming voor een station omvat o.a. ook Solarradiation en UVI, dus je mag verwerken verwachten als dat wordt aangeboden in de upload naar HWA_CustomUpload.
Bij het HWA_CustomUploadscript gevoed door software zoals StationForwarder of Meteobridge stuiten we op een verschijnsel dat in dat opzicht hoofdbrekens geeft.

Met een simpele en netjes ingevulde invoer volgens WU-protocol zoals hieronder getoond komt meestal aan de uitgang van HWA_CustomUploadscript netjes de bijbehorende verzameling meldingen tevoorschijn.

Code: Selecteer alles

https://hwaportal.nl/weatherstation/HWA12345/index.php?ID=HWA&PASSWORD=12345&dateutc=2000-01-01+10%3A32%3A35&winddir=230&windspeedmph=12&windgustmph=12&tempf=70&rainin=0&dailyrainin=0&baromin=29.1&dewptf=68.2&humidity=90&weather=&clouds=&softwaretype=Meteobridge%20versionxx&action=updateraw

Is de invoer afwijkend, óf door meer of minder velden, óf omdat de velden worden gevuld door onverwachte data, dan kan het misgaan,
oftewel de uitkomst is niet zoals verwacht, of er komt helemaal niets meer uit.
Aandachtspunten uit de huidige reeks met implementaties:
- windwaarden lijken niet altijd goed overgedragen, want resultaten in de HWA-vertoning soms afwijkend van wat lokaal bij de stationsbeheerder wordt gezien.
Vraagt onderzoek met vergelijking van binnenkomende data.
- rainin - [rain inches over the past hour)] -- the accumulated rainfall in the past 60 min
Is passende input voor rainRate in de HWA-file.
Met deze input zou je cumulerend Rain_Today kunnen maken,
maar dat vraagt veel rekenwerk en is onnauwkeurig.
In huidige uitvoering van HWA_CustomUpload is processing rainin niet werkend.
- dailyrainin - [rain inches so far today in local time]
Voorkeurinput voor Rain_Today: zie ook hierboven. Komt meestal netjes door HWA_CustomUpload.
- solarradiation wordt opgevangen en soms verwerkt/doorgegeven => twijfelachtig manco.
- UV wordt wel opgevangen, maar wordt niet verwerkt/doorgegeven => duidelijk manco.

We zien zulke verschijnsels o.a. optreden bij Meteobridge als databron gevoed door variërende PWSen,
en bij StationForwarder gevoed vanuit Weatherlink.com door variërende sensorsets.
‘Verkeerde input’ is een hoofdpijnpunt, want de databronsoftware pikt op wat de PWS aanbiedt,
en je kunt als stationsbeheerder meestal weinig bijstellen aan de PWS-output.

Kortom HWA_CustomUpload slikt niet alles, of vertaald soms naar onverwachte waarden,
maar vaak aan PWS-kant daaraan weinig aan te verhelpen.
Anderzijds misschien werk nodig aan het script voor HWA_CustomUpload voor robustere data-opvang en -verwerking, gebruikmakend van alternatieve cq parallelle inputs.

Wel relativeren, want als je naar AWEKAS, WUnderground of XWeather voedt met een datastring volgens WU-protocol, maar niet netjes gevuld,
dan krijg je ook uit die organisaties op z'n minst kommentaar ......

Aanpassing 16september2026 en 19oktober2026
Aanpassing/uitbreiding van de tekst.

[Ronnie]

Vandaag wat neerslag,
Weatherlink live geeft dit door "dailyrainin":{"in":0.008,"mm":0.2}
Helaas HWA pakt dit niet en blijft 0.0 aan geven.

Dus dailyrainin werkt niet! veranderen naar rainin doet ook niets.

10 minuut gemidelde heb ik gelukig al kunnen aanpassen in het script code.gs

[Toulon7559]

N.a.v. de vragen en reacties in diverse threads lijkt opportuun om te publiceren hoe het basis-WU-protocol er uitziet,
en welke realisatie-variant daarvan HWA_CustomUpload verwacht.
Lijkt zinvolle info voor diegenen die zelf een uploader willen bouwen volgens WU-protocol, en ook als basis voor discussie waar manco's en oplossingen zouden kunnen zitten.

In de aangehangen txt-file is dat uitgewerkt:
- basis is de tekstfile zoals overgenomen uit de aangegeven WU-wiki
- aangevuld uitleg van aspecten voor HWA_CustomUpload door invoegen van teksten tussen markeringen #######

Deze info is o.a. gecommuniceerd naar de ontwikkelaars van FOSHKPlugin, Meteobridge en WeeWX, dus hun interfacesoftware voor HWA_CustomUpload zou hiermee kunnen zijn opgelijnd.
Die ontwikkelaars weten ook dat HWA_CustomUpload een upload-output volgens Ecowitt-protocol kan oppakken:
FOSHKplugin heeft dat zelfs (vanzelfsprekend) als voorkeur.

PAS OP
Dit is dus niet hoe een willekeurige PWS een WU-type invulling realiseert voor HWA_CustomUpload via zijn interface voor een CustomServer!
Voor een PWS-invulling heb je als gebruiker voor de CustomerServer-interface (indien aanwezig!) bijna altijd alleen invloed op invulling van de header-URL, niet op de data-invulling.
Bij een softwarepakket zoals Cumulus, WeatherDisplay of WsWin heb je dat meer in de hand,
maar het vraagt inbreng van jezelf of van collega's.

Nabrander
Rondzoekend naar beschrijvingen hoe een PWS de uploadinterfaces invult deze Github-beschrijving gevonden voor Froggit, dus vermoedelijk vergelijkbaar van toepassing voor andere FOSHK/Ecowitt-gateways.
Die beschrijving geeft zowel een voorbeeld van een Ecowitt-output als voor een vergelijkbaar uitgebreide WU-output.
In die WU-output zie je ook velden met waarden die het mogelijk maken veel eenvoudiger een HWA-file verder te vullen, bijna vergelijkbaar met Ecowitt-invulling.
In die zin zinvol om in de interface naar HWA_CustomUpload al reservering te gaan maken voor uitlezing van

Code: Selecteer alles

monthlyrainin - [rain inches so far this month in local time] 
yearlyrainin - [rain inches so far this year in local time]

Gelijk temp5f reserveren voor Grastemperatuur kan ook geen kwaad.
Gezien discussie over windwaarden overwegen om optioneel ook gemiddelde windwaarden in de interface op te nemen zoals genoemd in de WU-protocolbeschrijving

Code: Selecteer alles

windspdmph_avg2m  - [mph 2 minute average wind speed mph]
winddir_avg2m - [0-360 2 minute average wind direction]

De huidige Meteobridge_firmware > v6.2 levert dat nu al probleemloos (maar aanwezigheid & vulling lijkt wel afhankelijk van de dataleverende PWS-configuratie):
wordt nagevraagd bij de Meteobridge-ontwikkelaar.
In de WU-protocolbeschrijving iets vergelijkbaars beschreven voor WindGust, maar een PWS-invulling daarvan en toepassing is nergens gezien.

Code: Selecteer alles

windgustmph_10m - [mph past 10 minutes wind gust mph ]
windgustdir_10m - [0-360 past 10 minutes wind gust direction]

[Toulon7559]

Antwoord gekregen van de Meteobridge-ontwikkelaar op de vraag waarom verschillen in output voor verschillende stations.
Behalve de sensorset van het PWS speelt een rol welk type Meteobridge wordt toegepast:
versies met ruim eigen geheugen zoals PRO(2), Nano of RPI hebben meer uitgangsinfo dan de oudere, kleinere versies.

[heersje]

Dat is belangrijke info, in Duisburg gebruik ik Meteobridge Nano SD. Men zou verwachtten dat basis gegevens identiek zijn met extra datavelden voor de krachtigere machines

[Toulon7559]

Voortgang

M.b.t. invullen in de HWA-file van rainRate is de fout gecorrigeerd m.b.t. inlezen van veld rainin volgens WU-protocol:
als in de data-aanvoer het veld rainin aanwezig is en gevuld,
dan zou met het gecorrigeerde script nu het veld rainRate gevuld moeten worden in de HWA-file.
De correctie-actie heeft vanavond wel geleid tot een paar hikken in de serverwerking,
dus mogelijk een gat in de statistieken voor betreffende stations!
De server van het HWAportal heeft trouwens weer stabiliteitskuren ......

Voor invullen in de HWA-file van monthlyRain is het nodig dat in de data-aanvoer het veld monthlyrainin aanwezig is en gevuld: o.a. Meteobridge doet dat momenteel niet.
Is dus uitzoekwerk aan de databronkant hoe je dat veld gevuld ter plaatse krijgt.

[heersje]

Ik kan het niet helemaal volgen maar moet meteobridge niet gewoon dit doorgeven: rain0total-monthsum

https://www.meteobridge.com/wiki/index.php/Templates

[Toulon7559]

Je hebt gelijk voor de benaming intern in de Meteobridge,
maar volgens WU-protocol heet op de uitgaande interface naar het HWAportal dat veld monthlyrainin.
Er moet dus in de Meteobridge nog ergens een vertaling worden gedaan,
plus invoegen van monthlyrainin in de outputstring.