Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- software:controller:vzlogger:vzlogger_rpi_pico [2024/09/02 17:04] – tge
+++ software:controller:vzlogger:vzlogger_rpi_pico [2025/01/01 20:55] (aktuell) – DS18B20 IDs tge
@@ Zeile 1: / Zeile 1: @@
 ==== Vorwort ====
-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
+Die Portierung des vzloggers auf den [[https://www.raspberrypi.com/documentation/microcontrollers/pico-series.html|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 kleinen, noch zu behebenden Schönheitsfehlern" (siehe ganz unten TODO), wozu jede Hilfe willkommen ist.
-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.
@@ Zeile 11: / Zeile 10: @@
   * sehr eingeschränkter RAM sowie Flash-Memory
-Versuche, libcurl zu portieren, hatten sich als sehr aufwändig herausgestellt und wurden beendet.
+Es gibt inzwischen RPi Pico 2 - insb noch sparsamer (hat auch mehr RAM u Flash-Speicher, mehr Schnittstellen usw usf - alles bisher nicht benötigt).
-Vorhanden ist eine IP Implementierung "lwip" (sowie bei Bedarf sogar "mbedtls" als TLS Implementierung, bisher nicht genutzt).
+Die RPi Pico gibt es auch als "WH" mit bereits angelöteten Pins - macht es nochmal einfacher, aber auch etwas teurer.
-In der Konsequenz heisst das (nur, wenn entspr comiliert):
+Versuche, libcurl zu portieren, hatten sich als sehr aufwändig herausgestellt und wurden abgebrochen.
+Statt dessen wird eine IP Implementierung [[https://www.nongnu.org/lwip|lwIP]] genutzt (sowie bei Bedarf sogar "mbedtls" als TLS Implementierung, bisher nicht genutzt).
+In der Konsequenz heisst das (nur, wenn entspr compiliert):
   * Embedded config als JSON-String
   * Logging nach stdout, über USB sichtbar, solange der Pico an einem "richtigen" Computer am USB-Anschluss hängt (gleichzeitig Stromversorgung)
   * Ersetzen von pthreads durch main-loop Konzept
-  * Minimale Implemetierung (kein embedded httpd, kein Push-Server, kein MQTT, keine SML/S2/D2/mbus/... Protokolle - diese könnten aber vermutlich noch hinzugefügt werden)
+  * Minimale Implementierung (kein embedded httpd, kein Push-Server, kein MQTT, keine SML/S2/D2/mbus/... Protokolle - diese könnten aber vermutlich noch hinzugefügt werden, zumindestens teilweise)
   * Ersetzen von Curl durch lwip-API
 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).
+Mittlerweile läuft der u.g. EmonLib-basierte "Stromzähler" ununterbrochen seit mehreren Monaten ohne jegliche Komplikationen.
 === Install PICO Dev-Kit ===
@@ Zeile 65: / Zeile 69: @@
   $ cp ../EmonLib-vz/* .
+=== Update Dez 2024 ===
+Neu:
+  * Neue Sensoren: HC-SR04 Entfernungsmesser und w1therm DS18B20 (basierend auf GPIO) - die dazu verwendeten externen libs müssen ggf wie oben heruntergeladen werden, es sind aber wenigstens keine Anpassungen nötig.
+  * Verschiedene Energiesparmassnahmen - siehe ganz unten.
+  * kontinuierliche Abfrage und Ausgabe von RAM, Betriebsspannung, benötigte Rechenzeit in verschiedenen Modi (damit Hochrechnung Energieverbrauch möglich)
+  * Pico2 W getestet - minimale Änderungen notwendig, funktioniert noch besser
 === Bauen ===
-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.
+Zuerst muss die "embedded config" in einem eigenen Header-File (Beispiel vz_pico_inline_config.h) angepasst werden, insb die VZ Server URL, WiFi Zugangsdaten, meters und channels - wie üblich, nur eben embedded.
+Mit einem Pico2 W beim cmake Kommando als Board "pico2_w" angeben.
   $ cd ~/projects/vzlogger/pico
   $ mkdir build
   $ cd build
-  $ cmake -DPICO_BOARD=pico_w ..
+  $ cmake -DPICO_BOARD=pico_w -DVZ_BUILD_ON_PICO=1 ..
   ...
   $ make
@@ Zeile 95: / Zeile 109: @@
   * kleine selbstgebaute Adapterschaltung, die den output o.g. Quellen für den RPi Pico ADC lesbar macht (s.u.). Wichtig dabei: der ADC verträgt max 0..3V AC, d.h. die AC Sinuskurven müssen um 1.5V pendeln im Bereich von eben max 0..3V
-Sieht dann so aus:
+Sieht dann so aus - die beiden SCT013:
- TODO Sicherungskasten Bild (kann nicht hochladen)
+{{:software:controller:vzlogger:rpi_pico:signal-2024-08-31-203850_005-1.jpeg?nolink&400|}}
- TODO Adapter Bild
+<note warning>Das Befestigen der SCT013 um Netzspannung führende Leiter ist an sich harmlos - trotzdem muss man evtl. im Sicherungskasten herumhantieren und man sollte wissen, was man da tut!!! Im Zweifel lieber Finger weg oder einen Elektriker bitten!</note>
-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).
+Die Adapterschaltung nebst RPi Pico (die Stecker: 2x I (SCT013), 1x U (kl 9V AC Netzteil)):
-Sieht dann so aus:
+{{:software:controller:vzlogger:rpi_pico:signal-2024-09-02-181804_002-1.jpeg?nolink&400|}}
+Die Grundidee ist nun, dass vzlogger kontinuierlich beide Sensoren (U und I) via EmonLib abfragt und daraus sowohl Wirk- als auch Scheinleistung berechnet (bei PV Einspeisung sogar negativ).
+Sieht dann so aus (bereits mit 2 Phasen, braun L1 und schwarz L2):
 {{:software:controller:vzlogger:rpi_pico:screenshot_2024-09-01_12-23-45.jpg?nolink&800|}}
 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
+D.h. pro einzelner Sinuswelle gibt es Hunderte von einzelnen Messwerten, womit sich die Kurve gut rekonstruieren (selbst 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.
+All dies ist sehr gut erklärt auf o.g. Seite, dort auch die Adapterschaltung:
+https://docs.openenergymonitor.org/electricity-monitoring/ct-sensors/interface-with-arduino.html
-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.
+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 passte nicht mehr zu I, 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:
+Beispiel (U und I verschoben, P aber korrigiert):
- TODO Simulator Bild
+{{:software:controller:vzlogger:screenshot_2024-08-17_11-03-02.jpg?nolink&800|}}
-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
+Idee hierbei ist es, im {{ :software:controller:vzlogger:rpi_pico:phasecal-generic.ods |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.
+Heisst, I ist U etwa 26 Stichproben voraus und ein korrekter Wert für P wird ermittelt, indem für jedes U[i] ein I[i - 26] verwendet wird.
 All dies passiert innerhalb EmonLib - es muss nur der "phaseCalibration" Config-Wert eingestellt werden.
+Die resultierende config sieht dann so aus (bereits mit 2 gemessenen Phasen s.u. - dies hatte übrigens den Effekt,
+dass die L1 Phasenverschiebung nochmal etwas anders war: 35 statt 26.
+Möglicherweise Interferenz der beiden SCT013?):
+  static const char * inlineConfig =
+  "{ 'verbosity': 5, \
+   'retry': 30, \
+   'meters': \
+   [ \
+     { \
+       'enabled': true, \
+       'skip': false, \
+       'interval': 10, \
+       'protocol': 'emonlib', \
+       'adcCurrent': 0, \
+       'adcVoltage': 1, \
+       'currentCalibration' : 30, \
+       'voltageCalibration' : 247.0, \
+       'phaseCalibration' : 35.0, \
+       'delay': 100, \
+       'numSamples': 20, \
+       'channels': \
+       [ \
+         { \
+           'uuid': 'f3ef9b70-de3b-11ee-83b5-73042e2a7e09', \
+           'api': 'volkszaehler', \
+           'middleware': '" VZ_SERVER_URL "', \
+           'identifier': 'RealPower'\
+         } \
+        ,{ \
+           'uuid': '560ff4e0-2d94-11ef-9a04-7f5c06e34262', \
+           'api': 'volkszaehler', \
+           'middleware': '" VZ_SERVER_URL "', \
+           'identifier': 'Voltage'\
+         } \
+        ,{ \
+           'uuid': '2e2a8c90-dd66-11ee-9621-0d0747854c29', \
+           'api': 'volkszaehler', \
+           'middleware': '" VZ_SERVER_URL "', \
+           'identifier': 'Current' \
+         } \
+       ] \
+     } \
+    ,{ \
+       'enabled': true, \
+       'skip': false, \
+       'interval': 10, \
+       'protocol': 'emonlib', \
+       'adcCurrent': 2, \
+       'adcVoltage': 1, \
+       'currentCalibration' : 30, \
+       'voltageCalibration' : 247.0, \
+       'phaseCalibration' : 132.0, \
+       'delay': 100, \
+       'numSamples': 20, \
+       'channels': \
+       [ \
+         { \
+           'uuid': 'a8d6bba0-6462-11ef-aea1-3b1a1ab3364e', \
+           'api': 'volkszaehler', \
+           'middleware': '" VZ_SERVER_URL "', \
+           'identifier': 'RealPower'\
+         } \
+        ,{ \
+           'uuid': 'd9c7cd20-67bf-11ef-938c-3b62ce66ce08', \
+           'api': 'volkszaehler', \
+           'middleware': '" VZ_SERVER_URL "', \
+           'identifier': 'Current' \
+         } \
+       ] \
+     } \
+   ] }";
+Die einzelnen Meter-Attribute:
+  * adcCurrent - welcher ADC Pin
+  * adcVoltage - welcher ADC Pin
+  * currentCalibration - ggf Kalibrierungswert (wenn SCT013-30 dann einfach 30)
+  * voltageCalibration - Kalibrierungswert, ausprobieren, siehe openenergiemon.org Doc
+  * phaseCalibration - Ausgleich Phasenverschiebung zw U und I (s.o.)
+  * delay - in Microsecs, Verlangsamung der Messschleife
+  * numSamples - wie viele Sinuswellen messen
+Der "delay" entspricht einem "sleep(100us)", damit kommen "nur" ~1500 Stichproben pro Messzyklus heraus,
+hat aber den Vorteil, dass der L2 Phasecal-Wert mit 132 bedeutet, dass in EmonLib nicht mehr als 256 Stichproben
+aufgehoben werden müssen - diese Anzahl Stichproben ist immer noch viel mehr als genug um die Sinuskurve rekonstruieren zu können).
 === 3-Phasen ===
-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:
@@ Zeile 135: / Zeile 237: @@
   * pro Phase ein SCT013 + nur ein Trafo an einer Phase.
-Variante 2 scheint ausreichend genau zu sein, d.h. U scheint für die verschiedenen Phasen ausreichend gleich. Es muss aber die gleiche Phasenkorrektur zwischen U und I wie oben stattfinden - wenn U und I an verschiedenen Phasen gemessen werden (dabei dann aber mit einer erheblich grössere Differenz).
+Variante 2 scheint ausreichend genau zu sein, d.h. U scheint für die verschiedenen Phasen ausreichend gleich.
+Es muss aber die gleiche Phasenkorrektur zwischen U und I wie oben stattfinden - wenn U und I an verschiedenen Phasen gemessen werden (dabei dann aber mit einer erheblich grösseren Differenz, in der realen Beispiel-Config 132).
+=== Simulation ===
+Wenn libs/EmonLib mit -DCALIBRATION compiliert wird, gibt der vzlogger nach jedem Messzyklus genau 1000 Stichproben als CSV aus (Zeitstempel in Microsecs;ADC I;ADC U) sowie die initialen OffsetI und Offset U.
+Diese Werte können in das Spreadsheet kopiert werden, damit sind dann im Idealfall schöne Sinuskurven sichtbar (*immer* für U, je nach Last für I -> Tip: große, rein ohmsche Lasten verwenden z.B. Wasserkocher, Toaster, ...).
+Damit wiederum den phaseCal Wert wie oben beschrieben ermitteln, in config eintragen, neu compilieren.
+Dies muss für alle Phasen separat gemacht werden.
+=== Tips und Tricks ===
+Ein paar Erfahrungen, die man nicht alle nochmal selbst machen muss:
+  * Die SCT013 in Spannungsvariante liefern AC max 1V, kann man also einfach mit einem Multimeter testen - um *eine* Kabelader clippen, Strom durchfliessen lassen, messen. 30A macht 1V, also 3A == 100mV usw. Dabei gibt es *keine* Richtung. SCT013 in Stromvariante geht genauso, erfordert aber einen Lastwiderstand.
+  * Der RPi Pico hat 3 (evtl 4) ADC Eingänge und genau einen ADC_GND (andere GND führen zu dubiosen Messwerten), d.h. alle Sensoren teilen sich den gleichen ADC_GND
+  * Die ADC Rohwerte lassen sich auch interpretieren. Der Pico ADC mit 12bits liefert also Messwerte zwischen 0..4094 (weil 2^12), d.h. mit einem 9V AC Netzteil (Leerlauf gern 11-12V, die dann mit der Adapterschaltung auf max 3V AC gebracht werden, mit 0 bei 1.5V) sind Rohwerte zwischen 500 und 3500 zu erwarten. Für I gilt prinzipiell das Gleiche, hier ist aber die Amplitude meist viel kleiner, die ADC Werte bewegen sich im 2000er Bereich.
+  * Der vzlogger output geht über den USB Anschluss und lässt sich anzeigen, indem man den RPi Pico gleichzeitig per USB von Laptop mit Strom versorgt und dann, sobald der RPi Pico bootet:
+  $ sudo screen -L /dev/ttyACM0
+Das gibt alles nach stdout aus, sowie gleichzeitig in ein File screenlog.0, was man dann später analysieren kann (enthält auch den CALIBRATION output). Alternativ zum Laptop tut es auch ein "normaler RPi". Vorteil: Im Dauerbetrieb kann der Laptop wieder ab. Das Logdatenvolumen kann per log-level in der embedded config gesteuert werden. Wenn alles klappt, als Stromversorgung ein einfaches USB Netzteil.
+Die DS18B20 w1 thermal Sensoren haben IDs, die in der config mit den channels verknüpft werden müssen. Anfangs sind diese IDs aber nicht bekannt - dann:
+  * Config mit irgendwelchen IDs Strings erstellen, Interval möglichst kurz (10s, sonst muss man solange warten)
+  * Loglevel auf 15 setzen, bauen und uf2 auf den Pico kopieren
+  * mittels USB Console den output protokollieren und auf folgende Ausgaben warten:
+  [Jan 01 19:54:07][mtr0] Querying meter ...
+  [Jan 01 19:54:07][]     Reading oneWire object 20012498 ...
+  [Jan 01 19:54:07][]     Have 2 oneWire devices.
+  [Jan 01 19:54:07][]     Adding ID[0]: 10D0F2BC020800A0
+  [Jan 01 19:54:07][]     Adding ID[1]: 280FB18600000068
+=== Energiesparmöglichkeiten ===
+Mit einem USB-Meter kann man messen, wieviel ein Gerät eigtl verbraucht. Der Pico W ("eins" übrigens, derweil gibt es V2 - noch nicht getestet)
+verbraucht ohne irgendwelche Anpassungen ~200mW (also ~40mA). Genauere Analysen zeigen: 40mA mit verbundenem WiFi, ohne WiFi ~20mA, während "connect WiFi" sogar 60mA -
+da ursprünglich WiFi dauerhaft verbunden war, resultieren daraus die ~40mA.
+Für Netzbetrieb gar nicht schlecht gut, für Batteriebetrieb aber noch viel zuviel.
+In der neuesten Version gibt es daher ein paar Config-Schalter, die Folgendes ermöglichen:
+  * Trennen WiFi wenn nicht benötigt
+  * Erst Daten sammeln, dann gesammelt schicken (Interval gesondert einstellbar, z.B. Messen alle 1min, senden nur alle 5min)
+  * Optimierung: Geteilte Netzwerk-Verbindung, wenn möglich (bisher jeder channel eigene Verbindung - obwohl eigtl gleicher Server:Port)
+  * CPU clock speed reduzieren, wenn weder Messen noch Senden (normalerweise 125MHz, gedrosselt 6MHz) - damit nur noch 9mA, dies aber fast die gesamte Zeit
+Mit all dem (und einer Config mit 1x HC-SR04 und 2x DS18B20) verbraucht der Pico W nur noch ~40mW (~8mA), der Pico2 W sogar nur ~25mW (~5mA).
+Mit einer 10000mAh Powerbank müsste dies also mindestens 8d reichen ...
+TODO:
+  * Powerbanks haben oft eine Abschaltung bei zu geringer Last - meine bei <100mA, geht also nicht.
+  * Es gibt Adaptermodule, die gleichzeitig ein PV-Modul und einen Akku ermöglichen - bestellt und unterwegs
+  * Es gibt noch einen lightsleep und deepsleep mode, womit nochmal erheblich weniger Stromverbrauch möglich sein könnte