Het is bijna ongelofelijk dat het me oorspronkelijk gewoon helemaal niet lukte om het uitlezen van data van mijn zonnepanelen voor elkaar te krijgen, terwijl het me gisteren maar een paar uur gekost heeft om het proces op een tweede SD-kaartje te herhalen. Ik heb de beschrijving, ik begin bij het setuppen van de Raspberry Pi, in het Engels op een aparte pagina gezet. Gezien de vragen die ik zo links en rechts tegen kom zijn er namelijk heel wat meer mensen die zoiets willen. In deel 1 kon je over de achtergrond en de gebruikte hardware lezen.
Het is een beetje jammer natuurlijk dat de levertijd van een Raspberry Pi nog steeds redelijk lang is, anders hadden ze bij ZonZoektDak een collectieve inkoopactie of zo kunnen opzetten voor hun klanten. Veel goedkoper dan hun oorspronkelijke aanbod. Waarschijnlijk zouden ze het dan voor de beheersbaarheid wel juist weer verder moeten dicht timmeren om te voorkomen dat hun klanten er ook XBMC op gaan draaien of zo. 😉
Hoe dan ook, ik hoop dat mensen zijn die er wat aan hebben. Het was voor mij in ieder geval de moeite waard om even te documenteren want over 2 weken ben ik dit weer vergeten.
Ook interessant:
Wat voor omvormer gaat het hier om? Zelf heb ik een kabeltje met enerzijds een stekkertje dat in de omvormer past, anderzijds een usb stekker. Ik sluit mijn laptop aan op de omvormers en zo lees ik dan de data uit.
vriendelijke groet,
José de Kruif
Het gaat hier om een Sunny Boy 1600TL. Welke omvormer heb jij?
Hier hebben we zes zonnepanelen daarmee is ons platte dak zo ongeveer vol. Per drie panelen is een Soladin 600 omvormer aangesloten, dus twee omvormers. Het voordeel was dat de omvormers gewoon met een stekker in het stopcontact zitten. Dus geen gedoe van doortrekken naar meterkast enz. met alle kosten van dien. Vandaar dat voor deze oplossing is gekozen. Want eigenlijk is 1 omvormer en dan met een grotere capaciteit, natuurlijk logischer.
Hier is een omschrijving http://www.solarcentury.co.uk/installers-and-roofers/products/inverters/mastervolt-soladin-600/. Niet bedoeld als reclame, overigens, maar dit kon ik snel vinden.
Er zijn ook apparaatjes in de handel waarmee je de boel gewoon zonder laptop kan uitlezen, maar dat geeft dan weer kosten…..
Voor de vergelijking maak ik gebruik van een amateurweerstation vlak bij ons huis. Die ligt een paar straten verderop, dus dat komt aardig overeen met de omstandigheden bij ons. Er zijn vast flink wat van zulke enthousiaste weerfanaten, misschien ook bij jou in de buurt. Misschien eens googelen op “weerstation” en dat soort termen en dan met je woonplaats?
Sympathiek initiatief trouwens, dat Zon zoekt Dak.
Zon Zoekt Dak via Raspberry Pi op PVOutput #2 – ICT & Onderwijs BLOG – http://t.co/tDc7ysVE
We hebben sinds afgelopen vrijdag 4410 wattpiek aan vermogen op het dak liggen (18 Canadian Solar 6P-245 op een SMA SB4000TL-21). En een van de leukste dingen is nu het opvragen van statistiekjes (en een terugzoevende ferrarismeter).
Nu had ik nog een Raspberry PI liggen en dankzij jouw heldere uitleg heb ik het bijna aan de praat. Het enige probleem waar ik nog steeds tegenaan loop zijn ongeldige waarden en datums die in 1970 liggen. Best bizar. Dat kost best nog wat tijd om werkend te krijgen.
Vanmorgen heb ik de smatool database weggegooid, opnieuw geinstalleerd, eerste import gedaan van een datum die helemaal gevuld was: ./smatool -v -from “2012-08-20 00:00:00” -to “2012-08-20 23:55:00” en zowaar ik heb een keurige dagopbrengst binnengekregen en naar PVoutput.org gestuurd.
Nu ik echter andere datums wil uitlezen kom ik onveranderlijk weer in 1970 terecht. Of in 2038 trouwens. Ook als ik de waarden van 2012-08-20 tot 2012-08-20 23:55:00 opnieuw uitlees.
Het lijkt wel of de omvormer na de eerste keer van slag is en er geen trek meer in heeft…?
Heb je enig idee hoe dit kan?
Hoi Sander,
Het is op zich geen probleem als er af en toe datums uit 1970 of 2038 voorbij komen, dat gebeurt bij mij ook. De wijzigingen in smatool.c die ik beschreef zijn er voor bedoelt om die gegevens weer uit de database te gooien.
Komt er namelijk eentje met 2038 in de database, dan zal smatool de keer erna proberen vanaf 2038 te lezen. Dat is geen geldig jaar, dus haalt het alle data binnen. Dat levert dan vaak weer het probleem op dat er regels bij zitten die PVoutput niet accepteert, maar die in de kolom “PVoutput” nog de waarde NULL hebben staan. Resultaat: er komt niet meer op PVoutput terecht.
Daarom even wat vragen om het beeld voor mij helderder te krijgen:
1) heb je gebruik gemaakt van mijn smatool.c danwel ben je 100% dat je alle beschreven wijzigingen in smatool.c hebt doorgevoerd. Zo niet, dan graag alsnog even doen.
2) zit er in de database nu weer data met PVoutput = NULL die te oud is om in PVoutput te laten importeren?
(check even met: select * from DayData where PVOutput is NULL order by DateTime ASC;)
Zo ja, dan is het waarschijnlijk net zo handig om die data gewoon te laten staan en er even voor te zorgen dat SMA-Bluetooth denkt dat ze al verstuurd zijn:
mysql> update DayData set PVOutput = “2012-08-22 00:00:00” where DATEDIFF(curdate(), DateTime) > 2;
(ik ga er even vanuit dat je de data van de afgelopen 2 dagen nog wilt uploaden ofwel al geupload hebt)
3) als je ./smatool -v uitvoert (-v zorgt er voor dat je wat meer te zien krijgt), welke “from” datum staat er dan?
Hoi Pierre,
Ik heb inderdaad jouw bijgewerkte versie van smatool.c gebruikt (nog maar even gecontroleerd voor de zekerheid).
Als ik controleer welke data er nog niet opgestuurd is dan zijn dat over het algemeen nulwaarden van momenten dat de panelen niets leveren (’s avonds tot ’s ochtends vroeg). Daarnaast zijn er nog een paar 1970 records aanwezig. Ik heb deze records nu bijgewerkt
zoals je aangegeven hebt.
De cronjob heeft net weer gedraaid en pvoutput.org is zojuist netjes geüpdate.
./smatool -v meldt: “Auto set dates from 2012-08-23 12:10:00 to 2012-08-23 12:14:00”. Dit lijkt me correct.
Ik hou de boel even in de gaten en mocht hij weer stoppen met updaten dan controleer ik de database even om te zien of er weer vreemde waarden in staan.
OK. Het script gaat er nu vanuit dat die 2038 of 1970 data allemaal “CurrentPower < 0 or ETotalToday = 9999999.999" hebben. Is dat bij jou voor die van 1970 dan niet zo? (welke waarden staan daar dan?) Die 0-waarden heb ik ook, dat is geen probleem zo te zien.
Even mySQL er op los gelaten:
Ok, ik had die blockquote anders verwacht. Ach ja 🙂
Dit zijn in ieder geval wat waarden die er nu weer vers in zitten en nu verhinderen dat pvoutput.org geupdate wordt.
Ah, ja voor deze run wel. Maar over 5 minuten zouden die er uit gegooid moeten worden als/voordat de volgende run uitgevoerd wordt. Want ze zijn allemaal “CurrentPower < 0 or ETotalToday = 9999999.999″
Die vreemde datums kunnen ook voorkomen tijdens een run die wel zinnige data oplevert.
1/1/1970 01:00:00 total=0.000 Kwh current=-201326560 Watts togo=65533 i=47 crc=1082900188Date Error! prev=16777213 current=0
23/8/2012 13:05:00 total=94.130 Kwh current=1129560 Watts togo=0 i=11 crc=1082900188
23/8/2012 13:10:00 total=94.243 Kwh current=1356 Watts togo=0 i=23 crc=1082900188
Wel bijzonder dat de eerste regel van de ‘normale’ waarden toch niet helemaal zo normaal is. Of ik heb uitzonderlijke panelen liggen natuurlijk 😉
Wat ik ook meegemaakt heb is dat smatool soms blijft hangen en de bluetooth verbinding open lijkt te houden. Het enige dat dan helpt is de Raspberry Pi rebooten (ofwel stroom er af) en dan gaat ie weer vrolijk verder.
Nee, het schijnt een bekend fenomeen te zijn dat SMA-Bluetooth niet altijd in staat is om zinnige data op te halen. De verschillen tussen de omvormers (wat betreft communicatie) en het feit dat het achterhalen van de exacte codes zo’n gedoe is zullen daar ook wel niet bij helpen.
Problemen met de bluetooth adapter komen helaas vaker voor bij de Raspberry Pi. Daar zag ik op hun eigen forums in ieder geval (wel ook in combinatie met PVOutput) meerdere berichten over. Ik heb daar gelukkig met mijn bluetooth adapter geen last van. Heb jij helaas niet veel aan als je niet toevallig binnenkort in de UK bij de Tesco komt. Daar kosten ze 5,97GBP.
Het lijkt inderdaad ook (deels) aan de bluetooth adapter te liggen. Ik zal eens zien of ik ergens een beter exemplaar op de kop kan tikken. De Tesco wordt het voorlopig niet, heb helaas nog geen reis naar de UK in de planning staan 🙂
Voor zover ik heb kunnen nagaan, liggen de leesfouten in het fout afhandelen van data.
Ik heb zelf andere software geschreven, die geen leesfouten lijkt te vertonen. Het werkt alleen wat anders, alle waarden die de software leest zet hij in een .csv bestand. Zelf zet ik dat naar een live webserver, waar het een PHP scriptje het in de database zet.
Zie https://github.com/creagraphy/sb_bt
Ernst
De SMAtool blijft een wat nukkig ding, je moet toch continu blijven controleren om te zien of ie het nog wel naar behoren doet. Nu kreeg ik via het forum van Tweakers de tip om een flink opgeschoonde kloon van de SMAtool te proberen, aangezien die minder fouten zou opleveren.
Gisteren heb ik deze kloon (https://code.google.com/r/janus44444-sma-bluetooth/) van de SMAtool opgehaald, gecompileerd en aan het werk gezet op de raspberry PI. Tot op heden heeft hij geen enkele fout opgeleverd, geen gekke datums, geen vreemde outputwaarden, alleen maar correcte data. Heel verfrissend 🙂
Het enige dat op dit moment nog loopt te klieren is de Bluetooth driver. Die knalt er af en toe gewoon uit en de bluetooth verbinding valt dan alleen maar te herstellen door de PI te rebooten. Nu is dat op zich niet heel spannend (cron is best handig) dus de PI wordt nu ieder uur braaf gereboot. Heel ranzig natuurlijk, maar het werkt wel 😀
Misschien dat dat verholpen kan worden door een andere (Tesco) bluetooth dongel. de kloon van de SMAtool doet zijn werk in ieder geval netjes. Dat is dus een tip voor iedereen die tegen de corrupte data aanloopt 😉
Ik heb tot nu toe 2 keer gehad dat de Bluetooth ontvanger dusdanig vast liep dat ik de RPi in zijn geheel moest resetten. Dus ook de Tesco dongle is niet probleemloos.
Sander,
Hoewel die van janus44444 flink opgeschoond is, zit er nog steeds veel te veel code in. Ik kreeg er wel regelmatig foute data mee, zij het inderdaad minder vaak dan met smatool.
Mijn software doet het helemaal goed, al die zaken als “inverter codes” etc. zijn ook helemaal niet nodig. Zie https://github.com/creagraphy/sb_bt voor veel eenvoudigere, goed werkende code. Dit is helemaal opnieuw geschreven.
Ernst,
Hij staat op mijn TO-DO lijstje om uit te proberen. 🙂
Pierre,
Leuk, alvast succes.
Wat ik recentelijk ontdekt heb (staat nog debug code voor op GitHub) is dat de SunnyBoy soms status informatie terugstuurt in plaats van data. Vermoedelijk een soort van “busy” bericht, ik krijg dat gemiddeld 2 keer per dag (bij elke 5 minuten uitlezen). Als je dat statusbericht interpreteert als data, krijg je rare waarden zoals die datum in 1970. Ik denk dat daar de meeste software de fout in gaat.