Meter uitlezen 24/7 met Raspberry, hoe moet dat continu?

[De_Perre]

voor je grafieken kan je eventueel cacti overwegen.

werkt op basis van rrd data.

[Con]

Voor degen die mij hebben geholpen even een update. Ik heb inmiddels volledig het

opslaan van gegevens als CSV-file onder controle. De file groeit maar en groeit.

 

Ik heb al wat voorbeeld grafieken gegenereerd van RRD-tools maar heb nog geen

enkele notie hoe je nu mijn opgeslagen gegevens moet uitlezen naar een RRD database.

 

Daar ben ik inmiddels al een week me bezig en krijg dat niet spits.

Ik heb een CSV-file met, (unix)datum, (unix)tijd, en dan nog 6 variabelen, zeg maar t.b.v. de X-as.

 

 

Wie geeft mij het juiste handvat? Ik heb me helemaal sufgesurfd maar geen voorbeeld

paste in mijn belevingswereld.

[bunbun]

Hoi Con,

 

tof te horen dat je verder geraakt bent. Heb je je al verdiept in de "architectuur" van RRD?

 

Je hebt je tijd en 6 andere "variabelen". Dus je hebt in RRD-termen 6 Data Sources (DS). Wat is deze data? Zijn het meter-uitlezingen of tellers (die altijd maar stijgen)? Ik vermoed het 1e dus je type DS zal GAUGE zijn. Verder moet je ook beslissen om de hoeveel tijd je waarden in een database gaat steken, je "step". Dit is standaard 300s dus 5 minuten.

Na je DS moet je ook RRA's definieren, Round Robin Archives. Dit bepaalt hoeveel data je wil bijhouden en welke data (gemiddelde, minimum, maximum, laatste); bv. een RRA waarbij je ieder uur het gemiddelde over dat uur gaat bewaren en dit dan gedurende een maand. Een RRA waarbij je het gemiddelde zal bijhouden over 6 uur gedurende een half jaar enz... Zo krijg je overzichten waarbij je heel fijn kan zien wat er de laatste maand gebeurd is maar ook een globaler overzicht krijgt over een half jaar. Dit zonder dat je een database krijgt die constant groeit en uiteindelijk je disk volschrijft :-)

 

Klein voorbeeldje:

 

#!/usr/bin/python
import rrdtool
ret = rrdtool.create("meter.rrd", "--step", "300", "--start", '0',
 "DS:var1:GAUGE:600:U:U",
 "DS:var2:GAUGE:600:U:U",
 "DS:var3:GAUGE:600:U:U",
 "DS:var4:GAUGE:600:U:U",
 "DS:var5:GAUGE:600:U:U",
 "DS:var6:GAUGE:600:U:U",
 "RRA:AVERAGE:0.5:1:288",
 "RRA:AVERAGE:0.5:12:1440",
 "RRA:AVERAGE:0.5:288:365"
)

Mijn RRD is wat roestig maar dit zou een goed startpunt voor jou kunnen zijn.

 

Creeer de file/database meter.rrd met een interval van 5 minuten (300s).

6 Data Sources (var1 tot var6 maar die kan je zelf een betere naam geven)

3 RRA waarbij voor allen maximaal de helft (0.5) van de data onbekend mag zijn (meting gemist of zo):

Bewaar het gemiddelde (AVERAGE).

288 records waarbij 1 meting wordt genomen (om de 5 minuten een meting dus 12 metingen per uur of 288 metingen op 1 dag)

1440 records waarbij het gemiddelde uit 12 metingen (1 uur genomen wordt); 1440 uur / 24 uur per dag = 60 dagen

365 records waarbij het gemiddelde uit 288 metingen (12 per uur maar 24 uren per dag = 1 dag) bewaard wordt; dus 1 jaar data met het gemiddelde van 1 dag.

 

Invoeren van de data kan als volgt

ret = rrdtool.update("meter.rrd", "N:%s:%s:%s:%s:%s:%s", %(var1, var2, var3, var4, var5, var6));

Waarbij de N staat voor Now (Nu); indien je dat commando dus om de 5 minuten data laat wegschrijven. Wil je je data uit de CSV in een RRD importeren dan moet je daar de Unix timestamp ingeven (bv. 1375123700 op het moment dat ik dit schrijf).

 

