Software: Grafieken, programmeren in relatie met DE.

[mkleinman]

Misschien een idee om een topic te starten over grafieken, programmeren enz. in relatie tot DE? Lijkt mij wel handig.

Deze quote van Ericplan was zo gek nog niet, in plaats van alles in het cafe te zetten een apart topic over programmeren, grafieken e.d. allemaal in relatie tot duurzame energie.

Ik ben zelf nu bezig met een webapplicatie ( Oracle / PLSQL / Apache / Google Charts ) om mijn meterstanden te beheren en daar mooie grafieken mee te maken.

Waar dit topic gaat eindigen? Geen idee, misschien is het idee van mijn webapp wel dusdanig goed dat ik hem beschikbaar moet/ga stellen aan de grote boze buitenwereld. Voordat dat kan moet ik wel nog een heleboel werk verzetten op diverse gebieden. Op dit moment is de applicatie houtjetouwtje en hackwerk.

Ik kan inmiddels mijn PV opbrengsten van jSunnyreports scrapen, de KNMI site benaderen voor graaddagen en dit allemaal verwerken in tabellen en grafieken. Oa

Opzet

Heel kort mijn opzet.

Ik hou de standen bij via een webapp in een tabel genaamd MTR_RAW_METERDATA. Hierin zitten alle losse records die ik ooit ingevoerd heb. ( tot op de minuut nauwkeurig ).

Ik heb ook een tabel MTR_DAGSTANDEN, hierin zit elke dag vanaf de kleinste t/m de nieuwste datum vanuit MTR_RAW_METERDATA. In deze tabel interpoleer ik alle verbruiken aan de hand van de meterdata tabel.

Daarnaast heb ik nog een afgeleide tabel met daarin de maand informatie. Deze sommeert alle data van een maand tot 1 record ( voor performance ). Het algoritme die deze tabel vult interpoleert ook de huidige maand en doet een schatting wat het verbruik zou zijn.

TODO

Code verbeteren en optimaliseren, sommige queries en stukken algoritme zitten nog niet perfect in elkaar.

De webapplicatie zelf is ranzig en er wordt niets aan type safety gedaan, hele code is wel beschermt tegen SQL injection.

[MasterMaceMichu]

Erg interessant! Ik kan zelf geen letter programmeren en ben ook niet handig (lees wellicht: heb er de tijd niet voor) om iets dergelijks op te zetten, maar wil WEL dit inzicht hebben.....De data verzamel ik al, deels in Excel en met een Youless (verbruik per dag) en deels via pvoutput/fp4all. Nu nog een manier om het bij elkaar te brengen het mooi grafisch te maken..... Daar lijkt me dit project wel geschikt voor!

[ Voor 9% gewijzigd door MasterMaceMichu op 04-01-2013 18:45 ]

[mkleinman]

Hmm, ben nu bezig met wat performance tuning van m'n code. In mijn profile report komt oa deze query naar boven die relatief duur is.

code:

      SELECT * INTO l_return
        FROM (
               SELECT * FROM mtr_raw_meterstanden mtr 
                WHERE mtr.datum <= p_datum
                  AND mtr.i IS NOT NULL 
                ORDER 
                   BY datum DESC
             )
       WHERE rownum = 1;

Ik moet afhankelijk van een datum ( gesorteerd ) het 1e record hebben. Ik weet niet beter dan dat dit de enige methode is in Oracle. Alleen is hij relatief kostbaar....

[Freemann]

mooi en leuk topic! Ben zelf met iemand anders ook bezig om een webApp in elkaar te zetten waarvan het einddoel ook niet echt duidelijk is. Eerste streven was om een gestructureerd stuk code in elkaar te draaien wat onze PowerOne omvormers uit kon lezen. Dit doel is nu bereikt en sinds kort kunnen we ook SMA omvormers uitlezen. De code is flexibel opgezet en in theorie kunnen we daarmee elke omvormer (die redelijkerwijs uit te lezen valt) uitlezen. De data kan reeds verzonden worden naar PVoutput, we zijn bezig met SocialMedia ondersteuning en momenteel zijn we bezig om de SlimmeMeter te ontsluiten (zijn we net mee begonnen) met Elektra/Gas en Water(voor de toekomst). Het volgende is om KNMI graaddagen mee te pakken deze met Gas in beeld brengen.

