Experimenten & Supplementen

Levels 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.
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 meteo-sites.

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.

Voor buitenstaanders geeft het een 'kijkje in de keuken tijdens voorbereiding, koken, maaltijd en vóór de afwas'.
Je ziet op deze pagina's voor een aantal (niet alle!) experimenten zowel de successen als de mislukkingen, met ook gaten in vertoning tijdens storingen & modificaties.
De webpagina's aangehangen aan deze rubriek zijn qua layout alleen maar een afsplitsing van deze webpagina om de omvang van de kern te beperken:
pas als de inhoud wordt overgeheveld naar de 'echte' website mag betere ordening & layout worden verwacht!

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:

Herverdeling van functies over processoren
Oplossing van Koude-voeten-problemen
Samenhang Lichtniveau en PV-productie
Energie-Info & Energie-voorziening [Verwachting & Realisatie]
Verbeterde/eigen grafische vertoning en Robuuste upload van Meteo-info naar HetWeerActueel
Meting Lucht-kwaliteit/ Fijnstof- & Gas-vervuiling
Oplijning & afregeling van beschikbare wind-info
Bodem-sensoren
Meteo-sensoren op afstand met WiFi & LoRa
Behuizingen van sensoren
Vervanging van WS7000-sensors
Toevoeging van Tempest_PWS

De niveau-indicator geeft per rubriek aan hoever iets is uitgewerkt:
- rood = opstartend/ starting
- half-groen = onderhanden/ in progress
- vol-groen = (bijna) gereed voor implementatie/ (almost) finished.

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.

Herverdeling van functies over processoren is nodig om te zorgen dat iedere processor ruim voldoende capaciteit heeft voor uitvoering van zijn functies, en voor een helderder structuur van functies per processor.
Te zwaar belasten cq. 'productie' mengen met Experimenten => crashes/vastlopers => data-verlies & werk & ergernis ......
Domoticz1 en Domoticz2 zijn de 'productie'-machines voor de essentiële functies.
Belading voor Domoticz1 (= Raspberry Type B met ethernet & 2*USB) vooral schakel-functies en Energie-regeling,
te reduceren naar interfacing van RS485-devices, van bekabelde sensoren en van communicatie via RFXCom.
Belading voor Domoticz2 (= Raspberry Type 3A+ met wlan & 1*USB) vooral (redundant) schakel-functies en daarnaast Meteo-rekenwerk,
te reduceren in de richting van afhandeling van de ESP8266en en communicatie via RFLink.
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 is een 3e Raspberry (Type 3B+ met wlan, ethernet & 4*USB) als Controller naast Domoticz1 en Domoticz2,
  vooral cq. steeds meer voor 'algemener' rekenwerk en voor ontlasting in de richting van Meteo, Licht & Energie.
  Domoticz3 is naast deze Support ook bedoeld voor software-experimenten op dezelfde netwerken als Domoticz1 en Domoticz2.
2. Domoticz4 = de 4e Raspberry (Type 3B+ met wlan, ethernet & 4*USB) is gericht op komende Meteo-functies, zoals een instantiatie van WeeWX die de beschikbare sensordata bundelt in 1 'beste' PWS.
  Die instantiatie van WeeWX wordt bewust gescheiden van Domoticz 1 t/m 3 om als 'onafhankelijk PWS' te kunnen werken: Redundantie!
  Domoticz4 bedient dan ook de bijbehorende uploads daaruit naar diverse organisaties.
3. Domoticz5 = 1e Raspberry_Zero_W => Annex voor uitlezing via I2C-interface van de licht/IR/UV-sensor type SI1145.
4. Domoticz6 = 2e Raspberry_Zero_W => Annex voor uitlezen via USB-interface van T&H-meterconsole HP3001 in het kader van de kruipruimte-metingen.
5. Domoticz7 = 3e Raspberry_Zero_W => wordt Annex voor verbeterd S0-uitlezen van kWh-meters in de meterkast, en daarom (voor S0PCM) met USB-Hub-addon.
  Domoticz7 wordt ook uitlezer voor de P1-interface van een 'slimme meter' => Domoticz7 in de meterkast.
6. Eventueel extra Raspberry_Zero_W(s) als Annex(en) voor vergelijkbare Experimenten/Toepassingen, als een ESP8266 daarin niet kan voorzien.
7. Alle Raspberries van RAMDisk te voorzien, zodat de schrijf-operaties naar de SD-kaarten worden beperkt => vermindering van wear & tear.
  De 'Productie'-Raspberries koppelen aan een NAS of USB-Drive voor nabije werkfiles & backupfiles.
