Experimenten & Supplementen

Aankoppelen van meer subsystemen, van meer sensoren, van meer afstandbediende schakelaars en van extra en/of andere software-functies voor PV-sturing, voor Meteo-uitlezing en voor Domotica vraagt experimenten, want zelden is een standaard-oplossing direct bruikbaar.
Mooie spreuk daarover (gevonden op TweakersNet):
"Meten is weten, gissen is missen en gokken is dokken."
Daarom eerst apart kijken als Experiment hóe je iets oplost, en óf een oplossing goed & robuust werkt, terwijl de 'productie' ongestoord doordraait.
Naast serieuze aanpak is dit ook ook de 'speeltuin' om 'even' te kijken óf een functie of een nevenaspect werkt, en hoe.
Dat kan een belangrijk aspect betreffen, of zoiets cosmetisch als vertoning van een 'klokje', dat dus (b)lijkt af te hangen welke O.S. en/of browser je gebruikt).
Uit dat 'hoe' komt dan vaak info die wel interessant is, maar niet voldoende om in deze website te promoveren naar een 'hoofd'- item of naar een aparte subpagina:
de beschrijving van zo'n experiment blijft dan met uitkomsten in deze rubriek staan met label Supplement of wordt overgezet naar de aparte rubriek Supplementen.

Mijn Experimenten hebben wel raakvlak met de 'productie'-configuratie voor PV, Meteo en Domotica, maar zijn heel bewust gescheiden daarvan,
dus bijv. geen upload van 'ruwe, experimentele' meetdata naar 'officiële' meteo-sites, hoogstens naar mijn eigen website.

Voor geplande en onderhanden Experimenten dient deze websectie vooral als 'werkplaats' en 'notitieblok',
en het is daarom een (vaak ongeordende, uitgebreide) bergplaats voor

• concepten & uitwerkingen,
• argumenten voor configuraties & realisaties,
• aantekeningen/geheugensteuntjes,
• tussenresultaten in de vorm van notities, schetsen, plaatjes van testversies & situaties,
  met bijbehorende grafieken en tabellen (die tijdens testen soms heel 'rafelig' verlopen)
• waarnemingen => conclusies,
• ToDo-lijstjes en planningen.

De 'productie'-computers Domoticz1 en Domoticz2 in deze configuratie dienen heel beperkt als testbed voor onderzoek en voor testen van experimenten die betrekking hebben op hun specifieke interfaces.
Testen en experimenten voor andere aspecten vooral met de andere Domotica-computers.
Pas als een setup bevredigend werkt, dan kun je overgaan tot verder invoegen in het 'Systeem' en in de 'hogere' pagina's van de website.

Geplande & onderhanden Experimenten

Voor de onderstaande onderwerpen zijn nu aanpassingen & toevoegingen als Experiment 'in wording/ in bewerking' of al Supplement geworden
(waarbij in iedere uitgewerkte rubriek eerst wordt aangegeven wat de beweegreden) is:

1. Werkverdeling over processoren
2. Kruipruimte, Oplossing van Koude-voeten-problemen
3. Samenhang Lichtniveau en PV-productie
4. Energie-Info & Energie-voorziening [Verwachting & Realisatie]
   • Lokale inverter displays
   • Monitoring van beschikbare energiewaarden door de gebruikers
   • Verwachtingswaarden voor PV-Productie
   • Koelen van panelen
   • Opzet voor Thuis-accu
5. Verbeterde/eigen grafische vertoning en Robuuste upload van Meteo-info naar HetWeerActueel (en anderen)
6. Meting Lucht-kwaliteit/ Fijnstof- & Gas-vervuiling
7. Oplijning & afregeling van beschikbare wind-info
8. Bodem-sensoren
   • Temperatuur
   • Vocht
   • Grondwaterpeil
   • Experiment1
   • Experiment2
9. Meteo-sensoren op afstand met WiFi & LoRa
10. Behuizingen van sensoren
11. Vervanging van WS7000-sensors
12. Introductie Tempest_PWS
13. 'Conventionele' Neerslagmeters

Onderhanden experimenten zijn deels operationeel, in duurtest, of zijn momenteel 'rustend', i.v.m. denkwerk, wachtend op gelegenheid voor bouw, of wachtend op onderdelen.
Het symbool geeft aan voor welk onderdeel momenteel een volgende stap is gepland.

• Werkverdeling over processoren is nodig om te zorgen dat iedere processor ruim voldoende capaciteit heeft voor uitvoering van zijn functies, en voor een heldere structuur van functies per processor.
  Naast toewijzen van werk aan nieuwe processoren komt het neer op een herverdeling van functies.
  Te zwaar belasten cq. 'productie' mengen met Experimenten => crashes/vastlopers => data-verlies & werk & ergernis ......
  Domoticz1 en Domoticz2 zijn de 'front-end'&'productie'-machines voor data-collectie en voor bijbehorende essentiële systeem-functies.
  Belading voor Domoticz1 (= Raspberry Type B met LAN & 2*USB & 1*RFXCom) vooral schakel-functies en Energie-regeling (= PV-Productie en Consumptie),
  te reduceren naar interfacing van RS485-devices, interfacing van bekabelde sensoren en van communicatie via RFXCom.
  Belading voor Domoticz2 (= Raspberry, Type 3A+ met WLAN & 1*USB/RFLinkGateway) vooral (redundant/backup) schakel-functies en daarnaast Meteo-rekenwerk & Meteo-communicatie,
  te reduceren in de richting van afhandeling van de ESP8266en en van communicatie via RFLinkGateway.
  ESP8266-met-ESPEasy heeft een bepaalde capaciteit & catalogus voor taken.
  Raspberries zijn in het algemeen krachtiger en vrijer inzetbaar.
  Dat is reden om nog meer Raspberries toe te voegen in de configuratie, en de configuratie van de Raspberries en de ESP8266en aan te passen:
  1. Domoticz3 = 3e Raspberry (= Type 3B+ met WLAN, LAN & 4*USB) als Controller naast Domoticz1 en Domoticz2,
     vooral cq. steeds meer voor 'algemener' rekenwerk en voor ontlasting in de richting van Meteo (vooral Tempest) en Licht.
     Domoticz3 is de primaire Gateway tussen WLAN en LAN.
  2. Domoticz4 = 4e Raspberry (= Type 3B+ met WLAN, LAN & 4*USB) bedient vooral de energie-aspecten voor uitlezen van de P1-interface van de 'slimme' gridmeter, en voor het (toekomstig) uitlezen via S0PCM van 5 kWh-meters met S0-interface.
     Domoticz4 als uitlezer voor de P1-interface van de 'slimme meter' hangt in de meterkast.
     Domoticz4 bedient daarvoor ook de bijbehorende uploads naar diverse organisaties, die nu vooral in Domoticz1 zitten.
     Domoticz4 is secondaire gateway (als backup) tussen WLAN en LAN.
     
  3. Domoticz5 = 1e Raspberry_Zero_W (= versie 1.1) => Annex/Satelliet voor uitlezing via I2C-interface van de licht/IR/UV-sensor type SI1145.
  4. Domoticz6 = 2e Raspberry_Zero_W (= versie 1.1) => Annex/Satelliet voor uitlezen via USB-interface van T&H-meterconsole HP3001 in het kader van de kruipruimte-metingen.
  5. Domoticz7 = 3e Raspberry_Zero_W (= versie 1.1) => wordt Annex/Satelliet voor uitlezen van S0PCModule zo dicht mogelijk bij de betreffende S0-interfaces.
     De S0PCModule krijgt een optocouplerfront om te kunnen omgaan met lange kabels naar kWh-meters.
     De USB&LAN-Hub-addon op deze RPI0W maakt hem geschikt voor direct aankoppelen van S0PCModule.
     Met de 4 USB-poorten en de ethernet-poort ook m.b.t. interfaces compatible met de 'grotere' Raspberries.
  6. Raspberry8 = 4e Raspberry_Zero_W (versie 2) => aparte, experimentele 'productie'-instantiatie voor WeeWX.
     Deze configuratie is bedoeld voor stand-alone experimenten met WeeWX gericht op modificatie & uitbreiding.
     Daarnaast de systeembreed beschikbare sensordata experimenteel gaan bundelen in 1 'beste' PWS. Bewust zonder Domoticz, omdat er hinderende wisselwerking (b)lijkt te zijn tussen de software van Domoticz en van WeeWX:
     Deze instantiatie van WeeWX wordt bewust gescheiden van Domoticz 1 t/m 7, om als 'onafhankelijke PWS' te kunnen werken: Redundantie!
     In de basis een clone van Raspberry9, bedoeld voor stand-alone experimenten met WeeWX gericht op modificatie & uitbreiding, met uitgeschakelde upload-functies.
     Ook bruikbaar als redundantie voor Raspberry9.
  7. Raspberry9 = 5e Raspberry (= Type 3B+ met WLAN, LAN & 4*USB) => aparte 'productie'-instantiatie voor WeeWX en voor verwante functies.
     WeeWX dient voor lokale uitlezing van het Tempest_PWS en voor uploads naar HWA, CWOP en eventueel WU, WOW en AWEKAS.
     Deze WeeWX-configuratie volgt die van Raspberry8 nadat de goede werking is bewezen van de software van Raspberry8.
  8. Raspberry10 e.v. zijn eventuele, extra Raspberries (i.v.m. gelijkheid bij voorkeur type RPI_Zero_W of type RPI_3B+) als Annexen voor aanvullende Experimenten/Toepassingen.
  9. Alle Raspberries ingesteld op RAMDisk-gebruik, zodat de schrijf-operaties naar de SD-kaarten worden beperkt => vermindering van wear & tear.
     De 'Productie'-Raspberries nog te koppelen aan een NAS of USB-Drive voor nabije werkfiles & backupfiles.
  10. Periodieke externe backup van de Raspberry-bestanden verbeteren en automatiseren, zodat na een crash eenvoudiger een snelle(re) herstart mogelijk wordt.
      Daarmee ook betere/zekerder toegang tot oudere data.
  11. De ESP8266en dienen als frontends voor Domoticz2 t/m 4 voor data-collectie en als actuators [= aansturing van relais en van PWM-uitgangen]
  12. De aanwezige PCDuino dient als 'Algemene' homeserver en als Linux-test-platform (met Arduino-'trekjes' waarvoor dat platform een T-board heeft)

  Status:
  1. Domoticz1, Domoticz2, Domoticz3, Raspberry9b en een aantal ESP8266en draaien 'productie' met gestabiliseerde configuraties en toepassingen.
  Alleen regelmatig update&upgrade van OS.
  2. Domoticz5 en Domoticz6 zijn momenteel grotendeels 'productie' geworden, terwijl de andere Raspberries en de ESP8266en werken in oprichtings-/experiment-/testfase.
  Alle Raspberries in deze laatste groep volgen de beta-upgrades van Domoticz.
  Vanzelfsprekend ook regelmatige update&upgrade van OS:
  bewust Raspian_Buster, totdat Raspian_Bullseye stabiel genoeg lijkt. Acties&Plannen:
  3. Continu aandachtspunt, met continue ontwikkeling en testen.

  

  ---

