Data van Conrad EnergyCount 3000 ontvangen (868.3Mhz)

[ThinkPad]

Ik werd getriggerd door deze post:

Batilan schreef op woensdag 04 februari 2015 @ 00:03:
Wellicht ook interessant voor het meten en visualiseren van energie verbruik van individuele apparaten: De Conrad Energy Count 3000 (ook wel verkrijgbaar onder de naam Velleman NETBSEM4). Deze zendt iedere 5 seconden het actueel opgenomen vernogen (in W) totaal energieverbruik (in Ws), totale meet tijd, totale tijd "aan" uit (op 868 MHz). Al verkrijgbaar voor minder dan € 10,- / stuk (bij 2 "plugs" inclusief display om actuele waardes uit te lezen)

Middels een $8 RTL-SDR dongle op te vangen middels ec3k en Gnuradio, vervolgens middels een scriptje inschieten in een dashboard (b.v. emoncms) geeft leuke inzichtelijke plaatjes:

[afbeelding]

Afgelopen weekend op een Raspberry gezet, draait stabiel (wel enkele overflows maar voldoende geldige packets om met een redelijke resolutie te meten).

Batilan in "Serieus elektriciteit besparen"

Dit zou een geweldige low-cost vervanger zijn voor het Plugwise systeem. Je zou bijv. van elke plug het verbruik in je domoticasysteem kunnen tonen!

De data valt dus met een RTL-SDR te sniffen. Naar mijn idee is dat echter omslachtig en vreet het CPU als je dit op een Pi draait (20% op een i5 volgens onderstaande blogs ).

Toevallig was ik laatst bezig dit: http://gizmosnack.blogspo...ug-energy-meter-hack.html na te maken (goedkope energiemeter, data van de chip aftappen via SPI met een Arduino).
Maar draadloos is natuurlijk nog mooier.

Mijn idee is om de data van de ontvanger af te tappen (SPI?), door er bijv. een Arduino aan te knopen en die Arduino dan aan je PC of Raspberry te knopen. Dan heb je geen last van het CPU-gebruik van de SDR-stick, omdat de ontvanger bijna al het werk doet.

Info die ik gevonden heb:
https://www.tablix.org/~a...neering_energycount_3000/
https://www.tablix.org/~a.../energycount_3000_part_2/
http://forum.jeelabs.net/comment/4020
https://github.com/avian2/ec3k

Iemand ideeën? Ik heb zelf alleen wat basiskennis van Arduino / Raspberry, als ik dat JeeLabs topic zie dan duizelt het mij een beetje Al zijn er volgens mij wel mensen die het is gelukt om het dataverkeer met een RFM12B module op te pikken.

[ Voor 43% gewijzigd door ThinkPad op 04-02-2015 16:35 ]

[franssie]

En hier is de conrad versie (Alleen de zender): https://www.conrad.nl/nl/...meter-19999-h-123049.html

Ik kan er eventueel een of twee ter beschikking stellen mochten mensen dit een leuk project vinden maar niet gelijk zo'n ding willen kopen.

[ThinkPad]

Oh, ik zie net dat er al een topic bestaat hierover: Reverse engineeren RF protocol
Nouja laten we maar verder gaan in dit topic

In dat topic werd deze link ook genoemd: http://www.elektronikforu...viewtopic.php?f=3&t=47546

Ik zie nu al wel dat het voor mij iig veel te ingewikkeld is... had gehoopt dat men inmiddels zover was dat je een paar datalijntjes aan de CPU kon knopen, sketch op de Arduino laden en gaan met die banaan... Maar het is een stuk ingewikkelder.

[ Voor 31% gewijzigd door ThinkPad op 04-02-2015 16:47 ]

[Batilan]

ThinkPadd schreef op woensdag 04 februari 2015 @ 16:24:
Ik werd getriggerd door deze post: Batilan in "Serieus elektriciteit besparen"

Die user ontvangt met een RTL-SDR de data die de energie-meetpluggen draadloos (868.3Mhz) sturen naar de ontvanger.
Dit zou een geweldige low-cost vervanger zijn voor het Plugwise systeem. Je zou bijv. van elke plug het verbruik in je domoticasysteem kunnen tonen!!

De data valt dus met een RTL-SDR te decoderen. Naar mijn idee is dat echter omslachtig en vreet het CPU als je dit op een Pi draait.

Op zich valt het met de omslachtigheid wel mee (althans voor een gemiddelde tweaker ;-)

1. Een rtl-sdr kopen op e-bay voor ca $8 en in de USB poort van je Pi (of Linux bak) steken
2. Gnuradio downloaden, compileren en installeren
3. ec3k downloaden, installeren en starten
4. een scriptje maken om de output in je favoriete database/dashboard in te schieten
5. klaar

Ik zal eens kijken hoe hoog het CPU verbruik ligt en hier melden, wellicht kan de samplerate nog wat omlaag zodat het CPU verbruik wat lager wordt, ook zou wellicht het direct in C programmeren van de aan elkaar geknoopte Gnuradio blocks wat minder CPU vergen, maar dat is dan wel weer een aardig projectje.