Dit is een beknopt maar hopelijk genoeg uitgebreide inleiding tot de wondere wereld van RRD :-)

[Con]

Hoi Con,

 

tof te horen dat je verder geraakt bent. Heb je je al verdiept in de "architectuur" van RRD?

 

Je hebt je tijd en 6 andere "variabelen". Dus je hebt in RRD-termen 6 Data Sources (DS). Wat is deze data? Zijn het meter-uitlezingen of tellers (die altijd maar stijgen)? Ik vermoed het 1e dus je type DS zal GAUGE zijn. Verder moet je ook beslissen om de hoeveel tijd je waarden in een database gaat steken, je "step". Dit is standaard 300s dus 5 minuten.

Na je DS moet je ook RRA's definieren, Round Robin Archives. Dit bepaalt hoeveel data je wil bijhouden en welke data (gemiddelde, minimum, maximum, laatste); bv. een RRA waarbij je ieder uur het gemiddelde over dat uur gaat bewaren en dit dan gedurende een maand. Een RRA waarbij je het gemiddelde zal bijhouden over 6 uur gedurende een half jaar enz... Zo krijg je overzichten waarbij je heel fijn kan zien wat er de laatste maand gebeurd is maar ook een globaler overzicht krijgt over een half jaar. Dit zonder dat je een database krijgt die constant groeit en uiteindelijk je disk volschrijft :-)

 

Klein voorbeeldje:

 

#!/usr/bin/python
import rrdtool
ret = rrdtool.create("meter.rrd", "--step", "300", "--start", '0',
 "DS:var1:GAUGE:600:U:U",
 "DS:var2:GAUGE:600:U:U",
 "DS:var3:GAUGE:600:U:U",
 "DS:var4:GAUGE:600:U:U",
 "DS:var5:GAUGE:600:U:U",
 "DS:var6:GAUGE:600:U:U",
 "RRA:AVERAGE:0.5:1:288",
 "RRA:AVERAGE:0.5:12:1440",
 "RRA:AVERAGE:0.5:288:365"
)

Mijn RRD is wat roestig maar dit zou een goed startpunt voor jou kunnen zijn.

 

Creeer de file/database meter.rrd met een interval van 5 minuten (300s).

6 Data Sources (var1 tot var6 maar die kan je zelf een betere naam geven)

3 RRA waarbij voor allen maximaal de helft (0.5) van de data onbekend mag zijn (meting gemist of zo):

Bewaar het gemiddelde (AVERAGE).

288 records waarbij 1 meting wordt genomen (om de 5 minuten een meting dus 12 metingen per uur of 288 metingen op 1 dag)

1440 records waarbij het gemiddelde uit 12 metingen (1 uur genomen wordt); 1440 uur / 24 uur per dag = 60 dagen

365 records waarbij het gemiddelde uit 288 metingen (12 per uur maar 24 uren per dag = 1 dag) bewaard wordt; dus 1 jaar data met het gemiddelde van 1 dag.

 

Invoeren van de data kan als volgt

ret = rrdtool.update("meter.rrd", "N:%s:%s:%s:%s:%s:%s", %(var1, var2, var3, var4, var5, var6));

Waarbij de N staat voor Now (Nu); indien je dat commando dus om de 5 minuten data laat wegschrijven. Wil je je data uit de CSV in een RRD importeren dan moet je daar de Unix timestamp ingeven (bv. 1375123700 op het moment dat ik dit schrijf).

 

Dit is een beknopt maar hopelijk genoeg uitgebreide inleiding tot de wondere wereld van RRD :-)

Volgens mij heb je mij de sleutel tot succes gegeven.

 

Ik citeer even alles om het verhaal compleet te houden, volgende keer neem ik wat minder mee, het worden anders van die lappen.

Dat van gauge en average heb ik inmiddels zo vaak gelezen dat het begint door te dringen . . .   nu nog de praktijk.

 

