[Toulon7559]

Er zijn vele wegen die vanaf een PWS naar de HWA-server kunnen leiden.

N.a.v. recente vragen van enkele gebruikers een zeer open vraag aan de forumleden:
als een PWS al zijn data naar Meteotemplate voedt (op welke manier dan ook), weet iemand hoe je dan die Meteotemplate kunt toepassen voor direct genereren en gereedzetten van een uploadfile voor HWA?

Rondkijkend op internet en op de website van Meteotemplate zie ik weinig bijdragen in de richting van 'snelle & periodieke' export vanuit Meteotemplate van data naar andere toepassingen, behalve de plugin WU_Upload die php-scripts gebruikt (onderaan in de plugin-lijst).
Er lijken 4 mogelijke manieren van aanpak zich aan te bieden.
1) Ombouwen van genoemde plugin WU_Upload
Een uitnodiging aan PHP-kundigen die ook gewenste HWA-filelayout & HWA-uploadmethode kennen.
Aangezien Meteotemplate al in webspace staat, is dit vooral verzamelen en her-ordenen van data, en compileren van de upload-file, en lijkt wegzetten van de resulterende HWA-uploadfile nog het minste probleem.
[Invoegen van benodigde historische data zoals dagwaarden en extremen is wel een aandachtspunt, want extra t.o.v. WU_Upload met alleen actuele waarden]
2) Toepassen van de RSS-Feed als databron
Bij de plugins zit een kandidaat die mogelijk ook bruikbaar is als periodieke databron

Station Feed
This plugin is an RSS feed for the station data. It allows generating information about current conditions in machine-readable formats. The possible formats are either XML or JSON, based on the parameter used in the URL.

Daaruit via een hulp-script dan extractie en vertaling naar een HWA-uploadfile.
Zo'n hulp-script zou zowel in de genoemde webspace als daarbuiten kunnen draaien.
[Invoegen van benodigde afgeleide data is ook hier weer een aandachtspunt]
3) Uitlezen van MySQL als databron
Meteotemplate gebruikt MySQL als database, dus dat zou startpunt voor volledige data-extractie kunnen zijn (als je hun database-structuur begrijpt).
Vraagt ook een hulp-script voor data-extractie en voor vertaling naar een HWA-uploadfile.
4) Export-functie
Op de website staat deze tekst

Can the tables be exported?
Yes they can. Version 3.0 Sour Cherry introduced a new feature. Most tables in the reports and other parts of the template now have a little toolbar above them. You can export the values to various formats including CSV, XLS (Excel file), TXT, DOC or even as an image (PNG) or JSON object. One thing to note – if you choose for example the XLS file, the file will be saved without an extension. All you have to do is always give the file the particular extension and then you can open it in this format. So if you are trying to export as .doc for example, just give the file a name “export.doc” etc.

Het citaat zegt nog niets over periodieke uitlezing, maar in ieder geval is er dus wel een ingebouwde functie voor data-export.
Vervolgstap op weg naar een HWA-upload is dan dat je via een hulp-script regelt dat je de uitlezing/export repeterend (bijv. iedere 10 minuten) kunt uitvoeren en daarop aansluitend de vertaling/compilatie uit zo'n format naar het andere, gewenste format voor de HWA-uploadfile.

Alle 4 mogelijkheden betekenen DHZ-inzet, maar met een bruikbaar voorbeeld vaak snel op pad .....
Vragen n.a.v. dit overzicht:
a) Kent iemand voor Meteotemplate een vergelijkbare functie als de WU_Upload, maar in andere richting (oftewel upload naar een andere organisatie)?
[Want door voorbeelden vergelijken laat zich vaak sneller een afgeleide maken]
b) Is er een gebruiker van Meteotemplate die een voorbeeld-export-file heeft (of wil maken) in TXT-format of JSON-format?
c) Of weet iemand een 5e methode die op basis van Meteotemplate snel een HWA-uploadfile ergens kan neerzetten?

05November2021:
2e en 3e Alinea toegevoegd
06November2021:
Tekst uitgebreid met gevonden info en opdeling gemaakt naar 1) t/m 4)
12+16November2021:
Vragen samengevat en ingedeeld naar a) t/m c)

[Toulon7559]