Toevallig was ik laatst bezig dit: http://gizmosnack.blogspo...ug-energy-meter-hack.html na te maken (goedkope energiemeter, data van de chip aftappen via SPI met een Arduino).

Maar draadloos is natuurlijk nog mooier.

Mijn idee is om de data van de ontvanger af te tappen, door er bijv. een Arduino aan te knopen en die Arduino dan aan je PC of Raspberry te knopen. Dan heb je niet het CPU-gebruik van de SDR-stick.

Wil je fysiek het signaal op de printplaat van de plugs gaan aftappen? In principe zou de aan de hand van de ec3k code de bitstream moeten kunnen decoderen op je Arduino lijk me? OK, dus je wilt de data van de ontvanger zelf aftappen, ik begrijp uit de genoemde artikelen dat dat nog niet zo eenvoudig gaat. Voor mij is deze oplossing dan weer wat omslachtiger, maar ja ik ben meer van de software

Info die ik gevonden heb:

https://www.tablix.org/~a...neering_energycount_3000/
https://www.tablix.org/~a.../energycount_3000_part_2/
http://forum.jeelabs.net/comment/4020
https://github.com/avian2/ec3k

ec3k is inderdaad de software welke ik heb gebruikt.

Iemand ideeën? Ik heb zelf alleen wat basiskennis van Arduino / Raspberry, als ik dat JeeLabs topic zie dan duizelt het mij een beetje Al zijn er volgens mij wel mensen die het is gelukt om het dataverkeer met een RFM12B module op te pikken.

Het signaal is FSK gemoduleerd, als je met de RFM12B het FSK gemoduleerde signaal weer naar een bitstream (of in ieder geval een puls-treintje) krijgt (met een squelch voor de stille periodes) dan zou je de processor aardig kunnen ontlasten? Het decoderen naar de juiste waardes zou je geheel kunnen afleiden uit de ec3k code.

Ik ken de RFM12B nog onvoldoende om te beoordelen of je de FSK demodulatie voor elkaar kunt krijgen.

[Infant]

Interessant. Die tosch gast van jeelabs heeft het toch min of meer helemaal uitgevogeld? Hij gebruikt er een JeeLinkV3 voor, wat basically een RFM12B + Arduino op een usb stick is. Want hoewel SDR leuk is om uit te vinden wat het is, lijkt het me minder ideaal om er hele tijd een paar GFlops (en dus kWatt/hr en) tegen je RF tooltje aan te smijten, terwijl ze zo blij zijn met een eigen verbruik van minder dan 0.3 Watt.

Zelf heb ik zo'n ding van de Action die alleen kan schakelen, zeg maar dit, maar dan nog goedkoper. Die luistert op magische wijze naar seriele data die ik zo'n 443 MHz zendertje heen duw. (Bij de buren doen ze dan ook klik, leuk.)

Ik zoek al een tijdje naar een ding die beide kan, dus meten en schakelen, uiteraard voor zo rammend weinig dat ik er vraagtekens bij ga hebben. Je zou zeggen als zo'n chinees ze los kan maken, dat er ook iemand een 1+1=1 gedaan heeft... maar ik kan ze niet echt vinden. En om er nou twee in elkaar te prikken is ook weer zo jammer.

[franssie]

Als het goed is heb ik nog ergens een jeelink liggen, maar heb ook een RFM12B besteld.
Idealiter zou je een aantal setups willen:
- RFM12B aan USB (kan iedereen zelf kiezen welke hardware er verder achter komt te hangen, bijvoorbeeld een synology NAS)
- Jeelink (lijkt al te werken) danwel een RFM12B aan een arduino
- RFM12B aan een raspberry Pi (meer de alles in één dommotica oplossing, meten én sturen)
- SDR

En loggen is één ding, ik ben nu met https://github.com/emoncm...er/docs/WindowsInstall.md aan het stoeien om de logging

[ThinkPad]

Ik heb als domotica oplossing 'Domoticz'. Daarbij is het erg makkelijk om een virtuele sensor aan te maken en daar de data in te stoppen. Zie: http://www.domoticz.com/wiki/Domoticz_API/JSON_URL%27s (zoek ff op 'counter'). Is niet meer dan een URL aanvragen met een GET-request en op de juiste plek een waarde te zetten.

Het is mij al gelukt om de data van een DS18B20 temperatuursensor aan een Arduino naar Domoticz te voeren door de Arduino een URL met daarin de juiste waarden aan te roepen.

[ Voor 12% gewijzigd door ThinkPad op 04-02-2015 19:59 ]

[mcDavid]

20% load op een i5 is schromelijk overdreven. Ik draai een ads-b receiver op een Rpi en die heeft een totale load van rond de 0.4-0.5. De receiver zelf kan max 500mA verbruiken en een Rpi doet ook zoiets, dus totaal zou je maximaal aan 1A ofwel 5W zitten. Kan het eventueel wel een keer meten, al heb ik een model B die minder zuinig is als de B+.

Op een moderne x86 CPU valt de load zo'n beetje weg in de marge. Bovendien kan ik me voorstellen dat een stuk of 20 vliegtuigen tracken meer load veroorzaakt dan één node die relatief weinig data uitzend in de buurt.

