Discussie forum met vragen over TFA, Nexus, Mebus, Irox en Honeywell
weerstations, specificaties, ervaringen etc..
Door Toulon7559
#67567
Voor periodieke upload t.b.v. HWA gebruik ik de toevoeging op WsWin, draaiend op een PC met Windows. De resulterende file staat op mijn webserver voor ophalen door HWA.
Mijn TFA_Nexus mist sensoren voor meting van Licht/IR/UV, dus waarden daarvoor zijn niet ingevuld in die file.

Via mijn Raspberry domotica-computer kan ik een paar sensoren toevoegen op de I2C-bus en daarmee Licht/IR/UV-info bemachtigen via een Python-script o.i.d.

Is er ook een manier om de zo verkregen Licht/IR/UV-info vanuit de Raspberry netjes in te voegen in de periodieke upload voor HWA die vanuit de PC over mijn webserver loopt?
Brainstormend denk ik daarbij bijv. aan een API/JSON-call o.i.d. waarmee de HWA-toevoeging in WsWin de benodigde info kan oproepen uit de Raspberry of van een vooraf gedefinieerde locatie. Apart ophalen door de HWA-server van aanvullende info lijkt me moeilijker en minder netjes.
#71619
In de loop van de tijd een praktisch antwoord gevonden.

De functie wsmerge van WsWin geeft de mogelijkheid vanuit een ander systeem een alternatieve dataset periodiek te uploaden voor merge met de dataset van WsWin.
0. Invoegen van data in WsWin kan alleen als de benodigde IDs voor de upload-data al in WsWin aanwezig zijn.
1. Maak buiten WsWin in een periodiek proces een wsmerge-file aan in de goede layout [de Help-file van WsWin geeft de benodigde info].
2. Zet geautomatiseerd de gegenereerde wsmerge-file in de hoofddirectory van WsWin.
Dat vraagt dus een periodieke upload/refresh naar WsWin vanuit het programma dat de wsmerge-file maakt.
3. Zet in programma WsWin de benodigde vinkjes in rubriek DateiÜberwachung
Bij inlezen van data kijkt WsWin daarna óf er een wsmerge-file is, en verwerkt die.

Op die manier kun je voor TFA_Nexus bijv. UV-data toevoegen aan de dataset van WsWin, en de data-input voor luchtdruk en voor wind overschrijven met data uit externe, betere sensoren.
Elders in het forum is (was?) een thread die uitgebreider ingaat op de werking van de wsmerge-functie.
#72569
Ook een 'omweg-manier' gevonden om 'echt gemeten' lichtinformatie in WsWin te brengen voor een PWS die dat normaal niet heeft, omdat de PWS geen type WS2500 of Davis is, of daarmee vergelijkbaar.
;-) Met die 'omweg' het meteoplaatje in WsWin weer iets completer.
Helaas licht-info alleen voor het lokale beeld, en niet in de ingebouwde upload-functies naar o.a. AWEKAS en WUnderground, want de lichtinfo wordt in WsWin voor zulke PWSen verwerkt als extra quasi-temperatuur/-vocht, en de schatting van lichtwaarde in Lux of in W/m^2 blijft ook intern.
M.i. een verstandige ontwerp-beslissing om te zorgen dat extern geen 'onzin' wordt verspreid.
De scripts voor HWA-upload zijn niet door hem ontwikkeld, en die hebben dus wel mogelijkheid om lichtwaarden en UV-waarden mee te nemen!

WsWin kent een rubriek Speciale Sensoren en daarin kun je een Solar-Sensor 'namaken', naar keuze op basis van
1) omgebouwde thermo&hygro-sensor, uitgebreid beschreven in de Help-file van WsWin
2) omgebouwde hygro-sensor, maar nergens verder beschreven.
3) door DiffTemp-vergelijk tussen 2 thermometers (op basis van een zgn. 'solar-jar' functie).
Methode 3) werkt o.a. direct met een TFA_Nexus (en vergelijkbaar) door vergelijk van de 'windthermometer' t.o.v. de 'basis-thermometer'.
Geen van de 3 bovengenoemde methoden is erg nauwkeurig en calibratie is m.i. eigenlijk een inschatting met 'natte vinger'.
Dat is voor de ontwikkelaar van WsWin de reden om die lichtwaarden niet op te nemen in de externe uploads.

In mijn configuratie werkt Methode 1) voor TFA_Nexus nu met een omgebouwde thermometer op ID=4 die voor het lichtbereik een quasi-temperatuur geeft van -5C t/m +65C, overeenkomend op de gekoppelde hygro-functie met ID=20 met een (licht)bereik van 0%~100%.
Die procentuele afbeelding wordt geregeld in WsWin door instellen van 0%-waarde en 100%-waarde t.o.v. het temperatuurbereik.