Uit contact met Jachym heel helder geworden dat Meteotemplate niet is opgezet om data naar andere toepassingen te exporteren.
Meteotemplate heeft bewust veel faciliteiten om te kunnen importeren uit allerlei databronnen, maar de plugins WU_Upload en RSSFeed voor geprogrammeerde, periodieke data-export zijn uitzonderingen voor een uitgang.
Generatie door Meteotemplate van een HWA-uploadfile is dus niet voorzien, tenzij iemand zich geroepen voelt een plugin te bouwen, in analogie met de oplossing in PWSDashboard.

Voor een praktische, snelle invulling voor een HWA-uploadfile moeten gebruikers van Meteotemplate daarom naar de databronkant kijken of daar een mogelijkheid zit om ook een HWA-uploadfile te maken: bekende opzetten zijn beschreven in 'Weeramateur/ Meedoen', aangevuld/bijgewerkt met recentere bijdragen in dit forum.
Vergeet ook PWSDashboard niet als mogelijke intermediair tussen je PWS en HWA.

[wvdkuil]

Uit contact met Jachym heel helder geworden dat Meteotemplate niet is opgezet om data naar andere toepassingen te exporteren.
. . .
Voor een praktische, snelle invulling voor een HWA-uploadfile moeten gebruikers van Meteotemplate naar de databronkant kijken of daar een mogelijkheid zit om een HWA-uploadfile te maken: bekende opzetten zijn beschreven in 'Weeramateur/ Meedoen', aangevuld/bijgewerkt met recentere bijdragen in dit forum.
. . .

Correct, in MeteoTemplate is er geen FTP-oplaad naar andere locaties ingebouwd. Maar dat is ook helemaal niet nodig.
Het is redelijk te doen om ook een conversie MeteoTemplate=>HWA formaat PHP script te maken.
Dan is het geen echt bestand wat al op de website staat, maar een PHP-script wat op aanvraag dat bestand levert. Dus de HWA server gebruikt geen geen link die eindigt op .txt maar een link die eindigt op .php
Er zijn er nu al diverse beschikbaar in de MeteoTemplate. Bijvoorbeeld voor de Mesonets (liveMesodata.php) en voor de Steelseries (ssMeteotemplate.php).

Het eerste probleem is dat de oplaad-file voor HWA niet eenduidig gedefinieerd is.
De voorbeelden voor de verschillende weer-programma's verschillen allemaal net ietsje van elkaar.

Benodigd: de kleinst mogelijke lijst met de velden die in het HWA-oplaad-bestand benodigd zijn.
Dus alleen maar alle velden die werkelijk gebruikt worden

• in de database
• voor de historie
• op de stations-pagina
• of ergens anders waar wij als deelnemer niets van weten

En in die opsomming ook een indicatie "optioneel/verplicht"
En wat we moeten doen met velden die niet beschikbaar zijn bij sommige stations, b.v. "stations-tijd"

Als we met een afgeslankte, gestandaardiseerde en eventueel al door Luc goedgekeurde versie beginnen dan moet het toch mogelijk zijn dit al lang slepende probleem van de oplaad-bestanden op te lossen.
En dan meteen voor alle weer-programma's verbeterde oplaad-bestanden en beschrijving te maken.

Als we die documentatie en voorbeeldbestanden niet zelf in het HWA-menu kunnen onderbrengen dan moet het maar tijdelijk met 1 externe link naar een andere lokatie.

Het tweede probleem: Er zijn dan natuurlijk minstens 1 of 2 MeteoTemplate gebruikers nodig om te testen.
Want als er geen vraag is van MeteoTemplate gebruikers, waarom doen we dan de moeite?

Wim

[Toulon7559]

Wim,

Helemaal mee eens.

