slimme meter loggen

ik heb een slimme meter en lees hem uit op mijn PC.

ik heb snel een script in elkaar geflanst dat iedere 5 minuten in een cyclische buffer de laatste waarden stopt.

nu heb ik dus 300 meetwaarden die ik kan plotten in mijn domotica-pagina.

iemand een idee hoe bijvoorbeeld andere systemen dit doen? ik kan makkelijk een sql database maken (mijn pc is een nas met 4TB) maar ik wil enkel grafiekjes met laatste dag/maand/jaar

het jaar grafiekje hoeft natuurlijk geen 5 minuten resolutie.

Volgens mij is er "rrdb" round robin database.

Je zou dan een dag iedere 2 minuten kunnen bewaren, een week iedere 10 minuten, een maand ieder halfuur. een jaar ieder uur.

Maar.... als je gaat uitrekenen hoeveel data het je kost om gewoon iedere 10 sec (update slimme meter) alle veranderde data op te slaan, dan gaat het om een zodanig subtiele hoeveelheid data, dat ik heb besloten alles de sql database in te gooien. Mocht ik dan een keer een rare piek zien, dan kan ik een week en een maand terug om te kijken of dat de vorige woensdag ook was. Of de vorige 13e van de maand.

Mijn meter geeft met alles opslaan in mysql ongeveer 1Mb per dag. Dat is 3 jaar per gigabyte. Dus als ik van mijn 16G SD kaart 8G reserveer voor de SQL database, dan moet ik over ongeveer 24 jaar een grotere SD kaart kopen....

@rew: Dan is ie SDkaart al lang overleden vanwege het maximale aantal writes.
Ik log trouwens 1 keer/minuut actuele data (gooi ik weg na een week) en per 10 minuten de cumulatieve data (gooi ik nooit weg). Groeit mijn DB niet zo hard en gebruik een 32G SD kaart zodat ie lekker kan wear-levelen.

Ik gebruik al jaren (ik denk 6) een mysql database waarin om de minuut een 10 tal gegevens worden opgeslagen (temperatuur 5tal plaatsen, tellerstanden gas. ik bewaar ook in deze database opnamegegevens van een aantal webcams (naam weggeschreven file bij beweging)+ afzonderlijk op deze schijf de webcams file. deze staat op een ubuntu server met 80GB harddisk en atom processor, deze schijf is nog belange niet vol.
Etienne

ik heb een PC, dus aantal writes is niet zo'n groot probleem.

als je het zo bekijkt is 1x minuut wel te doen, 288 waarden zijn nu 16kb.

(5x int + id + timestamp)

rew,

ik lees de regels in met python. die stop ik in een dictionary, met het eerste deel van zin als index.

om de zoveel tijd haal ik de waarden die ik wil uit de dict en plaats ik ze in een query, ik kan dit gewoon cyclisch doen, de data wordt continue ververst.

zo te zien moet dat om de minuut wel lukken.

Op 28 december 2016 11:39:48 schreef JoWi:
@rew: Dan is ie SDkaart al lang overleden vanwege het maximale aantal writes.
Ik log trouwens 1 keer/minuut actuele data (gooi ik weg na een week) en per 10 minuten de cumulatieve data (gooi ik nooit weg). Groeit mijn DB niet zo hard en gebruik een 32G SD kaart zodat ie lekker kan wear-levelen.

SD kaart (of beter gezegd, de onderliggende NAND-flash) slijt niet zozeer door schrijven (wel een beetje), maar vooral door het wissen dat nodig is om te kunnen schrijven.

Als je zoals Rew langzaam een kaart volschrijft (en je een fatsoenlijk filesysteem gebruikt) hoef je nooit te wissen.

Beter is natuurlijk een "echt" opslagmedium, zoals een fileserver (nas) met fatsoenlijke backup- en management opties. Zodat de oplsag kunt vervangen zondere de historie of de datebase kunt verwisselen.
Want in de praktijk gaan SD-kaartjes over een periode van meerdere jaren ook aan andere dingen dan flash-slijtage kapot.

Ik heb vroeger een Arduino met wat sensoren metingen laten doen en de data verstuurd dmv een wifi module die een php pagina opvroeg met de gemeten waardes als parameters. Die php pagina schreef dan de metingen weg in een sql database (MariaDB).

Achteraf kon ik de metingen bekijken door data van een bepaalde periode op te vragen en met een API van google werd dit in een grafiek weergegeven.

De webserver en SQL database draaide gewoon op een NAS die ik toch al had staan.

Beter is natuurlijk een "echt" opslagmedium, zoals een fileserver (nas)

Of, voor wie het liever wat betaalbaar houdt, twee SD-kaartjes gespiegeld, bv. met md ... Voor mij is dat fatsoenlijk genoeg :)

