Het weer, actueel weer van alle weerstations

Stilstand is achteruitgang .........

De 'standaard'-aanpak van de HWA-server voor dataverkeer heeft bepaalde 'oude&beproefde' voordelen,
omdat databron en dataverwerker ieder in eigen tempo in eigen domein kunnen werken.

De wereld beweegt echter ook in andere richtingen,
en meeliften op een rijdende trein kan dan efficiënt zijn en makkelijker tegemoetkomen aan gebruikersinzet.

Voor WUnderground-dataflow is er wel de weg via 'vragende' aanroep aan de WU-API,
maar 'push' data-upload volgens WU-protocol is de meest gebruikte directe weg tussen databron en dataverwerker, zoals je ziet bij een heleboel PWSen en portals.
Voor de HWA-server vraagt dat een extra, WU-achtige 'push'-ingang op internet.
Luc is huiverig daarvoor (niet alleen m.b.t. de hoeveelheid werk).
Alternatief is dat een hulpserver zo'n WU-achtige ingang voorziet en de binnengekomen berichten vertaalt als frontend voor de HWA-server die dan niet beter weet dan dat er een aantal extra stations 'normaal' binnenkomt vanuit webruimte.
Kunnen we na het experiment misschien Luc overtuigen dat de hele zwik snel & veilig in de HWA-server kan worden geschoven.

Om het experiment aan te gaan, een PHP-script gezocht dat voor dat werk op een internet-server kan draaien.
Functioneel zoiets als hier beschreven.
Gevraagde functies van het PHP-script:
1. (veilig) opvangen van een WU-layout message, bijv. uit de 3e uitgang van een Bresser_PWS
- de PWS-eigenaar krijgt daarvoor vanuit HWA voor zijn stationsinterface vooraf aangereikt een specifiek ID & PassWord ingebouwd in een voorbewerkte url-string voor richten van de datamessage naar de hulpserver
2. checken & vertalen van de inkomende datamessage naar een JSON-file specifiek voor dat ID&PW
3. opslaan van die JSON-file in een folder, apart dus voor iedere combinatie van ID&PW
Dan kan voor het experiment de JSON-file daarna door een andere processor worden opgehaald en worden vertaald naar een HWA-file e.d.
Alleen laatste versie van die JSON-file.
optioneel
4. vertalen van de bovengenoemde JSON-file naar een HWA-file met een bijbehorende kenmerkende filenaam
5. opslaan van die HWA-file in een folder, apart dus per binnenkomend station.
Alleen laatste versie van die HWA-file.

Het aangehaalde PHP-script realiseert in essentie de bovengenoemde punten 1. t/m 3. , maar m.i. is dat voor LAN-bedrijf met een vast IP-adres, dus vraag:
- hoe maak ik dit script werkend voor bedrijf op internet, bijv. geplaatst op een server van Strato?
[want o.a. adressering en file-locaties lijken daarvoor een kritisch, praktisch puntje]
- zijn er alternatieve softwarepakketten die deze invulling al beter beantwoorden?
- aanwijzingen hoe e.e.a. netjes werkend te krijgen is op een Strato-server?

Gezien de wereldwijde toepassing van WU-protocol kan ik me niet voorstel dat genoemd PHP-script het enige is, maar totnutoe nog niet iets gevonden dat eenvoudig & robuust de functievraag invult, dus hints welkom.

Uiteraard aan databron-kant eerst eenvoudigst beginnen, met als quasi-PWS 1 zelfgebouwd WU-achtige databronscript op een Raspberry (= clone van een echte upload vanuit Domoticz),
voordat we het loslaten op de echte Bresser-PWSen e.d. van deze wereld.

Wellicht zie ik iets over het hoofd, daarom deze post.

Het WU-protocol kent maar een beperkt aantal (< 30) "velden"
In ieder geval zijn er geen hoog-laag waarden en tijdstippen.

De bestanden die Leuven-Template en PWS_Dashboard voor HWA moeten leveren bevatten ongeveer 50 velden.
Volgens mij is het upload protocol zoals WU gebruikt niet geschikt om op te laden naar HWA.

Of begrijp ik je post verkeerd?

M.v.g.
Wim

Dit is een screenshot van de code die gebruikt wordt om met het WU-protocol op te laden naar WU/PWS/WOW/AWEKAS
Als je dus zo'n bericht opvangt van een weer-station apparaat zoals Bresser of Ecowitt, zijn er geen andere velden.

Wim,

In dat zicht voor HWA dus heel blij met de software die een ‘lange’ HWA-file incl. afgeleiden kan afleveren.
Zou wensen dat iedere stationbeheerder met zulke software zou werken,
maar als veel gebruikers dat niet hebben cq niet kunnen of willen gebruiken, dan moet je kijken wat wel kan,
en dan zijn WU-protocol en Ecowitt-protocol defacto populair geworden, waarvan WU-protocol dan het eenvoudigst lijkt.