Daarbij hebben wij ons zelf de eis gesteld dat het op low-power devices (bijv. RaspberryPi) moet kunnen draaien. Tot op heden gaat dat goed en hebben we dit vooral bereikt door gebruik te maken van low-resource software oplossingen. Als DB-"backend" gebruiken we SQLite3 en draait het bewezen stabiel op webserver software van Nginx en Lighttpd beide met PHP5.3. De frontend is volledig gestoeld op Javascript(-templating, handlebars). PHP5 zorgt ervoor dat de data uit de database klaargestoomd wordt en middels JSON richting de frontend gaat. Daarna neemt Javascript het volledig over om de frontend op de client van de bezoeker op te bouwen. Deze opzet zorgt voor minimale resource op de server en maximale belasting op de client. Ook ondersteund het languages, met engels als default en daarnaast is Nederlands beschikbaar.
Alle JavaLibs zijn vrij te gebruiken,onbeperkt en offline te gebruiken. Hierdoor kan de logger, na installatie, probleemloos in een internet vrij omgeving draaien. Vooral de graphlibs zijn nogal problematische, dit omdat Google het niet toestaat om zijn libs offline te gebruiken en Highcharts het niet toestaat om de libs "commerciel" in te zetten. We gebruiken nu JqPlot, wat een graphLib is die op JQuery gebaseerd is. Zo goed als de hele frontend maakt gebruik van Jquery(-ui), wat dan ook X-browser compatibiliteit "garandeerd".

in de admin zitten 2 heel interessante opties:
1. update functie (php-svn)
2. db backup functie

Optie 1 maakt het mogelijk om met 2 klikken een nieuwe versie te installeren en dat zonder tussenkomst van de console en/of linux kennis van commando's (wget, subversioning, cp, mv, rm, chmod, etc).
Optie 2 maakt het mogelijk om met 1 druk op de knop een backup van de Database op te slaan in de cloud (vooralsnog wordt alleen Dropbox ondersteund). Deze 2 opties geven Linux noobs de mogelijkheid om een leuke tool te gebruiken.

Het geheel te nog zwaar in Beta, maar wel te testen en te downloaden.
Download WebSolarLog(zoals het nu nog heeft) van sourceforge

[ Voor 14% gewijzigd door Freemann op 04-01-2013 21:53 ]

[ericplan]

Leuk topic Martin. Vooral om te zorgen dat we niet allemaal het wiel steeds opnieuw moeten uitvinden. Of het nu java of PHP is, je komt steeds dezelfde problemen tegen. Handig als er een plek is waar we iets kunnen vinden of vragen.

[mkleinman]

Ik heb een leuke verbetering gevonden in mijn code. Het algoritme voor het bepalen/interpoleren van de dagverbruiken was erg traag. Het doorrekenen van halverwege 2006 t/m 2013 deed er ruim 8 seconden over.

Het probleem zat in een CURSOR die ik blijkbaar nogal misbruikte. Ik heb de code nu aangepast en het hele algoritme werkt nu in slechts 2 seconden. Nog erg lang in mijn ogen maar al een stuk beter.

[Paul C]

@mkleinman:
7 jaar, dat zijn dus in het geval van dagen 2,5k datapunten. Je doet er dus 1ms per datapunt over. Dat lijkt me inderdaad heel veel. Doe je niet misschien iets te veel aan de databasekant?

En nog even over je m³ vs. graaddagen grafiek. Je hebt het daar volgens mij over graaddagen/dag op de x-as, dan vallen die dagen tegen elkaar weg en heb je het gewoon over graden.

[ollie1965]

Krijgen we hier een crowdsourcing

Zomaar een brainwave van mij, kunnen we meerdere initiatieven delen/laten samenwerken?

Ik zie dat Freemann met nog iemand op de uitlees toer is (digitaal) maar nog niet de bereken/grafieken stadium heeft bereikt
Ik zie dat Kleinman juist voornamelijk aan de andere zijde zit en lekker in de weer is met de data en grafieken

Oké talen/platformen zullen nog deels verschillen maar is zoiets te stroomlijnen?
Is (willen jullie) het "open" te maken? GNU GPL? EDIT "Open talen"?

Waar zou ik aan mee kunnen helpen?
Monkeytest ben ik goed in
Datamodellen, Analyse, Functioneel ontwerp, Architectuur

Laat eens horen, is het wat?
Zouden er meerdere tweakers aan mee willen helpen ieder vanuit zijn eigen deskundigheid?

[mkleinman]

