Sickel

Lurte på å bruke noen Shelly 1 Mini til å styre lys i uthus og denslags men lurer på noen ting: - Den har to tilkoblinger merket Live og Neutral. Dette er vel egentlig meningsløse betegnelser for oss som har IT-nett i huset, men har det noe å si for bruken? Jeg klarer ikke helt å se hvorfor det skulle ha noen betydning om hvordan fasen som kobles inn er i forhold til jord? - Jeg hadde tenkt å bruke dem blant annet for å styre noen utelys. De har nå en topolet bryter montert innendørs, vil det være lovlig / trygt å bruke en puck som bare bryter en fase? (Også søkte jeg litt her og kom over artikkelen her om LED-lys som står og smågløder når strømmen nominellt er av gjennom en Shelly puck, og siden alt det jeg har tenkt å styre er LEDlys lurer jeg på om dette er noen ide i det hele tatt...)

På jobben har vi en offgrid seismisk stasjon på Svalbard. Det kunne vært hensiktsmessig å ha værdata på stasjonen, ikke minst vindmåling da den primære strømforsyningen om vinteren er vindmølle. Stasjonen må da kunne tåle lav temperatur og kraftig vind. Jeg har null tro på en "propelltype" vindsensor i dette klimaet, så det må være ultralydssensor. Så langt tror jeg en ecowitt sensor kunne fungert, imidlertid, værstasjonen bør kunne strømforsynes utenifra og helst overføre data via kabel, her finner jeg ingen, før jeg kommer opp i Vaisala-stasjonene som er litt heftig priset for "kjekt å ha"-data... Er det noen som vet om en leverandør som har en god værstasjon med kablet tilkobling i prisklasse opp til ca 10000?

Hva slags lagringsløsning er det du har eller ser for deg å bruke? Ser du for deg å beholde alt til evig tid eller skal noe bort etterhvert? Jeg kjører postgresql med timescaledeb i min homeassitant og tar vare på alle data som er blitt lagret, det er noen ting jeg ikke gidder å lagre i utgangspunktet. Enn så lenge er det ikke noe problem med diskkapasitet eller søketid, sannsynligvis vil moores law sørge for at det holder seg slik. Jeg jobber mye med State of Healt data fra diverse systemer på jobben og har et tilsvarende system der.

Jeg har en Tibber pulse hvor jeg har hentet inn data til Home assistant via Tibber integrasjonen. For noen dager siden sluttet den å sende data til Home Assistant. Jeg ser ingen feilmeldinger eller noe, men ingen data. Pulsen fungerer, jeg ser oppdaterte forbruksdata i tibber appen. Noen andre som har samme problem eller helst noen tips til hvordan det kan rettes opp? Et godt alternativ er jo også å hente inn data lokalt, mener jeg har sett en slik mulighet, men har ikke hatt tid til å lete noe mer etter det etter at integrasjonen gikk ned.

Jeg har også tenkt på det. Har en del Shelly plugger jeg er superfornøyd med hjemme. Så kan jeg ha en temperaturmåler på et passende sted i rommet. Eneste fordelen jeg ser med en wifi / zigbee / zwave ovn er at da kan jeg styre termostaten i ovnen direkte.

VI bygger ut hytta og skal ha noen nye panelovner. Hva er det som er anbefalt nå om dagen? Jeg skal sette opp en home assistant instans på hytta og er fullstendig allergisk mot ting som må ha forbindelse med eksterne servere for å fungere. Jeg har vurert Namrons zigbee ovner, men de finnes ikke i den effekten og fargen jeg vil ha, jeg har også lest ting her om noe firmware kluss på dem. Så hva anbefales om dagen? Jeg skal ha noen ovner på ca 600W, hvite. Wifi er greit om det kan kjøres helt lokalt, ellers er zigbee eller zwave kurant.

Jeg la ut mitt script for import av metdata i en gist her: https://gist.github.com/sickel/18e9aee3d20e4151600ca385150f7cb6 , kobling til en gist med sql for å lage tabell. scriptet importerer bare øyeblikksdataene, ikke nedbør (og eventuelt andre) parametere som må måles over tid, kan være det kommer etterhvert.

Jeg bruker som sagt "cloud_area_fraction(...)" dataene og får oversikten jeg trenger med det. Da jeg satt opp det systemet for et par år siden tenkte jeg ikke over "fog_area_fraction", den er sikkert også av betydning. Siden jeg har samlet vær- og produksjonsdata over snart tre år, kunne jeg jo prøve å kjøre en multivariat analyse på dette og se om det kommer noe interessant ut av det.