[GENETX]

nvm

[ Voor 97% gewijzigd door GENETX op 04-02-2015 20:48 ]

[franssie]

nvm inderdaad (433 of 868) - @GENETX elke input en meedenken is welkom!

[ Voor 95% gewijzigd door franssie op 04-02-2015 21:25 ]

[Batilan]

Infant schreef op woensdag 04 februari 2015 @ 19:38:
Interessant. ... Want hoewel SDR leuk is om uit te vinden wat het is, lijkt het me minder ideaal om er hele tijd een paar GFlops (en dus kWatt/hr en) tegen je RF tooltje aan te smijten, terwijl ze zo blij zijn met een eigen verbruik van minder dan 0.3 Watt. ...

Even gemeten met mijn "nieuwe" Velleman NETBSEM4, die eigenlijk een "La Crosse Techology Remote Cost Control Monitor" blijkt te zijn (op de pluggen staat "model RT-110" op het display staat geen type aanduiding).

Het verbruik van mijn Raspberry Pi 2+ is zo'n 4 watt inclusief RTL-SDR stick volgens de Voltcraft/Velleman/La Crosse energie monitor. Afgezien van een eventuele onbetrouwbaarheid van de meter lijkt dat dus wel mee te vallen

Helaas blijkt wel dat de capture + ec3k python programma's praktisch alle CPU cycles van de Raspberry opvreten (ca 55% voor ec3k en 40% voor capture.py), vandaar ook de eerder genoemde overflows. Voor de SDR oplossing zul je dus voorlopig een Raspberry dedicated moeten inzetten (tenzij je alleen wat niet timing kritische software er op draait). Op zich blijft de ec3k software wel bruikbaar als je er iets naast draait wat veel CPU vreet, maar je mist gewoon wat meer samples.

Een oplossing waarbij een receiver zelf de FSK decodering kan doen zou dus wel mooier zijn. Wellicht dat met optimalisatie van de software: lagere sample rate, capture + python Gnu radio blocks omschrijven naar C een acceptabeler CPU verbuik oplevert.

Als iemand hier thuis is in het inzetten van een RFM12B (of iets vergelijkbaars) t.b.v. FSK demodulatie dan komen we wellicht verder met een dergelijke oplossing.

Voorlopig offer ik 1 van mijn Raspberry's op aan de monitoring.

[franssie]