Het is semantiek en definitie, maar je legt terecht de vinger op een 'onduidelijk, zwerend plekje'.
Hieronder een zoveelste poging om de onduidelijkheid te verminderen:
- laten we de datafile die de HWA-server nodig heeft, de 'HWA-file' noemen
- als een gegenereerde HWA-file door upload naar een url wordt klaargezet voor uitlezing daarna door de HWA-server, dan kun je dat een 'upload-file' noemen die op een 'uitlees-url' staat
- als je zo'n gegenereerde HWA-file krijgt door een php-script aan te roepen, dan zou je - voor onderscheid - dat php-script misschien beter een 'uitlees-file' kunnen noemen die op een 'uitlees-url' staat.
- In die zin voorstel om in het vervolg voor eenduidigheid de bovengenoemde definities te gebruiken
[maar ik houd me aanbevolen voor een nog betere definitie en graag bereid dan dit bericht aan te passen!]:
# HWA-file = data-file die de HWA-server wil/kan inlezen
# Upload-file = HWA-file die door upload is klaargezet voor uitlezing
# Uitlees-file = file die een HWA-file genereert bij aanroep
# Uitlees-URL = url die de HWA-server moet aanroepen om een HWA-file te krijgen

De voorbeeld-layout voor een HWA-file die compatible is met de uitlezing door de HWA-server staat onderaan deze thread: even doorscrollen naar bericht #72914 en daar vind je een Nederlandse en Engelse file met de indeling en betekenis van de velden, die is overlegd met Luc.

Zou als Moderator de Handleidingen wel willen bijwerken, maar heb onvoldoende rechten om daarvoor de website te kunnen veranderen, dus de voorzetbijdragen van mij en anderen zitten nog steeds verspreid in allerlei forumberichten: als voorzet zou ik de diverse nu losse delen kunnen samenvoegen als concept en ergens voor kommentaar in 1 forumbericht neerzetten.

Inderdaad is een 'versie' voor Meteotemplate (en andere templates & scripts) pas zinvol als we actieve aanvraag & medewerking krijgen van betreffende gebruikers, eerder niet: dus wie zoiets wil, moet zich 'helder' melden en meedoen bij de opzet, ontwikkeling en testen.
Totnutoe vonden Meteotemplate-aanvragers nog altijd een snellere&eenvoudige oplossing aan de databronkant van Meteotemplate.

MVG, Anton

16November2021:
n.a.v. vervolgbericht de tekst aangepast voor scrollen naar bericht #72914

[wvdkuil]

Eens, maar:

De link met de Cumulus => HWA 140 regels, 28 blanko = 113 data velden
Het "officiële" weatherlink bestand https://www.hetweeractueel.nl/meedoen/
=> https://www.hetweeractueel.nl/instructi ... -software/
==> Openweerdata_wl.zip
Bevat 115 velden waarvan er toch een aantal niet overeenkomen met het Cumulus bestand.
En ook kwam ik al bijna 20 velden met een verschillende schrijfwijze ten, b.v. $utcTime en $utctime

Ik had geen probleem om voor door mij ontwikkelde templates (Leuven en PWS_Dashboard) een "Uitlees-file"-script te maken. Maar als de eigenaar van HWA niet kan of wil aangeven welke data-items worden gebruikt?

Ik kan namelijk niet geloven dat de weer-programma's en weer-templates van de deelnemers
meer dan 110 data-velden moeten aanleveren
terwijl ik op de stations-pagina's nog niet de helft van die velden kan vinden.

https://www.hetweeractueel.nl/weer/herent/actueel/ => 20 velden
https://www.hetweeractueel.nl/weer/herent/historie/ => 4 velden (+ 4 uit de database)

Een paar van de nergens gebruikte velden:

Code: Selecteer alles

    [71] => $hiHeatindexTime=hiHeatindexTime;
    [72] => $hiMonthlyHeatindex=hiMonthlyHeatindex;
    [73] => $hiYearlyHeatindex=hiYearlyHeatindex;
    [74] => 
    [75] => $thw=thw;
    [76] => 
    [77] => $hiTHSWindex=hiTHSWindex;
    [78] => $hiTHSWindexTime=hiTHSWindexTime;
    [79] => $hiMonthlyTHSWindex=hiMonthlyTHSWindex;
    [80] => $hiYearlyTHSWindex=hiYearlyTHSWindex;

Dat kost heel veel werk en puzzelen om die velden in een oplaad-bestand te krijgen.
Dus wederom mijn vraag, is er ergens een lijst van de echt benodigde data-velden?
Of een stukje SQL code met de insert in de database?

Wim