• Supplement: Koude voeten gaven aanleiding tot aanbrengen van extra isolatie in vorm van de 2-laags Tonzon-kussens in de kruipruimte.
  Bij sterke condensvorming valt echter de onderste kussenlaag naar beneden, dus effectief daarna een 'halve invulling'.
  Beter begrip van de processen die vochthuishouding om het huis bepalen, krijg je door lezen van bijv. deze uitleg.
  Vinden van een remedie vraagt onderzoek naar de oorzaken, i.s.m. firma Tonzon.
  Voor dat onderzoek sinds november 2016 online meting aan plafond en bodem van de kruipruimte om kwantitatief te bepalen óf en hoe groot de vochtoverlast is, met registratie door het Domotica-syteem en vertoning via de lokale en remote webserver(s).
  M.b.t. het meetsysteem is in 2020 uitgebreid met online uitlezing van de sensoren van de HP3001-Console.
  De uitbreiding met de bodemmeting in de tuin levert ook aanvullende info voor vergelijking.
  Een goede oplossing voor het achterliggende hoofd-probeem is een heel ander aspect.
  Als effector toevoeging van een ventilatie-systeem, gestuurd door een bijbehorende meetprocessor.
  Om te kijken OF het werkt, is een experimentele opstelling handig, die met niet te veel moeite kan worden gebouwd, en eventueel weggehaald.
  Het aangehaalde voorbeeld met processor en ventilator in de kruipruimte is wel mooi uit het zicht, maar in onze kruipruimte lijkt het niet gemakkelijk een 'handige' plek&bevestiging bij 2 ventilatiepijpen te vinden, nog afgezien dat ventilator en voeding 'watervast' aangelegd moet worden.
  Aan de straatkant zou enigszins kunnen, maar aan de tuinkant is vooral toevoer van voeding complex.
  'Interim'-oplossing is plaatsing aan de tuinkant van 2 ventilatorkastjes op ventilatieopeningen die dienen voor kruipruimteventilatie (=afzuiging), en voeding over de muur naar de ventilatorkastjes vanaf een lichtpunt.
  In ieder ventilatorkastje een gerecyclede 12VDC-PC-ventilator: in Ventkast1 een 'geruisarme' variant, in Ventkast2 een 'normale' uitvoering.
  De voeding van de ventilators wordt initiëel geschakeld met een KAKU door Domoticz, vanuit het meetsystem vergelijkend op basis van de T&H-metingen in de kruipruimte en in de buitenlucht.
  Bewuste keuze voor een opzet met Advies vanuit vergelijk, maar met Sturing op basis van alleen buitenluchtmetingen,
  omdat de metingen in de kruipruimte minder betrouwbaar zijn, en bovendien zal het daar nagenoeg altijd te vochtig zijn & blijven.

  Status:
  1. Meetsysteem operationeel, maar op hoger niveau Onvoltooid i.v.m. uitblijven van een principieel goede probleemoplossing.
  2. Afzuigventilatoren in bedrijfgesteld sinds 29 maart 2021, eerste 2 dagen continu-draaiend met verlaagde snelheid,
  daarna continu draaiend op volle snelheid met handuitschakeling tijdens ongeschikt buitenweer (= te natte lucht en/of te lage temperatuur).
  Vanaf midden april onder sturing van Domoticz op basis van actuele buitentemperatuur en -vocht gemeten door de meteosystemen.
  De ventilatievoeding kan via een electronische schakelaar worden bediend vanuit 2 Controllers, zodat de opzet een vorm van redundantie heeft.
  Die 2 Controllers hebben toegang tot iets verschillende, continu-aanwezige buitenshuis-sensorensets, en geen toegang tot de kruipruimte-sensoren
  (want daar bij voorbaat zeer hoge R.V. en daarmee teveel risico van uitvallen-door-condens).
  Het onderzoek richt zich in dit stadium dus op de mogelijkheid om met deze configuratie een goede regeling te maken.

  Acties&Plannen:
  2a. Verbetering van geforceerde kruipruimteventilatie door verfijning van de geautomatiseerde ventilatorsturing vanuit Domoticz
  2b. Bij goed resultaat van 2a. de opbouw 'definitief' maken met een eigen processor voor meting en voor voedingsbediening.
  3. Bij gelegenheid omwerken van dit onderwerp voor overdracht naar Supplementen [want dit aspect heeft vooral relatie met de Nederlandse manier van huizen bouwen],
  met een engelse samenvatting voor rubriek Supplements
  4. 'Mechanische' neven-oplossingen realiseren (als de werkomstandigheden in de kruipruimte dat toelaten) zoals een drainageslang onder de bodemfolie, incl. aansluiting naar een te graven 2e dompelpompput
  5. Blijven zoeken naar nieuwe inzichten en invalshoeken .........

  

  ---

• Supplement: Lichtniveau heeft samenhang met PV-productie en nog veel meer processen.
  Voor bepaling van die samenhang (in meer detail dan nu met de 2 omgebouwde thermo-sensoren van de PWSen en met de UVN800) wordt een lichtmeting opgericht door meerdere, enkele en dubbele sensoren, incl. uitwerken tot 1 enkele, 'algemene' uitkomst (=> Lux-waarden en UV-waarden).
  Meerdere sensoren voor 'echte' lichtmeting lijkt overdone, maar door schaduwwerking om het huis en door beperkingen van de lichtsensoren is er niet 1 enkele, optimale sensor-opstelling mogelijk, dus moet worden gewerkt met een 'distributed setup' waarvan de metingen door software worden verzameld.
  De toevoeging van het Tempest_PWS is een inbreng van gecalibreerde waarden voor Licht en UV:
  beter dan beschikbaar uit eigenbouw, maar ook de Tempest-waarden zijn beperkt geldig vanwege de opstelling.
  Een oplijning onderling én met externe referenties is vereist, met berekeningen en met o.a. KNMI-waarden als waarschijnlijk beste, lokale, actuele referentie.
  Startpunt voor vergelijking en oplijning is samenbrengen van de berekende referentie-waarden en de actuele meetwaarden in RRDTool-database en -grafieken.
  Vergelijken (onderling en t.o.v. referenties) is moeilijk, want de sensoren hebben heel verschillende eigenschappen & realisaties:
  - het gevoeligheidsspectrum varieert per sensortype (in combinaties, voor visueel, IR en UV)
  - de sensorchips hebben interne processing die zonder veel uitleg alleen tot uitdrukking komt in getallen van de datasheets
  - door schaduwzones komen niet alle sensoren over de tijd onbelemmerd uit de verf
  Van calibratie is daarom geen sprake (en kan ook niet), hoogstens van een poging tot oplijning!
  Voor de grafieken in deze sectie worden de meetwaarden experimenteel geschaald.
  De licht- en IR-waarden worden nog niet toegepast voor de meteo-upload naar diverse organisaties:
  de UV-waarden worden wel toegepast en vóór de upload ruw geschaald & gedrempeld m.b.v. de berekenende referentiewaarden uit de lokale calculatie en uit OpenUV.
  • Grafiek Licht1 combineert experimenteel de sensoren van Nexus, WS7000, Tempest en een ESP8266 met BH1750-sensoren i.c.m. een LDR.
    Voor deze grafiek1 komen 3 lichtmetingen als quasi-Temperatuur uit Nexus en WS7000:
    - 2 quasi-Temp-waarden komen van PWS-thermometers omgebouwd met LDR/Fotodiode i.p.v. thermistor-weerstand (=NTC),
    - de Nexus_Wind Licht-waarde komt op de manier van 'solar-jar' door bepaling van de verschiltemperatuur tussen een thermosensor in de zon (als deel van de anemometer) t.o.v. de basis-temperatuur van het PWS (van een afgeschermde thermosensor).
    De eerste info-bewerking op de eerste 2 waarden is een best-fit inschaling binnen het betreffende PWS, en voor de Nexus Wind-Licht-waarde een versterking 10*.
    Voor de grafiek &tabel voor de WS7000-lijn daarna een bias/schaal-correctie (voor gelijkloop met de Nexus-lijn).
    Vermenigvuldiging van de Nexus Wind-Licht-waarde met 0.5 resp. 500 geeft voor grafiek en tabel ruwweg een Lux-waarde in de buurt van de meting door WS7000P_19.
    De ESP8266 in deze grafiek1 is een Testbed binnenshuis voor experimenten met sensor-fusie/ sensor-correlatie.
    De steile flanken voor BH1750 & LDR omstreeks 12:00~13:00uur worden veroorzaakt door beperking van sensorenzicht naar het Oosten en het Westen i.v.m. bebouwing en beplanting.
    De info uit de WS7000P_19 Lichtmeter wordt voor test & integratie ingevoegd vanaf 26 Januari 2020.
    Vanaf 30 November 2020 zijn de lichtwaarden uit het Tempest_PWS ingekoppeld.
    
  • Grafiek Licht2 combineert de sensoren van Nexus, WS7000, Tempest, SI1145 en een ESP8266 met BH1750+TSL2561-sensoren.
    Voor deze grafiek2 zijn de quasi-Temp-waarden uit Nexus en uit WS7000 gelijk aan de brekenwaarden van grafiek1.
    Voor alle sensoren in deze dataset moeten de schaalwaarden nog verder worden opgelijnd, onderling en t.o.v. referenties.
    De ESP8266 in deze grafiek2 is de versie voor uitgebreide meting met meerdere sensoren, als ondersteuning van de Lichtmeter WS7000P_19 voor diens 'blinde vlekken'.
  • Grafiek Licht3 verzamelt de informatie van de diverse UV-sensoren,
    waarbij de analoge meetwaarden uit de sensoren type GUVA12, ML8511 en SI1145 in Domoticz nog verder om te rekenen naar een praktische/realistische UVI.
    De rekenwaarden uit OpenUV zijn de ideale, 'Clearsky'-waarden voor deze locatie, terwijl de rekenwaarden uit UVCalc meer 'praktisch' zijn, incl. gemeten weerafhankelijke dempingseffecten.
    Vanaf 30 November 2020 zijn de UV-waarden uit het Tempest_PWS ingekoppeld.
    Verklaring zoeken waarom vergelijkbare grafieklijnen toch zo verschillend verlopen.
  • Grafiek Licht4 verzamelt de informatie van de diverse IR-gevoelige sensoren, en van de 'Breedband'-functie van de 2 TLS2561en,
    De meetwaarden uit de sensoren type TLS2561 en SI1145 in Domoticz nog op te lijnen cq. om te rekenen naar een praktische/realistische IR-waarde.
    Vanaf 30 November 2020 zijn de lichtwaarden uit het Tempest_PWS hier toegevoegd.
    Verklaring zoeken waarom vergelijkbare grafieklijnen toch zo verschillend verlopen.
  Als referentie zijn gemeenschappelijk in alle 4 grafieken 1 of 2 Grafieklijnen gereserveerd voor een externe waarde, zoals van Calculatie, Accuweather, Darksky e.d.:
  in de genoemde 3 grafieken is deze referentie nu een calculatie onder noemer LightCalc, met een daarvan afgeleide, nominale UV-waarde onder noemer UVCalc, en daarnaast OpenUV_Current als externe, 2e UV-referentie.
  Geen praktische, online referentie-info gevonden voor IR-bronnen.
  De genoemde referentie-calculaties voor lichtwaarden maken gebruik van rekenmodellen t.a.v. atmosferische functies, die deels gebruikmaken van statische en dynamische inputs als invoer voor 'lokale effecten'.
  Deze inputs bestaan uit:
  • Geo-locatie van het PWS [= Lengte, Breedte en Hoogte]
  • Actuele, lokale tijd
  • Actuele luchtdruk (niet bij OpenUV)
  • Wolken-bedekking uitgedrukt in 'Octa' [0 = Helder > 8 = Zwaarbewolkt], geleverd door Ogimet.com (niet bij OpenUV, want 'Clearsky'-info)
  Reden van de 'hakkels' in de grafieklijnen van de referenties:
  - Info van OpenUV wordt per half uur ingevoerd,
  - Info voor'Octa' wordt door Ogimet per uur berekend.
  Op termijn zal een aparte Raspberry alle lichtmetingen en - berekeningen voor zijn rekening gaan nemen.
  Die Raspberry correleert dan ook de Lichtmetingen met de UV-metingen van de diverse sensoren, en met een eventuele IR-meting.

  Status:
  1. Onderweg, met testen & afwerken.
  Obstakels die schaduw geven blijken meer invloed te hebben dan verwacht.
  Tempest als lokale referentie vergemakkelijkt het oplijnen.
  2. Gekoppeld aan webpagina Calibratie(kwaliteit) in rubriek Supplementen.
  Acties&Plannen:
  3. In de laatste versies van de grafieken nog 'best-fitting' grafieklijnen toe te voegen als 'Resultanten' voor Licht en voor UVI:
  als uitgangswaarden voor meteo-toepassing worden dat de uploadwaarden naar de diverse organisaties.
  4. Daarna dit Experiment integreren in betreffende Meteo webpagina's en/of overbrengen/koppelen met een engelse tekst naar rubriek Supplements.

  Bijzonderheden:
  

  

  ---