8. 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.
9. De ESP8266en dienen als frontends voor Domoticz2 en Domoticz3 voor data-collectie en als actuators [= aansturing van relais en van PWM-uitgangen]
10. 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 en Domoticz2 en een aantal ESP8266en draaien 'productie' met gestabiliseerde configuraties en toepassingen.
2. De andere Raspberries en ESP8266en zijn in oprichtings-/experiment-/testfase, en volgen de beta-upgrades van Domoticz.
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'.
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 de 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 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 moeizaam.
'Interim'-oplossing is plaatsing aan de tuinkant van 2 ventilatorkastjes op ventilatieopeningen die dienen voor kruipruimteventilatie, en voeding over de muur naar de ventilatorkastjes vanaf een lichtpunt.
In de ventilatorkastjes een oude 12VDC-PC-ventilator.
De voeding van de ventilators wordt geschakeld met een KAKU door Domoticz, vanuit het meetsystem vergelijkend op basis van de T&H-metingen in de kruipruimte en in de buitenlucht.
Status:
1. Meetsysteem operationeel, maar op hoger niveau Onvoltooid i.v.m. uitblijven van een principieel goede probleemoplossing.
Acties&Plannen:
2. Opbouw van de 'Interim'-oplossing voor geforceerde kruipruimteventilatie.
2a. Bij goed resultaat de opbouw 'definitief' maken met een eigen processor.
3. Bij gelegenheid omwerken van dit onderwerp voor overdracht naar Supplementen [blijft Nederlands, want heeft alleen relatie met de Nederlandse manier van bouwen],
met een engelse samenvatting voor rubriek Supplements
4. 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. dempingseffecten.
  Vanaf 30 November 2020 zijn de UV-waarden uit het Tempest_PWS ingekoppeld.
- 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.
  Daarvoor de lichtwaarden uit het Tempest_PWS hier toe te voegen.
  Ook 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 (niet bij OpenUV, want 'Clearsky'-info), uitgedrukt in 'Octa' [0 = Helder > 8 = Zwaarbewolkt], geleverd door Ogimet.com
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.
  Dit thema speelt pas op termijn:
  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 het bovengenoemde dynamische prijsmodel, 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 robuuste 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 invulle, script-aanpassing en testen.
