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

[Thomas Gentsch]

Hallo Thorben,
hab Dank für's Anschauen + drüber Nachdenken!! 
Ein paar kl Kommentare s.u. ...

On Fri, 2024-08-23 at 21:19 +0000, Thorben Thuermer wrote:
> 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!)

Njaa, main Mail-Output ist hoffentlich noch akzeptabel, grossartig mehr kommt da auch nicht mehr

> 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.

Jaaaa, da hab ich auch selbst Einiges gelernt ... das malloc-Thema scheint unter Kontrolle, nachdem ich auch eine
Möglichkeit gefunden hatte (mallinfo/sbrk Abfrage, noch nicht committed), den aktuellen Stand abzufragen und
kontinuierlich auszugeben, sehe ich, dass es anfangs natürlich etwas wächst, dann aber konstant bleibt.
In der Praxis läuft das Ding auch immer noch seit 1W

> 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.)

Sehr wichtig m.A., dass das Nicht-Verwenden der pthreads nur dann passiert, wenn es eben keine gibt (#ifndef
VZ_USE_THREADS). Ansonsten hab ich etwas code verschoben (z.B. was bisher in threads.c war, ist jetzt praktisch 1:1 in
MeterMap), so dass es in beiden Modi aufrufbar ist - an der Architektur auf klassischen OS hat sich gar nichts
verändert.
Abgesehen von dem Wunsch, möglichst wenig zu verändern, find ich die thread-basierte Architektur eigtl auch viel
schöner.

> 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?

Teilweise. Viele protocols hab ich überhaupt nicht, MQTT auch nicht usw usf ... (zugegebenermassen kann es natürlich
sein, dass ich dabei doch irgendwas kaputt gemacht hab, das sollte aber leicht reparabel sein, da sich *grundsätzlich*
nichts geändert hat)

Allerdings war das auch nicht die Idee - ich sehe auch nicht so sehr, dass es sinnvoll ist, *alles* auf dem RPi Pico zu
unterstützen. Im Gegenteil, eher eine "Minimallösung", die genau das tut, was sie jetzt tut, *möglicherweise*
ausbaufähig.
Oder umgekehrt, wenn jmnd Lust drauf hat, noch weitere Teile zu "portieren", kann er/sie das gern ausprobieren :-) (das
"executable" ist im Moment bei 1.6MB, also 400K sind noch übrig :-))

Wie gesagt - meine Grundidee war:
- bisherige Architektur usw bleibt komplett unverändert (sources auch soweit wie möglich)
- zusätzliche Plattform mit dem, was dort sinnvoll ist

> 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).

Hmm, kann man natürlich auch so interpretieren. Andererseits ist der vzlogger ja schon genau das, was (zumindestens ich
:-)) wollte, bloss eben mit neuem "protocol" (das MeterOnboardtemp ist Spielerei)

> 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 b/astelei (an 230V)
> offiziell unterstuetzen wollen wuerden.

Der einzige "Kontakt" mit 230V ist das Befestigen des/der SCT013 im Sicherungskasten um die Zuleitungsadern herum,
einfach Festclippen, raus kommt max 1V AC galvanisch getrennt

> > 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.

ok (muss erstmal forschen, wie das geht :-))

> 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.

ist jetzt schon so

> (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.

definitiv ja, war allerdings auch mein erster Kontakt mit cmake, etwas Hilfe wär hier sehr willkommen :-)

> 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
> ).

ok, auch hier bisher keine Erfahrungen, aber muss ja auch lösbar sein

> insgesamt halte ich das aber alles fuer wenig realistisch, siehe oben :(
> 
> - T.

Danke nochmals trotzdem auf jeden Fall!!
Viele Grüsse, auch T :-)

PS: Das grösste Potential sehe ich in dem minimalen Ressourcenverbrauch (evtl batterietauglich oder per PV versorgbar),
Anschaffungspreis und dem onboard-ADC (Analogsensoren, die ganzen anderen GPIO gibt es ja zusätzlich auch noch).
MeterW1Therm müsste damit an sich gehen (natürlich nicht über /sys/bus/w1/devices), MeterFile und MeterExec werden
definitiv nicht gehen, bei den anderen hab ich ehrlich gesagt nicht allzuviel Ahnung.
Ich schau mir gerade das hier an https://github.com/dangarbri/pico-distance-sensor - evtl kann man damit auch den
Wasserstand in einem Behälter überwachen ... 

> 
> 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
> > > > > 
> > > >