[vz-dev] vzlogger on Raspberry Pico + merkwürdige Messung Balkon-PV

Do Jul 25 22:58:02 CEST 2024

Hallo allseits,
ich habe hier wieder etwas gefeilt - insb:
   1. das bisherige MeterSCT013 komplett ersetzt durch MeterEmonLib und diese eingebunden:
https://github.com/openenergymonitor/EmonLib
Hat die Vorteile:
       - deren Code wird unverändert genutzt
       - kann mit U-Sensor (s.u.) die Wirkleistung berechnen
       - sehr gute Doc incl verständliche Beschreibung der theoretischen Grundlagen:
https://docs.openenergymonitor.org/electricity-monitoring/index.html
   2. Jetzt auch ein dort beschriebenes kleines AC Netzteil mit Spannungssensor eingebunden. Damit zum einen aktuelle
      Netzspannung + noch viel wichtiger, die tatsächliche Wirkleistung, wird tagsüber mit PV Einspeisung sogar negativ
      berechnet
   3. Nochmal komplett neu alles zusammengelötet (U und I Sensor) und jetzt stimmen die Kurven grundsätzlich.
      Interessant dabei, dass die absurden Werte verschwunden sind - entweder vorher war noch irgendwo eine schlechte
      Lötstelle oder ein Wackler, oder das ist ein Nebeneffekt, dass Beides jetzt auf einer Platine ist (mit nur ADC_GND
      statt vorher GND und ADC_GND getrennt, weil vorher 2x Kabel nötig. Möglicherweise darf man das nicht, steht zwar
      so explizit nirgends, aber wer weiss ...)
      Weiterer Nebeneffekt - vorher waren die HW resets unzuverlässig, jetzt nicht mehr.
      "Zufällig" der Stecker zum SCT013 andersrum, jetzt ist auch die "PV Einspeiseenergie" negativ.

Grau ist übrigens U (gemessen mit EmonLib), vom Wechselrichter abgefragt wird gelb P und hellblau U. Schwarz ist Irms,
violett P (beides aus EmonLib).
Code im github Form committed.

Noch zu tun:
 * das Out-Of-Memory-Problem noch nicht gelöst
 * nach HW-Reset dauert es mehrere Zyklen, bis sich insb die I-Messung eingepegelt hat - das sind die Spitzen in der
   schwarzen und violetten Kurve. Ideen vorhanden, noch offen
 * nachts ist die P-Kurve (violett) schön eben, allerdings bei ~15W Einspeisung :-) Ideen vorhanden, noch offen
 * die CMake files sind noch optimierungsfähig

Viell könnte sich das jmnd ja mal ansehen - in der vorherigen Version auch auf "standard Linux" lauffähig, aber etwas
Review/Test schadet sicher nichts.

Viele Grüsse T

On Wed, 2024-06-05 at 17:17 +0200, Thomas Gentsch wrote:
> 
> Hallo allseits,
> ich hab jetzt mal 2 Wiki-Seiten angelegt - erstere kann man hoffentlich so lassen :-)
>  https://wiki.volkszaehler.org/hardware/channels/solar_inverters/hoymiles
> 
> Die zweite ist zum Thema vzlogger auf RPi Pico:
>  https://wiki.volkszaehler.org/software/controller/vzlogger/vzlogger_rpi_pico
> wo ich versucht hab, den aktuellen Zustand zu beschreiben. Mein Code-Fork ist wie beschrieben immerhin auch auf
> "normalen" Linux-Rechnern funktional, sollte an sich alles "wie bisher" laufen, allerdings kann es natürlich schon
> sein,
> dass ich irgendwas kaputt gemacht habe ...
> Daher wäre ein Review unbedingt willkommen, auch sonst jede Hilfe. Die Seite kann auch gern irgendwoanders hin ...
> 
> Neben einigen #ifdef Stellen habe ich habe ein paar Sachen umstrukturieren müssen:
> - Verschieben von grossen Teilen aus threads.cpp nach MeterMap sowie Channel (eben, weil Pico keine pthreads kennt)
> - Undo == operator and isEqual function in Reading.hpp - das habe ich aus einer älteren Version übernommen, da mit der
> neuen Variante ein Compilerfehler kam:
>  ~/projects/vzlogger/pico/include/Reading.hpp:63:14: error: 'dynamic_cast' not permitted with '-fno-rtti'
>    63 |  Pointer ptr(dynamic_cast<Pointer>(other));
> Möglicherweise geht das auch anders (Cross-compiler zu alt?), aber als "kleinster gemeinsamer Nenner" m.A. auch ok.
> 
> Wie schon gesagt, Feedback + Mithilfe immer gern :-)
> Viele Grüsse
>   T
> 
> On Sat, 2024-05-25 at 22:31 +0200, Thomas Gentsch wrote:
> > Hallo allseits,
> > ich wollte mich hierzu mal wieder melden ... es dauert zwar alles wie immer länger, aber immerhin tut sich schon
> > noch
> > was.
> > 
> > 1) Beim RPi Pico SDK gibt es immerhin eine Möglichkeit, mallocs u dgl zu tracen - damit hat sich herausgestellt,
> > dass
> > es
> > keine signifikanten Memory-Leaks gibt sondern dass offenbar die Vergabe von Heap bei dem Ding anders funktioniert.
> > Es
> > wird auch hie+da bei Microcontrollern von malloc&Co abgeraten.
> > Das wiederum auszubauen, ist aber schwierig ... mal sehen ...
> > 
> > Als Workaround hab ich einen Weg genutzt, den "out-of-memory" Zustand "abzufangen und dann einen reset auszulösen.
> > Hässlich, aber damit geht's erstmal kontinuierlich weiter.
> > 
> > 2) Mit Schein/Wirkleistung kann emonlib offenbar umgehen, vorausgesetzt es sind auch AC Spannungswerte vorhanden.
> > Die
> > hab ich noch nicht, aber der Ansatz hier scheint mir vielversprechend:
> >  https://boredomprojects.net/index.php/projects/home-energy-monitor#h3-1-1-hardware
> > Einfach ein kl AC-Netzteil an einen Analogport ...
> > 
> > 3) Ich hab inzwischen auch was gefunden, womit ich die Messwerte vom (hoymiles) Wechselrichter abgreifen kann (läuft
> > auf
> > einem "normalen" RPi, hat sogar eine VZ-Integration eingebaut), funktioniert bestens:
> >  https://github.com/lumapu/ahoy/tree/main/tools/rpi
> > Damit bekomme ich einen schönen Graphen für die PV Produktion, der auch weitgehend zu dem passt, was der SCT013 im
> > Sicherungskasten misst. Nur weitgehend, aber das könnte nun wirklich an (2) liegen.
> > 
> > Damit wiederum ist aber der "Smarte Stecker" entbehrlich - scheint ein Tuya-Derivat zu sein, also theoretisch
> > Tasmota-
> > fähig. Da 2024 angeschafft, dürfte das hier wahrsch nicht mehr gehen ... (?)
> >  https://github.com/ct-Open-Source/tuya-convert
> > An die Methode "Aufmachen und Löten" hab ich mich noch nicht gewagt ...
> > 
> > Viele Grüsse
> >   T
> > 
> 

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20240725/7d943dec/attachment-0001.htm>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : Screenshot_2024-07-25_21-44-24.jpg
Dateityp    : image/jpeg
Dateigröße  : 219517 bytes
Beschreibung: nicht verfügbar
URL         : <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20240725/7d943dec/attachment-0001.jpg>