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

Fr Aug 23 23:19:55 CEST 2024

Moin,

habe deinen thread/posts gelegentlich gelesen,
fand's nicht ganz uninteressant, aber es erschien mir leicht off-topic,
wollte dir schon vorschagen, vlt. irgendwo ein projekt-blog anzulegen,
wo das vielleicht besser aufgehben waere, als auf dieser mailingliste.
(aber wie gehabt, durchaus nicht uninteressant!)

bzgl. vzlogger auf raspberry pi pico:
es ist durchaus interessant, dass das moeglich ist,
aber ich kann mir nur schwer vorstellen, das wir das als eine
"offiziell" unterstuetzte platform anbieten wollen.
malloc() auf microcontrollern ist moeglich, aber ob das langfristig
stabil laeuft, scheint fraglich.
auch wenn ich lese, wieviel du in vzlogger umbauen musstest (pthreads
ausbauen, usw.) frage ich mich, inwieweit das noch sinnvoll ist.
(und halte es fuer fraglich, ob wir das uebernehmen wollen wuerden.)
in deinem code sehe ich neben deinem neuen meter hauptsaechlich
anderungen in der volkszaehler-api. hast du geprueft, ob die anderen
APIs und meter, und features wie aggregation, mqtt, ...
in deiner konfiguration noch lauffaehig sind bzw. funktionieren?
wenn nicht, sehe ich sehr wenig sinn darin, das zu uebernehmen.

die volkszaehler.org middleware ist durchaus mit einer eigenen API
ausgestattet, damit verschiedenste programme mit ihr interagieren
koennen, es muss nicht vzlogger sein.
ueberlege mal, ob es nicht sinnvoller ist, ein eigenstaendiges
programm zu schreiben, und ggfs benoetigte teile aus vzlogger zu
uebernehmen (im rahmen der lizenz ja durchaus moeglich).
ich wollte dir voerher schon sagen, das es zB fuer s0-meter sinnvoller
scheint, ein eigenstaendiges programm auf basis von libsml zu schreiben
(libsml ist eher auf microcontrollern lauffaehig aus vzlogger),
das gibt es zB auch schon irgendwo, habe den link gerade nicht zur hand.

bzgl. des sct013 + trafo meters:
wie gehabt, eine interessante bastelei,
aber ich denke nicht das das massentauglich genug ist, als dass eine
integration bei uns sinnvoll ist,
insbesondere auch wenn die raspberry pi pico portierung alleine schon
problematich ist (s.o.).
und ich weiss insbesondere auch nicht, ob wie soeine bastelei (an 230V)
offiziell unterstuetzen wollen wuerden.

> 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

abgesehen von den punkten oben,
es steht es dir frei einen merge-request aufzumachen.
ich habe das hier mal testweise gemacht, nur um deine anderungen
bequemer anschauen zu koennen:
https://github.com/volkszaehler/vzlogger/pull/676

ein paar schritte die denke ich mindestens noetig oder zumindest
hilfreich sein wuerden:
lege mal bei dir einen anderen branch als master an.
mache den (ohnehin spaeter noetigen) rebase auf volkszaehler/master.
die gesamten aenderugen am threading koennte ich mir allerhoechstens
dann vorstelle zu uebernehmen, wenn das ganze optional ist,
also den betreffenden code in funktionen extrahieren, und dann nur
deren verteilen auf threads per #ifdef variieren.
(insofern das ueberhaupt moeglich ist, so genau habe ich noch nicht
geschaut.)
das getrennte CMakeLists file fuer die pico version ist denke ich
keine option, das sollte sauber ueber cmake-parameter dynamisch gemacht
werden.
und der pico build muesste in die continuous integration (gitlab
workflow) integriert sein (
https://github.com/volkszaehler/vzlogger/blob/master/.github/workflows/build%2Btest.yml
).

insgesamt halte ich das aber alles fuer wenig realistisch, siehe oben :(

- T.

On Wed, 21 Aug 2024 17:42:05 +0200
Thomas Gentsch <tg at e-tge.de> wrote:
> 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
> > > > 
> > > 
> > 
> 