Moderne, digitale lichtsensoren zijn veel beter met bepaling & uitgifte van meetwaarden, maar hoe krijg je de info daarvan ingevoerd in WsWin?
Domoticz leest in mijn configuratie een aantal lichtsensoren uit, waaronder de beste een WS7000P-19 (= clone van WS7000-19 aka WS2500-19) met als sensor een IC type MAX44009 [0~188kLux met 22bit resolutie].
Zulk bereik & resolutie is beter dan veel lichtsensoren in kant-en-klare PWSen:
als 'losse' sensor is minder nauwkeuriger type TLS2561 of SI1145 natuurlijk ook heel goed bruikbaar.
In de praktijk met die sensor WS7000P_19/MAX44009 deze zomer een max. lichtmeetwaarde gezien <70kLux:
daar zit nog uitzoekwerk, want praktisch zou dat hoger kunnen zijn.
In mijn configuratie maakt Domoticz een file wsmerge.csv, waarmee data naar wWsWin wordt geupload voor invoer, dus de data-input en het transportmiddel zijn beschikbaar.

De navolgende beschrijving koppelt de info uit de 2 voorgaande alinea's functioneel aan elkaar.

In de proefperiode lopen de omgebouwde T&H-meter van TFA_Nexus en de upload van wsmerge.csv parallel, en compatibilteit is dan gewenst.
In Domoticz wordt daarom voor upload naar ID=4 in WsWin in wsmerge.csv een waarde gezet die de lichtmeetwaarden 0~70kLux vertaalt naar temperatuurbereik -5C t/m +65C => (toevallig) 70C voor 70kLux => schaalfactor 1% = 700Lux [voor een andere omgebouwde T&H-meter zullen de grenswaarden anders zijn!!!]
De uploadwaarde overschrijft in WsWin de interne waarde van ID=4.
De schaal van de grafiek is nu niet langer 'toevallig', maar stelt echt iets voor, en ook bepaling van bewolking en berekening van zonneschijnduur werken direct met de beproefde WsWin-functies.
Daar zit echter het addertje onder het gras dat de bepaling van bewolking en de berekening van de zonneschijnduur met de procentuele schaalwaarde zijn gekoppeld.
De standaardinstellingen voor de bovenste 3 grenzen in die functies zijn:
>=85% = zonnig => Tijd, als drempelwaarde voor Zonneschijnduur
>=70% = licht bewolkt,
>=50% = bewolkt.
Met 100% = 70kLux krijg je met die instellingen echter in de praktijk dichte bewolking en heel weinig zonneschijnduur!
Want volgens WMO-richtlijnen is zonneschijnduur de tijd dat Lichtsterkte >= 120W/m^2 oftewel >= 20kLux.
Toepassingen van die richtlijnen o.a. te vinden bij http://www.plevenon-meteo.info/techniqu ... ement.html en bij WS2500-19
In lijn daarmee moet je voor WsWin met de bovengenoemde upload van max. 70kLux de instelling dus veranderen in:
>=30% = zonnig => Tijd, als drempelwaarde voor Zonneschijnduur [want 20kLux = 0,3 * 70kLux]
>=25% = licht bewolkt,
>=20% = bewolkt

Het is een omweg, maar WsWin werkt zo met praktische afbeelding & toepassing van een 'echte' lichtwaarde met 70kLux fullscale!

Verbetering (als je geen omgebouwde T&H-meter toepast , maar wel de toegang van WsWin voor Solar) kan zijn om de schaalfactor en data-input 'handiger' te maken,
bijv. 1% = 1000Lux via 0~100kLux => 0C~100C => 0%~100% fullscale:
# het interpreteren vanuit info in de grafiek en tabellen wordt daarmee eenvoudiger
# met max. 100kLux voldoende invulruimte voor heel felle zon!
# geen rescaling nodig in scripts, want
- in de upload met wsmerge.csv direct toepassing van de originele kLux-waarde,
- binnen WsWin geven ID=4 en ID=20 direct de waarde in kLux.
Omdat de procentuele Y-as niet automatisch aanpast op de lage waarden is nadeel van die keuze dat de afbeelding in een grafiek zeker in de winter wel erg laag wordt.
T.o.v. een 'schijn-lichtmeter' volgens methode 1) met een fotodiode is de grafiekkromme ook wel erg laag in de wintertijd.

De 3 hierna volgende uitvoeringsvarianten voor volledigheid vermeld, maar kun je misschien maar beter laten passeren: veel moeite, en m.i. weinig direct gunstig effect.