• Energie-Info & Energie-Voorziening [Verwachting & Realisatie]
  Duurzaam in-/uitschakelen vraagt een eenvoudige, directe vertoning van beschikbare energiewaarden en aanverwante informatie.
  Nu is vertoning van energie-waarden (zowel voor productie als consumptie) alleen mogelijk door opgeroepen uitlezing via webpagina's.
  Naast zicht op actuele productie/consumptie is een prognose ook interessant.
  Nu zijn de functies nog verdeeld over de 2 Raspberries, maar op termijn zal een aparte Raspberry voor Energie-aspecten alle metingen en - berekeningen voor zijn rekening gaan nemen.
  1. Lokale inverter displays
     Een eenvoudig, lokaal 'technisch' display bij de inverters (en o.a. de wasmachines) is gewenst.
     Dan kun je daar direct zien hoeveel actueel PV-vermogen er totaal beschikbaar is t.o.v. de actuele totale consumptie.
     Het kleinste, experimentele display1 hiernaast is te klein:
     een volgende display2 heeft een schermpje met meer tekst.
  2. Monitoring van beschikbare energiewaarden door de gebruikers
     Voor de huiskamer is een mooier uitgevoerd, lokaal display gewenst van meetresultaten, waarop gebruikers direct & actueel kunnen zien hoeveel PV-vermogen beschikbaar is cq. hoeveel electra geconsumeerd wordt, en ;-) dat veel goedkoper dan met een 'Toon' o.i.d.
     ToDo is een display3 met veel groter scherm, grotere karakters en meer grafisch beeld.
  3. Verwachtingswaarden voor PV-Productie
     Als je weet welke PV-productie verwacht mag worden, dan kun je m.b.v. Domotica gaan anticiperen op de beschikbaarheid van energie.
     Lokaal is die info niet direct beschikbaar: alleen indirect vanuit de meteo-verwachting.
     Extern is zulke info beschikbaar gekomen bij de website forecast.solar afgeleid van zowel PV-rekenmodellen als ook Meteo-rekenmodellen.
     Volgende stap is om die info online uit te lezen en in te voeren in Domoticz, om daaruit voor lokaal gebruik niet alleen een vergelijkingsfunctie, maar ook een schedulingfunctie op te zetten:
     1. met vergelijking kun je (als kwaliteitscontrole) checken of de verwachtingen kloppen t.o.v. actuele info
     2. als stap1 bevredigend is, dan hoef je niet zelf de actuele productie in de gaten te houden, maar zou je het kunnen overlaten aan het Domotica-Systeem om de voorspelde waarden te monitoren, te vergelijken met de werkelijke waarden en dan via scheduling apparaten wel of niet inschakelen
     Startpunt van implementatie is een aparte webpagina met vertoning van de verwachtingswaarden t.o.v. de actuele productiewaarden.
  4. Koelen van panelen
     De productie uit PV-panelen is afhankelijk van de zoninstraling en van de temperatuuur van de panelen.
     Dat laatste is een natuurkundig verschijnsel:
     - als de temperatuur van een PV-paneel > 25 graden Celsius, dan vermindert de productie met ca. 0,5% per graad t.o.v. 25 graden
     - als de temperatuur van een PV-paneel < 25 graden Celsius, dan neemt de productie toe met ca. 0,5% per graad t.o.v. 25 graden
     De temperatuur van een paneel heeft direct raakvlak met de omgevingstemperatuur en ventilatie van het paneel:
     de zoninstraling kan daarnaast de temperatuur van een paneel hoog opjagen, zeker voor panelen met zwarte elementen
     => de oppervlaktetemperatuur kan oplopen tot boven 70 graden Celsius)!

     In 2012 is een korte test uitgevoerd om te kijken of het loont om PV-panelen te koelen door besproeien met water.
     Daarvoor zijn 2 sprinklers tussen 2 rijen panelen gezet, en op het heetst van de zomerdag is gematigd gesproeid over die panelen:
     leidingwater, dus ongecontroleerde temperatuur, maar vrij koel t.o.v. de buitenlucht.
     Als referentie een rij van 3 ongekoelde panelen met ongeveer gelijke belichting.
     Ruwe conclusie uit de datalogging van de gekoelde panelen en hun inverters, vergelijkend met de opbrengst uit de andere panelen:
     - inderdaad geeft de besproeing met leidingwater meer energie uit de gekoelde panelen,
     - sproeien moet heel nauwkeurig plaatsvinden om effect te hebben,
     - sproeien en het water laten weglopen is een aanpak die niet economisch is en niet duurzaam
     - de extra opbrengst weegt niet op tegen de kosten voor het sproeiwater uit de waterleiding.
     => sproeikoeling van panelen is alleen rendabel als je beschikking hebt over een eigen, ruime voorraad van zuiver & koud koelwater
     en beschikt over een bijbehorend, heel efficient rondpomp-, sproei- en opvangsysteem!
     Argumenten voor die conclusie:
     a. het koelwater moet zuiver zijn als leidingwater, want anders krijg je aanslag op de panelen (en dat is contraproductief)
     b. het volume en de (lage) temperatuur van het koelwater moet voldoende zijn om langdurig koel genoeg in a cyclus rond te pompen over de panelen
     => combinatie van volume & temperatuur vereist voor opvangen warmte en verdamping,
     => gesloten circuit, want anders door verlies van de vloeistof niet economisch en niet duurzaam.
     c. oppompen van het eigen koelwater kost installeren van een pomp en daarna in bedrijf ook energie benodigd voor rondpompen, en dat is dus niet gratis.....

     Verslag van het experiment te vinden in de aanhang

     Effectiever en stukken goedkoper lijkt om te zorgen voor goede, natuurlijke luchtstroming rond de panelen, zodat de panelen niet veel heter worden dan de omgevingslucht.
     Tevens zorgen dat de onderliggende vlakken niet heet worden en naar de panelen kunnen stralen.
     In dat kader wordt ook wel genoemd om een onderliggend plat dak te beplanten met groen, zoals sedum:
     beplanting met teeltlaag blijft vanzelf koeler/natter dan kale bitumen of grind,
     maar plantengroei vraagt voor licht wel meer ruimte onder de paneel-opstelling.

  5. Thuis-accu
     Energietechnisch gezien maakt het voor lokaal verbruik niets uit of je energie zelf opwekt of van het publieke grid haalt.
     Het verschil zit in duurzaamheid en kostenverdeling, meestal uitgedrukt in geldstromen:
     - wat je zelf opwekt en dan lokaal gebruikt, is geen belasting voor de 'buitenwereld'
     - betalingen aan externe organisaties zijn meestal liquide verliesposten, terwijl eigen productie eigen verdienste geeft
     - zelf vasthouden & toepassen van lokaal energie-overschot is een verlengstuk van het bovenstaande.

     Lokale opslag van energie heet officieel "residentiële energieopslag".
     Breed gezien kun je dat op meerdere manieren doen:
     1) Vooral gericht op geldelijke winst, gecontroleerd externe energie binnenzuigen van het publieke 230V-grid als de prijs aantrekkelijk is,
     lokaal opslaan en dan de opgeslagen energie intern gebruiken in tijden met hogere kosten/ hoger lokaal verbruik.
     2) Vooral gericht op duurzaamheid, schuin kijkend naar minderkosten, de eigen PV-energie binnenshuis houden voor tijden dat geen/weinig PV-energie beschikbaar is,
     met het publieke 230V-grid voor referentie, voor aanvulling als de lokale opslag leeg is, en voor teruglevering van overschot als de lokale opslag vol is.
     3) Combineert 1) en 2), met uitbreiding voor terugleveren vanuit de lokale buffervoorraad aan het publieke 230V-grid als algemene reserve voor het grid, niet alleen bij lokaal overschot.

     Momenteel dient (m.b.v. de salderingsregeling) het publieke 230V-grid als 'super-accu' en is het niet financieel rendabel om een thuis-accu te plaatsen.
     Dit thema speelt daarom pas op termijn, tenzij voordien een technische reden opkomt:
     gedachten worden verder uitgewerkt in een aparte websectie.

     Status PV-display & - verwachting:
     1. 2 displays met scherm <1" Gereed & Operationeel, maar tekst is te klein voor handig gebruik.
     2. PV-Verwachting: onderweg / testing
     Acties&Plannen:
     3. 'Mooi, groter' 3e display: Uitzoekwerk
     4. Teksten m.b.t. PV-verwachting verder verwerken in de betreffende PV-webpagina's.
     5. Bij gebleken geschiktheid (vooral t.a.v. nauwkeurigheid & stabiliteit!) de PV-verwachting verwerken in domotica-functies
     
     Status Koel-experiment/ PV-opbrengst:
     6. Koel-experiment uitgevoerd/ afgerond.
     Geen vervolg van deze opzet, want argumenten a. en b. kunnen niet praktisch worden ingevuld, en c. is heel precair.
     Acties&Plannen:
     7. Geen plannen, behalve 'iets' de opstelling verbeteren van de groepen C en D op de schuur, voor meer lucht/ruimte onder de panelen.
     Status & Plannen Thuis-Accu:
     8. Toepassing van een thuis-accu is nu uitzoekwerk.
     Voorlopig gericht op een accu-configuratie met dekking van het lokale 230V-verbruik in de komende 1* of 2* 24uur (~ 2,5 kWh of 5 kWh capaciteit), want het andere eind van de invulling (= een komplete dekking van jaarbehoefte) vraagt een heel grote accu-configuratie.
     Ook bekijken of & hoe teruggeleverd kan worden als de lokale accu vol is, en wat & wanneer dat dan opbrengt.
     [Dat laatste wordt heel moeilijk bij invoering van een (zoals nu in opmars), want dan moet je eigenlijk online toegang hebben tot de info van de energiemarkt met dynamisch reagerende software in je opslagsysteem of in een 'zeer slimme meter']

     

  ---