Waar ik mee zat was de csv file in te lezen (en dat heb je aangegeven met een duidelijk voorbeeld . . . . . (denk ik).

 

Ik heb op dit moment een file die dus komma-gescheiden is met de volgende volgorde (plastisch gezegd);

"unix-tijd, oplopende waarde 1, oplopende waarde 2, oplopende waarde 3, oplopende waarde 4, op-en-neer lopende waarde 1, een op-en-neer-lopende waarde 2".

 

Kortom 7 waarden met een komma gescheiden. Het is weliswaar een enorme tabel met een

stap van 10 seconden maar dat kan volgens mij overruled worden met de "step" van RRD.

 

In Python heb ik die waarden kunnen scheiden met een komma, het zijn echter wél strings ($).

Mijn basis vraag was (even terug naar af) hoe lees je die uit. Je hebt het voorbeeld al gegeven.

 

Goed beschouwd zou ik eerst een en ander meer eens moeten proberen. Maar laat ik toch maar

nóch een vraag stellen. Kan RRD-tools een string zien als een getal? Of moet ik eerst de

strings omzetten naar integers? (Volgens mij is integers hetzelfde in het Engels . . .??) 

 

Maar op voorhand is mijn dank al weer groot.

[Con]

Die Unix tijd zit mij nog wel een beetje dwars, misschien maak ik mij voor niets zorgen.

Uiteraard heb ik het csv bestand al ettelijke keren in Excel binnen gehaald.

De Unix tijd omgezet naar een "Excel-tijd" maar daar moest ik altijd 7200 seconden

bij optellen (bij de Unixtijd) om op de Nederlandse tijd uit te komen.

Terwijl de klok in mijn Raspberry als op mijn W7 exact gelijk staan, beetje tricky dus, in ieder geval vreemd. 

 

Ik realiseer me nu dat ik de omrekening van een Engels-talige site heb geplukt.

Wellicht geen wonder omdat Engeland en Nederland niet synchroon lopen . . .

 

Dat zal het verschil van die 2 uur zijn . . . zomer- wintertijd.

 

Maar zolang ik in mijn Raspberry blijf heb ik daar natuurlijk geen last van . . .

want die rekent met de Unix tijd.

29 juli 2013 aangepast door Con

[bunbun]

Hangt af hoe je de file inleest; als het echt een string is kan je die omzetten naar een int met int

 

nummer=int(string);

 

Op termijn zou ik niet meer naar een CSV schrijven maar rechtstreeks naar een RRD. Gewoon zorgen dat je om de 5 minuten je meter uitleest en die waarden in een RRD pompt. Veel minder gepruts :-)

 

Voor de constant oplopende waarden kan je beter een counter nemen; je bent immers meer geinteresseerd in hoeveel die gestegen zijn op 5 minuten, niet zozeer hoeveel die nu absoluut is. Je verbruik bv.: je wil weten wat je verbruik was gedurende die 5 minuten, niet de je meter van 5000 naar 5003 gegaan is.

 

Wat je step betreft; als je een RRD creeert met een step van 300 zal deze dacht ik alle waarden negeren tot je step terug overschreden is; dit is iets wat je misschien eens kan testen. Je kan de waarden van een RRD altijd dumpen met rrdtool dump. Zo kan je makkelijk kijken wat je er precies hebt ingeschreven.

 

Voor de op- en afgaande waarden neem je dus best een Gauge. Voor de constant oplopende waarden denk ik beter COUNTER.

Beschouw GAUGE als een meter voor bijvoorbeeld temperatuur en COUNTER voor je water- of electriciteits-verbruik of -productie.

Je bent voor dacht ik toch meer ge-interesseerd (voor grafieken) hoeveel je opgewekt hebt in een uur tijd ipv op hoeveel je meter toen stond.

[Con]

Ik heb in ieder geval stof voor minimaal een week, ben een zeer langzame leerling, de leeftijd gaat ook een rol spelen.

 

Op dit moment ben ik geïnteresseerd in mijn meterstanden, gewoon omdat ik die kan uitlezen.

Als dat allemaal werkt ga ik verder met het proberen uit te lezen van mijn zonne-inverter.

De slimme meter (lees uiterst belachelijke stomme meter, de sukkel laat alleen de saldi zien

van mijn momentane verbruik) heb ik dus in een csv weggeschreven. Excel ziet het als getallen.

RRD misschien ook. Zoniet dan zet ik ze even om met jouw oplossing.

 

