Övervaka elmätare LED

[maDa]

Hej!

Tänkte övervaka förbruknings-blink-LED på min elmätare i nya lägenheten. Den ger 1000 imp/kWh, vilket borde innebära 1 Wh per blink. Det blir med en Arduino, fototransistor och Bluetooth, alternativt bättre radiomodul om det behövs.

Men det finns två sätt att räkna har jag insett:
- Mäta tiden mellan pulserna (vilket kan bli nästan 2-3min nattetid), där tiden motsvarar en viss förbrukning
- Räkna antalet pulser på en viss bestämd tidsperiod, och räkna ut förbrukningen på det viset

Jag vill ha någerlunda responsivt, man ska gärna se när man kokar kaffe eller kör vattenkokaren. Systemet jag kommer logga till har 1 minut upplösning så lösningen måste kunna rapportera effekten med det intervallet. Räkna ut nått snitt på 10min är lite för segt känner jag. Just nu känns ta tiden mellan blinken vettigast, då de bara behövs två blink sen har man en siffra.

Hur hade ni gjort?

Jag har klurat på det där med metod ett, men kommer inte fram till något bra.

[Icecap]

Du vill ha en snabb återmatning av avläst data, alltså är det tiden mellan pulserna som gäller.

Men är det 10 minuter mellan varje puls och du vill logga med 1 minut intervall vill du alltså ha ut data med 10gg så hög upplösning som finns - och det kan man inte! Enl. Nyqvists teorem går det inte att sampla data på det vis helt enkelt, alltså måste du fuska!

Det blir då helt enkelt så att värdet för senaste "blinket" gäller fram till nästa uppdatering, är det alltså 10 minuter mellan blinken är det 6W som gäller - fram till det värde ändras.

[blueint]

Om kaffebryggaren använder 680 W:

1 kWh = 3 600 000 J = 3 600 000 W/s

Tid för att förbruka 1 kWh:
3 600 000 / 680 = 5294 sekunder

Med 1000 impulser per kWh:
3 600 000 / 680 / 1000 = 5,3 sekunder

Så det tar inte längre än 5,3 sekunder för att få en reaktion på kaffebryggaren och därefter blir det en uppdatering åtminstone var 5,3:e sekund.

Energiåtgång per puls: 0,001 kWh

Alternativ energiåtgång per puls: 3600 J (för att använda rena SI grundenheter)

[maDa]

Jepp, så sant. Men jag kan hantera på andra sidan att värden för tillfället är okänt, det är inga problem.

Men så.. 600s = 6W, 120s = 30W, 60s = 60W, 6s = 600W, 1s = 3600W osv.. ?

P = 3600 / t

Eller är jag ute och cyklar? Alltid varit lite snurrig på det där med tid...

[blueint]

Det verkar stämma. Tänk dock på att det blir medeleffekten mellan två pulser och att pulslängden varierar. Så mätarens värde som effektmätare är inget vidare.

[gkar]

Alternativ energiåtgång per puls: 3600 J (för att använda rena SI grundenheter)

Nja, nu är ju faktiskt inte J, (Joule) en SI grundenhet. Det du menar är:
"Alternativ energiåtgång per puls: 3600 kg·m2/s2 (för att använda rena SI grundenheter)"

[blueint]

Den är vart fall klart bättre än kWh

[maDa]

Har nu börjat på projektet och fungerar initialt rätt hyfsat. Ska lägga upp lite bilder när jag kommer hem. Pratar just nu Bluetooth till min hemmaserver, där jag loggför värdena till Graphite.

Datan som skickas är i följande format:

Kod: Markera allt

i:5528,Pw:115,Wh:2086;
i:5529,Pw:115,Wh:2086;
i:5530,Pw:115,Wh:2087;

Där i är en räknare, Pw är uträknad effekt och Wh är antal pulser sedan start.

Detta lyssnas sedan av ett Python-skript som masserar om variablarna till Graphite/Carbon-format och skickar till dess port på tcp/2003

Kod: Markera allt

servers.atom.metermon.meter0.i 5545 1384774832
servers.atom.metermon.meter0.Pw 112 1384774832
servers.atom.metermon.meter0.Wh 2091 1384774832

Det hela jobbar med 10-sekunders interval. Det fungerar rätt bra, visar med responsivitet när jag drar igång spisen eller t.om när kylen går igång. Men har lite programmässiga saker att lösa. T.ex som när det har varit hög förbrukning en stund, och sedan går ner. Då blir Pw noll ett tag tills det kommit en puls igen, eller ibland skjuter värdet i taket (typ 20kW) Måste fundera ut någon gående snitt-uträkning baserat på tio senaste eller så. Sen Wh vet jag inte riktigt hur jag ska hantera, men man får väll se det som en räknare, ungefär som bytes på ett nätverksinterface.

[Hedning]

Redan efter en sekund utan puls vet du att max är [någonting litet] Watt.
Efter två sekunder är det högst hälften av föregående. Du kan få mellanvärden
som inte nödvändigtvis behöver visas på displayen men som gör att det går att
räkna ut ett medelvärde som kryper neråt när förbrukningen plötsligt går ner.
Att vänta tio sekunder och bara ha ett gammalt och för högt värde går att komma runt.
Åt andra hållet, låg till hög förbrukning, är lättare när pulserna kommer mycket tätare.

Ett bra recept på glidande medelvärdesbildning (lågpassfiltrering) är att använda en
"fönsterfunktion" som inte är rektangulär (summera värden och dela med antalet t.ex.).
En "fönsterfunktion" som är en triangel och låter mittenvärdet få större "vikt" är t.ex.

((v1+v5)*0,333+(v2+v4)*0,666+v3)/3

Fem värden är med beräkningen (v1..v5) och den ger inga överslängar på medelvärdet.
Testa i Excel med spikar och steg i värdena så syns egenskaperna bra.

[maDa]

Ja, har också funderat runt fönsterfunktioner, men en rektangulärt som du säger, känns inte helt rätt heller.

Intressant formel! Har provat lite nu. Det är tanken att det är v3 är senaste mätningen?

[Hedning]

Sista samplet är v1 eller v5, det är symmetriskt. (numrerade i tidsordning)

Inga digitala filter är utan fördröjning, filterlängd och samplingsfrekvens avgör
när ändringar på indata syns på "utgången". I ditt fall är det väl inga problem
att sampla oftare än du visar resultatet.