• Verbeterde/eigen grafische vertoning en robuustere upload van Meteo-info naar HetWeerActueel (en anderen)
  1. Grafische vertoning van info
  1a. Templates & Scripts
  Voor 'persoonlijke' vertoning maken programma's zoals WsWin het mogelijk een aangepaste grafische uitvoer te maken met een zgn. custom-file:
  - de 'basis'-custom-file is het raamwerk voor een persoonlijke variatie op de standaard-uitvoer van WsWin
  - ook een uitgebreide versie die nog wat meer ontwikkeling vraagt
  Het werk zit in de script-aanpassing & test totdat de layout & inhoud geschikt is voor publicatie.
  Daarnaast kun je een 'persoonlijke' vertoning maken met extern gevonden templates:
  ook daar zit het werk in invullen, script-aanpassing en testen.
  Met een template zoals van PWS_Dashboard gaat dat laatste heel snel:
  dit is een Tempest-versie gebruikmakend van data uit WUnderground e.d.
  Met WeeWX-software kan lokaal een website worden opgebouwd, met online via upload een externe kopie:
  voor deze locatie gerealiseerd verbonden met het Tempest_PWS.
  1b. 'Eigen werk'
  Een 'eigen' vertoning is een oplossing als grafieken uit andere programma's en uit templates toch niet datgene opleveren wat je wenst als upload voor verwerking & vertoning elders, omdat bepaalde elementen ontbreken, of beter anders vertoond moeten worden.
  De toepassing begint in deze configuratie altijd met een data-uitlezing via Domoticz, gevolgd door database-vulling.
  O.a. RRDTool is daarna een mogelijkheid om die database grafisch uit te beelden: dit plaatje is een voorbeeld van meteo-waarden voor een zeer stormachtige dag.
  2. Alternatieve upload van meteodata naar HetWeerActueel (en anderen)
  Voor Nexus-meteodata komen de upload t.b.v. HetWeerActueel en de basis-uploads naar WUnderground en naar AWEKAS sinds 2014 (vanwege toen beschikbare software) uit WsWin @ PC:
  a. Dit is een realisatie met een korte weg van Sensorsysteem > Console > WsWin => upload.
  b. De layout van de upload is volgens een vast formaat, en alleen variabel door aanpassing van de brondata en een beperkte variatie van instellingen van WsWin.
  c. Die uploads moeten continu 24/7 doorlopen, maar aan die eis wordt niet voldaan door haperingen van de inmiddels 'bejaarde' Windows-server.
  Aspect a. is positief, maar aspecten b. en c. vragen verbetering.
  Voor WS7000-meteodata en Tempest-meteodata is upload naar WUnderground en naar AWEKAS inmiddels via Domoticz met meervoudige alternatieven beschikbaar, maar (tot voor kort) nog niets voor upload naar HetWeerActueel.
  Best (want zeer ruime mogelijkheden) lijkt een upload-opzet met toepassing van de Raspberry, liefst redundant.
  PWS_Dasboard, WeeWX, Meteotemplate en Domoticz bieden inmiddels mogelijkheden:
  • PWSDashboard maakt gebruik van data uit o.a. WUnderground als input en dat is dus t.o.v. de sensoren een indirect (= langer) traject.
    De mogelijkheid voor upload naar HetWeerActueel is een standaard ingebouwde uitgangsfunctie van PWS_Dashboard.
    Handicap van deze oplossing is dat calibratie moet hebben plaatsgevonden in de databron, en dus punt van aandacht in het 'voortraject'.
    
  • WeeWX leest via een Raspberry direct de UDP-signalen van de Tempest-sensorhub, en maakt daaruit direct een uploadbestand, dus kortste traject.
    Upload naar HetWeerActueel wordt bestuurd m.b.v. inbouw van een template in WeeWX, zoals hier beschreven, met heel veel aanpasmogelijkheden, incl. calibratie/afregelen van de sensordata.
  • Meteotemplate maakt voor dit experiment gebruik van Tempest-data uit WUnderground als input en dat is dus t.o.v. de sensoren een indirect (= langer) traject.
    De mogelijkheid voor upload naar HetWeerActueel is een experimenteel toegevoegde uitgangsfunctie van Meteotemplate m.b.v. een plugin.
    Handicap van deze oplossing is dat calibratie moet hebben plaatsgevonden in de databron of in de plugin, en dus punt van aandacht in het 'voortraject' en/of 'natraject'.
    
  • Domoticz kan voor dit experiment gebruikmaken van alle sensordata beschikbaar in Domoticz (dus zowel uit PWSen als uit 'losse' sensoren, en dat is dus t.o.v. de sensoren een kort traject.
    De mogelijkheid voor upload naar HetWeerActueel is een experimenteel toegevoegde uitgangsfunctie van Domoticz m.b.v. een script-set.
    Bij deze oplossing gebeurt calibratie in Domoticz.
    
  • WUS02/Meteobridge is apart apparaat toegevoegd in combinatie met TFA_Meteotime_Console.
    Meteobridge leest data van TFA_Nexus, Tempest en GW1000 parallel aan de andere flows.
    Kant-en-klare invulling voor inlezen van sensordata en daaruit uploads naar diverse organisaties.
    
  Status/ Acties&Plannen:
  1. Verbetering afbeelding
  1a/1b. 'Eigen werk' doorgaand in ontwikkeling, in bewerking, en deels in Test
  2. Alternatieve uploadfunctie naar HetWeerActueel e.a. via diverse takken 2a. WeeWx-met-Simulator en daarna WeeWX-met-Tempest opgezet en getest, en liep voor test met upload naar HWA_station Hengelo_Noord en loopt nu voor test naar WeatherCloud Hengelo(Slangenbeek).
  WeeWX heeft ook standaard ingebouwde functies voor upload van meteodata naar WUnderground, AWEKAS, PWSWeather, WOW en CWOP.
  Omdat voor Tempest via Weatherflow resp. via Domoticz al gerealiseerde uploads voor WUnderground en voor AWEKAS, op dit ogenblik geen behoefte nog een kopie te activeren via WeeWX.
  Uploads van Tempest als vervanger voor PWSWeather en voor WOW eventueel pas na validatie, als blijkt dat Tempest echt beter is dan TFA_Nexus.
  Upload naar CWOP bestond nog niet: is nu toegevoegd met Tempest-brondata.
  Voor Nexus en WS7000 zijn in deze configuratie al Domoticz-realisaties voor upload naar WUnderground, AWEKAS, PWSWeather en WOW.
  Als alternatief een eenvoudige WeeWX-upload voor deze PWSen vraagt voor iedere sensor een aparte WeeWX-instantiatie, OF een selectief invoegen van elementen als extra sensoren.
  Daarom voor Nexus en WS7000 voorlopig een WeeWX-instantie 'on hold'.
  2b. Meteotemplate met zijn HWAFeed.php-script heeft overgenomen van WeeWX voor de upload naar HWA-station Hengelo_Noord.
  De uitwerking voor upload naar HetWeerActueel vanuit Meteotemplate is experimenteel, op basis van data uit Tempest, onder test.
  2c. Domoticz met zijn HWAFile-scriptset loopt nu onder test t/m upload naar het 'tussenstation', parallel aan de upload uit WsWin:
  is WsWin 'ontregelt', dan neemt Domoticz over.
  De uitwerking voor upload naar HetWeerActueel vanuit Domoticz is experimenteel, op basis van data uit Tempest, onder test.
  Omdat alleen Domoticz een alternatieve uitlezing voor de betere WS7000-sensoren kan bieden, gaat op termijn de upload van die WS7000-data naar HetWeerActueel naar de Domoticz-instantiatie.
  2d. WUS02/Meteobridge met upload van data uit TFA_Nexus, Tempest en GW1000 is in oprichting:
  na eerste testen in de richting van AWEKAS en WUnderground te bezien of/hoe dit eventueel uit te breiden cq. met sensordata uit Tempest&GW1000 op te zetten richting HetWeerActueel.

  

  ---

• Lucht-kwaliteit/ Fijnstof- & Gas-vervuiling begint steeds meer belang te krijgen.
  Momenteel is er wel een officieel nationaal meetnetwerk, maar dat is niet fijnmazig genoeg voor 'lokale' conclusies.
  
  Daarom voor mijn Meteo-Systeem in oprichting & test een Fijnstof-toevoeging met een eenvoudige breedband-dustsensor type GP2Y10 als Annex aan Domoticz, en een nauwkeuriger sensor SDS011 die gesplitst meetresultaten geeft voor deeltjes van 2,5 micron en 10 micron, en die meetwaarden upload naar een internationaal netwerk.
  Voor bepaling van luchtkwaliteit is NO₂&O₃-meting een ontbrekend belangrijk element, maar dat hangt af van de beschikbaarheid van een betaalbaar, betrouwbaar meetconcept.
  Voor meting van NO₂ is deze webpagine een eerste aanzet.

  Status:
  1. voor Fijnstofmeting ingevuld en operationeel, maar te verfijnen.
  2. voor Gasmeting Testing met een eerste, eenvoudige aanzet:
  Acties&Plannen:
  3. Wachtend op een praktisch realiseerbaar, nauwkeuriger en robuuster Gasmeetconcept.

  

  ---

• Supplement: Oplijning & afregeling van beschikbare wind-info is nodig voor een eenduidig windbeeld.
  De meteo-configuratie kent 4 windmeters:
  - TFA_Nexus => windsnelheid & windrichting & windstoten, op ca. +5,5m boven grond
  - WS7000/15 => windsnelheid & windrichting, windstoten = 0, op ca. +4,5m boven grond
  - Conrad bestelnr. 108685 => alleen windsnelheid [via reedcontactsluiting/omwenteling], op ca. +3,5m boven grond
  - Tempest => windsnelheid & windrichting & windstoten, op ca. +3,5m boven grond
  

  De afbeelding hiernaast toont de opstelling van deze 4 windmeters.
  De eerste 3 windmeters in de configuratie zijn fysiek boven elkaar verdeeld over 1 gemeenschappelijke mast:
  de snelheidsmeetwaarden zouden enigszins moeten overeenkomen.

  Echter, niets is minder waar:
  • Nexus geeft 3 verschillende uitkomsten bij online uitlezing via zijn Console en daaruit WSWin, resp. draadloos via Domoticz/RFXCom en draadloos via Domoticz/RFLink .
    Console en Domoticz/RFXCom komen visueel min of meer overeen, maar data-uitlezing uit Domoticz/RFXCom lijkt gefilterde waarden te geven.
    Groot verschil bij data-uitlezing uit Domoticz tussen Domoticz/RFXCom en Domoticz/RFLinkGateway [schaalfactorfouten?].
    Daarom herschaling nodig voor Domoticz/RFLink en Domoticz/RFXCom om in de grafiek bijpassend te worden met plausibele waarden.
  • De uitlezing van WS7000 is via zijn Console, draadloos via WsWin/PC-Interfaces en draadloos (en visueel uitgelzen) via Domoticz/RFLink goed overeenkomstig.
    Data-uitlezing via Domoticz/RFLink heeft echter onvermoede afwijkingen die demping van de windsnelheid vragen.
  • 'Conrad' is volledig ongeijkt, zowel voor de puls-uitlezing als een afgeleide analoge uitlezing.
    De pulsen worden uitgelezen met een telleringang van een ESP8266 en daarna geschaald t.o.v. de andere databronnen.
    Volgens de bijgeleverde beschrijving zou vermenigvuldigfaktor 0,0179 een resultaat in m/s moeten geven, maar empirisch blijkt een andere factor nodig.
  De Tempest-windmeter staat apart op de top van een eigen mast, in de tuin op een afstand van ca. 5m afstand vanaf de andere mast.
  Voor onderlinge oplijning is in de categorie electromechanische sensoren de WS7000-anemometer waarschijnlijk de beste, lokale referentie.
  Tempest als moderne, solidstate sensor is mogelijk de absoluut betere referentie.
  Windsnelheid, ongecorrigeerd Windsnelheid, gecorrigeerd en Windstoten, gecorrigeerd

  De linkergrafiek toont voor vergelijk in RRDTool-grafieken de actuele meetwaarden zoals gemeld door Domoticz.
  Na de experimenten lijkt door calibratie-correctie enige gelijkloop mogelijk in de grafieken.
  Tempest is ingesteld als referentie met calibratie-correctie op 1 gezet.
  Voor de andere sensoren is calibratie-correctie ingezet voor een ruwe oplijning op basis van plausibiliteit t.o.v. de Tempest-waarden:
  correcte relatie van de 'opgelijnde' waarden met de werkelijke windwaarden is dus niet gegarandeerd!
  De grafieken & tabellen midden en rechts zijn met 'opgelijnde' waarden:
  deze opgelijnde waarden worden niet toegepast bij externe dataverdeling, maar alleen hier voor het experiment.
  Voor deze calibratie-correcties, zie verderop de inhoud van venster 'Bijzonderheden'.

  Het analoge signaal van de Conrad-windmeter was een electronische afgeleide van de pulssignalen via een integratie-circuit, gelezen door een A/D-converter:
  dat analoge signaal blijkt geen toegevoegde waarde t.o.v. het pulsende signaal, i.v.m. het slechte signaal/ruis-niveau.
  In de praktijk geeft vergelijken t.o.v. externe referentie-data zoals van KNMI, Accuweather of DarkSky alleen maar verwarring:
  de input voor 'Reference' is daarom tot nader orde op 0 gezet.

  Status:
  1. Experiment afgerond, met conclusie dat vergelijk/oplijning moeilijk is.
  2. Gekoppeld naar rubriek Calibratie(kwaliteit) in rubriek Supplementen
  Sinds 09 December 2020 ook Tempest-uitlezing gekoppeld.
  Acties&Plannen:
  3. Verder koppelen met een engelse tekst aan rubriek Supplements
  4. Grafieken met tekst nog aanhangen of koppelen in de Meteo-layout webpagina

  Bijzonderheden:
  

  

  ---

• Bodem-sensoren
  Meteo is gebruikelijk vooral meting in de lucht, maar de uitwerking van de bodem heeft daarop een belangrijke invloed.
  Ook omgekeerd is er interactie van lucht naar grond.
  Daarom is bodemmeting gewenst voor onderkennen van de samenhangen.
  Voor metingen buitenshuis vlak boven&onder het aardoppervlak heeft het Meteo-systeem in de basis
  - een WS7000P25 T&H-meter met Temperatuur & Humidity gecombineerd op +10cm,
  - een Nexus T&H-meter met Temperatuur op +20cm, maar Humidity op +120cm,
  - een WS7000/27 T&H-meter met Temperatuur-voeler via kabel op -10cm en Humidity op +150cm.
  - 'Buiten mededinging' nog een WS7000/25 T&H-meter met Temperatuur & Humidity gecombineerd, op de 'niet-standaard'-hoogte van +50cm,
  Van de WS7000 T&H-meters is de H/Vocht-sensor gaandeweg slechter inzetbaar door ouderdomskwalen.
  Alleen de WS7000P25 is momenteel uitgerust voor netjes gecombineerde data in het 'officiële' bodemoppervlaktegebied,
  met een nauwkeurigheid van +0,3°C voor Temperatuur en +2% voor R.V.
  Deze WS7000P25 T&H-meter is operationeel vanaf 2 April 2020, met de T&H-sensor gemonteerd in Davis-weerbehuizing.

  Hieronder de beschrijving van de uitbreiding voor 'echte' bodemmeting:

  • Achtergrond & Techniek
  • Resultaten
  • Status & Plannen

  Achtergrond & Techniek
  Meting op & in de bodem van temperaturen geeft zicht op de onderste luchtlaag, maar meting van vocht en waterpeil ook
  de mate van 'oppervlakkige' vochtbereikbaarheid voor zaaigoed en voor kleinere planten,
  en hoe de 'diepere' vochttoevoer voor bomen en struiken kan zijn.
  Ondergrondse metingen is een ondergeschoven kindje, voor goede kwaliteit met beperkte keus in (dure) componenten en systemen.
  Niet helemaal onterecht, want metingen ondergronds hebben vaak lagere prioriteit en hebben hun eigen soort problemen.
  Voor een kosten-effectieve aanpak is zelfbouw daarom een uitweg, met vereiste van begrip voor de eigenschappen van elementen,
  anders dan voor de 'normale' meteo-sensoren.

  De realisatie is stapsgewijs, om - al gaande - uit te vinden wat met zelfbouw-constructies wel of niet werkt:

  • Experiment1 is de basis voor temperatuur-meting en vocht-meting
  • Experiment2 is de ombouw op basis van ervaring uit Experiment1
  • Experiment3 is de (finale?) versie daarna

  Grondsoort & -profiel, algemeen voor dit perceel
  (van belang voor verklaring van temperatuurverloop en van waterpeil):
  boven -100cm = los, 'zwart' zand (~ Twentse benaming van deze grondsoort)
  onder -100cm = keihard & gesloten, wit zand
  (wordt nauwkeuriger bepaald bij uitdiepen van peilbuis 1 en bij aanleg van peilbuizen 2 en 3)

  Temperatuurmeting
  Het Meteo-Systeem miste nog een aansluitende temperatuurmetingreeks aan & in de bodemlaag volgens het beeld van o.a. KNMI en MetOffice_UK.
  Voor KNMI de 'gras-/klomp-hoogte'-sensoren op +10cm en ondergrondse sensoren op -5cm, -10cm, -20cm, -50cm en -100cm t.o.v. de oppervlakte.
  MetOfficeUK vraagt een andere manier van meten met naast de hoofdmeting op +1,25m, de andere bovengrondse sensoren voor 'grass_minimum' op +35mm en voor 'concrete_minimum' vastgezet op een groot, vrijliggend betonblok/-tegel, met de ondergrondse sensoren op -10cm, -30cm en -100cm.
  De door KNMI en MetOfficeUK gewenste configuratie van ondergrondse sensoren is vergelijkbaar te realiseren met moderne elektronische sensoren,
  schuin kijkend naar de manier waarop MetOfficeUK de sensoren ondergronds plaatst.
  De 'concrete_min'-sensor zou een eenvoudige toevoeging van de 'bodem'-opstelling zijn, maar bij onze opstelling zeker niet representatief,
  want de betonnen terrastegels en padtegels zijn in onze tuin veel te klein & teveel omsloten door pergola's, beplanting en bebouwing.

  Vochtmeting
  Luchtvochtigheid is een gebruikelijke maatstaf voor bovengronds vochtgehalte,
  maar ondergronds is dat niet van toepassing.
  Pogingen tot meting met gecombineerde T&H-sensoren SHT11 en SHT15 beschermd door capsule in een ruime behuizing in de bovenste grondlaag leken eerst goed te gaan,
  maar zijn op termijn toch een mislukking gebleken, waarbij het vochtmeetdeel uiteindelijk verdrinkt en onbruikbaar wordt:
  op zich verklaarbaar, want die sensoren dienen voor meting van lucht-vochtigheid, niet voor materiaal-vochtgehalte.
  De Davis_PWSen gebruiken voor de ondergrondse vochtbepaling speciale elementen waarvan de weerstand een functie is van vochtgehalte van de omgeving,
  met bijbehorend een specifieke meettechniek met puls-signalen.
  Regen-indicatie cq. bladvocht-indicatie is ook interessant als secondaire fase-monitor naast de neerslagmeting en de R.V.-meting, want

  • regen-indicatie geeft snellere info of er regen of mist is dan een 'tik' van de conventionele neerslagmeters, die alleen komt als het 'emmertje' vol is
  • bladvocht is soms nauwelijks neerslag, maar wel een aspect met duidelijke invloed voor plantenteelt.
  Zowel de Davis-type ondergrondse meting als de bladvocht-indicatie vragen een bijbehorend, afwijkend soort bediening:
  dat vraagt apart ontwerp, en calibratie daarvan is nog weer een ander hoofdstuk.
  Het Tempest_PWS met zijn solidstate sensoren levert een bijdrage t.a.v. regen-/bladvocht-indicatie, hoewel (waarschijnlijk) niet specifiek zo is bedoeld.

  Waterpeilmeting
  Het grondwater-peil is naast lucht- en grondvochtgehalte ook interessant gebleken o.a. in de discussies over neerslagtekort en over de natheid van onze natte kruipruimte.
  Indien mogelijk een oplijning met de manier van peilen van waterschap Vechtstromen:
  handpeiling is de basis, met daarnaast als aanvulling een automatische, electronische peiling in eigen variant.
  Dit onderdeel is nog geheel 'in oprichting', zoals daarvoor beschreven onder 'Nog-te-doen'

  Experiment1

  Een collectie sensoren gekoppeld aan een ESP8266-processor voorziet in een eerste opzet:
  zie de Meteo_Configuratie.
  Als invulling voor meting van de bodemtemperatuur is een array met 4*DS18B20_RVS-thermosensor
  (met nauwkeurigheid van +0,5 °C) gemonteerd in/aan een PVC-buis van 32mm en ingegraven aan de zijkant van de tuin,
  gericht op gelijktijdige temperatuurmeting gestuurd door een ESP8266-processor op -10cm, -20cm, -50cm en -100cm volgens de KNMI-opzet.

  Groei van kleine(re) planten wordt sterk beïnvloed door vocht & temperatuur aan de oppervlakte.
  Gecombineerde T&H-meting op -5cm vlak onder het oppervlak geeft daarvoor de benodigde informatie.
  Een SHT1x T&H-sensor met gecombineerd Temperatuur en Humidity in beschermende capsule past mogelijk voor deze functie:
  type SHT15 past met + 0,3°C en +2% in nauwkeurigheid goed bij de 'bovengrondse' sensoren type SHT31 van WS7000P.
  De bovengenoemde ESP8266-processor bedient ook de T&H-meter SHT15, en verzorgt tevens uitlezing van de naastgelegen analoge Regen-/Bladvocht-indicator.

  Realisatie Experiment1

  1) Ondergrondse thermo-sensoren
  Het ondergrondse thermosensor-array is voor plaatsing gemonteerd & getest tegelijk met bijbehorende Regen-indicator, ESP8266 processor en zonne-voeding.
  Temperaturen van het array vóór de buitenplaatsing onderling afgeregeld in de software: andere sensoren nog niet verder opgelijnd.
  Na de winterpauze 2020~2021 bij de opleving van de zonnevoeding helaas wegblijven van de ondergrondse sensoren:
  lijkt te wijzen op (hardnekkige) problemen met de verbindingen, aldanniet met uitval van de sensoren onder invloed van vocht.
  Soms adhoc 'opleven' van de sensoren misschien tekenen dat de sensoren zelf nog bruikbaar zijn (voor onkritische toepassingen en experimenten).
  Ingrijpende aanpak nodig voor herstel => herbouw van het array met nieuwe sensoren, incl. herordening van de sensoren => Experiment2
  

  2) Voeding
  Eerste/ Basic zonnevoeding = zonnecel zonder accu => het pakket van ESP8266+sensoren alleen in actie bij voldoende zon (in de praktijk >20kLux).
  Als de Bodemmeet-ESP8266 niet werkt, dan worden in Domoticz defaultwaarden (of 'laatste waarden') gebruikt voor testen van scripts en grafieken.
  Tweede/ Vervolgversie zonnevoeding is een uitbreiding volgens een 'geleende' opzet met accu-circuit voor overbrugging in zwak licht & duisternis.
  Krachtiger uitgevoerd met 2 paneeltjes die parallel het circuit voeden,
  maar in de praktijk nog steeds (te) zon-afhankelijk gebleken en ruim onvoldoende om jaarrond 24/7-voeding te geven,
  vermoedelijk mede ook vanwege de aanhang van 6 sensoren.
  Gezien het trage verloop van veranderingen ondergronds lijkt 4 à 6 metingen per uur al genoeg.
  De Bodemmeet-ESP8266 tussentijds in 'slaap-mode' zetten spaart sterk op verbruik uit de accu.
  Derde/ Vervolgversie zonnevoeding daarom met de Bodemmeet-ESP8266 ingesteld met slaap-functie op 4 metingen/uur.
  Vierde/ [Eind?]configuratie heeft via kabel een koppeling met een 230V-voeding voor periodieke aanvulling,
  via parallel-input naast de zonnecellen, want zonnevoeding blijkt onvoldoende (zeker in tijden met weinig zon zoals in de winter).
  De zonnevoeding-met-accu dient in deze opzet als 'UPS'.
  Een DCDC_Booster aan de uitgang van de zonnevoeding houdt de voedingspanning voor de Bodemmeet-ESP8266 continu op 5VDC, waardoor de setup beter functioneert.
  De 'slaap-mode' van de Bodemmeet-ESP8266 is niet meer echt nodig, maar het helpt wel langer te doen met een accu-lading.
  

  3) Oppervlakte-sensor
  In de kruipruimte is een ingekapselde SHT11-sensor toegepast aan een ESP8266: lijkt ook in de tuin passend als gecombineerde T&H-sensor op -5cm.
  Bij de kruipruimte-metingen is duidelijk verdrinkingsrisico gebleken bij ondergronds plaatsen van zulke T&H-sensors,
  ook als ze ingekapseld zijn en zelfs vrijliggend boven de toplaag.
  In afwaterende tuingrond is misschien dat risico iets anders dan in een kruipruimte, maar ook aanwezig gebleken => R.V.-sensordeel defect.
  => Uitzoekwerk voor een behuizing & opstelling die goed bodemcontact geeft, overstroming voorkomt en eventueel een geforceerde droging eenvoudig toestaat.
  Niet gelukt, en daarom alternatief deze sensor in recycling toepassen voor bovengrondse meting => Experiment2.

  4) Samenbouw
  Voorlopig proberen met de hieronder getoonde 'knutsel'-opbouw met spullen uit de rommelbak pal naast & aan de bodemthermometers.
  
  
  
  
  
  
  

  Zichtbare delen van de eerste bodemsensor-configuratie
  • T&H-sensor op -5cm
    Met 2 plantpotjes met spatie in elkaar houden we ondergronds op de gewenste diepte de ingekapselde kop van sensor SHT15 vrij van direct contact met grond
    • sensor SHT15 steekt door de onderkant van bovenste plantpot1
    • plantpot1 rust met 3 kurken als afstandhouders in een plantpot2 => vloeistofvrij 'kamertje' voor de sensor
      (B)lijkt onvoldoende, want midden september 2020 gaat de R.V.-sectie van de SHT15 in storing met kenmerken die lijken te wijzen op 'verdrinking'.
    • de gaten in de bodems van de 2 plantpotten zorgen voor doorstroming van temperatuur en vocht uit de ondergrondse omgeving,
      maar tevens goede afscherming en drainage tegen overvloedig vocht
    • plantpot1 gevuld met grond, gestapeld op plantpot2 => sensor op diepte met 'correcte' grondafscherming boven de sensor
    • bovengronds extra, omgekeerd plantbakje tegen doorslaande regen (of tegen sproeiwater).
      Blijkt geen succes (want dekt de grond te veel af) en daarom verwijderd en vervangen door een plantpot nauwsluitend om de 'kop'.
  • Ombouw & bescherming
    Eerste, losse, omhullende buitenafscherming voor de kabelaansluiting tegen zon & neerslag door een omgekeerde plantpot over het thermo-array en over de samenbouw voor sensor SHT15
  • een extra, luchtige afscherming door een omgekeerde, grotere vijverplantenbak, die zon weghoudt, maar goed geleidelijk lucht, wind en neerslag doorlaat.
    Denkfout [dus die kap verwijderd], want 'Soil'-metingen moet worden gedaan met de oppervlakte zoveel mogelijk blootgesteld aan alle elementen, dus zonder 'Zonnekap' en zo krap mogelijk
  • de opstelling staat binnen bereik van de tuinsproeiers.
    Ongewenst dat sproeien de bodem-metingen gaat verstoren, en daarom wordt dan improviserend/tijdelijk een ruime plantkuip over het geheel gezet.

  5) Regen-/Bladvocht-indicator
  De originele, analoge regendetector werkte met de interne ADC van de eerdergenoemde ESP8266 niet vanwege een script-aspect m.b.t. de 'Slaap-mode'.
  Uit experimenten blijkt ook dat de aangesloten regen-/bladvochtsensor meehelpt dat de zonnevoeding snel leegloopt:
  de originele regen-/bladvochtsensor is daarom verplaatst naar een andere ESP8266 elders met continue voeding uit het 230V-grid.
  Bij die andere ESP8266 ook met continue uitlezing met de interne ADC, want het is denkfout om met periodieke uitlezing sprongen in neerslag sneller te vangen dan met een regenmeter.
  Toepassing van de interne ADC blijft nodig om voldoende resolutie te krijgen.
  De eerste regen-indicator werkte met een gelijkspanning op het detectorraster voor weerstandmeting.
  Dat veroorzaakt stevige corrosie door electrolyse, en het raster wordt 'weggevreten'.
  In de nieuwe opstelling elders wordt een PWM-signaal toegepast voor aansturing van het detectorraster:
  rasterhelft1 als PWM-zender en rasterhelft2 als PWM-ontvanger.
  Toepassing van PWM = wisselspanning geeft geen of veel minder electrolyse in het detectorraster.
  Functioneel nog steeds een weerstandsmeting.
  De ESP8266 zorgt voor PWM-generatie (= 1kHz-blokgolf van 3V amplitude) en voor uitlezing met de interne ADC:
  de hulpschakeling zorgt voor de interface tussen ESP8266 en detectorraster.
  Werking van PWM als medium is inmiddels empirisch positief aangetoond.
  De lage uitgangspanning van de hulpschakeling met 1 diode geeft echter meer de karakteristiek van een stortbui-detector.
  Ook een ongewisheid door het vocht, onregelmatig verzamelend & afvloeiend over het detectorraster.
  Plaatsen van een audioversterker in de ontvangketen geeft niet veel verbetering:
  veel effectiever blijkt toevoegen van een 2e diode voor betere gelijkrichting van het inkomende signaal.
  Voordeel van deze PWM-uitvoering is dat geen elektronica in de buitenlucht nodig is.
  Eerste inschaling is faktor 0,1* aan sensorkant.
  De meetwaarden worden daarmee ruw vertaald naar een schaal lopend van 0% (= gortdroog) naar 100% (=kletsnat):
  tabelwaarde heeft label Regen-niveau / Rain-Wetness.

  6) Waterpeiling
  Grondwaterpeiling is nu handmatig met 2 peilbuizen van 40mm diam (met lengte van ca. 1,5m) voor periodiek een ruwe meting tot ca. -1,4m met een peilstok.
  Er wordt een 2-tal concepten uitgewerkt dat (al dan niet gecombineerd) tot ca. -3m automatisch, electronisch, periodiek op afstand kan meten:
  nu de configuratie uitwerken, mitsen-en-maren bepalen en de mogelijke prestaties!
  Daarna realisatie.

  Experiment2

  Vervanging Thermo-sensoren
  Na de 'sensor-verdrinking' in Experiment1 is het sensor-array herbouwd voor 6 thermosensoren en 1 vochtsensor:

  • het 1e deel met thermosensoren op -10cm, -20cm en -30cm is een PVC-buis met schuine zijtakken waarin de sensoren min of meer vast gemonteerd zijn in de afsluitkappen van de zijtakken.
    Op -30cm zit nu extra de 2e ondergrondse thermosensor volgens de opzet van MetOfficeUK.
    Alle afsluitkappen zijn geperforeerd i.v.m. drainage.
  • onderaan de genoemde PVC-buis zit op -50cm in de geperforeerde afsluitkap een vochtvorksensor (waar voordien een thermosensor zat)
  • het 2e deel met lagere sensor heeft een PVC-buis tot -0,5m, waarin aan zijn kabel een 'diepe' sensor als kop wordt neergelaten,
    zodat bij eventuele technische problemen deze sensor als los deel eenvoudig kan worden opgetrokken voor reparatie/vervanging.
    Deze buis aan de kop afgesloten met gaas tegen indringen van zand, terwijl wel eventueel water in en uit kan stromen.
  • het 3e deel met de laagste sensor heeft een PVC-buis tot -1m, waarin een dunnere PVC-buis met de 'diepe' sensor als kop wordt neergelaten,
    zodat bij eventuele technische problemen de lage sensor als los deel eenvoudig kan worden opgetrokken voor reparatie/vervanging.
    Ook deze buis aan de kop transparant afgesloten met gaas.
  • het array heeft ook aansluiting voor een extra, losse thermo-sensor, nu in gebruik genomen voor temperatuurmeting in de bodemtoplaag,
    gedacht als eventuele vervanger/aanvuller voor het temperatuurdeel van de SHT15.
    Als bescherming tegen bovengrondse zoninstraling en neerslag zit deze thermosensor onderin de behuizing van de SHT15.
  • de junction box van het array heeft voor eenvoudige (ont)koppeling connectors voor de ESP8266-interface, de lage sensoren en de extra sensor.
  • extra aandacht voor bescherming van de sensoren tegen vochtindringen en voor afvoer van ingedrongen vocht door afplakken en dichtkitten,
    en door betere 'overkapping' tegen neerslag, met aandacht voor ventilatie, zodat tenminste de bovengrondse delen droger blijven.
    De kap over het sensor-array staat links op het plaatje met de 2 sensorhutjes.

  Aangepast gebruik van de SHT15 T&H-sensor
  Door de vochtproblemen is de ingekapselde SHT15 gediskwalificeerd als T&H-sensor-in-de-grond.
  Recycling wordt geprobeerd in de rol van extra, lokale bovengrondse sensor op ca. +5cm à +10cm hoogte, gemonteerd in een sensorhutje.
  Het sensorhutje bestaat uit een ventilatiekoker met voetstuk op de bodemtoplaag.
  Het voetstuk (= omgekeerd bloempotje) heeft een rij extra gaten om de rand voor luchttoevoer vanuit/over de bodemtoplaag:
  rechts in het plaatje met de 2 sensorhutjes.
  Temperatuurmeting is gebrekkig/onregelmatig: vochtmeting lijkt helemaal niet meer te 'reanimeren'.

  Vervanging van de SHT15 T&H-sensor als bodemsensor
  Alternatieve invulling van meting in de toplaag is een 'gesplitste' T&H-sensor.
  De extra Thermosensor DS18B20 hierboven genoemd is in de grond gestoken onder hetzelfde sensorhutje als de SHT15:
  geeft meting van de toplaagtemperatuur, wel blootgesteld aan de elementen, maar beschermd tegen directe neerslag.
  De vorkvoeler van de nieuwe Bodemvochtmeter zal direct naast het sensorhutje in de bodemtoplaag worden geplaatst als toplaagvochtvoeler.
  Deze Bodemvochtmeter is een variant van de PWM-Regen-/Bladvocht-indicator bovengenoemd onder 5): een vorkvoeler met 2 draadnagels in een keramiek kroonsteen, afgeschermd met een (deodorantroller)kapje tegen inregenen, want alleen grondvoelen gewenst.
  In eerste aanzet vertoning van de vochtmeetwaarde als % (evenredig verdeeld 0~100% over de schaalwaarden van gortdroog = 0 tot kletsnat = 1024).
  Voor vertoning als grondvochtwaarde is een vertaling nodig van de meetwaarden naar een schaal lopend tussen 0 cbar (= volledig nat) en 200 cbar (= gortdroog).
  Die niet-lineaire vertaling wordt een interessante uitdaging, gezien de achtergronden.
  De meetwaarde van deze bodemvochtsensor staat als vochtwaarde bij de thermosensor DS18B20-Y.

  Sneller & eenvoudiger is toepassing van bijv. WH51-Vochtsensor plus WN34-Temperatuursensor:
  die sensoren zijn gericht ontworpen voor de functie van metingen in de grond via een penvoeler.
  Een WH51-vochtsensor is onder test, met uitlezing door een GW1000_Gateway:
  die GW1000-uitlezing is (nog) niet gekoppeld aan het Systeem.

  Vervangende Regen-/Bladvochtsensor
  De vervangende Regen-/Bladvochtsensor in deze setup werkt capacitief en via een interface-board PCF8591, zonder last van de script-aspecten t.a.v. de interne ADC.
  Die capacitieve vochtmeter [bedoeld voor bodemvochtmeting] komt op de plaats van de analoge regen-indicator:
  conceptueel beter geschikt in richting van dauw-sensor annex bladvochtmeter [zie de ESP8266-lijst]
  Anders dan bij de PWM-sensoren hier zorg/bescherming nodig voor de electronica op de vorksensor.
  Tevens met het interface-board ruwe meting van licht en omgevingstemperatuur als monitorfunctie voor de elektronicabox.
  Mindere resolutie (8-bits vs 10-bits) is acceptabel voor deze 'hulp-functies'. In eerste aanzet vertoning van de meetwaarde als %, met ruwe inschaling van meetwaarden 0~256 opgelijnd met de andere vochtsensoren volgens formule (meetwaarde - 100)*2
  Tabelwaarde heeft label Bladvocht / Leaf-Wetness.

  Waterpeiling-in-wording
  De huidige Grondwaterpeiling is met 2 peilbuizen PVC40mm van ca. 1,5m lengte voor periodiek een ruwe, handmatige meting tot ca. -1,4m met een peilstok.
  Is primitieve layout met simpele, stoffen afsluiting van het onderste pijpeind, zodat wel water kan opwellen, maar geen zand kan binnenkomen.
  Gezien de (slechte) ervaring met de ondergrondse electronische temperatuursensoren, bij voorbaat in de nieuwe opzet ook een mogelijkheid voorzien om handmatig waterpeil te blijven meten met peilstok of (beter) met dompelklokje..
  Als verbetering worden de 2 huidige handpeilbuizen vervangen door 2 nieuwe handpeilbuizen (PVC32mm) verlengd/verdiept tot ca. -3m en voorzien van een verbeterde filterkop voor (snellere & nauwkeuriger) meting met dompelklokje.
  Dezelfde opbouw is van toepassing voor de 2 peilbuizen die de sensoren bedienen.
  De plaatjes laten de gerealiseerde opbouw zien.

  # Filteropbouw:
  - iedere pijp aan ondereind afgesloten met kap met een miniem gaatje voor aanvoer/afvoer van vocht
  - onderste 10cm van de pijp doet niet mee in de meting en dient voor opvang/neerslag van eventueel inkomend zand/grond
  - boven 10cm vanaf het onderste eind over een lengte van minimaal 50cm geperforeerd met gaatjes van 2m, zodat rondom goed water kan instromen
  - de onderste 1m en het eind van de pijp is omwikkeld met (synthetische) stof, zodat - in principe - wel water, maar geen zand/grond in de pijp kan komen
  [Bewust synthetische stof om chemisch verval te vertragen]
  # handpeilbuis1 komt op de positie van de huidige peilbuis terzijde van het huis bij de perceelgrens
  # handpeilbuis2 komt achter in het perceel (i.p.v. midden in het perceel).
  Zodra geplaatst, handpeilingen uitvoeren dagsynchroon met de opname door waterschap Vechtstromen op de 14e en 28e dag van de maand.
  Na start van deze handpeilingen een geleidelijke realisatie van 2 nieuwe, vergelijkbare peilbuizen tot ca. -2,5m resp. tot -3m om automatisch, electronisch, periodiek op afstand te gaan meten:
  # Grondwaterpeiler_A is een drukverschilmeter met drukmeters A en B.
  Deze 2 drukmeters geven ieder uitlezing van de absolute luchtdruk van hun omgeving:
  het rekenkundig verschil is maat voor de gemeten waterkolom.
  Deze peiler wordt opgesteld naast de electronische bodemthermometers, om gebruik te kunnen maken van gemeenschappelijke voeding draaiend op Zon en/of 230V.
  De externe behuizing voor deze Grondwaterpeiler_A is een PVC32mm-pijp van 2,5m lengte (= peilbuis3) vergelijkbaar met de eerdergenoemde handpeilbuizen1 en 2.
  In deze peilbuis3 wordt een PVC3/4"-pijp (= peilbuis3A) gehangen met een 'kop' waaraan/waarin de drukmeters zijn gemonteerd:
  - drukmeter A zit naast de 'kop' in aparte behuizing in de openlucht (als referentie) - drukmeter B zit in de 'kop' en meet de omstandigheden binnen peilbuis3A De 'kop' en peilbuis3A zijn geschroefd verbonden, luchtdicht t.o.v. de buitenlucht, terwijl de onderzijde van peilbuis3A open is.
  De 'kop' en peilbuis3A worden op druk gebracht totdat onderin lucht (hoorbaar) ontsnapt naar de omhullende PVC32mm-pijp
  => water uitgedreven uit de PVC3/4"-pijp:
  => luchtdruk in de peilbuis3A & 'kop' is nu representatief voor de waterkolom naast peilbuis3A => uitlezing drukmeter B.
  => verschil in drukuitlezing tussen drukmeter A en drukmeter B is daarmee maat voor de bovengenoemde waterkolom.
  => met kennis van de positie van de onderkant van peilbuis3A t.o.v. maaiveld is dan te bepalen wat het grondwaterpeil is.
  [Zolang de combinatie van peilbuis3A & 'Kop' nog niet gereed is i.c.m. met de uitlezing van de drukmeters, wordt deze PVC32mm-pijp peilbuis3 ook gebruikt voor handmatig peilen van het grondwater]
  # Grondwaterpeiler_B is een kolomdrukmeter.
  Deze peiler wordt opgesteld achter in het perceel direct naast de handpeilbuis2.
  De externe behuizing voor deze Grondwaterpeiler is een PVC40mm-pijp (= peilbuis4) van 3m lengte gelijk uitgevoerd als de 32mm peilbuizen.
  Onderin deze pijp ligt de druksonde, via kabel verbonden met de bovengrondse electronica.
  => de relatieve druk gemeten door de sonde is maat voor de waterkolom boven de sonde.
  => met kennis van de positie van de sonde t.o.v. maaiveld is dan te bepalen wat het grondwaterpeil is.
  Voor deze electronische Grondwaterpeilers is een vergelijkbare systeem-opzet gepland als voor de bodemthermometer met ESP8266+WiFi (of misschien met processor met LoRaWAN voor echt grote afstand?).
  Omdat zeker de waterpeiler van Gorndwaterpeiler_B op afstand zal staan van een net-aansluiting is daarvoor zonnevoeding zondermeer vereist, en
  (om eerdergenoemde perikelen met interne-ADC en 'Slaap-mode' te vermijden) accepteren van alleen uitlezing als de zonnevoeding voldoende is.
  Als optie/growth-potential een aparte ADC-aan-I2C toepassen, mede voor uitlezing met hogere resolutie.
  De electronische waterpeilers krijgen zeker aparte antenne's aan de ESP8266en voor betere WiFi-verbinding.

  Resultaten (doorlopend voor alle Experimenten)

  Temperatuurmeting
  Grafiek Bodem1 en Grafiek Bodem2 tonen de resultaten van de laatste 24uur voor de nu geldende configuratie.
  Grafiek1 met de absolute meetwaarden, Grafiek2 als tendens-indicator per diepte.
  Voordat plaatsing in de grond plaatsvond, zijn de sensoren onderling opgelijnd op kamertemperatuur:
  benodigde correcties ingevoerd in de sensor-ESP8266, zodat meetwaarden gelijklopen m.b.t. calibratie.
  Op locatie verder proefondervindelijk fijner naregelen t.a.v. plausibele volgorde van meetwaarden per diepte, en met bovengrondse temperaturen.
  Als de thermosensoren op +10cm t/m -100cm niet online zijn, dan wordt de laatst-gemeten waarde doorgetrokken als 'flatline'.
  Hieronder alternatieve vertoning van T&H-waarden per sensor in tekst-tabellen met dynamische invulling van de getallen:

  • voor Nexus@+20cm en voor WS7000@-10cm alleen temperatuur in de tabel, want de bijbehorende vochtsensoren zijn door hoogteverschil 'niet compatible' (=> 'n.c.')
  • Nexus@+20cm en WS7000@+10cm staan elders in de tuin op ca. 10m resp. 20m afstand van de andere sensoren, en lopen daarom vaak niet gelijk op.
  • X = SHT15, T-meting onder test; R.V. = 'Defect'.
  • Y = extra DS18B20, toont temperatuur, met vocht-aanduiding vanuit de Bodemvochtsensor met PWM-vorkvoeler aan 10bit-ADC.
    Vocht uitgedrukt als % van het ADC-bereik.
  • A t/m D + UK = DS18B20, toont temperatuur, vochtmeting 'niet-aanwezig' (dus R.V. = 'n.a.').
    C heeft als partner-Bodemvochtsensor een PWM-vorkvoeler aan 8bit-ADC.
    Vocht uitgedrukt als % van het ADC-bereik.
  • Regen-niveau / Rain-wetness = vocht-aanduiding met PWM-rastervoeler aan 10bit-ADC.
    Vocht uitgedrukt als % van het ADC-bereik.
  • Bladvocht / Leaf-wetness = capacitieve bodemvochtsensor als pen-voeler, alternatief toegepast als bladvochtsensor aan 8bit-ADC.
    Vocht uitgedrukt als % van het ADC-bereik.

  Regen-/Bladvocht-/Bodemvochtmeting
  De regen-meetwaarde van de verplaatste PWM-regenmeter is deel van Grafiek Bodem2.
  Vertoning in een grafiek voor de capacitieve regenmeter/ bladvocht-indicator en voor de PWM-bodemvochtmeter wordt nog verder uitgewerkt.

  Waterpeiling
  Grondwaterpeiling is totnutoe met 2 handpeilbuizen voor een adhoc/onregelmatige, ruwe meting tot ca. -1,4m met een peilstok.

  Status:

  • Experiment1 heeft aangetoond dat
    • ondergrondse thermosensoren beter vochtbestendig moeten worden gemonteerd
    • geen sensoren ondergronds te installeren die daarvoor niet zijn ontworpen [ze leven niet lang]
  • Experiment2 nu in uitvoering met stappen volgens navolgende 'Acties&Plannen'.
  Acties&Plannen:
  1. Afwerking van de nieuwe opstelling nog verder verbeteren:
  => waterdichtheids-aspecten - betere verpakking gerealiseerd -
  => SHT15 'recyclen' en opnieuw behuizen - nieuwe opstelling gerealiseerd, maar recyclen voor vochtmeting is mislukt, en temperatuurmeting is onstabiel -
  2. Voeding en/of ESP8266-script verbeteren voor continuiteit:
  => Bekabeling nalopen en corrigeren&verbeteren - gerealiseerd -
  => Uittesten met continu voeding via USB-aansluiting - gerealiseerd [waarbij originele zonnevoeding acteert als UPS] -
  => Daarna instellen van de timing van de periodieke 230V-bijvoeding en eventueel van de sleep-mode.
  3. Bodemmeetgegevens in Domoticz verder invoegen, oplijnen & uitwerken
  => Temperatuur- & Vochtwaarden beter integreren in de meteowebpagina [bijv. beter diagram met temperatuur als f(diepte)]
  4. Vochtsensoren integreren.
  4a. De vervangende capacitieve regen-/bladvocht-indicator is nu onder test.
  => Constructie checken op deugdelijkheid - gerealiseerd -
  => Proberen te kalibreren - ruwe 1e versie gerealiseerd -
  4b. De bodemvochtsensor benodigd als vervanging van het vocht-deel van de SHT15-sensor (en de 'diepe' sensor op -50cm),
  wordt een variant van de regen-indicator 'nieuwe opzet' met de ESP866 voor PWM en ADC:
  de sensor in de grond is hiervoor een eenvoudige DHZ-'vork'-sensor met poot1 als PWM-zender en poot2 als PWM-ontvanger.
  => Hulpschakeling bouwen - gerealiseerd -
  => Opstellen & aansluiten & testen - gerealiseerd -
  => Proberen te kalibreren - ruwe 1e versie gerealiseerd -
  => dupliceren voor bodemvochtmeting op -50cm - gerealiseerd -
  4c. Combi-grafiek maken, met actueel totaal-beeld van neerslag cq. vochtgehalte voor
  - Nexus Regenmeter
  - WS7000 Regenmeter
  - Tempest Regenmeter
  - PWM-Regensensor
  - Leafwetness-sensor
  - PWM-bodemvochtmeters
  - HW51-bodemvochtmeter
  Kan eenvoudig als uitgebreidere versie van de vergelijkingsgrafiek voor Tempest_PWS:
  reserve inbouwen voor meer sensoren.
  5. Grondwaterpeiler-concept verder uitwerken & realiseren:
  1. Peilbuizen voor handmatige meting met dompelklokje
     De gedachte opzet van de electronische peilers is beschreven in deze samenvatting:
     de schets daarbij toont de sensorpijpen van Opstelling_A [= vergelijkende drukmeting] en Opstelling_B [= kolomdrukmeting] samengevoegd in 1 gemeenschappelijke, omhullende pijp1.
     Grondwaterpeiler_B heeft een 40mm PVC-pijp nodig als behuizing i.v.m. de doorsnee van de druksonde, maar Grondwaterpeiler_A kan ook werken met een 32mm PVC-pijp als omhullende.
     Beschikbare voedingssoort op een locatie speelt een rol, zeker als ge-automatiseerde toevoer van perslucht gaat worden toegepast voor Grondwaterpeiler_A,
     want dat vereist een 230V-aansluiting voor de luchtpomp.
     De sensorenpakketten en hun electronica (incl. eigen ESP8266) zitten niet vast aan de omhullende peilbuizen en kunnen makkelijk worden opgenomen cq. ingezet voor controle, reparatie & vervanging.
     Grondwaterpeiler_A kan [met bijbehorende ESP8266] eventueel in handpeilbuis2 geplaatst worden onder voorwaarde van lokale persluchtvoorziening.

     Als lerend voorwerk en verbetering van de huidige peil-functies 3 peilbuizen opzetten voor opstelling met dompelklokje voor meting tot ca. -2,5m (of dieper).
     

     • a. De huidige handpeilbuis van PVC40mm aan de westelijke zijkant van de tuin wordt gelicht en omgebouwd voor toepassing als peilbuis4 voor Grondwaterpeiler_B
       - ombouw gerealiseerd -
       Nieuwe handpeilbuis 1 is een stand-alone PVC32mm-pijp op zelfde locatie:
       alleen vervanging nodig door een langere 32mm PVC-pijp in een dieper boorgat, en met nette filterbekleding en afsluiting.
       - samengesteld, nog plaatsen -
       
     • b. De huidige handpeilbuis van PVC40mm midden in de tuin wordt gelicht en hergebruikt als deel van peilbuis4 voor Grondwaterpeiler_B.
       Geen vervanging op die positie. - ombouw geraaliseerd -
     • c. Handpeilbuis2 van PVC32mm komt extra (zuidelijk) achter in de tuin op de locatie van Grondwaterpeiler_B [= kolomdrukmeting] als referentie voor Grondwaterpeiler_B.
       - samengesteld, nog plaatsen -
       
     • d. Peilbuis3 van PVC32mm komt op de locatie van Grondwaterpeiler_A [= verschildrukmeting], eerst als referentie, daarna als behuizing voor peilbuis3A.
       - samengesteld, nog plaatsen -
       
  2. Grondwaterpeiler_A voor geautomatiseerde meting [= vergelijkende drukmeting]
     
     Deze opstelling vraagt een locatie waar een vorm van druklucht beschikbaar is,
     want periodiek moet de sensorprobe watervrij gemaakt wordt door uitblazen.
     Drukluchtvoorziening daarvoor eerst provisorisch regelen (fietspomp?), alleen voor/op de meetmomenten):
     daarna misschien bijv. een aquariumpomp voor continu of periodiek druklucht-voorziening.
     Bij afregelen/controleren op locatie leveren de handpeilbuizen 1 en 2 de vergelijkingswaarden m.b.v. handmatige dompelklokmeting.
     • e. De sensorpeilbuis3 voor Grondwaterpeiler_A (= 32mm PVC-pijp van 2,5m lengte) wordt gelijk met handpeilbuizen 1 en 2 geplaatst, maar pas voorzien van de sensorprobe (= peilbuis3A) met instrumenten na afregelen daarvan in de hulpopstelling.
     • f. De sensorprobe van Grondwaterpeiler_A is een 3/4" PVC-pijp met een luchtdichte 'kop' met daarin een electronische druksensor.
       Via de 'kop' kan de sensorprobe watervrij worden geblazen, en via een connector worden luchtdicht aangesloten op de meetopstelling.
     • g. Als hulpopstelling voor controle/afregeling van beide Grondwaterpeilers dient de vijver
       Calibratie van de te testen sensoren in de hulpopstelling door
       • defaultcheck van sensorprobe+ESP8266 in de open lucht = kijken of er een verschildruk optreedt tussen drukmeter A en drukmeter B, en welke [noteren]
       • de sensorprobe gecontroleerd in de vijver laten zakken, waarbij continu luchttoevoer zodat de sensorprobe watervrij blijft
       • afzinkdiepte en druk aflezen voor drukmeters A en B [noteren]
       • => correlatie-tabel van diepte vs meetwaarde
  3. Grondwaterpeiler_B voor geautomatiseerde meting [= kolomdrukmeting]
     
     Deze Grondwaterpeiler_B is de voorkeurs-configuratie voor een stand-alone toepassing op afstand, dus ook met zonnevoeding.
     Afronding van realisatie nadat Grondwaterpeiler_A enige tijd draait.
     Bij afregelen/controleren op locatie levert de naastliggende handpeilbuis2 de vergelijkingswaarde m.b.v. handmatige dompelklokmeting.
     • h. Sensorpeilbuis4 voor Grondwaterpeiler_B is een PVC-pijp van 40mm om de druksensor makkelijk te kunnen neerlaten en ophalen.
       Te plaatsen gelijk met de andere 3 peilbuizen- samengesteld, nog plaatsen -
     • i. De electronica en dataverwerking voor Grondwaterpeiler_B wordt uitgewerkt en gerealiseerd op basis van testen en ervaringen met Grondwaterpeiler_A.
       

  