Paul C schreef op vrijdag 04 januari 2013 @ 23:07:
@mkleinman:
7 jaar, dat zijn dus in het geval van dagen 2,5k datapunten. Je doet er dus 1ms per datapunt over. Dat lijkt me inderdaad heel veel. Doe je niet misschien iets te veel aan de databasekant?

En nog even over je m³ vs. graaddagen grafiek. Je hebt het daar volgens mij over graaddagen/dag op de x-as, dan vallen die dagen tegen elkaar weg en heb je het gewoon over graden.

Het algoritme klopt volgens mij van geen kant, ik werk nu van oudste naar nieuwste datum en bepaal per datum de juiste waarden.

Veruit grootste kostenpost is het bepalen van vorige en het volgende record. En dat moet per I,II, GAS en WATER apart omdat niet elk record perse een waarde voor elk veld hoeft te hebben.

Dus 4x praktisch redundante code.

Verder gooi ik bij elk nieuw punt de hele DB leeg om hem helemaal overnieuw te vullen, misschien dat ik beter van die dag 10 dagen kan verwijderen voor die datum en na die datum en die overnieuw te bepalen.
Nu ik dat zeg... Volgens mij is dat de oplossing!

Verder verlies ik heel veel tijd doordat ik steeds van een datumwaarde naar het maandgetal en jaargetal moet. Ik zit er nu over te denken om die redundant op te nemen in de database.

[Paul C]

Volgens mij is dit de oplossing:
- Haal een lijst met meetwaarden uit je DB op chronologische volgorde
- Ittereer de lijst
- - en bereken hierbij alle tussen item(n) en item(n+1)
- - sla deze op in een tweede lijst
- als je de eerste lijst door bent heb je alle waarden in de tweede lijst en kun je de eerste discarden of iets als lijst1 = lijst2; doen.

Maand en datum redundant opnemen kan idd ook een goede optimalisatie zijn.

[mkleinman]

Paul C schreef op vrijdag 04 januari 2013 @ 23:40:
Volgens mij is dit de oplossing:
- Haal een lijst met meetwaarden uit je DB op chronologische volgorde
- Ittereer de lijst
- - en bereken hierbij alle tussen item(n) en item(n+1)
- - sla deze op in een tweede lijst
- als je de eerste lijst door bent heb je alle waarden in de tweede lijst en kun je de eerste discarden of iets als lijst1 = lijst2; doen.

Maand en datum redundant opnemen kan idd ook een goede optimalisatie zijn.

Ik heb het anders opgelost, ik herbereken alleen de datums die mogelijk aangepast zijn. Dus als de DB dit bevat:

1. 01-01-2013
2. 02-01-2013
3. 04-01-2013

En ik voer daarna een record in voor 03-01-2013 dan wordt vanaf 02-01-2013 t/m 04-01-2013 alles opnieuw berekend. Daarnaast gooi ik niet meer alles weg en begin ik overnieuw maar update ik bestaande records en insert alleen als ze niet bestaan.

Van 2.2 seconden terug naar niet meetbaar zo snel.

Next up: Jobs maken voor het scrapen van de KNMI site en jSunnyreports.

[Promy]

Een zeer interessant topic!
Het toeval wil dat ik de voorbije dagen bezig ben geweest met m'n eigen php scriptjes hiervoor.

Bij mij zit het als volgt in elkaar:

1. Er zijn 5 tellers aanwezig: totaal elektriciteitsverbruik / elektriciteitsverbruik warmtepomp / waterverbruik koud water / warm water en regenwater.
2. Deze pulstellers zijn aangesloten op een DS2423 1-wire teller. (die hebben elk 2 tellers, dus er zijn 3xDS2423 in gebruik)
3. M'n Raspberry Pi leest elke 5 minuten de tellers uit via een cronjob en steekt ze in een mysql database. Hierbij wordt bijgehouden = volgnummer(rowid) / datum / tijd / tellerstand
4. Via een php script kan ik dan grafieken maken van deze gegevens met jpgraph

Ik heb in het kerstverlof m'n grafieken wat uitgebreider gemaakt, en er ook dag/nachtverbruik ingezet voor de elektriciteitstellers.
Waar ik nu echter mee zit is dat het verschrikkelijk lang duurt om een grafiek te maken.
bv: het maken van een grafiek met de waardes van de 2 elektriciteitstellers (met ook dag/nacht) erin, duurt 50 seconden.