Nog even een antwoord op jouw eerdere vraag. Nee, op de structuur heb ik geen vinger op weten

te leggen. Ik hoopte ergens op het grote ww gewoon een simpel schema met de componenten

die nodig zijn.

 

Voorlopig denk ik dat je;

a een deel hebt hoe je de gegevens ophaalt

b een deel hoe je de grafieken wil presenteren

c de grafieken genereren met een grafische extensie.

 

Maar helder . . . . helaas.

Weet je, het houd me wel uit de kroeg en dat is mooi, maar ook een (erg) beetje uit mijn bed   

[Con]

Nick heeft mij erg geholpen. Mede door hem de volgende resultaten;

 

http://ccvd.eu/Energie.html zie de grafieken rechts.

[tik]

Nick heeft mij erg geholpen. Mede door hem de volgende resultaten;

 

http://ccvd.eu/Energie.html zie de grafieken rechts.

 

N.a.v. je opmerking onderaan die webpagina heb ik een wellicht bruikbare tip: als je meerdere fases in de groepenkast hebt, en je kunt één fase volledig reserveren voor het aansluiten van de omvormer (op die fase sluit je uitsluitend de omvormer aan en letterlijk NIETS anders)...

Dan is er GEEN 'intern' verbruik van de opbrengst van de zonnepanelen en gaat ALLE opwek dus langs de meter. Dus heb je een zuivere meting; opwek = retour.

Wellicht is dit een simpele oplossing voor je probleem.

 

Bovendien maakt het met de huidige regelgeving niets uit of je binnenshuis je eigen opwek gebruikt of niet; aan het einde van de periode wordt er toch 1 op 1 gesaldeerd.

[Con]

Ik denk dat je doelt op het gebruik van de inverter zelf.

 

Maar dat bedoel ik niet.

 

Voor dat ik panelen had heb ik de Youless gekocht om mijn verbruik te screenen.

Daarop kon ik dan anticiperen. Als je bv een lamp aanknipte kon je meestal het

verbruik van die lamp zien (tenzij je koelkast ook gelijk aan ging).

 

Nu is het zo wanneer je aan zon 500 Watt/h binnenkrijg en je verbruik in huis is

bijvoorbeeld 1200 Watt/h dan is af te lezen dat je 700 Watt/h afneemt (verbruikt

van de energiemaatschappij). De meter, of dit nu de Youless is of direct via P1,

geeft het gesaldeerde verbruik. Je kunt dus niet meer je echte gebruik aflezen.

 

De enige oplossing is om het echte gebruik van de zonopbrengst af te trekken

om de zonopbrangst separaat te meten. Daar zijn natuurlijk wel verschillende

manieren voor maar de slimme meter is dus een oerstomme meter, die kan

alleen gesaldeerde waarden tonen zowel bij afname als bij levering.

 

Op de site van Enerlogic kun je je ook opgeven, daar visualiseren ze je

energiestromen. Maar je kunt op die site ook niet zien wat je aan zon hebt

binnengekregen en ook niet je echte gebruik. Uiteraard geldt dit alleen wanneer

er zonopbrengst is. Met donker werkt alles naar behoren, maar ja dan wordt er

gegarandeert geen zonwinst geleverd.

 

Nee, het is tobben met die "slimme meters" terwijl de hele wereld die dingen

promoot, schiet mij maar lek.

 

Wat kun je n rechtstreeks allemaal uitlezen via P1 (RJ11);

Afname piek

Afname dal

levering piek

levering dal

afname momentaan

levering momentaan

piek/dal stand

en ook nog gas.

 

De eerste 6 energiestromen worden allen gesaldeerd weergegeven.

[tik]

Ik denk dat je doelt op het gebruik van de inverter zelf..

 

Nee. Ik ben niet helemaal duidelijk geweest. Zelf neem je ook de tijd om mensen te helpen (op basis van deze leerzame thread ben ik zelf ook lekker bezig thuis) dus hoop ik nu wat terug te doen.

 

Uitgangspunt is dat je slimme meter 4 telwerken heeft; dal/piek afname en dal/piek retour. Sommige meters maken bij retourlevering geen onderscheid tussen dal en piek. In dat geval kun je 'm doorgaans kostenloos laten omruilen voor eentje die dat wel kan als je zelf energie opwekt.

 