Også kom jeg på nå, høye skyer er opp til 8 km over bakken. Hvis solen står lavt vil jo lyset gå gjennom høyt skydekke et helt annet sted enn der solcellepanelen er... Nå om dagen er maks solhøyde her hvor jeg bor snaut 30 grader, så det betyr at høye skyer av betydning for mine solceller er opp til over 14 km sør for meg når sola er på det høyeste og enda lengere unna før og etter det... Ved firetiden, når sola begynner å forsvinne bak mitt eget møne, er sola på 12 grader, tangens til 12 er 0.21, så avstanden til skyen foran sola er nesten fem ganger høyden til skyen... Jeg vet ikke hvor ofte dette har noen praktisk betydning for annet enn de høyeste skyene, men om man har solceller med fri sikt til soloppgang eller solnedgang kan det begynne å bli store avstander - igjen et datasett til man kan se om har noen betydning.

Og forresten, ved å ta vare på hele tidsserien, altså hva som er varslet for et gitt tidspunkt i varselet til en gitt tid, får man også en indikasjon på hvor godt varselet er. Det er selvfølgelig enklere å beregne været i en stabil situasjon enn i en mer kaotisk, dersom du samler mye data, kan du også sannsynligvis etterhvert si hvilke varsler som har mer sannsynlighet enn andre for å slå til der du bor.

Som jeg sa i innlegget mitt, om du har skygge på panelene på tider av døgnet vil høyt og tynt skydekke kunne gi mer produksjon. Jeg ser det veldig tydelig hjemme, har noen trær og et hus i sørøst, og produksjonen tidlig på dagen er klart høyere på dager med lett skydekke enn med klar himmel. (så min optimale dag for solproduksjon er lett, høyt skydekke tidlig på formiddagen og klart etter det) Men ellers, om du vil ha best mulige data, kan du jo bruke alle tilgjengelige. yr og storm baserer begge modellene sine på samme grunnmodell fra det europeiske værsenteret i Reading. Jeg vet ikke hvor de andre du nevner får data fra. Ved å bruke alle settene sammen gjør du i og for seg det samme som meteorologene gjør med å kjøre en ensemblemodell hvor man kan se både på snitt og spredning.

Jeg er ansvarlig for noen off-grid solcelledrevne systemer på jobben. Jeg bruker api.met.no. Jeg henter data for interessante steder en gang i timen med crontab: for eksempel for stasjonen vår på Jansonhaugen litt øst for Longyearbyen: 17 * * * * /usr/bin/curl -X GET -A '<epost>' --header 'Accept: application/xml' 'https://api.met.no/weatherapi/locationforecast/2.0/?altitude=70&lat=78.18&lon=16.38' > /var/www/html/weather/jansson.json 2> /dev/null (met vil at man ikke henter data for ofte. Med å gjøre det på denne måten får jeg relativt nye data og kan gjøre hva jeg vil av lesing internt, om jeg husker riktig oppdateres varselet hver 6 time) Så kjører jeg et importscript som dytter dataene inn i en postgresdatabase: wdb=# create table forecast( parameter varchar not null, value numeric not null, unit varchar, timestamp timestamp not null); wdb=# alter table forecast add primary key(parameter,timestamp); og dette pythonscriptet: import psycopg import urllib.request import json from datetime import datetime import time debug = True dateformat='%Y-%m-%dT%H:%M:%Sz'#"YYYY-MM-DDTHH:MM:SSZ" dbconn = "dbname=database user=user password=langtvanskeligpassord" url = "http://localhost/homelog2/weather.json" # url peker til en webadresse hvor filen jeg lastet ned med crontab er tilgjengelig CONN = psycopg.connect(dbconn) #,cursor_factory=psycopg.extras.DictCursor) CUR = CONN.cursor() # Workaround for timescaledb with compound primary key: INSERT = """ insert into forecast(parameter,value,unit,timestamp) values(%s,%s,%s,to_timestamp(%s)) on conflict (parameter,timestamp) DO UPDATE set value = EXCLUDED.value """ f=urllib.request.urlopen(url) metdata=json.loads(f.read()) updated = metdata['properties']['meta']['updated_at'] print(updated) updatetime = datetime.strptime(updated,dateformat) units = metdata['properties']['meta']['units'] datapoints = metdata['properties']['timeseries'] for cast in datapoints: forecasttime = datetime.strptime(cast['time'],dateformat) timedelta = (forecasttime - updatetime).seconds+(forecasttime - updatetime).days*24*3600 utime = int(time.mktime(forecasttime.timetuple())) forecast = cast['data']['instant']['details'] if debug: print(forecast) for parameter in forecast: CUR.execute(INSERT,[parameter,forecast[parameter],units[parameter],utime]) CONN.commit() Da setter jeg inn hele varselet. Med å bruke ON CONFLICT vi ekstisterende data for et bestemt parameter for et bestemt sted for en bestemt tid bli oppdatert med nye data. Det siste varselet for et gitt tidspunkt vil bli liggende i databasen. Det er jo ikke nødvendigvis riktig, men det er som regel rimelig greit. Da kan jeg lage plott som dette (Her har vi ni stasjoner med hver sitt separate solcellepanel innen ca 1km2, så jeg bruker samme værmelding på alle. De har derimot forskjellige solforhold) Jeg trikser med parameterene "cloud_area_fraction" og "cloud_area_fraction_%" for å få til de to skynivåene og himmel. Det kan også være viktig å se i hvilke lag skyene ligger med parameterene cloud_area_fraction[low/mid/high] Jeg har ikke laget noen produksjonsprediksjonsprosedyrer fra disse dataene, men med litt erfaring ser man umiddelbart hvilke dager som gir mye eller lite produksjon. Batteribanken på disse systemene er for liten for at de kan kjøre normalt over vinteren, men vi kan skru av en del helpesystemer og spare strøm. Denne oversikten har vært et veldig godt hjelpemiddel. I morgen, 15. mars, kommer det til å lade dårlig, 16 mars vil det lades bedre, men jeg vet at den stasjonen som står slik at den har mest morgensol får lite. Dom det er trær eller hus eller annet som kaster skygge på panelene, vil ofte et tynt og høyt skydekke gi øket produksjon, så det er ikke alltid så enkelt som at skyer minker produksjonen. Det er mulig at for en god prediksjon bør man også ta hensyn til regnvær, og ikke minst den store katastrofen, snøvær og snødekke. Met kommer jo også med et 21-dagers varsel nå. Her meldes det dag for dag om sannsynlighet for nedbør og sannsynlig temperaturspenn. Det er ikke gitt noe direkte skyvarsel her, men man kan utlede litt, høy sannsynlighet for nedbør er jo høy sannsynlighet for skyer, stort sannsynlig temperaturspenn betyr (i hvert fall for store deler av året her hvor jeg bor) liten sannsylighet for skyer.

