<html><head></head><body><div><br></div><div>Hallo allseits,</div><div>ich habe hier wieder etwas gefeilt - insb:</div><ol><li>das bisherige MeterSCT013 komplett ersetzt durch MeterEmonLib und diese eingebunden:</li><div><a href="https://github.com/openenergymonitor/EmonLib">https://github.com/openenergymonitor/EmonLib</a></div><div>Hat die Vorteile:</div><ul><li>deren Code wird unverändert genutzt</li><li>kann mit U-Sensor (s.u.) die Wirkleistung berechnen</li><li>sehr gute Doc incl verständliche Beschreibung der theoretischen Grundlagen:</li></ul><div><a href="https://docs.openenergymonitor.org/electricity-monitoring/index.html">https://docs.openenergymonitor.org/electricity-monitoring/index.html</a></div><li>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</li><li>Nochmal komplett neu alles zusammengelötet (U und I Sensor) und jetzt stimmen die Kurven grundsätzlich.<br>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 ...)<br>Weiterer Nebeneffekt - vorher waren die HW resets unzuverlässig, jetzt nicht mehr.<br>"Zufällig" der Stecker zum SCT013 andersrum, jetzt ist auch die "PV Einspeiseenergie" negativ.</li></ol><div><br></div><div>Grau ist übrigens U (gemessen mit EmonLib), vom Wechselrichter abgefragt wird gelb P und hellblau U. Schwarz ist Irms, violett P (beides aus EmonLib).</div><div>Code im github Form committed.</div><div><br></div><div>Noch zu tun:</div><ul><li>das Out-Of-Memory-Problem noch nicht gelöst</li><li>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</li><li>nachts ist die P-Kurve (violett) schön eben, allerdings bei ~15W Einspeisung :-) Ideen vorhanden, noch offen</li><li>die CMake files sind noch optimierungsfähig</li></ul><div><br></div><div>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.</div><div><br></div><div>Viele Grüsse T</div><div><br></div><div>On Wed, 2024-06-05 at 17:17 +0200, Thomas Gentsch wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>Hallo allseits,</div><div>ich hab jetzt mal 2 Wiki-Seiten angelegt - erstere kann man hoffentlich so lassen :-)</div><div> <a href="https://wiki.volkszaehler.org/hardware/channels/solar_inverters/hoymiles">https://wiki.volkszaehler.org/hardware/channels/solar_inverters/hoymiles</a></div><div><br></div><div>Die zweite ist zum Thema vzlogger auf RPi Pico:</div><div> <a href="https://wiki.volkszaehler.org/software/controller/vzlogger/vzlogger_rpi_pico">https://wiki.volkszaehler.org/software/controller/vzlogger/vzlogger_rpi_pico</a></div><div>wo ich versucht hab, den aktuellen Zustand zu beschreiben. Mein Code-Fork ist wie beschrieben immerhin auch auf</div><div>"normalen" Linux-Rechnern funktional, sollte an sich alles "wie bisher" laufen, allerdings kann es natürlich schon sein,</div><div>dass ich irgendwas kaputt gemacht habe ...</div><div>Daher wäre ein Review unbedingt willkommen, auch sonst jede Hilfe. Die Seite kann auch gern irgendwoanders hin ...</div><div><br></div><div>Neben einigen #ifdef Stellen habe ich habe ein paar Sachen umstrukturieren müssen:</div><div>- Verschieben von grossen Teilen aus threads.cpp nach MeterMap sowie Channel (eben, weil Pico keine pthreads kennt)</div><div>- Undo == operator and isEqual function in Reading.hpp - das habe ich aus einer älteren Version übernommen, da mit der</div><div>neuen Variante ein Compilerfehler kam:</div><div> ~/projects/vzlogger/pico/include/Reading.hpp:63:14: error: 'dynamic_cast' not permitted with '-fno-rtti'</div><div> 63 | Pointer ptr(dynamic_cast<Pointer>(other));</div><div>Möglicherweise geht das auch anders (Cross-compiler zu alt?), aber als "kleinster gemeinsamer Nenner" m.A. auch ok.</div><div><br></div><div>Wie schon gesagt, Feedback + Mithilfe immer gern :-)</div><div>Viele Grüsse</div><div> T</div><div><br></div><div>On Sat, 2024-05-25 at 22:31 +0200, Thomas Gentsch wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Hallo allseits,</div><div>ich wollte mich hierzu mal wieder melden ... es dauert zwar alles wie immer länger, aber immerhin tut sich schon noch</div><div>was.</div><div><br></div><div>1) Beim RPi Pico SDK gibt es immerhin eine Möglichkeit, mallocs u dgl zu tracen - damit hat sich herausgestellt, dass</div><div>es</div><div>keine signifikanten Memory-Leaks gibt sondern dass offenbar die Vergabe von Heap bei dem Ding anders funktioniert. Es</div><div>wird auch hie+da bei Microcontrollern von malloc&Co abgeraten.</div><div>Das wiederum auszubauen, ist aber schwierig ... mal sehen ...</div><div><br></div><div>Als Workaround hab ich einen Weg genutzt, den "out-of-memory" Zustand "abzufangen und dann einen reset auszulösen.</div><div>Hässlich, aber damit geht's erstmal kontinuierlich weiter.</div><div><br></div><div>2) Mit Schein/Wirkleistung kann emonlib offenbar umgehen, vorausgesetzt es sind auch AC Spannungswerte vorhanden. Die</div><div>hab ich noch nicht, aber der Ansatz hier scheint mir vielversprechend:</div><div> <a href="https://boredomprojects.net/index.php/projects/home-energy-monitor#h3-1-1-hardware">https://boredomprojects.net/index.php/projects/home-energy-monitor#h3-1-1-hardware</a></div><div>Einfach ein kl AC-Netzteil an einen Analogport ...</div><div><br></div><div>3) Ich hab inzwischen auch was gefunden, womit ich die Messwerte vom (hoymiles) Wechselrichter abgreifen kann (läuft</div><div>auf</div><div>einem "normalen" RPi, hat sogar eine VZ-Integration eingebaut), funktioniert bestens:</div><div> <a href="https://github.com/lumapu/ahoy/tree/main/tools/rpi">https://github.com/lumapu/ahoy/tree/main/tools/rpi</a></div><div>Damit bekomme ich einen schönen Graphen für die PV Produktion, der auch weitgehend zu dem passt, was der SCT013 im</div><div>Sicherungskasten misst. Nur weitgehend, aber das könnte nun wirklich an (2) liegen.</div><div><br></div><div>Damit wiederum ist aber der "Smarte Stecker" entbehrlich - scheint ein Tuya-Derivat zu sein, also theoretisch Tasmota-</div><div>fähig. Da 2024 angeschafft, dürfte das hier wahrsch nicht mehr gehen ... (?)</div><div> <a href="https://github.com/ct-Open-Source/tuya-convert">https://github.com/ct-Open-Source/tuya-convert</a></div><div>An die Methode "Aufmachen und Löten" hab ich mich noch nicht gewagt ...</div><div><br></div><div>Viele Grüsse</div><div> T</div><div><br></div></blockquote><div><br></div></blockquote><div><br></div></body></html>