a) Bij Methode 1) weghalen van omgebouwde T&H-meter als upload van lichtwaarden goed werkt
Als de beschreven uploadketen voor Methode 1) goed werkt, dan is de data uit de omgebouwde T&H-meter op zich overbodig geworden.
Na zo'n verwijdering zou je ook de eerdergenoemde 'verbetering' kunnen invoeren, maar opletten, want in WsWin worden daarmee dan ook automatisch de voorgaande registraties 'gecorrigeerd', dus misschien wel de T&H-meter weghalen, maar voor de eenvoud en voor onveranderd behoud van de statistiek beter niet 'functioneel verbeteren'.

b) Invoer met Upload van lichtwaarden via Methode 2)
Via Methode 2) zou upload van externe meetwaarden direct(er) naar een quasi-Vochtmeter-schaal kunnen voor toepassing onder Speciale Sensoren/Solar, maar de bijbehorende ID moet dan liggen tussen 1 en 16 en bedoeld voor Vochtwaarde:
in een uitgebreide configuratie is dat even zoeken.
Goede afbeelding in de grafiek en drempel-instellingen is daarna nog niet vanzelfsprekend en eigen uitzoekwerk, zonder hulpbeschrijving.

c) Direct lichtwaarde uploaden naar een vrije ID in WsWin als quasi-vochtwaarde
Je kunt ook direct naar een vrije 'vocht'-ID uploaden in WsWin => direct afbeelding op schaal 0~100%.
Naast aangepaste wsmerge.csv en de bijpassende instelling onder tabs Bestand/Eigenschappen moet je dan ook nakijken onder tab Internet/Aanpassingen/Sensoren en tab Weerstation/Beschikbare Sensoren of die Sensoren/IDs wel tevoorschijn komen: anders weliswaar een ID-koppeling, maar nog weinig verdere toepassing.

08Juni2021:
Eind van eerste alinea aangepast.
#72962
Ook als je PWS geen eigen/echte ingebouwde lichtsensor heeft (zoals voor o.a. Nexus), dan kun je dus WsWin met 'echte' lichtwaarden voeden via Upload met wsmerge.csv
Met proefondervindelijk uitgezochte instelling voor de quasi-temperatuur krijg je een redelijk goede vertoning langs de R.V. -schaal: bijv. lineair 0~100% voor 0~100kLux.
Alleen zit je in de praktijk een groot deel van de tijd onderin de schaal en klopt de vertaling naar zonneschijnduur niet echt.
Kun je afvragen of de lichtsterkte-afbeelding wel zo 'echt' moet zijn:
een werkende zonneschijnduur-bepaling is misschien zinvoller.
.
Dat laatste kun je (met wat script-knutselen) bereiken door vóór de upload m.b.v. wsmerge.csv van lichtwaarden een logarithmische [Log10]vertaling los te laten op de lichtwaarden en de uitkomst passend te maken voor de R.V-schaal (bijv. met 20 vermenigvuldigen voor invulling 0~100%):
10Lux => 1 => 20%
100Lux => 2 => 40%
1kLux => 3 => 60%
10kLux => 4 => 80% [20kLux => 86%]
100kLux => 5 => 100%
De bovenstaande vertalings-uitkomst geeft afbeelding van gebruikelijke lichtwaarden 'meer bovenin' de grafiek.
Terugrekenen van % naar Lux is moeilijk, maar zonneschijnduur wordt pragmatisch/realistisch ingevuld.
Bijkomend voordeel: als de upload van wsmerge.csv een keer faalt en de 'lokale' schijntemperatuur uit de omgebouwde thermometer neemt het weer over, dan zitten ze in hetzelfde bereik, dus zonneschijnduurbepaling gaat redelijk ongestoord door.
.
Blijft geknutsel, maar als WsWin voor TFA_Nexus en soortgenoten geen directe zij-ingang en schaalafbeelding heeft voor 'echte' lichtwaarden, dan moet je een praktisch bruikbaar alternatief bedenken ....

16Feb2021:
aangepast/ingekort
#73357
Nexus heeft geen interface voor UVI, maar WsWin staat voor Nexus toe dat je UV-info invoegt (waarschijnlijk gebaseerd op een ooit bedoelde, maar niet gerealiseerde sensorconfiguratie).
Schaling voor UVI is geheel proefondervindelijk aan de kant van de databron.
De UVI-waarden ingevoerd in WsWin via wsmerge.csv komen daar in de database, en daarmee in de grafieken en in de non-standaard-uploads, zoals naar HWA.

Te noteren bijverschijnsel:
als de data opnieuw worden opgehaald uit de console van TFA_Nexus,
dan loop je het risico dat de UV-info die al in de database staat wordt overschreven met blanco waarden (want de console heeft immers geen UV-data ter beschikking)..