Fikk installert solcelleanlegg i oktober i fjor, så siden det har det vært lite sol, til dels dårlig vær og tider med en halvmeter snø på panelene... Nå er det spennende å følge med på hvor mye som produseres. Growattinverteren sender enn så lenge data til skyen og growatts systemer gjør virkelig et solid arbeid for å hindre tilgang til egne data bortsett fra gjennom deres rimelig elendige webinterface. Så fant jeg ut at det går an å dele tilgang til inverter siden og fra denne delte siden kan man laste ned forbrukshistorikk. Så da tar jeg ca en gang i døgnet og laster ned siste døgns data og putter det inn i en postgresqldatabase og hente inn det jeg ønsker å se i grafana. Så fant jeg stadig at jeg drev og kikket fram og tilbake mellom dager for å se når på dagen det var produsert hvor mye (Jeg har paneler på to tak som står 90grader på hverandre og har noen hus og trær i sør, så det er ikke helt optimalt og en del variasjon gjennom dagen) Dataene jeg laster ned er på 5minutters intervaller, i databasen bruker jeg utvidelsen timescaledb, blant mange andre ting, gir den noen sql-utvidelser så jeg kan spørre etter data over et hvilket som helst tidsintervall, så select time_bucket('5 minutes',time) as timestep, max(ppv_total) from pv group by timestep order by timestep gir meg maksproduksjon for hvert femte minutt. Det jeg vil ha er maksproduksjonen som har skjedd hvert femte minutt for hver dag systemet har vært installert. Da kan jeg gjøre om tidssteppet til et klokkeslett uten dato: select time_bucket('5 minutes',time)::time as timestep, max(ppv_total) from pv group by timestep order by timestep Gir meg da det meste som har vært produsert kl 00:00, 00:05, 00:10 etc for alle dagene panelene har vært i drift. For å få dette på et vis som kan sammenliknes med dagens dato, legger jeg til midnatt i dag: select time_bucket('5 minutes',time)::time+now()::date as timestep, max(ppv_total) from pv group by timestep order by timestep For å få maksproduksjonen også plottet på gårsdagen kjører jeg querien en ekstra gang i grafana og setter relativ tid til 24 timer, eventuelt kunne jeg brukt en - interval '1 day' i spørringen. (Grønn linje, produksjon siste 48 timer, lyseblå linje, maksproduksjonen over hvert tidsintervall, den gulgråbakgrunnen er solhøyde, så i går produserte systemet mer fra ca 10 - 11 enn hva det hadde gjort før, samme for ca 11:30 - 12:30 i dag) Når jeg etterhvert har en sommer med solceller bak meg blir dette litt mindre interessant, da får jeg endre spørringen til å hente data fra tider på året med ca samme solhøyde.

Har ennå ikke produsert mer enn forbruk og ennå ikke hatt noen problemer, men i den enkle verdenen der, ser det ut for å fungere bra. Er en av de få med solceller i et relativt tett nabolag, så regner med at det skal gå an å bli kvitt eventuell overskuddsstrøm om/når det "problemet" dukker opp.

Dataene ser fornuftige ut. Spenningen stiger til ca 400V nesten så snart det blir lyst, og så begynner den å gi strøm når sola står på. Data hvert femte minutt, ja men etter hva jeg har lest meg til skal det være mulig å sende data oftere om man går inn og klår på kommunikasjonsinstillingene. Skal se på det og rapportere her når jeg får wifisticken.