Met een template zoals PWSDashboard gaat dat laatste heel snel:
dit is een proefversie gebruikmakend van de upload naar WUnderground e.d. 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.
Voorlopig gekozen om RRDTool toe te passen voor het maken van grafieken voor vertoning op deze website.
2. Upload naar HetWeerActueel (en anderen)
De upload t.b.v. HetWeerActueel en de basis-upload naar WUnderground en naar AWEKAS komt nu (vanwege de beschikbare software) uit WsWin @ PC, en die uploads moeten continu 24/7 doorlopen.
Aan die laatste eis wordt niet voldaan door haperingen van de Windows-server.
Voor upload naar WUnderground en naar AWEKAS zijn inmiddels meervoudige alternatieven beschikbaar, maar nog niets voor upload naar HetWeerActueel. Best lijkt een upload-opzet met toepassing van de 2 Raspberries, liefst redundant.
Voor de aspecten 1b. en 2. begint de toepassing 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.
Status/ Acties&Plannen:
1a/1b. Doorgaand in ontwikkeling, in bewerking, en deels in Test
2. Upload naar HetWeerActueel is in ontwikkeling (uitzoekwerk)
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.
- 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 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.
Daarom bodemmeting gewenst voor kennen van de samenhangen.
Voor metingen buitenshuis vlak boven&onder het aardoppervlak heeft het Meteo-systeem in de basis
- een WS7000P T&H-meter met Temperatuur & Humidity gecombineerd op +10cm,
- een Nexus T&H-meter met Temperatuur op +20cm, maar Humidity op +120cm,
- een WS7000 T&H-meter met Temperatuur op -10cm en Humidity op +150cm.
- 'Buiten mededinging' nog een WS7000 T&H-meter met Temperatuur & Humidity gecombineerd, op de niet-standaardhoogte van +50cm,
Van beide WS7000 T&H-meters is de H-sensor gaandeweg slechter inzetbaar door ouderdomskwalen.
Alleen de WS7000P is dus 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 WS7000P T&H-meter 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
Meting op & in de bodem geeft zicht op de onderste luchtlaag, maar ook de mate van 'oppervlakkige' vochtbereikbaarheid voor zaaigoed en voor kleinere planten,
en hoe de 'diepere' vochttoevoer voor bomen en struiken kan zijn.
Het Meteo-Systeem miste daarvoor nog een aansluitende metingreeks aan & in de bodemlaag volgens het beeld van o.a. KNMI en MetOffice_UK.
Voor KNMI de 'gras-/klomp-hoogte'-sensoren op +10cm en ondergronds op -5cm, -10cm, -20cm, -50cm en -100cm t.o.v. de oppervlakte.
MetOffice vraagt een andere manier van meten met (naast de hoofdmeting op +1,25m) de andere bovengrondse sensoren voor 'concrete_minimum' vastgezet op een groot betonblok/-tegel en voor 'grass_minimum' op +35mm, met de ondergrondse sensoren op -10cm, -30cm en -100cm.
De door KNMI gewenste configuratie is het best te realiseren met moderne elektronische sensoren, schuin kijkend naar de manier waarop MetOffice de sensoren ondergronds plaatst.
De 'concrete_min'-sensor zou een eenvoudige toevoeging van de 'bodem'-opstelling zijn, maar zeker niet representatief,
omdat de betonnen terrastegels en padtegels in onze tuin veel te omsloten zijn door beplanting en bebouwing.
Anderzijds intrigerend hoe temp_'concrete_max' er uit ziet in de zomer.
Het grondwater-peil is daarnaast interessant gebleken o.a. in de discussies over neerslagtekort en over de natheid van onze natte kruipruimte.
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 de 'tikken' van de neerslagmeter
- bladvocht is soms nauwelijks neerslag, maa wel een aspect met invloed voor plantenteelt.
  Bijkomend aspect is dat bladvocht (door o.a. grondmist e.d.) een variatie kan hebben met de hoogte t.o.v. grondoppervlak, dus is een opstelling met identieke sensoren op meerdere hoogtes interessant?
  Een collectie sensoren gekoppeld aan ESP8266-processor(en) voorziet nu hierin:
  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.
  De bovengenoemde ESP8266-processor bedient ook de naastgelegen T&H-meter SHT15 op -5cm, en
  was gepland voor uitlezing met zijn ADC van een naastgelegen Regen-/ bladvocht-indicator: zie de beschrijving hieronder.
  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 voor deze functie:
  Type SHT15 uit de SHT1x-reeks past met + 0,3°C en +2% in nauwkeurigheid goed bij de 'bovengrondse' sensoren type SHT31 van WS7000P.
  
  Resultaten/ Info
  Grafiek Bodem1 en Grafiek Bodem2 tonen de resultaten van de laatste 24uur.
  Grafiek1 met absolute meetwaarden, Grafiek2 als tendens-indicator per diepte.
  Als de thermosensoren op +10cm t/m -100cm niet online zijn, dan worden de laatst-gemeten waarden getoond.
  
  Alternatieve vertoning van T&H-waarden per sensor in tekst-tabellen met dynamische invulling van de getallen:
  voor Nexus op +20cm en voor WS7000 op -10cm alleen temperatuur in de tabel, want de bijbehorende vochtsensoren zijn dus 'niet compatible'.
  Grondsoort:
  boven -100cm = los, 'zwart' zand (~ Twentse benaming van deze grondsoort)
  onder -100cm = keihard & gesloten, wit zand
  
  Voor grondwaterpeiling nu 2 peilbuizen voor periodiek een ruwe, handmatige 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 opzet uitwerken, mitsen-en-maren bepalen en de mogelijke prestaties!
  Status:
  1) Het ondergrondse thermosensor-array is gemonteerd & getest met bijbehorende Regen-indicator, ESP8266 processor en zonne-voeding.
  Temperaturen van het array vóór buitenplaatsing onderling afgeregeld in de software: andere sensoren nog niet verder opgelijnd.
  Eerste/ Basic versie 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 24/7-voeding te geven,
  vermoedelijk mede ook vanwege de aanhang van 6 sensoren.
  2) 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 zijn verbruik uit de accu.
  Derde/ Eind[?]configuratie daarom ingesteld op 4 metingen/uur met slaap-functie voor de Bodemmeet-ESP8266.
  Als dat niet voldoende blijkt (in tijden met minder zon), voor de aanhangende sensoren nog te bedenken hoe die een bijbehorende, sparende voeding kunnen krijgen.
  3) In de kruipruimte is een SHT11-sensor toegepast aan een ESP8266:
  zou ook hier passen als gecombineerde T&H-sensor op -5cm.
  Bij de kruipruimte-metingen is echter duidelijk verdrinkingsrisico gebleken bij ondergronds plaatsen van zulke T&H-sensors,
  ook als ze ingekapseld zijn en zelfs vrijliggend.
  In afwaterende tuingrond is misschien dat risico iets anders dan in een kruipruimte
  => Uitzoekwerk voor een behuizing & opstelling die goed bodemcontact geeft, overstroming voorkomt en eventueel een geforceerde droging eenvoudig toestaat.
  Voorlopig proberen met de hieronder getoonde 'knutsel'-opbouw met spullen uit de rommelbak pal naast & aan de bodemthermometers:
  - met 2 plantpotjes 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..
  - 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 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 blootgesteld aan alle elementen, dus zonder 'Zonnekap'
  - 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.
  De analoge regendetector werkt met de eerdergenoemde ESP8266 niet vanwege een script-aspect m.b.t. de 'Slaap-mode'.
  Uit experimenten blijkt ook dat de zonnevoeding met aangesloten regen-/bladvochtsensor gauw leegloopt:
  de regen-/bladvochtsensor wordt daarom verplaatst naar een ESP8266 met continue voeding uit het 230V-grid.
  De accu-oplading is echter op donkere dagen onvoldoende gebleken voor continue voeding van de overblijvende configuratie van 4*DS18B20+1*SHT15:
  iets te bedenken voor 'bijvoeding' in zo'n donkere periode, en/of sleep-mode instellen voor langere intervallen.
  4) Voor de Grondwaterpeilmeter is een vergelijkbare opzet gepland met ESP8266+WiFi (of misschien met processor met LoRaWAN voor echt grote afstand?).
  Zeker omdat die peiler op afstand zal staan van een net-aansluiting (=> zonvoeding zondermeer vereist) en omdat in deze toepassing de variaties nog trager verlopen:
  1 meting per 4 uur is frequent genoeg.
  Acties&Plannen:
  1. Voeding en/of script verbeteren voor continuiteit
  2. Bodemmeetgegevens verder oplijnen & uitwerken
  3. Bodemmeetgegevens beter integreren in de meteowebpagina [bijv. beter diagram met temperatuur als f(diepte)]
  4. Regen-/bladvocht-indicator verplaatsen en werkend maken op een andere ESP8266.
  De huidige regen-indicator werkt met een continue analoge spanning die daarmee corrosie door electrolyse veroorzaakt:
  in de nieuwe opstelling wordt een experiment uitgevoerd waarbij een PWM-signaal als aansturing wordt toegepast.
  Ook de opzet met een capacitieve vochtmeter uitwerken en realiseren [zie de ESP8266-lijst]
  5. Grondwaterpeiler-concept verder uitwerken & realisatie opzetten:
  - a. onderdelen verzamelen
  - b. samenbouwen van testsetup met alle pijpwerk, sensoren en ESP8266 [= eindversie, maar bovengronds, met gesloten deksel aan de onderkant]
  - c. testen 'op het droge' voor calibratie e.d. & eenvoudig aanpassen (indien nodig)
  - d. geschikte plaats in tuin zoeken (= voldoende uit zicht [i.v.m. WAF] & voldoende diepte met 'losse' grond & voldoende zon voor zonnevoeding)
  - e. boorgat tot -2,5m of - 3m maken
  - f. plaatsen van het geheel & installeren/activeren
  - g. koppelen aan Domoticz
  - h. koppelen aan website
  - i. koppelen aan LoRaWAN ?
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:
- 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/GY19 + 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 blijkt niet hog & 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 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 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 operationeel, en 1*Licht testend.
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.
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 duurtest in het winterseizoen]
8. Pas na bewezen continue, goede werking van WS7000P_19 een verdere koppeling naar de Systeem-functies en naar andere uploads.
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 komt voorlopig alleen uit externe bronnen:
- eigen Weatherflow-vertoningswebsite,
- een WU-link,
- een gekoppelde variant van het PWS-Dashboard.
Koppeling met&vanuit Domoticz is de volgende stap van integratie:
eerste kleine stap is gelukt, zoals bijgaande tabel toont,
plus de aanpassing van de upload naar AWEKAS_Stationsweb
Status:
1. Geïnstalleerd, geactiveerd, en testend.
2. Integratie met het 'Systeem'
= 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'
= inlezen/toepassen in Domoticz van de UDP-berichten uit de Weatherflow-sensorhub (= direct & lokaal)
= inlezen/toepassen in Domoticz van de volledige JSON-file van de Weatherflow-server (= indirect & remote, over 1 externe server)
=> koppelen vanuit Domoticz naar andere applicaties.

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

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