P.S. Misschien kan een moderator dit topic splitsen zodat er niet meer MeteoTemplate in de topic naam staat?
Ik weet uit vragen uit het verleden dat er veel meer kundige deelnemers zijn die het oplaad-bestand probleem kunnen en willen aanpakken.

[Toulon7559]

Om duistere redenen geeft de genoemde link naar het bericht met de voorbeeldfile een verbinding naar het eerste bericht in de thread over dat onderwerp, terwijl ik de 2 uitgewerkte pdf-files bedoel die aan het bericht #72914 van die thread hangen.
[in bericht #73604 nu een aanwijzing toegevoegd om daarheen door te scrollen]
In die pdf-files zie je dat de basis-uitvoering van de gewenste HWA-file weinig verplichte, rode velden heeft, de groene optie-velden mogen worden ingevuld (als invulling zinvol aanwezig is) en de blauwe velden werden ooit in de handleiding wel genoemd, maar die mag je straffeloos leeglaten.
De HWA-server herkent & pakt alleen die velden waar hij wat mee kan doen:
als we praten over aangepaste omvang dan moet in dat opzicht worden overlegd met Luc.

===== In lijn met Wim’s PS pakt deze nieuwe thread het onderwerp HWA-file ‘gekuist’ op in een afsplitsing voor 'Opbouw & gebruik van de HWA-file' =====

27November2021:
Opmerking over veld 137 (= software-identificatie) is verwijderd, want in huidige uitvoering van HWA2.0 wordt daarmee niets meer door de software gedaan.
Nu alleen een visuele identificatie-mogelijkheid bij controle van de HWA-file.
26December2021:
Weblinks gecorrigeerd

[Luc]

Hierbij een opsomming van de velden die in HWA gebruikt worden:

Code: Selecteer alles

$stationDate
$stationTime
$tempUnit (indien niet aanwezig aanname: Celsius)
$humUnit (indien aanwezig aanname:  %)
$barUnit (indien aanwezig aanname:  hPa)
$rainUnit (indien aanwezig aanname:  mm)
$windUnit  (indien aanwezig aanname:  km/u)
$windDirection
$sunriseTime
$sunsetTime
$outsideTemp
$hiOutsideTemp
$lowOutsideTemp
$lowOutsideTempTime
$hiOutsideTempTime
$lowMonthlyOutsideTemp (wordt opgeslagen maar niet gebruikt)
$hiMonthlyOutsideTemp (wordt opgeslagen maar niet gebruikt)
$hiYearlyOutsideTemp (wordt opgeslagen maar niet gebruikt)
$lowYearlyOutsideTemp (wordt opgeslagen maar niet gebruikt)
$outsideHumidity
$lowHumidity (wordt opgeslagen maar niet gebruikt)
$hiHumidity (wordt opgeslagen maar niet gebruikt)
$lowHumTime (wordt opgeslagen maar niet gebruikt)
$hiHumTime (wordt opgeslagen maar niet gebruikt)
$hiMonthlyHumidity (wordt opgeslagen maar niet gebruikt)
$lowMonthlyHumidity (wordt opgeslagen maar niet gebruikt)
$hiYearlyHumidity (wordt opgeslagen maar niet gebruikt)
$lowYearlyHumidity (wordt opgeslagen maar niet gebruikt)
$outsideDewPt
$hiDewpoint (wordt opgeslagen maar niet gebruikt)
$lowDewpoint (wordt opgeslagen maar niet gebruikt)
$hiDewpointTime (wordt opgeslagen maar niet gebruikt)
$lowDewpointTime (wordt opgeslagen maar niet gebruikt)
$hiMonthlyDewpoint (wordt opgeslagen maar niet gebruikt)
$lowMonthlyDewpoint (wordt opgeslagen maar niet gebruikt)
$hiYearlyDewpoint (wordt opgeslagen maar niet gebruikt)
$lowYearlyDewpoint (wordt opgeslagen maar niet gebruikt)
$windSpeed
$wind10Avg
$hiWindSpeed
$hiWindSpeedTime
$hiMonthlyWindSpeed (wordt opgeslagen maar niet gebruikt)
$hiYearlyWindSpeed (wordt opgeslagen maar niet gebruikt)
$windDir (wordt opgeslagen maar niet gebruikt)
$windDirection
$windChill
$lowWindchill (wordt opgeslagen maar niet gebruikt)
$lowWindchillTime (wordt opgeslagen maar niet gebruikt)
$lowMonthlyWindchill (wordt opgeslagen maar niet gebruikt)
$lowYearlyWindchill (wordt opgeslagen maar niet gebruikt)
$outsideHeatIndex
$hiHeatindex (wordt opgeslagen maar niet gebruikt)
$hiHeatindexTime (wordt opgeslagen maar niet gebruikt)
$hiMonthlyHeatindex (wordt opgeslagen maar niet gebruikt)
$hiYearlyHeatindex (wordt opgeslagen maar niet gebruikt)
$barometer
$barTrend
$lowBarometer (wordt opgeslagen maar niet gebruikt)
$hiBarometer (wordt opgeslagen maar niet gebruikt)
$lowMonthlyBarometer (wordt opgeslagen maar niet gebruikt)
$hiMonthlyBarometer (wordt opgeslagen maar niet gebruikt)
$lowYearlyBarometer (wordt opgeslagen maar niet gebruikt)
$hiYearlyBarometer (wordt opgeslagen maar niet gebruikt)
$lowBarometerTime (wordt opgeslagen maar niet gebruikt)
$hiBarometerTime (wordt opgeslagen maar niet gebruikt)
$dailyRain 
$stormRain (wordt opgeslagen maar niet gebruikt)
$monthlyRain 
$totalRain (wordt opgeslagen maar niet gebruikt)
$rainRate (wordt opgeslagen maar niet gebruikt)
$hiRainRate (wordt opgeslagen maar niet gebruikt)
$hiRainRateTime (wordt opgeslagen maar niet gebruikt)
$hiRainRateHour (wordt opgeslagen maar niet gebruikt)
$hiMonthlyRainRate (wordt opgeslagen maar niet gebruikt)
$hiYearlyRainRate (wordt opgeslagen maar niet gebruikt)
$solarRad (optioneel)
$hiSolarRad (wordt opgeslagen maar niet gebruikt)
$hiSolarRadTime (wordt opgeslagen maar niet gebruikt)
$hiMonthlySolarRad (wordt opgeslagen maar niet gebruikt)
$hiYearlySolarRad (wordt opgeslagen maar niet gebruikt)
$uv (optioneel)
$hiUV (wordt opgeslagen maar niet gebruikt)
$hiUVTime (wordt opgeslagen maar niet gebruikt)
$hiMonthlyUV (wordt opgeslagen maar niet gebruikt)
$hiYearlyUV (wordt opgeslagen maar niet gebruikt)

Als ik dit samenvat naar de minimaal benodigde velden die op dit moment gebruikt worden, dan is dit het lijstje:

Code: Selecteer alles

$stationDate
$stationTime
$windDirection
$sunriseTime
$sunsetTime
$outsideTemp
$hiOutsideTemp
$lowOutsideTemp
$lowOutsideTempTime
$hiOutsideTempTime
$outsideHumidity
$outsideDewPt
$windSpeed
$wind10Avg
$hiWindSpeed
$hiWindSpeedTime
$windDirection
$windChill
$outsideHeatIndex
$barometer
$barTrend
$dailyRain 
$monthlyRain 
$solarRad (optioneel)
$uv (optioneel)

Gr,
Luc

[Toulon7559]

Luc's lijsten in de voorgaande 2 berichten geven kort aan wat de HWA-server doet met de data die wordt aangeleverd in de HWA-file.

In een eerder bericht is beschreven met enige uitleg hoe je daarvoor een passende HWA-file kunt maken, wat daarin 'verplicht' is, wat 'optioneel' is, wat (momenteel) weg mag, en hoe je sommige velden zou kunnen vullen.

In overleg met Luc zijn de bijlagen van dat eerdere bericht opgelijnd.

[Toulon7559]

Elders op internet zijn vast veel mooiere oplossingen te vinden (zoals Wim's voorstel om 'on-the-fly/ op-afroep' de HWA-file te maken), maar voor een HWA-koppeling aan Meteotemplate loont het misschien om dicht tegen dat software-pakket te blijven: dat bevordert de herkenbaarheid voor gebruikers en voor medewerkers bij software-opzet. Bovendien zijn die constructie al bewezen met beschikbare databanken en uitgangen.

Met die gedachte het Meteotemplate-pakket gedownload en diverse files daarvan verder bekeken op toepasbaarheid om daaruit met minimale moeite een compiler voor een HWA-file te maken:
# Plugin wuUpload lijkt een geschikte kandidaat als basismateriaal om een file-compiler te maken die daarna de HWA-file wegzet 'ergens' op de server waar het Meteotemplate draait, want die heeft al de functie van periodiek een uploadfile maken.
- Eerste aanpassing is dat geen WuID en WuPW nodig zijn, maar wel de uitlees-URL waar de HWA-file wordt klaargezet.
Dat hoeft geen gebruiker-invoer te zijn, maar kan een 'constante' tekst zijn met de gedachte dat bovenstaande 'ergens' een vast-gedefinieerde uitlees-URL is binnen de Meteotemplate-installatie.
- Tweede aanpassing is dat de HWA-file niet 1 lange textstring is zoals in de upload naar WU, maar een tekst-file met regels, dus iets andere file-formattering.
- Derde aanpassing is modificatie van de 'template' in de plugin wuUpload naar de inhoud van de korte HWA-file, met aanvulling in het script voor data ophalen en file-vulling.
# Script Stationfeed laat zien dat/hoe voor die korte versie van de HWA-file veel benodigde elementen in Meteotemplate aanwezig zijn als oproepbare waarden, of hoe ze afgeleid kunnen worden.

Deze waarnemingen verwerkt in een 'korte' veldenlijst voor de Maskerfile, bestaande uit de 21 Basis-velden en de Optie-velden.
Met wat rondkijken in andere php-files van Meteotemplate vinden we vermoedelijk de ontbrekende waarden (in de veldenlijst nu aangemerkt als gele velden), en anders even gaan vragen ....

Wie pakt de uitdaging op om een bovengeschetste plugin 'HWAFeed' uit te werken?

22Dec2021:
1e Alinea toegevoegd en verdere tekst bijgewerkt.
24Dec2021:
Korte veldenlijst toegevoegd, met bijbehorende aanpassingen van het bericht.
25Dec2021:
Aanhangsel met veldenlijst vervangen door weblink, zodat bewust de werkversie van die korte veldenlijst maar op 1 plek in het forum staat.

[Toulon7559]

In overleg met Jachym lijkt er een voor de hand liggende oplossing te zijn binnen Meteotemplate, eenvoudiger dan maken van een variant van de wuUpload-plug-in.

Het Meteotemplate-script StationFeed kan op aanroep een JSON-file maken of een XML-file.
Volgens de beschrijving lijkt dat script functioneel op het PWS_hwa.php-script van PWSDashboard:
je roept het script aan via url (met vermelding welk soort file je wenst) en als uitkomst krijg je die betreffende file.
Dus StationFeed uit te breiden met een mogelijkheid om een txt-file (of een htm-file) te genereren, die qua vorm & inhoud een HWA-file is,
of een aparte script-variant maken die bij aanroep een HWA-file maakt.

Script ssMeteotemplate.php (volgens hint van Wim_vdKuil) heeft o.a. als voordeel dat het voor veel waarden ook de tijden voor day_max. en day_min. al beschikbaar heeft. Moet alleen een ‘output-sectie’ krijgen die een HWA-file maakt.

nu 'alleen nog maar' voor beide uitvoeringen wat details invullen (zoals inkoppelen van benodigde scriptsegmenten met bijbehorende waarden) en testen of de output klopt.
Daarvoor ook zelf maar een installatie gestart voor beter begrip en voor zelf 'knutselen' & testen ......
De weblink naar het originele StationFeed-script staat voor mijn PWS onder deze weblink voor json-output (en hier voor xml-output):
dat script haalt zijn meteosensordata uit een 'algemene' txt-file binnen Meteotemplate:
in die txt-file zit niet direct alle data benodigd voor een HWA-file, dus vraag waar we de rest kunnen ophalen/afleiden.

Bij uitwerken van het script zou hulp van een kundig PHP-ontwikkelaar zeer op prijs gesteld worden, en iemand die Meteotemplate goed kent.

15Jan2022:
3e alinea + onderste 4 regels toegevoegd.