Meteo-sensoren op afstand vergroten met WiFi & LoRaWAN het beeld op het weer.
Soms geen luxe, maar noodzaak, omdat het r.f.-communicatiesysteem van de 2 huidige PWSen en ook van Domoticz beperkingen heeft:

- Richt-antenne's helpen voor selectiviteit en reikwijdte in een bepaalde richting.
- Repeaters helpen wel om de reikwijdte te verbeteren door een positie aan de rand van het bereik van het hoofd-toegangspunt, maar betekenen tegelijk principieel ook een halvering per repeater van de netwerk-capaciteit.
- Extra Toegangspunt-aan-kabel is nog de beste maatregel, omdat de kabel-verbinding niet veel capaciteit claimt van het LAN, terwijl het extra toegangspunt onbelemmerd kan werken.
• reikwijdte van 433MHz-verbindingen is beperkt tot hoogstens 100m rond het toegangspunt.
  Voor 433MHz-communicatie zou je richt-antennes, repeaters of toegangspunten-aan-kabel kunnen toepassen om in bepaalde richtingen selectiviteit en vergroot bereik te verkrijgen voor een teogangspunt.
  Echter, deze stadsomgeving is al dermate vergeven van 433MHz-toepassers (vooral KaKu's) dat bij voorbaat nut van welke maatregel dan ook heel beperkt is.
  
• Toepassing van 868MHz is alleen beter i.v.m. (voorlopig) minder onderlinge storing van toegangspunten en clients, ook omdat er (nog) minder 868MHz-toepassers zijn.
  Richtantenne's wel beschikbaar, maar repeaters en toegangspunten aan kabel zijn niet zo gebruikelijk in dit frequentiegebied.
• reikwijdte van WiFi-verbindingen is beperkt tot hoogstens 100m rondom het toegangspunt.
  Voor verbetering van WiFi-verbindingen kun je gebruik maken van richtantenne's, repeaters of van toegangspunten naar buiten verzet door een kabel-aansluiting.
  Alleen beter t.o.v. de 433MHz en 868MHz door de golflengte, maar in stadsomgeving is de hoeveelheid WiFi-toepassers enorm, dus praktisch nut heel beperkt.
• demping tussen draadloze sensoren en basisstation door beplanting, terrein of obstakels
  => voor alle frequenties tamelijk onvoorspelbaar geen constante, soms slechte of soms helemaal geen data-overdracht.
• alleen een kabelverbinding naar een 'buitenpost' is wel robuust, maar over grotere afstand niet handig cq. moeizaam en ook stoorgevoelig
• LoRaWAN biedt een mogelijkheid om sensoren draadloos over grotere afstand te verbinden (tot meerdere km's!), weliswaar tegen inleveren van capaciteit.
  Het experiment begint met verbinding maken met een dichtstbijzijnd LoRa-netwerk.
  Uitdaging om daarna een LoRa-configuratie met sensoren te ontwikkelen, die via het LoRa-netwerk functioneel aansluit bij het huidige Meteo-Systeem.

Status:
1. Eerste experiment met MARVIN & KPN gestopt i.v.m. aflopen abonnement
Acties&Plannen:
2. Wachtend op oplossing voor een TTN-verbinding voor de Marvin-Node (o.i.d.)
3. Info verzamelen & experimenteren

---

Behuizingen van sensoren zijn een aspect dat ook aandacht vraagt.
Zeker bij zelfbouw moeten de componenten netjes worden opgeborgen op een manier dat ze, én goed kunnen functioneren, én niet worden blootgesteld aan eventuele schadelijke invloeden van het weer e.d.
Dat heeft een hoog 'experimenteel' gehalte vanwege de componenten die moeten worden opgeborgen.
In de loop van de tijd daarvoor een reeks behuizingen uitgevonden en gerealiseerd.

Status:
Grote delen afgerond
Acties&Plannen:
Steeds doorgroeiend a.h.v. opkomende behoeftes o.a. door uitbreidingen en door ervaringen

---

Vervanging van WS7000-sensoren is een aspect dat uit leeftijd van mijn WS7000-PWS volgt.
Het WS7000-PWS is in bedrijf sinds 2001: sinds 2003 op de huidige locatie.
Blootgesteld aan de elementen slijten zeker sensoren in de buitenlucht:
de 2 sensoren type WS7000/25, de anemometer WS7000/15 en de neerslagmeter WS7000/16.
Voor de laatste 2 componenten is helaas regelmatig onderhoud de enige optie, of vervangen als nog een 2e-hands exemplaar kan worden gevonden.
Bij de windmeter is zo'n vervanging al een keer gebeurd: de oude windmeter nu achter de hand voor reservedelen.
Sinds ca. 2011 worden de 2 T/H-meters type WS7000/25 beschermd door een extra behuizing, maar de componenten hebben toch te lijden van zon & vocht & temperatuur.
De originele thermosensor is een 10k NTC-weerstand die eenvoudig vervangbaar is (en dat is na breuk door verroesten al een keer gedaan), maar voor de originele hygro-sensor is geen direct compatibele vervanger te vinden.
Met dit voor ogen wordt nu deelgenomen in een opzet voor een zonnecelgevoed cluster verder genoemd WS7000P.
WS7000P voorziet in deze setup gecombineerd in:
- 2*T/H-meter,
- 1*Lichtmeter,
- een gemeenschappelijke Controller,
aan de PWS-kant compatibel met het WS2500-PWS en met het WS7000-PWS.

Anders dan de stand-alone sensoren van de WS7000-configuratie clustert de Controller de genoemde sensoren en emuleert de communicatie van 3 WS7000-sensoren, alsof
2*T/H-meter type WS7000/25 (maar met intern een T/H-sensor type SHT31)
+ 1*Lichtmeter type WS7000/19 (maar met intern een Lichtsensor type MAX44009/GY49 + I2C-converter voor aanpassing aan de Controller).
[Met de I2C-Converter zou de MAX44009-sensor netter moeten aansluiten op de 5Volt I2C-bus van de Controller, maar de voedingsspanning uit de Controller lijkt niet altijd stabiel genoeg om de I2C-converter goed te laten functioneren]

De 2 T/H-sensoren van het nieuwe cluster vervangen de 'bejaarde', originele 2*WS7000/25 met betere nauwkeurigheid dan alle huidige T/H-meters in de PWSen:
SHT31 heeft + 0,3°C voor Temperatuur en +2% voor R.V., tegen WS7000/25 met +1°C resp. +8% en tegen TFA_Nexus met +1°C resp. +5%
De Lichtsensor is met zijn functionele benadering van het menselijk zicht en met zijn technische bereik van 188kLux en 22bits resolutie een welkome aanvulling op het sensorpakket,
met een vertaalslag in Domoticz passend bij de WS7000-PWS en bij de TFA_Nexus-PWS.

De nieuwe setup is zo ver mogelijk van de bebouwing achter in de tuin aan een pergola gemonteerd om bebouwingsinvloed te beperken.
De nieuwe lichtsensor en de zongevoede Controller zijn bovenop die pergola gemonteerd om onbeperkt zoveel mogelijk licht te kunnen vangen.

De nieuwe T&H-sensoren zijn lager aan een paal van die pergola geplaatst in Davis-sensorhutten, op een redelijk vrije, meestal beschaduwde plaats,
op een hoogte van +1,5m resp. +0,1m, voor T&H-meting op 'standaardhoogte' respectievelijk 'gras-/klomphoogte'.
Versie/Setup1 met Head1 (= gescheiden lichtsensor en Controller, met de lichtsensor onder 45 graden elevatie onder filterkap) had last van onduidelijke storingen, vermoedelijk in de bekabeling.
Versie/Setup2 met Head2 (= samengebouwde lichtsensor en Controller, met de lichtsensor onder 45 graden onder filterkap) heeft een korte kabel plus levelconverter voor aansluiting van de lichtsensor en tegelijk een connectorkoppeling voor de korte kabel tussen 'kop' en T&H-sensors, voor eenvoudiger installatie, test & onderhoud.
[De rode filterkap over de lichtsensor is in Versies 1 en 2 provisorisch i.v.m. software-afregeling, terwijl de glashuls extra bescherming geeft:
die extra, interne glashuls blijkt echter ongewenste reflecties te geven, dus verwijderd voor Versie3]
Versie/Setup3 met Head3 (= samengebouwde lichtsensor en Controller, met de lichtsensor bovenin de glasbol gemonteerd als zenith-scanner) staat zover mogelijk van de beplanting die in Setup2 teveel schaduw gaf.
[De T&H-sensors blijven in de posities van Versie/Setup2 i.v.m. WAF; aansluiting met een verlengkabel-in-serie is nettere oplossing dan een 'ster' zoals in Versie/Setup1]
De originele 2*WS7000/25 leven verder - zolang het duurt - als redundante, backup T/H-sensoren binnen het WS7000_PWS,
voor gecontinueerde toepassing als Thermo-sensor op hun huidige positie, terwijl de R.V.-functie van deze oudere senoren wegens slechte kwaliteit z.s.m. wordt uitgeschakeld.
De WsWin@PC-instantiaties met PC-Interface WS7000/13 hebben geen interface voor de WS7000/19 Lichtmeter, en daarom zal via Domoticz en de wsmerge-functie de gemeten licht-info worden geïnjecteerd in WsWin@PC als quasi-temperatuur en/of quasi-vochtwaarde, dichter bij de waarheid dan de quasi-lichtsterkte die WsWin@PC nu afleidt uit de schijn-temperatuur van de omgebouwde WS7000-T/H-meter cq. de omgebouwde Nexus-T/H-meter.

De Controller van WS7000P heeft ook nog interface-mogelijkheid voor de WS7000-anemometer en voor de WS7000-neerslagmeter, maar daarvan wordt nu geen gebruik gemaakt:

• de huidige WS7000-anemometer en de WS7000-neerslagmeter en de huidige WsWin-interfaces en de Domoticz-interfaces voldoen nog prima,
• toepassing vraagt enerzijds ombouw van de interfaces van de anemometer resp. de neerslagmeter voor aanspassing aan de Controller,
• activeren van die interfaces in de Controller vraagt anderzijds aanpassing door de maker van de firmware van de Controller.
• met nieuwe firmware voor de anemometer-interface kan 'moderne' functionaliteit geleverd worden, maar dan geen compatibiliteit meer met WS7000/15,
  dus geen verbinding met de ontvangers van WS2500, WS7000 en Domoticz (hoewel voor Domoticz via RFLink mogelijk iets apart is te regelen).

Status:
1. Geïnstalleerd, geactiveerd, 2*T&H + 1*Licht operationeel.
2. 2*T&H-sensors PWS-WS7000P_25 zijn functioneel vervanger voor de 2 'oude' T&H-sensors 1 en 2 van type WS7000-25
[de 2 sensoren WS7000P_25 zijn nu de primaire T&H-sensoren van het WS7000-PWS]
3. Update uitgevoerd van firmware van de Controller t.b.v. Licht-sensor WS7000P_19,
maar mogelijk nog een update nodig i.v.m. ontdekte 'clamping' van het lichtniveau.
4. Update uitgevoerd aan de sensor-montage van opstelling met 45-graden elevatie naar een opstelling met zenith-scanning.
5. Lichtdata uit WS7000P_19 wordt nu via Domoticz doorgekoppeld naar WsWin_Nexus als vervanger voor de huidige lichtinvulling met een schijntemperatuur,
maar WsWin_Nexus koppelt die lichtwaarde (nog) niet door naar de uploads voor HWA, BNLWN en EWN.
6. Lichtdata uit WS7000P_19 nu ook deel van de directe Domoticz-upload op basis van Nexus-data naar PWSW, WUnderground en AWEKAS.
Acties&Plannen:
7. Eventueel voeding- en data-interface voor MAX44009 te verbeteren [na evalulatie/duurtest in het winterseizoen 2020 en gehele jaar 2021]
8. Pas na bewezen continue, goede werking van WS7000P_19 een verdere koppeling naar de Systeem-functies en naar andere uploads:
na evaluatie van jaar 2021 een clamping van het licht-niveau ontdekt in Domoticz op 65kLux, terwijl technisch 188kLux mogelijk moet zijn.
Te onderzoeken welke oorzaak en welke remedie:
een ruwe, tijdelijke oplossing kan bestaan uit een dempingskap over de sensor en vermenigvuldiging in Domoticz van de meetwaarde.

All Rights & Credits for WS7000(Plévenon): Christophe Hamon

---

Toevoegen van het Tempest_PWS is een aspect dat volgt uit de leeftijd van mijn WS7000-PWS, in combinatie met de beperkingen van het TFA_Nexus_PWS.
Een oplossende invulling is om een kompleet, modern PWS toe te voegen aan de configuratie:
na een tijdje validatie draaien de rollen om, en worden TFA_Nexus en WS7000 de aanvullende/ondersteunende PWSen (of verdwijnen).

De info van het Tempest_PWS gaat eerst vooral via de volgende externe weblinks:
- eigen Weatherflow-vertoningswebsite,
- een bijbehorende WU-link,
- een aan WU gekoppelde variant van het PWS-Dashboard.
Intern/lokaal is de Tempest-sensorhub via zijn UDP-berichten direct gekoppeld naar de WeeWX-software:
extern via deze weblink.
Directe koppeling met&vanuit Domoticz is de volgende stap van integratie:
eerste kleine stap daarvan is gelukt, zoals bijgaande tabel toont,
plus de upload naar AWEKAS_Stationsweb

Status:
1. Geïnstalleerd, geactiveerd, en testend via bovengenoemde weblinks.
2. Integratie met het 'Systeem'
= uitlezen van de UDP-berichten van de Tempest-hub en omzetten naar JSON-berichten en XML-file
= inlezen/toepassen in Domoticz van delen van de JSON-file van de Weatherflow-server (= indirect & remote, over 1 externe server)
=> koppelen vanuit Domoticz naar RRDTool voor grafieken.
=> experimenteel vergelijken van verschillende uitlezingen uit interesse naar de werking van de Weatherflow-server (en voor controle van gelijkloop met de andere sensoren).
Acties&Plannen:
3. Verder integreren met het 'Systeem':
3a. = omzetten van de lokaal gemaakte JSON-berichten en XML-file naar data voor grafieken en tabellen
=> verder uitwerken met Domoticz voor directe data-uitlezing incl. lokale calibratie
3b. = inlezen/toepassen in Domoticz van meer delen of van alles van de JSON-file van de Weatherflow-server (= indirect & remote, over 1 externe server)
=> koppelen vanuit Domoticz naar andere applicaties.

---

Neerslagmeters is voor experimenten een onderwerp dat volgt uit de plotselinge, zware sneeuwval (tot 20cm) in Februari 2021 en de stortbuien (van ca. 60mm/stuk) van juli 2021.
De elektronische neerslagmeters kunnen goed omgaan met neerslag in de vorm van 'rustige' regen, maar bij sneeuw of bij wolkbreuk lopen ze achter de feiten aan.
De oplossing is in beide gevallen een improvisatie die geheel offline hardware-uitwerking heeft:
de gerealiseerde meetmiddelen hebben alleen blijvende waarde voor een volgende, hevige sneeuwval, voor een dramatische overstroming of voor een wolkbreuk.

Sneeuwmeter
• Versie 0.0 is een rotanstok met isolatiebandjes als ruwe markering op hoogtes van 10cm, 20 cm en 30cm
  Neergezet op diverse plekken om het huis geeft dat vergelijkingsinformatie voor vlakke bedekking en voor sneeuwophopingen.
• Versie 0.1 is met viltstiftstrepen op de voetpaal van het vogelhuisje opvolgende cijfermarkering op 10cm, 20cm en 30cm, met tussenmarkering op 5cm, 15cm, 25cm en 35cm
• Versie 0.2 is een verbetering (voor uitlezen op afstand) met een plakker op de cijfermarkeringen op 10cm t/m 40cm
• Versie 0.3 heeft als weerbestendiger peilstok een gekleurde prikker per 5cm bij de viltstiftstrepen en bij de cijfermarkeringen.

Status:
1. Geïnstalleerd, en gebruikt.
2. Niet af, maar geen vervolg, want volgende toepassing zal zeldzaam zijn
3. Geen online integratie met het 'Systeem'
= adhoc handmatig inlezen/toepassen van Versie 0.3 is voldoende functionaliteit.
Acties&Plannen:
4. Een losstaande thermometer in de tuin wordt met markeerbandjes uitgerust als extra meetpaal Versie 0.0

Regenmeters
• De (groene) 'basis'-regenmeter in bekervorm heeft een gekalibreerde capaciteit voor 35mm, met voldoende reserve voor opvang van 45mm.
  Genoeg voor som-opvang van een reeks 'normale' buien.
• De (blanco) 'extended'-regenmeter in bekervorm heeft een gekalibreerde capaciteit voor 100mm=4inch
  Moet voldoende zijn om een reeks stortbuien op te vangen, als backup en 'overloop' voor de 'basis'-regenmeter.
• Monding van beide regenmeters zit op gelijke hoogte op een staaf, en vrijstaand, zodat de opvang gelijkloopt

Status:
1. Geïnstalleerd, en in gebruik.
2. Geen online integratie met het 'Systeem'
= adhoc handmatig inlezen/toepassen is voldoende functionaliteit.
Acties&Plannen:
3. Geen

---

Nog ruimte voor meer experimenten, want uitbreiding & verbetering blijft doorgaan .....

---

Sitemap/ Jumplist voor deze website, incl. links to english versions of pages

Copyright © 2013-2022 T4S
Samenvatting voor Rechten & Verantwoordelijkheden / Summary for Rights & Liabilities