De bugfix is klaar. Download hem hier.
Hiermee wordt je database aangepast zodat de jaarwaarden voortaan goed worden weergegeven.
Dit is overigens een tijdelijke oplossing, in een nieuwe versie komen meer tabellen, die mooiere grafieken mogelijk maken. Tegen die tijd zal een nieuwe tabel gevuld moeten worden.
dinsdag 9 februari 2010
woensdag 3 februari 2010
Code bug in SolGet 2.36
Helaas is er een vervelende fout geslopen in de grafieken database van SolGet 2.36. Mijn persoonlijke database achter deze site zit iets anders in elkaar, en daarom heb ik het zelf nooit opgemerkt. Tot op heden heb ik er ook geen klachten over gehoord, maar op de sites waar SolGet in gebruik is, heb ik het probleem wel gezien.
Gevolg van de bug is dat er buiten de zomer geen waarden in de lange termijn tabel terecht komen.
De data is helaas niet terug te halen want deze is door de bug simpelweg niet weggeschreven in de tabel.
De dagwaarden in het CSV bestand zijn overigens wel correct. De bug betreft puur de jaargrafieken.
Een bugfix zal spoedig op deze pagina verschijnen.
Technische uitleg; voor zover ik RRDTOOL uit kan leggen:
De fout zit in de creatie van de database table voor de lange termijn waarden.
Bij de creatie wordt het volgende gedaan:
rrdtool create $RRDSOL -s 300 \ (Iedere 300 seconden wordt een waarde verwacht)
DS:pwr5:GAUGE:600:0:500 \ (Uiterste wachttijd op een waarde is 600 seconden.)
(Geldige waarde moet tussen 0 en 500 liggen.)
RRA:AVERAGE:0.5:1:576 \ (bewaar gemiddelde waarde van 1 metingen, totaal 576 stuks (=48 uur)
RRA:AVERAGE:0.5:6:672 \ (bewaar gemiddelde waarde van 6 metingen, totaal 672 stuks (=14dgn)
RRA:AVERAGE:0.5:24:732 \ (bewaar gemiddelde waarde van 24 metingen, totaal 732 stuks (=61 dgn)
RRA:AVERAGE:0.5:144:1460 (bewaar gemiddelde waarde van 144 metingen, totaal 1460 stuks (= 2jr)
De waarde 0.5 houdt in dat 50% van de meetwaarden geldig moet zijn. (De soladin moet dan dus draaien)
Dat betekent voor tabel 4 dat (144x5 minuten) er één gemiddelde wordt weggeschreven over 12 uur. Vanwege de 50% regel, en het feit dat van ieder dagdeel (ochtend / avond) per 12 uur gemeten wordt komt het probleem in de herfst, lente en winter om de hoek kijken. De soladin draait niet lang genoeg om geldige meetwaarden op te leveren.
Hierdoor worden er dus dagelijks 2 lege waarden opgeslagen, en is er niets in de grafiek te zien buiten de zomermaanden.
Gevolg van de bug is dat er buiten de zomer geen waarden in de lange termijn tabel terecht komen.
De data is helaas niet terug te halen want deze is door de bug simpelweg niet weggeschreven in de tabel.
De dagwaarden in het CSV bestand zijn overigens wel correct. De bug betreft puur de jaargrafieken.
Een bugfix zal spoedig op deze pagina verschijnen.
Technische uitleg; voor zover ik RRDTOOL uit kan leggen:
De fout zit in de creatie van de database table voor de lange termijn waarden.
Bij de creatie wordt het volgende gedaan:
rrdtool create $RRDSOL -s 300 \ (Iedere 300 seconden wordt een waarde verwacht)
DS:pwr5:GAUGE:600:0:500 \ (Uiterste wachttijd op een waarde is 600 seconden.)
(Geldige waarde moet tussen 0 en 500 liggen.)
RRA:AVERAGE:0.5:1:576 \ (bewaar gemiddelde waarde van 1 metingen, totaal 576 stuks (=48 uur)
RRA:AVERAGE:0.5:6:672 \ (bewaar gemiddelde waarde van 6 metingen, totaal 672 stuks (=14dgn)
RRA:AVERAGE:0.5:24:732 \ (bewaar gemiddelde waarde van 24 metingen, totaal 732 stuks (=61 dgn)
RRA:AVERAGE:0.5:144:1460 (bewaar gemiddelde waarde van 144 metingen, totaal 1460 stuks (= 2jr)
De waarde 0.5 houdt in dat 50% van de meetwaarden geldig moet zijn. (De soladin moet dan dus draaien)
Dat betekent voor tabel 4 dat (144x5 minuten) er één gemiddelde wordt weggeschreven over 12 uur. Vanwege de 50% regel, en het feit dat van ieder dagdeel (ochtend / avond) per 12 uur gemeten wordt komt het probleem in de herfst, lente en winter om de hoek kijken. De soladin draait niet lang genoeg om geldige meetwaarden op te leveren.
Hierdoor worden er dus dagelijks 2 lege waarden opgeslagen, en is er niets in de grafiek te zien buiten de zomermaanden.
dinsdag 2 februari 2010
Totaal verbruik 2009
Het rekenen aan 2009 was een beetje lastig, omdat we tot 2 maal toe de standen vergaten op te schrijven. Uiteindelijk heb ik er toch nog wel wat van kunnen maken.
(Alle plaatjes zijn klikbaar)
Te beginnen bij de electriciteit, valt het me niet tegen.
Een totaal jaarverbruik van 2468 kWh. Hiervan is 1442 kWh nachtstroom, en 742 kWh dag, en 284 kWh is verbruikt van onze zonnepanelen. Verder hebben we nog 153 kWh aan het net teruggeleverd.
Totale opbrengst van de panelen was over 2009 437 kWh. Een record.
(2006: 107kWh, 2007: 407kWh, 2008: 425 kWh)
Omdat een plaatje toch meer zegt dan duizend woorden:
Het waterverbruik liet eigenlijk weinig spannends meer zien. Een totaalverbruik van 78 kuub, tegen 64 vorig jaar. Je zou dus kunnen stellen dat mijn dochtertje 14 kuub heeft opgedronken :)
(Alle plaatjes zijn klikbaar)
Te beginnen bij de electriciteit, valt het me niet tegen.
Een totaal jaarverbruik van 2468 kWh. Hiervan is 1442 kWh nachtstroom, en 742 kWh dag, en 284 kWh is verbruikt van onze zonnepanelen. Verder hebben we nog 153 kWh aan het net teruggeleverd.
Totale opbrengst van de panelen was over 2009 437 kWh. Een record.
(2006: 107kWh, 2007: 407kWh, 2008: 425 kWh)
Omdat een plaatje toch meer zegt dan duizend woorden:
Het waterverbruik liet eigenlijk weinig spannends meer zien. Een totaalverbruik van 78 kuub, tegen 64 vorig jaar. Je zou dus kunnen stellen dat mijn dochtertje 14 kuub heeft opgedronken :)
Wat betreft het gasverbruik is onze papa- en mamadag erg goed terug te zien. In de zomermaanden als er weinig gestookt wordt is het effect van de zonneboiler ook nog wel te zien.
Een totaalverbruik van 988 Kuub, tegen 778 van 2008. Dat wordt bijbetalen...
Abonneren op:
Posts (Atom)