Ik vermoed dus dat ik niet zo efficient bezig ben
Ter info m'n php script voor 30 dagen 2 tellers uit te lezen (ik heb enkel basiskenning van php programmeren, dus het zal ongetwijfeld zeer rommelig zijn...)

De grafiek die hieruit komt is (let niet op de groene achtergrond, dit is omdat de bijhorende webpagina die kleur heeft ) (het is zo klein omdat er 3 grafieken van 30dagen en 3 grafieken van laatste 24h op 1 pagina die geschikt is voor tablet moeten kunnen)



Mocht er hier iemand hints kunnen geven om het te optimaliseren

PS: wat ik er graag wil bijzetten is het actuele verbruik. Maar m'n elektellers geven 800 pulsen per kWh. Heb ik het dan correct dat dit een resolutie geeft van 4500W per seconde? (dus alles kleiner dan 4500W zie je niet als je 1 seconde later uitleest?)

[mkleinman]

Druk bezig met het optimaliseren van mijn code. Het vullen van de afgeleide tabel met maanddata was ook niet de snelste ook al bevatte die tabel maar een kleine 100 records. Code is nu stukje netter, al het werk zit in 1 grote query.

Performance winst: van 0,5 seconden naar 0,035

* mkleinman loves code optimalization.

[hansdegit]

mkleinman schreef op vrijdag 04 januari 2013 @ 19:15:
Hmm, ben nu bezig met wat performance tuning van m'n code. In mijn profile report komt oa deze query naar boven die relatief duur is.

code:

      SELECT * INTO l_return
        FROM (
               SELECT * FROM mtr_raw_meterstanden mtr 
                WHERE mtr.datum <= p_datum
                  AND mtr.i IS NOT NULL 
                ORDER 
                   BY datum DESC
             )
       WHERE rownum = 1;

Je kunt toch volstaan met die inner query en dan met een cursor alleen het 1e record fetchen? Zal met een index op datum nooit meer dan 3 buffer gets mogen kosten. Zonder index op datum zal Oracle altijd een full table scan doen op raw_meterstanden.

[ Voor 5% gewijzigd door hansdegit op 05-01-2013 12:08 ]

[mkleinman]

hansdegit schreef op zaterdag 05 januari 2013 @ 12:08:
[...]

Je kunt toch volstaan met die inner query en dan met een cursor alleen het 1e record fetchen? Zal met een index op datum nooit meer dan 3 buffer gets mogen kosten.

Is inderdaad ook een optie, waarom heb ik daar niet aan gedacht. . Ga ik proberen

Edit:

http://stackoverflow.com/...t-row-which-one-is-better

met cursor eerste row fetchen is zelfs trager. DENSE_RANK schijnt de oplossing te zijn. Ga ik nu proberen.

Edit2:

Ook DENSE_RANK is nogal ranzig veel trager. van 1.2 seconde voor totale uitvoer naar 7.7 seconden. brrrr

[ Voor 30% gewijzigd door mkleinman op 05-01-2013 14:52 ]

[Paul C]

@mkleinman:
KNMI scrapen kan gewoon via de api. (Ik zeg het maar even, want het koste mij nogal wat moeite om 'm te vinden.):
http://www.knmi.nl/kd/daggegevens/scriptxs-nl.html

[mkleinman]

Ik gebruik nu een andere javascript API voor de grafieken. Gisteravond snel wat in elkaar gezet met highcharts. ( werkt wel op de IPAD! )

Interactieve scatterplot. Kan dynamisch jaren aan en uit zetten en de grafiek wordt automatisch geschaald.

[ericplan]

Het script van -LA- voor de Youless maakt ook gebruik van highcharts. Lijkt redelijk veel mogeliheden te bieden.

[Freemann]

Het script van LA?

HighCharts is inderdaad een mooi en uitgebreide charts Lib.
Helaas zijn de license niet zo vriendelijk. Echter voor huis tuin en keuken gebruik is het vooralsnog te doen en nog steeds gratis.

[hansdegit]

Ik ben zelf bezig om de steile muur van d3.js te beklimmen. Samen met crossfilter.js geeft dat heel basic bouwstenen en veel hoofdpijn....

Binnenkort interactieve daycharts met zoom. Alleen: beetje sloom op Firefox en ik heb het in IE nog niet aan de praat gekregen. Ik weet eigenlijk niet of ik veel moeite in IE ga steken, is niet zo web-standaard compliant, denk ik dan.