Ik heb een RFM12B ontvangen dit weekeinde. Voor eerst zal ik denk ik ook voor de SDR oplossing gaan (ik heb wel een Pi B over).
Parrallel ben ik bezig mijn Jeelabs plug goed aan de praat te krijgen. Hij ontvangt wel de signalen - maar het decoden lukt niet. Pas als ik deze werkend (want ik snap nu nog niets van de configuratie, maar ik ben lerende) heb ga ik denk ik de RFM12B aan een Pi hangen en kijken of ik arduino code han herbruiken op de Pi. Dat is denk ik de mooiste oplossing, evt met een printje - maar dat is nog toekomst muziek. Misschien is de jeelink wel gewoon een prima oplossing voor deze meters aangezien die ook niet zo heel erg duur is (maar momenteel uitverkocht http://www.digitalsmarties.net/products/jeelink )

edit:// Ik had dus beter dit board kunnen kopen - in plaats van die losse RFM12B-, prik je zo op de rPi: http://shop.openenergymon...e-station-receiver-board/

[ Voor 31% gewijzigd door franssie op 09-02-2015 11:10 ]

[mcDavid]

Batilan schreef op vrijdag 06 februari 2015 @ 10:57:
[...]

Een oplossing waarbij een receiver zelf de FSK decodering kan doen zou dus wel mooier zijn. Wellicht dat met optimalisatie van de software: lagere sample rate, capture + python Gnu radio blocks omschrijven naar C een acceptabeler CPU verbuik oplevert.

Ik weet er zelf het fijne niet van, maar zou je niet kunnen kijken of je de GPU in kunt zetten voor de decoding?

Ik weet dat iig rtlsdr-flarm dat doet op de Raspberry Pi, maar helaas zijn daar geen sources van.

[Candymirror]

Super topic! Dit idee had ik een jaar geleden al. http://gathering.tweakers...message/41810722#41810722

Ik heb alle onderdelen al een eeuwigheid in huis liggen (DVB-t stick, en de energie meters) het is me tot op heden nooit gelukt om een werkende combinatie van de software te krijgen. Meerdere pogingen ondernomen, op de raspberry en mijn intel werkstation altijd compile errors gehad voor gnuradio/rtl-sdr die ik niet heb kunnen fixen. Ook de apt-ubuntu packages geinstalleerd staan, echter wouden die niet samenwerken met het EC3k python script van Avian.
Inmiddels heb ik het dan ook maar opgegeven. Maar als het anderen is gelukt, waarom zou het mij dan niet lukken?

Kan er een lijstje gemaakt worden van het OS/ software en werkende versies? Of nog beter/makkelijker een image

Ik zie net dat er onlans een update voor EC3k is geweest en dat er nu dus versies worden vermeld.
Combination of versions last known to work:

GNU Radio release 3.7.5
rtl-sdr git commit d447a2e9 (2014-08-26)
gr-osmosdr git commit 48045b59 (2015-01-10)


BTW. Als je de EC als opbrengstmeter wil gebruiken, zul je draden moeten wisselen. Je moet de afgaande 220v draad omwisselen met de inkomende 22v draad op de print. dankzij de massa van de shunt weerstand (gewoon een stukje massief koperdraad van 2,5mm2) en de hoeveelheid soldeertin op de print is dit iets lastig, maar wel te doen.

[ Voor 11% gewijzigd door Candymirror op 09-02-2015 14:00 ]

[Batilan]

Candymirror schreef op maandag 09 februari 2015 @ 12:34:
Super topic! Dit idee had ik een jaar geleden al. http://gathering.tweakers...message/41810722#41810722


Kan er een lijstje gemaakt worden van het OS/ software en werkende versies? Of nog beter/makkelijker een image

Ik zie net dat er onlans een update voor EC3k is geweest en dat er nu dus versies worden vermeld.
Combination of versions last known to work:

GNU Radio release 3.7.5
rtl-sdr git commit d447a2e9 (2014-08-26)
gr-osmosdr git commit 48045b59 (2015-01-10)

Ik ben begonnen met een image met Gnuradio er op omdat het compileren anders zo lang duurt zie:
http://garethhayes.net/gnu-radio-for-raspberry-pi/
Moest wel even een kleine fix toepassen vanwege een issue met volk_malloc, zie hier:
http://lists.gnu.org/arch...dio/2014-03/msg00419.html

Zal binnenkort een compleet blogje maken met alle stappen.

[franssie]

Een blogje wordt gewaardeerd. Vraag me ondertussen ook af hoe ik de berichten (SDR of Jeelink) naar het dashboard push - ik had gehoopd dat deze ook kan pullen maar ik moet dus een soort brug bouwen die informatie ophaald (bijvoorbeeld van mijn andere Pi die aan de hoofdmeter hangt) en de SDR/Jeelink en dat dan naar het emoncms pushed, of domoticz mocht ik dat ook gaan installeren.

---

En ik heb ontvangst met de Jeelink had ik al in 2012 kunnen hebben ... w as ik dat topic maar blijven volgen op hun topic.
met testscripts 13 (versie 14 komt niet door de arduino lader)- moest register 2 (R2) 5 notches lager zetten en toen kwamen ze mooi binnen, nu nog iets bijstellen voor betere ontvangst van de zenders op afstand en kjken of de 'baudrate' van de ontvangst ook nog iets bij te stellen is.

Nu me verdiepen in de berichtenbus, schijnt er al te zijn maar zoals opensource betaamt ook niet tot slecht gedocumenteerd ... het blijft hobby

[ Voor 43% gewijzigd door franssie op 09-02-2015 20:47 ]

[Batilan]

franssie schreef op maandag 09 februari 2015 @ 15:16:
Een blogje wordt gewaardeerd. Vraag me ondertussen ook af hoe ik de berichten (SDR of Jeelink) naar het dashboard push - ik had gehoopd dat deze ook kan pullen maar ik moet dus een soort brug bouwen die informatie ophaald (bijvoorbeeld van mijn andere Pi die aan de hoofdmeter hangt) en de SDR/Jeelink en dat dan naar het emoncms pushed, of domoticz mocht ik dat ook gaan installeren.

Niet 100% on-topic maar wellicht wel interessant: Zelf heb ik voor de rtlsdr oplossing een eenvoudig perl parsing scriptje geschreven wat de data via http als emoncms 'input' aanlevert, daar heb je natuurlijk weinig aan voor je Jeelink oplossing. Ik wil dit gaan omzetten naar een oplossing welke MQTT / Mosquitto gebruikt, dat zal ik opnemen in de blog.

Ik zie dat er ook een MQTT client implementatie voor Arduino is, dus die kun je wellicht voor je Jeelink gebruiken?

Samen met mqttwarn op een Linux node (Raspberry?) kun je eenvoudig met een flink aantal backend systemen interfacen waaronder emoncms, met de http service kun je waarschijnlijk ook vele andere backends interfacen. Dit is een leuke flexibele oplossing, je moet wel een betrouwbare netwerk verbinding naar je MQTT server hebben (lukt dat met een Jeelink?), sowieso verstandig om de data te bufferen indien dat mogelijk is lijkt me.

En ik heb ontvangst met de Jeelink had ik al in 2012 kunnen hebben ... w as ik dat topic maar blijven volgen op hun topic.
met testscripts 13 (versie 14 komt niet door de arduino lader)- moest register 2 (R2) 5 notches lager zetten en toen kwamen ze mooi binnen, nu nog iets bijstellen voor betere ontvangst van de zenders op afstand en kjken of de 'baudrate' van de ontvangst ook nog iets bij te stellen is.

Nu me verdiepen in de berichtenbus, schijnt er al te zijn maar zoals opensource betaamt ook niet tot slecht gedocumenteerd ... het blijft hobby

Ben benieuwd naar het resultaat, je krijgt hiermee dus netjes gedecodeerde data binnen (en gelogd in flash?).

[franssie]

Batilan schreef op dinsdag 10 februari 2015 @ 18:15:
[...]

Dank voor de MQ tips, zal er induiken. Ik vind het on-topic, aan alleen ontvangen heb je niet zoveel (het is immers afgesplitst uit het energie bespaar topic waar meten=weten het credo is.

Dit is wat ik krijg in een TTY terminal:

>r2 A679 #hier zet ik de frequentie wat omlaag in de ontvangst chip

R2 A679 #readback van de jeelink

>E C #hier start ik de decode

R2 A679 #readback van alle registers

R3 C610

R4 94A2

R5 C2AC

R6 CA8F

R7 CEAA

R9 C4A7

drecvintr start t=123575 #tijdstamp (in sec) van de jeelink >> en dan komen de gedecodeerder waarden.

EC3K 125857172 ID=6FAF 82798 sT 82797 sON 1131 Wh 79.5 W 84.3 Wmax 2 resets (3 n
oCRL)

EC3K 127947284 ID=7840 64942080 sT 64942080 sON 12262 Wh 111.8 W 158.5 Wmax 2 re
sets (3 noCRL)

EC3K 128476604 ID=FE05 516991 sT 500609 sON 1161 Wh 18.9 W 130.8 Wmax 2 resets (
7 noCRL)

De ID's kloppen, de verige waarden ook lijkt het.

Nu nog zien te pushen naar emoncs etc, en eens kijken hoe ver ik ze kan ontvangen (eventueel moet ik aan een paar verderweg gelegen zenders een betere antenne solderen maar als zendamateur moet dat lukken.

[Batilan]

franssie schreef op dinsdag 10 februari 2015 @ 18:37:
[...]

Dit is wat ik krijg in een TTY terminal:

[...]

De ID's kloppen, de verige waarden ook lijkt het.

Nu nog zien te pushen naar emoncs etc, en eens kijken hoe ver ik ze kan ontvangen (eventueel moet ik aan een paar verderweg gelegen zenders een betere antenne solderen

Ziet er goed uit . Ik ben nog niet zeer bedreven met de Jeelinks en Arduino's (heb er zelfs nog niets mee gedaan ) maar zou ik met de RFM12Pi v2 en de RF12test13.pde sketch dit ook voor elkaar kunnen krijgen (wellicht enkele poorten aan te passen)? Hoewel ik wellicht beter ook voor een Jeelink kan gaan omdat deze breder inzetbaar is en de sketch ongewijzigd bruikbaar is en deze zonder problemen aan een RPi gehangen kan worden?

Oh ja, en hoe zit het met de verkrijgbaarheid van Jeelink en RFM12Pi in Nederland?

maar als zendamateur moet dat lukken.

Leuk! Ben zelf bezig voor de N-licentie

[ Voor 3% gewijzigd door Batilan op 10-02-2015 19:52 . Reden: Vraag over verkrijgbaarheid Jeelink en RFM12Pi ]

[franssie]

Jeelink had ik dacht ik al een link naar geplaatst (ga ik zo opzoeken) maar die is nu tijdelijk uitverkocht,
En succes met je N, heb ik zelf ook.
Arduinos etc heb ik zat liggen, grotendeels ongebruikt, net als de Jeelink, Ik ben zo'n prutser die als ie iets leest dan gelijk de componenten koopt maar er eigenlijk ook de tijd niet voor heeft om er echt iets mee te doen (vandaag koperbuis gekocht om een j-pole marifoon antenne te solderen voor een AIS project en een 1970 sailor groene marifoon die ik ook eens op marktplaats tegenkwam, kan ook zo maar twee jaar in de schuur liggen tot ik eens de geest krijg om lekker te gaan grof-solderen)

de jeelink http://www.digitalsmarties.net/products/jeelink (tijdelijk uitverkocht)
De rPi ontvanger http://shop.openenergymon...e-station-receiver-board/ (er staat uitverkocht bij maar als ik het goed lees geldt dat alleen voor de 433 versie en is de 868 wel direct leverbaar)

[ Voor 12% gewijzigd door franssie op 10-02-2015 20:46 ]

[Batilan]

Even mezelf verbeteren:

Batilan schreef op dinsdag 10 februari 2015 @ 18:15:
[...]
Ik zie dat er ook een MQTT client implementatie voor Arduino is, dus die kun je wellicht voor je Jeelink gebruiken?

Aangezien het hier om een Jeelink gaat hangt ie waarschijnlijk aan een host die het MQTT werk veel beter kan uitvoeren?

[franssie]

Ik ga denk ik inderdaad MQTT op een rPI zetten en dan kijken of ik er verder mee kom. Die arduino implementatie is voor arduino's met een ethernet shield - die heb ik dan weer niet.
Thanks!
edit:// lijkt erop dat dit me ook kan gaan helpen https://learn.adafruit.co...node-red/what-is-node-red om alles te interfacen.

[ Voor 28% gewijzigd door franssie op 12-02-2015 16:30 ]

[Batilan]

Een update, het lijkt er op dat de Rfm12Pi v2 zoals genoemd in:

franssie schreef op dinsdag 10 februari 2015 @ 20:34:
De rPi ontvanger http://shop.openenergymon...e-station-receiver-board/ (er staat uitverkocht bij maar als ik het goed lees geldt dat alleen voor de 433 versie en is de 868 wel direct leverbaar)

Intussen niet meer verkocht wordt en is vervangen door de rfm69pi. De rfm69pi is gebaseerd op de rfm69cw welke bedoelt is om de rfm12b op te volgen.

[ Voor 9% gewijzigd door Batilan op 16-02-2015 10:38 . Reden: Link naar Rfm12Pi V2 en rfm69pi beschrijvingen toegevoegd ]

[Candymirror]

Ik had gisteren even tijd om met m'n raspberry en rtlsdr stick te knoeien. Op zich lijkt de software het nu te doen. Hij blijft echter eindeloos Noiselevel -** decibel spugen. Er komen geen waardes langs, wat bovendien opvalt zijn de O's na de eerste paar regels.

linux; GNU C++ version 4.6.3; Boost_104900; UHD_003.004.002-0-unknown

gr-osmosdr v0.1.3-4-g42c66fdd (0.1.4git) gnuradio 3.7.5git-0-g2bb2b314
built-in source types: file fcd rtl rtl_tcp uhd hackrf rfspace
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Using 16 buffers of size 262144.
Found Rafael Micro R820T tuner
Using Volk machine: generic
Noise level: -39.5 dB
Noise level: -35.3 dB
Noise level: -33.1 dB
OOOOOOONoise level: -32.1 dB
OOOOOOOOONoise level: -31.4 dB
OOOOOOONoise level: -30.7 dB
OOOOOOOOOOOOOONoise level: -30.7 dB
OOOOOOOOOONoise level: -30.3 dB
OOOOOOOOONoise level: -29.8 dB
OOOOOOOONoise level: -29.4 dB
OOOOOOONoise level: -28.9 dB


iemand een idee wat er mis is?

[Batilan]

Candymirror schreef op dinsdag 17 februari 2015 @ 11:12:
Ik had gisteren even tijd om met m'n raspberry en rtlsdr stick te knoeien. Op zich lijkt de software het nu te doen. Hij blijft echter eindeloos Noiselevel -** decibel spugen. Er komen geen waardes langs, wat bovendien opvalt zijn de O's na de eerste paar regels.

linux; GNU C++ version 4.6.3; Boost_104900; UHD_003.004.002-0-unknown

gr-osmosdr v0.1.3-4-g42c66fdd (0.1.4git) gnuradio 3.7.5git-0-g2bb2b314
built-in source types: file fcd rtl rtl_tcp uhd hackrf rfspace
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Using 16 buffers of size 262144.
Found Rafael Micro R820T tuner
Using Volk machine: generic
Noise level: -39.5 dB
Noise level: -35.3 dB
Noise level: -33.1 dB
OOOOOOONoise level: -32.1 dB
OOOOOOOOONoise level: -31.4 dB
OOOOOOONoise level: -30.7 dB
....


iemand een idee wat er mis is?

Was afgelopen weekend bezig om de gehele setup te reproduceren om mijn beloofde blogje te kunnen schrijven. Ik liep tegen precies hetzelfde aan. Na wat speuren kwam ik er achter dat de ec3k_recv in de source tree wel zijn werk deed terwijl de geïnstalleerde versie in /usr/local/bin zich zoals hierboven gedroeg.

Kun je ook eens proberen of eck3_recv in je source tree het wel doet. Dit heeft wellicht te maken met de beschikbare python modules. Overigens geeft ook de ec3k_recv in de source tree op mijn Raspberry de overflows (O), maar daartussen door wel regelmatig gedecodeerde paketten.

Ik moet nog uitzoeken waar het probleem precies zit, ik zal dit artikel updaten zodra ik meer weet.

De overflows op een Raspberry zijn vrees ik "normaal" omdat de cpu amper toereikend is om alle ontvangen data te verwerken. Op een sneller platform zag ik ze niet als alles goed geconfigureerd was.

[DavidZH]

Ik wil ook nog wel een duit in het zakje doen: Panstamp.

Een Arduino achtige met óf een AVR processor en een CC2500, óf een TI CC430 er op. Die radio chips van TI kunnen alle vrije frequenties onder de 1GHz aan, maar het boarddesign bied eigenlijk vooral 868MHz, ideaal voor wat hier gezocht word lijkt me (wordt aangepast in V3 zodat ook 433MHz werkt.

Ze zijn te programmeren met een gepatchte Arduino IDE, superzuinig en klein. Ze kosten €18.

Ze kunnen dan het decoderen voor hun rekening nemen en de ruis filteren. De ontvangen data kunnen dan via USB naar de PI gestuurd worden. Of desnoods met een ESP8266 direct het netwerk op.

Ik ben nu aan het wachten op mijn exemplaar (uitverkocht, want grote interesse... ) zodat ik ik me kan gaan richten op de draadloze thermostaatknoppen...

[Batilan]

DavidZH schreef op dinsdag 17 februari 2015 @ 20:20:
Ik wil ook nog wel een duit in het zakje doen: Panstamp.

Ziet er interessant uit, ik ben heel benieuwd naar je ervaringen. Aangezien de AVR versie min of meer Arduino compliant is kun je wellicht de hierboven genoemde Arduino sketch als uitgangspunt nemen voor het decoderen. Maar voor het radio deel zul je waarschijnlijk wel wat moeten uitzoeken en aanpassen?

[ Voor 0% gewijzigd door Batilan op 17-02-2015 23:14 . Reden: spelfaut ]

[franssie]

Al die 00 waarden zag ik ook bij mijn jeelink toen mijn frequentie niet goed stond, die van mij moest iets omlaag, misschien dat daar wat winst te halen valt? (kan natuurlijk zijn dat ie bij de SDR wat omhoog moet en van SDR is bekend dat ze sowieso niet erg precies zijn out of the box als het op frequentie aankomt)

---

[rant]waarom is er bij open source geen documentatie, laat staan fout afhandeling? Node Red is echt een geniaal concept, ontwikkeld door IBM nota bene, super krachtig maar documentatie ... nope.
Zelfde voor Emoncms, schitterend concept, maar man o man wat een gedoe. Een datamodel oid zou al helpen.
Ik ben een groot voorstander voor open source maar dit soort mooie projecten laten wel zien waarom het zo fantastisch is (het was er anders niet) en waarom het op deze manier niets groots word (het is in feite voor 99,9% van de wereld bevolking onbruikbaar). [/rant]
Dit gezegd hebbende, ik heb nu wel een basic flow van mijn slimme meter naar de emoncms aan de praat. Volgende stap is de jeelink hierin op nemen en die shit ook posten. Voordeel van Node Red is dat het 'relatief eenvoudig' wisselen is naar andere bronnen en afnemers van data. Twitter en email (etc) intergratie is overigens wel echt gaaf van Node Red.

[ Voor 59% gewijzigd door franssie op 17-02-2015 23:11 ]

[Batilan]

Intussen heb ik een eerste versie van mijn eerder beloofde blogje gemaakt, zie:
https://batilanblog.wordp...g-ec3k-with-raspberry-pi/

Omdat ik nog geen complete beschrijving gevonden had heb ik hem maar direct in het Engels gemaakt. Ik maak ook nog wel een wat verkorte NL versie op Tweakers.net als daar behoefte aan is.

Ik heb geprobeerd zo compleet mogelijk te zijn. Ik ben benieuwd naar alle ervaringen bij het volgen van dit stappenplannetje. Er valt vast nog wel wat te verbeteren.

[franssie]

@Batlian, Netjes! Ik zal toch eens kijken of ik een SD kaartje kan vinden om je blog te testen, het aantal stappen valt me reuze mee.
En natuurlijk (zie mijn rant hierboven) kijk ik erg uit naar deel 2

[Candymirror]

Batilan schreef op dinsdag 17 februari 2015 @ 20:16:
[...]


Was afgelopen weekend bezig om de gehele setup te reproduceren om mijn beloofde blogje te kunnen schrijven. Ik liep tegen precies hetzelfde aan. Na wat speuren kwam ik er achter dat de ec3k_recv in de source tree wel zijn werk deed terwijl de geïnstalleerde versie in /usr/local/bin zich zoals hierboven gedroeg.

Kun je ook eens proberen of eck3_recv in je source tree het wel doet. Dit heeft wellicht te maken met de beschikbare python modules. Overigens geeft ook de ec3k_recv in de source tree op mijn Raspberry de overflows (O), maar daartussen door wel regelmatig gedecodeerde paketten.

Ik heb dit net uitgeprobeerd. Er is bij mij geen verschil in ec3k_recv in de /usr/local/bin directory en die in de source. Beiden leveren hetzelfde resultaat op. een diff tussen deze twee levert ook geen verschil op. Ik vermoed dat er een versie verschil is bij jou tussen deze twee??

Ik heb voor de aardigheid naast de developers versie op git, ook versie 1.1.1 geprobeerd met hetzelfde resultaat. Tevens de hele mikmak op mijn debian server in de meterkast geinstalleerd. Helaas ook daar hetzelfde resultaat. Overigens heb ik op de server geen last van overflows. Ik begin er bija aan te twijfelen of die dingen van mij wel geschikt zijn. Ook ik heb die velleman dingen rt-110.

[ Voor 16% gewijzigd door Candymirror op 20-02-2015 15:25 ]

[Batilan]

Candymirror schreef op vrijdag 20 februari 2015 @ 10:23:
[...]
Ik heb voor de aardigheid naast de developers versie op git, ook versie 1.1.1 geprobeerd met hetzelfde resultaat. Tevens de hele mikmak op mijn debian server in de meterkast geinstalleerd. Helaas ook daar hetzelfde resultaat. Overigens heb ik op de server geen last van overflows. Ik begin er bija aan te twijfelen of die dingen van mij wel geschikt zijn. Ook ik heb die velleman dingen rt-110.

Je hebt in ieder geval 1.1.1 nodig om met Gnuradio 3.7.5. te kunnen werken. Verder kan het (zoals franssie al aangaf) zijn dat je de frequentie wat moet aanpassen, dit kan afhankelijk zijn van je dongle). Je zou je dongle eens aan een Windows bak kunnen hangen en dan met SDR# kijken wat je "ziet" op 868.3 MHz.

Omdat FSK modulatie gebruikt wordt zul je dan een vrij breed spectrum zien als het goed is, maar het is vrij eenvoudig om het midden te bepalen. Je zou eens kunnen proberen of het beter gaat als je de frequentie van ec3k hierop aanpast (wordt default gezet in ec3k.py ca. regel 275), dit kun je overriden door in regel 20 van ec3k_recv een extra freq argument mee te geven, b.v. ec3k.EnergyCount3K(callback=callback, freq=838.24).

Welk type dongle gebruik je? Ik heb zelf ook een paar Pinnacle DVB-T dongles met Fitipower FC0013 tuner welke behoorlijk doof lijken op bepaalde frequenties. Ik heb meer succes met de "Nano" dongles (de kleinste en goedkoopste dongles op Ebay) met een Rafael Micro R820T tuner.

[ Voor 0% gewijzigd door Batilan op 20-02-2015 22:40 . Reden: dongle => tuner ]

[Candymirror]

@batilan: Bedankt, ik heb de frequentie iets aangepast en nu doet hij het.

[Batilan]

Candymirror schreef op woensdag 25 februari 2015 @ 10:09:
@batilan: Bedankt, ik heb de frequentie iets aangepast en nu doet hij het.

Bedankt voor de terugkoppeling. Welke frequentie ben je op uitgekomen?
Heb je inderdaad SDR# gebruikt om de juiste frequentie te vinden?

Ik zal de blog nog aanpassen om dat deze tuning toch een vrij essentiële stap blijkt.

[Candymirror]

ik heb touchSDR voor android gebruikt. Overigens zat de ingestelde frequentie in ec3k wel binnen de bandbreedte van wat touchsdr mij liet zien. Ik heb uiteindelijk de ingestelde frequentie in ec3k.py van 868.402 gewijzigd in 868.202.
PS heb je voor mij misschien je emoncms script?

[Batilan]

Candymirror schreef op woensdag 25 februari 2015 @ 14:55:
... Ik heb uiteindelijk de ingestelde frequentie in ec3k.py van 868.402 gewijzigd in 868.202.
...

Ik ben hier nog even wat verder ingedoken: heb een soort van "scan" gedaan op verschillende frequenties en deze gedurende enige tijd afgeluisterd. Ik heb de resultaten in een stacked bargraph weergegeven welke per ingestelde frequentie het aantal ontvangen samples voor iedere plug laat zien:



Dit geeft een interessant beeld te zien: over een behoorlijk frequentiebereik kun je (een deel van) de dongles ontvangen. Er blijken echter diverse frequenties te zijn waarbij ec3k geen paketten lijkt te kunnen decoderen uit het ontvangen signaal. Het kiezen van de juiste frequentie luistert dus behoorlijk nauw. Het typische is dat precies op de "officiële" 868.3 MHz frequentie er geen enkel geldig ec3k pakket ontvangen werd.

Natuurlijk zal de optimale frequentie per rtl-sdr dongle weer anders kunnen zijn. Dit moet per dongle vastgesteld worden.

Ik zal dit binnenkort ook aan mijn blogje toevoegen, ik moet nog wat sleutelen aan het python scriptje om de scan te doen, zal die dan ook publiceren.

@Candymirror: ik heb het gevraagde scriptje t.b.v. emoncms via een DM verzonden.

[ Voor 0% gewijzigd door Batilan op 01-03-2015 11:44 . Reden: minor edit ]

[moi427]

Heel interessant topic dit, ik hoop genoeg tijd en kennis op te gaan doen om dit te gaan toepassen. Zou voor mij als niet-elektronicus etc. mooi zijn als er kits te koop waren voor de hardwarematige zaken. Misschien is dat al ergens aangegeven, maar dan heb ik dat nog niet herkend.
Anyway, zeer interessant en alle bijdragers bedankt zover!

[franssie]

jep, kan bijvoorbeeld met de jeelink http://www.digitalsmarties.net/products/jeelink of met een SDR (DVB-T) dongle

let op dat je de juiste frequentie koopt mocht je voor de jeelink gaan.

[Speedy-Andre]

Ik heb sinds kort een Jeelink v3c in m'n Rpi-2 zitten, maar hij wil m'n Lacrosse rf kwh tellers niet zien
Om de Jeelink aan te sturen heb ik Fhem geïnstalleerd en die praat met de Jeelink.
Een van de prolemen is de juiste ontvangstfrequentie vinden, het 868MHz plus een beetje.
Fhem is een beetje lastig te doorgronden voor mij.
Ik wil met een commando de frequentie tunen, dit ziet er zo uit:

attr myJeeLink initCommands 30t 0a 868280f v

Deze regel kan ik in een .cfg zetten en opslaan, ik weet niet of Fhem opnieuw moet starten voor hij een aangepaste frequentie uitvoert.
Met de eventmonitor zou je binnenkomende data moeten zien, maar die geeft niets weer