Wie het héél waterdicht wil houden die kan ze dan vervangen, elk jaar eentje, bv., kost nog steeds geen drol.

Op 28 december 2016 13:05:37 schreef blurp:
[...]
Als je zoals Rew langzaam een kaart volschrijft (en je een fatsoenlijk filesysteem gebruikt) hoef je nooit te wissen.

Probleem is de database, ik gebruik sqlite en geen MySQL zoals Rew, maar bij het toevoegen van een record wordt ook de index bijgewerkt. Het is dus niet sequentieel volschrijven.
Daarom heb ik veel grotere kaart gebruikt dan nodig is.

Ik zie niet goed waarom men voor dit soort simpele sekwentiële data enige vorm van database zou willen gebruiken. Dat is toch op een mug schieten met een kanon? Simpelweg in een sekwentieel tekstbestand schrijven en je doet met awk en sed alles wat je maar wil. Of maak het bestand in een of andere csv-opmaak en je kunt het gelijk openen in een rekenbladprogramma om grafiekjes te trekken of zo. Keep It Simple and Stupid!!!

Mijn idee...

In een grijs verleden nog wel eens wat tegen een Oracle database server aan zitten kletsen. Daar bleken 'full table scans' als het om integers ed. ging vaak goedkoper dan 'indexed' enzo...

Overigens hangt de 'winst' dan wel van je filesystem af. Als je iets als FAT32 gebruikt (ik noem maar een willekeurige dwarsstraat), dan doet elke update natuurlijk nog steeds 'pijn'. Niet in de filedata, maar wel op het stukje waar de FAT staat... Tenzij het kaartje daar natuurlijk een slimme list op verzonnen heeft.

Overigens.... Was de smoes van de Roverheid om al die meters door te drukken nou niet 'energie besparing'? Zou het nou wat besparen als we allemaal spulletjes neer gaan zetten om te loggen? Ik heb me wel eens laten vertellen dat een search bij bijvoorbeeld een toko als google net zoveel energie kost als het zetten van een kop koffie - als je omrekent wat ze verstoken en hoeveel queries ze krijgen. Gevoelsmatig klopt dat niet, maar als het wel klopt, is het natuurlijk best raar dat men waterkokers met een beetje meer vermogen wil gaan verbieden maar 'draadloze communicatie' wel als basisbehoefte ziet.
Nou ja, off-topic. Succes met je project :)

het is een linux bak met EXT4 :)
schijf is 64 GB ssd.

de reden dat ik dit bouw is omdat ik lang geleden een arduino heb gemaakt om de lichten te schakelen. via een tcp verbinding kon ik 2 relais schakelen en een paar 433 MHz tussenstekkers van de action bedienen.

Daar heb ik een webinterface voor gebouwd en werkt nu al een tijd perfect. (zelfs de oppas gebruikt de tablet om de lampen te schakelen)

omdat het een webomgeving wil ik de grafiek in de browser renderen. .csv als backend kan dan natuurlijk, maar als je een tijdbestek wil opgeven is een index wel leuk. (tenzij je een ringbuffer van 300 regels hebt, zoals voorheen)

ik vind het zelf erg zonde. ik heb een proces in python dat de seriele poort leest. om diezelfde data in de browser te tonen moet ik een socket openen of een hele SQL database gebruiken.

??? Beweer jij nu echt dat python geen (liefst zelf-refreshend) paginaatje html zou kunnen genereren? Of wat zit ik te missen?
(maar @EricP heeft gelijk: dit gaat off-topic)

[Bericht gewijzigd door big_fat_mama op (16%)]

kijk eens naar domoticz, en de sourcecode kun je daar ook van bekijken.

En om peter een beetje te steunen...

Ik heb Domoticz ook op een Pi draaien en dit zijn de grafieken die daar via de webinterface bij horen...

Je kunt dus precies zien wanneer we vandaag de afwas hebben laten doen en de wasmachine bezig is geweest en hoe laat we hebben gegeten... zelfs mijn kopje koffie rond half acht staat er op....

En zoals je ziet 2e kerstdag zijn we helemaal los geweest. :-)

Weet je wel hoe gevaarlijk het is om al die data te bewaren. O-)
https://tweakers.net/nieuws/119447/amerikaanse-politie-vraagt-data-op-…

De verdachte had meer smarthomeproducten, zoals een slimme watermeter. Deze is eveneens gebruikt in de zaak. De meter toonde aan dat er op de avond van de moord meer dan 500 liter water was verbruikt. Het slachtoffer was aangetroffen in de hot tub van de verdachte en de politie denkt dat er veel water gebruikt is om sporen te wissen.