Helemaal gelijk dat het WU-protocol zich eigenlijk beperkt tot actuele waarden.
Ook o.a. CWOP en WRIJ als databron hebben (op een heel andere manier) heel duidelijk zulke beperking in hun datafiles.
AWEKAS en Skyz.be zijn als databron beter met direct een aantal afgeleide waarden in hun datafile.
XWeather zou goed zijn met een file1 met actuele waarden plus een file2 met afgeleiden, maar die heeft de eigenaardigheid dat ze file2 sturen met de waarden om middernacht, en daar heb je dus de rest van de dag helemaal niets aan:
kostte na ontdekking moeite dat hun team duidelijk te maken, voor hen een Oeps-ervaring, en ze hebben (nog) geen oplossing gegeven om file2 periodiek & actueel te krijgen.

Al heel lang dus mijn gewoonte om voor een een nieuwe HWA-interface zelf een Python-script-aanhang te voorzien die naar behoefte aanvullend de afgeleiden bepaalt om de HWA-file in te vullen.
Daarin per station toepassing van een dictionary als historisch werkgeheugen:
een gemeenschappelijke database gebruiken zou ook kunnen, maar met een dictionary lekker compact, eenvoudig leesbaar & wijzigbaar, en direct zichtbare relatie met een station.
Kost wat moeite en soms per stationsconfiguratie iets variërend, maar op zich een standaardkunstje met als basis een standaard-jsonfile.

In zicht van bovenstaande zou een PHP-script met een input volgens Ecowitt-protocol ook een mogelijkheid zijn,
maar dat lijkt me aan de gemiddelde gebruiker moeilijker uit te leggen, dus voor het gemak dan maar niet.
Als je voorbeelden hebt van PHP-script i.c.m. inlezen van datamessage met Ecowitt-protocol, altijd zinvol om te overwegen als deel van het experiment.

Als ik je goed begrijp wil je dus de afgeleide / hoog-laag / e.d. waarden zelf berekenen.
Dat is zeer wel mogelijk.
Praktisch:

Een "weerstation met een vrije upload naar WU gebruikt een GET met een serie veldnamen-waardes

Naar een ontvangst-script op een HWA-extra-server die
1. op basis van USERID & PASSWORD het bericht accepteert of afwijst.
( Gezien het relatief kleine aantal stations hoeven we geen wachtrij aan te leggen.)
2. de historie ophaalt van vandaag van het bekende station (of een lege historie voor een nieuw station)
3. de historie bijwerkt met de nieuwe waardes inclusief "roll-over" bij het eerste bericht na middernacht
4. de historie opslaat
5. en een HWA-bestand (in HWA formaat) genereert en bewaart .

De HWA-server kan dan het HWA-bestand ophalen wanneer het hem/haar uitkomt
- - -
Allemaal goed te doen.
1. Alleen moet er dan wel een document zijn over welke velden HWA echt nodig heeft.
2. E.e.a. zal nauwelijks een belading zijn, het basis pakket van de meeste providers zal voldoende zijn.
3. Wel opletten dat er iedere 5 minuten wordt opgeladen. Niet iedere 5 secondes e.d. zoals bij WU.
Dus een veldje in de historie met de laatste oplevering is nodig om WU-rtupdates tegen te houden.

Mvg Wim

‘Rapidfire’ zoals genoemd in de scriptbeschrijving in het eerste bericht van deze thread is zeker ongewenst:
‘normaal’ is al snel genoeg.
Alleen bang dat de gemiddelde PWS-gebruiker niet weet hoe je dat instelt …….

T.a.v. HWA-filelayout & vulling kun je hier kijken:
beschrijft via weblinks ook verder een 'lange' versie en een 'kortste' versie.
Maar ook praktische invulling daarvan:
voor de WRIJ-regenmeters is de 'kortste' versie in gebruik met invulling van "---" voor alle basis-meetwaarden anders dan neerslag, want immers uit de databron niet meer beschikbaar dan de neerslagwaarden en hun afgeleiden.

Toulon7559 schreef: ↑Vandaag, 15:46 ‘Rapidfire’ zoals genoemd in de scriptbeschrijving in het eerste bericht van deze thread is zeker ongewenst:
‘normaal’ is al snel genoeg.
Alleen bang dat de gemiddelde PWS-gebruiker niet weet hoe je dat instelt …….

De meeste basis weerstations kunnen gelukkig helemaal geen "rapid-fire" of "real-time" updates aan.
Daarvoor is minstens een echte PC o.i.d. nodig.

Ik heb een pdf bijgevoegd van een script met alle velden die ik nu gebruik om een HWA-bestand te genereren.

Kan je daar de "echt (nog) niet nodige" velden uit verwijderen?
Dan zal ik een eerste versie maken van een WU_HWA_ontvang script.

Wim

Wim,

Even heel snel vergelijkend met de lijst ooit gemaakt in dit bericht,
lijkt me dat je uit jouw lijst in voorgaand bericht alle jaarwaarden kunt schrappen en de maandwaarden behalve de maandwaarde voor regen.
De HWA-file die dan overblijft kan de HWA-database vullen voor een normale, goed uitgeruste PWS-configuratie (incl. Licht & UV):
als de velden voor basiswaarden en opties zijn ingevuld zoals aangegeven in bovengenoemd forumbericht, dan is er voldoende vulling voor alle vakjes van HWA-vertoning.