Die Portierung des vzloggers auf den Raspberry Pico W war/ist ein „Bastelprojekt“ insb mit der Motivation „das müsste doch gehen“ und der aktuelle Zustand ist „funktioniert mit ein paar noch zu behebenden Schönheitsfehlern“ (siehe ganz unten TODO), wozu jede Hilfe gern angenommen wird. Weitere Motivation war die Verfügbarkeit von analogen GPIO Ports (on-board ADC), also analogen Sensoren (s.u.), sowie geringerer Stromverbrauch (batterietauglich?) und Anschaffungskosten.
Der RPi Pico W („W“ für on-board WiFi - alles andere macht es noch komplizierter und lohnt vermutlich nicht) ist im Gegensatz zum „normalen“ Raspberry Pi ein „Microcontroller“ mit einem RP2040 Chip. Dies bedeutet insb:
Versuche, libcurl zu portieren, hatten sich als sehr aufwändig herausgestellt und wurden beendet. Vorhanden ist eine IP Implementierung „lwip“ (sowie bei Bedarf sogar „mbedtls“ als TLS Implementierung, bisher nicht genutzt).
In der Konsequenz heisst das (nur, wenn entspr comiliert):
Dies wiederum erforderte ein paar Umstrukturierungen - der resultierende Code ist aber sowohl auf dem RPi Pico als auch einem normalen RPi lauffähig (muss natürlich separat gebaut werden).
Siehe Doc hier:
https://www.raspberrypi.com/documentation/microcontrollers/c_sdk.html https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf
$ mkdir ~/projects/pico $ cd ~/projects/pico $ git clone https://github.com/raspberrypi/pico-sdk.git --branch master $ cd pico-sdk $ git submodule update --init $ cd .. $ git clone https://github.com/raspberrypi/pico-examples.git --branch master
$ mkdir ~/projects/vzlogger/pico $ cd ~/projects/vzlogger/pico $ git clone https://github.com/tge12/vzlogger
Es gibt 2 CMakeLists.txt Varianten - linke die Passende (ja, das ist hässlich, noch TODO):
$ ln -sf CMakeLists-pico.txt CMakeLists.txt
Diese müssen selbst compiliert werden, da eine „fertige“ lib für den RPi Pico nicht zu finden war/ist.
$ cd ~/projects/vzlogger/pico/libs/json-c $ git clone https://github.com/json-c/json-c .
Auch hier sind ein paar Anpassungen nötig, um die lib json-c kompilierbar zu machen für den RPi Pico (TODO auch hässlich und zu verbessern, evtl sind Erweiterungen im Bauprozess in der lib json-c nötig):
$ cp ../json-c-vz/* .
Ähnliche Situation. EmonLib ist für den eigentlichen RPi Pico-Port nicht notwendig, wohl aber für das neue „protocol“ zum Lesen von Strommesswerten mittels SCT013 (s.u.). Es gibt auch hier einen git fork, welcher 2 Erweiterungen enthält, die z.T. unbedingt notwendig sind (s.u.).
$ cd ~/projects/vzlogger/pico/libs/EmonLib $ git clone https://github.com/tge12/EmonLib .
Auch hier sind ein paar Anpassungen nötig, um die lib kompilierbar zu machen für den RPi Pico (TODO auch hässlich und zu verbessern, evtl sind Erweiterungen im Bauprozess in der lib json-c nötig):
$ cp ../EmonLib-vz/* .
Zuerst muss die „embedded config“ in src/vzlogger_pico.cpp angepasst werden, insb die VZ Server URL, WiFi Zugangsdaten, meters und channels - wie üblich, nur eben embedded.
$ cd ~/projects/vzlogger/pico $ mkdir build $ cd build $ cmake -DPICO_BOARD=pico_w .. ... $ make ...
Wenn alles klappt, kommt ein File namens …/build/src/vzlogger.uf2 dabei raus, welches auf den RPi Pico kopiert werden kann wie in der Pico SDK Doc beschrieben.
Es gibt allerlei andere Projekte, die mit dem nicht-invasiven (einfach um stromführenden Leiter drum herum clippen) Stromsensor SCT013 den heimischen Energieverbrauch messen. Idee war, dies in VZ zu integrieren. Die mit Abstand beste Seite hierzu mit viel Theorie usw usf:
https://docs.openenergymonitor.org/electricity-monitoring/index.html
Dazu wird benötigt:
Sieht dann so aus:
TODO Sicherungskasten Bild (kann nicht hochladen)
TODO Adapter Bild
Die Grundidee ist nun, dass vzlogger kontinuierlich beide Sensoren abfragt (via EmonLib) und aus U und I sowohl Wirk- als auch Scheinleistung berechnet (bei PV Einspeisung sogar negativ). Sieht dann so aus:
TODO VZ-Web Bild
Ein Messzyklus mit EmonLib calcVI() misst 20 volle Sinuswellen (dauert bei 50Hz immer reichlich 200ms), dabei werden vom RPi Pico bis zu ~6000 Messwerte gewonnen. D.h. pro einzelner Sinuswelle gibt es Hunderte von einzelnen Messwerten, womit sich die Kurve gut rekonstruieren (auch wenn in der Realität verzerrt) und auch die „Richtung“ des Stroms (Bezug oder Einspeisung) ermitteln lässt. All dies ist sehr gut erklärt auf o.g. Seite.
Die EmonLib Erweiterung hat sich als notwendig entpuppt, da der o.g. kl Trafo eine hohe Phasenverschiebung (eingebaute Komponenten?) zwischen U und I erzeugte, d.h. U hat nicht mehr zu I gepasst, selbst und inbs. mit rein ohmschen Lasten (Toaster), wo genau dies eigtl nicht passiert. Zum anderen ist in der Erweiterung die Möglichkeit enthalten, die tatsächlichen ADC Messwerte auszugeben, um diese dann in ein Spreadsheet zu laden und damit die echten Sinuskurven anzuzeigen. Hier ein Beispiel mit der genannten falschen Phasenverschiebung:
TODO Simulator Bild
Ohne Phasenverschiebungsfehler:
TODO Simulator Bild
Um Messfehler, die durch die eigene Messinfrastruktur erzeugt wurden, zu kompensieren, gibt es verschiedene EmonLib-Parameter (die in der vzlogger Config enthalten sein müssen). Diese „Kalibrierung“ ist ebenfalls auf der openenergymonitor Seite beschrieben, außer o.g. neue Phasenverschiebungsfehler-Kompensation. Idee hierbei ist es, im Simulations-Spreadsheet die Stichproben-Reihen zu ermitteln die für U und I jeweils am nächsten bei Null sind (ohne Phasenverschiebung und mit rein ohmscher Last (!!) wäre dies exakt die gleiche Stichprobe) und quasi softwaremäßig wieder zurück zu verschieben, d.h. passend zu U Reihe 44 und für I Reihe 18, macht 44-18=26. Heisst, U ist I etwa 26 Stichproben voraus und ein korrekter Wert für P wird ermittelt, indem für jedes V[i] ein I[i - 26] verwendet wird. All dies passiert innerhalb EmonLib - es muss nur der „phaseCalibration“ Config-Wert eingestellt werden.
Im Moment wird nur ein Phase gemessen - erstmal sehen, ob das überhaupt alles so klappt. Um mehrere Phasen zu messen, gibt es die folgenden Möglichkeiten: