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

Thomas Gentsch tg at e-tge.de
Mi Aug 21 17:42:05 CEST 2024


Hallo allseits,
so langsam gefällt mir das ... Memory-Leak gelöst und Reconnect verbessert, läuft jetzt seit mehreren Tagen stabil und
die Daten stimmen jetzt auch
(Hintergrund: https://community.openenergymonitor.org/t/sct013-value-consistently-too-low/26480/24, zusammenfassend: der
kl Trafo, der zur Erfassung der Spannungsmesswerte dient, bringt eine hohe Phasenverschiebung rein, die wieder
rausgerechnet werden muss).
Sieht jetzt so aus (heute, gelb ist der PV Wechselrichter, lila die Wirkleistung im Sicherungskasten):
 
Noch zu tun:
 * code in git kopieren
 * Doc aktualisieren
 * bisher nur 1 Phase gemessen, Erweiterung auf 3 noch offen
Würde das dann irgendwie in den "offiziellen" code übergehen, wer würde das machen? Ich hab es eine Weile nicht mehr
probiert (aber auch nichts Substantielles mehr geändert), aber sollte so auch auf normalen Linux-Sys laufen.
Viele Grüsse
  Thomas

On Thu, 2024-07-25 at 22:58 +0200, Thomas Gentsch wrote:
> 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
> > > 
> > 
> 

-- 
 ........................................................  Thomas Gentsch  mobil : (+49) 0173 - 6620507  e-mail: tg at e-
tge.de  ........................................................
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20240821/e575c491/attachment-0001.htm>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : Screenshot_2024-08-21_17-35-19.jpg
Dateityp    : image/jpeg
Dateigröße  : 115348 bytes
Beschreibung: nicht verfügbar
URL         : <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20240821/e575c491/attachment-0001.jpg>


Mehr Informationen über die Mailingliste volkszaehler-dev