Uitgaande van moderne groepenkasten met schakelaars: je electrische installatie thuis heeft doorgaans ofwel 1 fase, ofwel 3 fasen. In het laatste geval kun je per fase maximaal 4 groepen aanleggen (per fase 1 aardlekschakelaar en 4 schakelautomaten).

 

Als je de goede slimme meter hebt, en 3 fasen hebt die niet te vol zitten kun je de 'truuk' toepassen die ik beschreef. Want (dit is de clue): intern gebruik van zelf opgewekte electriciteit vindt uitsluitend plaats op de fase waarop de omvormer is aangesloten.

 

Oftewel: als je al je bestaande groepen (maximaal 8 dus) slim verdeeld over fase 1 en 2, en op fase 3 uitsluitend de omvormer aansluit, dan kan er geen intern verbruik zijn van de opgewekte electriciteit. En dus gaat dan 100% van de opgewekte electriciteit retour het net op, en dus 100% langs dat telwerk voor teruglevering. Oftewel: je oplossing!

 

Ik hoop dat het zo duidelijk is en dat je het ook kunt toepassen.

10 oktober 2013 aangepast door tik

[ceesv]

Kan je dan per fase het gebruik uitlezen?

[Con]

Dit is wat je kunt uitlezen qua elektra (los van piek/dal status);

 

p1_str=str(p1_raw)
p1_line=p1_str.strip()
if "1.8.1" in p1_line:
ad= int (1000 * float(p1_line[10:19])) # ad= afgenomen dal
if "1.8.2" in p1_line:
ap= int (1000 * float(p1_line[10:19])) # ap= afgenomen piek
if "2.8.1" in p1_line:
gd= int (1000 * float(p1_line[10:19])) # gd= geleverd dal
if "2.8.2" in p1_line:
gp= int (1000 * float(p1_line[10:19])) # gp= geleverd piek
if "6.14." in p1_line:
pd= int (1000 * float(p1_line[13:15])) # pd= piek versus dal
if "1.7.0" in p1_line:
am= int (1000 * float(p1_line[10:17])) # am= afgenomen nu
if "2.7.0" in p1_line:
gm= int (1000 * float(p1_line[10:17])) # gm= geleverd nu

 

En niet per fase.

[tik]

Kan je dan per fase het gebruik uitlezen?

Nee, bij 3 fasen wordt verbruik en teruglevering geregistreerd van alle fasen samen. Feitelijk verbruik je dus ook van 3 verschillende fasen en IS het technisch mogelijk hier qua telwerken onderscheid in te maken. Je verbruiksmeter doet dat echter niet (wellicht toekomstige modellen wel).

 

De methode die ik beschreef zorgt er voor dat er geen intern verbruik kan plaatsvinden, dus ook geen interne 'saldering'. Je weet dan exact wat er op ieder moment aan intern gebruik en teruglevering plaatsvindt.

 

Wel nog een kanttekening; de opzet die ik beschreef gaat alleen op als je een 1-fase omvormer hebt, dus tot maximaal 3680 W (limiet van 1 x 16A groep). Zwaardere omvormers worden normaliter op alledrie de fasen aangesloten en dan gaat de truuk niet meer op. _{En ja ik weet dat je ook een 4000W omvormer op een 20A schakelautomaat kunt zetten, maar dan krijg je eindeloze discussies over veiligheid, selectiviteit enz..}

 

De andere zijde van dit verhaal: als je JUIST zo veel mogelijk van je eigen opwek binnenshuis wilt verbruiken, sluit de omvormer dan aan op een fase waarop het meeste interne verbruik plaatsvindt (o.a. de apparaten die dag en nacht stroom verbruiken).

 

Ook grappig: wat jij teruglevert aan het net wordt door het telwerk van je meter geregistreerd en als eerste door je buren verbruikt (weg van de minste weerstand). Echter daar komt het ook weer langs het telwerk binnen. Zo wordt alles correct verrekend.

10 oktober 2013 aangepast door tik

[Con]

Ik denk dat "tik" die ene fase (waar de inverter op zit wil monitoren én de totaalstroom,

dan kun je je eigen gebruik (lampen, apparaten) precies bepalen.