Een nieuwe toepassing van het aloude "ignorance is bliss" ..? ;)
Maar niets belet om de data te encrypteren.

Op 28 december 2016 22:26:55 schreef floppy:
Weet je wel hoe gevaarlijk het is om al die data te bewaren. O-)

Dan moet je daar in de thread (tweakers.net) mijn commentaar ook maar eens lezen en dan ook de reactie daaronder....

Maar niets belet om de data te encrypteren.

Dat zou betekenen dat je Arduino or rPI ook access tot die storage moeten hebben. Beiden lijken me nou niet zo'n heel veilige opslag voor de key.
Buiten dat: de Roverheid vindt dat die informatie van hen is, dus die komt met een decryptie bevel. Doe je het niet, dan ben je daarmee schuldig (ofwel: schuldig tot het tegendeel bewezen is).
En als jij het niet bewaart, dan doet je 'netbeheerder' het wel. Oh, per ongeluk voor debugging lazen we nog elk uur uit in plaats van eens in de 3 maanden... Goh, ja, dat is niet netjes van ons (maar nu wel ff handig!)
En voor dit soort zaken geloof ik het nog wel, echter men hangt steeds meer op aan deze data...

Op 28 december 2016 15:21:03 schreef EricP:
Ik heb me wel eens laten vertellen dat een search bij bijvoorbeeld een toko als google net zoveel energie kost als het zetten van een kop koffie - als je omrekent wat ze verstoken en hoeveel queries ze krijgen. Gevoelsmatig klopt dat niet

Google zegt zelf:

Google emits about 8 grams of CO2e per day to serve an active Google user—defined as someone who performs 25 searches and watches 60 minutes of YouTube a day,has a Gmail account, and uses our other key services.

8gr C02 komt overeen met 4-6kWh aan electriciteit. Genoeg om 40 liter water aan de kook te brengen. Hoeveel daarvan search is, en hoeveel "other key services"...

Op 28 december 2016 17:11:02 schreef Progger:
ik vind het zelf erg zonde. ik heb een proces in python dat de seriele poort leest. om diezelfde data in de browser te tonen moet ik een socket openen of een hele SQL database gebruiken.

Ik denk dat die SQL database (een paar procent CPU gebruik) minder energie verbruikt dan die RS232 poort (10Vpp in 3k)

Op 28 december 2016 14:23:00 schreef JoWi:
maar bij het toevoegen van een record wordt ook de index bijgewerkt. Het is dus niet sequentieel volschrijven.

En dan denk jij dat die index op dezelfde sectoren blijft staan en steeds herschreven wordt. Dat is logisch gezien ook wel zo, maar fysiek gebruikt ie iedere keer nieuwe sectoren voor die index. Wear leveling heet dat.

Op 29 december 2016 09:40:55 schreef blurp:
Ik denk dat die SQL database (een paar procent CPU gebruik) minder energie verbruikt dan die RS232 poort (10Vpp in 3k)

Die RS232 poort is niet RS232. Maar opto isolated TTL level, waarbij je zelf de 5V moet aanleveren....

[Bericht gewijzigd door rew op (27%)]

Op 29 december 2016 10:10:14 schreef rew:
[...]En dan denk jij dat die index op dezelfde sectoren blijft staan en steeds herschreven wordt. Dat is logisch gezien ook wel zo, maar fysiek gebruikt ie iedere keer nieuwe sectoren voor die index. Wear leveling heet dat.

Yep, dat stond ook in mijn post.

[...]
Die RS232 poort is niet RS232. Maar opto isolated TTL level, waarbij je zelf de 5V moet aanleveren....

En dan nog geïnverteerd ook. Dus bij gebruik van een MAX232 of zo moet je het 5V signaal ook nog inverteren.

@EricP: je hebt gelijk, ik verwarde tussen de data in de meter (waar je als burger moet afblijven want de meter is niet van jou, dus ook niet de data die erin zit) en de zelfgelogde data. Die kun je wel degelijk encrypteren, maar dat verandert niet zoveel aan de vertrouwelijkheid van je data: het lijkt niet zo waarschijnlijk dat iemand je Raspi of zo gaat hacken om je electriciteitsverbruik te kunnen analyseren - zonder te beginnen met te weten dat er op die bepaalde Raspi dat en dat soort data staat.

Been there. Done it. Data uit chippies peuteren om iets aannemelijk te kunnen maken. Niet strafrechtelijk maar civiel in deze... Wat rew met HDDs doet, heb ik voor een opdrachtgever wel eens met NAND en NOR flash gedaan...