[quote data-userid="13402" data-postid="102020"] Gibt es denn Probleme wenn ich dann ne Strippe ziehe zu den anderen Komponenten?
Also die RS485 Verbindung? Denn vom Zähler bis zum Ort der anderen Geräte werden es ggf 25-30m werden.
[/quote]
Ob das gehen kann, sagt dir die Spezifikation, aber in der Praxis entscheidet die Qualität des Kabels.
RS485 gilt als sehr robust.
@e-t0m : Ich hätte noch eine Frage zu folgendem Code Schnipsel:
Das ist ja quasi der "Überladeschutz". Also wo dann mehr ins Hausnetz eingespeist werden soll als nötig damit die Batterie nicht zu voll wird.
Leider verstehe ich die Gleichung hier aber nicht ganz.
Wenn jetzt z.b. deine Batteriespannung 58V erreicht wäre "free_power" ja nur 25W.
Heisst also wenn Send_Power jetzt z.B. nur 200W wäre und PV_Input z.B. 800W dann würden ja auch mit der Gleichung nur 225W vom Soyo raus geschickt werden und der Rest landet in der Batterie.
Hier vertraust du dann dem e-Smart dass er passend eingreift? Verstehe denn Sinn hier nicht wirklich. 
/p>
Hi Rainer, ja ganz genau, damit wird das "Nullniveau" leicht nach unten gezogen. Um leichte Schwankungen mit leichter "Übereinspeisung" abzudecken.
(in Kombination mit dem zero_shift wird macht es doppelt Sinn)
Wer möchte, kann das leicht ändern. Aber als Standard habe ich einen sehr kleinen Wert eingesetzt.
Ich kann natürlich nur für meinen esmart3 sprechen, aber ich vertraue ihm. Den Ladestrom (und Spannung) zu regeln ist seine Hauptaufgabe!
Notfalls wäre dann auch noch das BMS, was die Leitung kappen kann. Die Sicherung an der Batterie ist nur für hohen Strom zuständig.
Noch zwei Fragen:
Moin Rainer,
Ich habe skagmos lib nur minimal verändert: für den Datenexport und einen bug bei der Temperatur korrigiert.
Auch das esmart_test stammt von ihm, daher die Spannungskorrektur.
Meinen esmart habe ich nie kalibriert, vermutlich hat aber jedes Gerät seine eigenen Abweichungen im Rahmen der Fertigung. (Nachtrag: Die Vermutung hat sich bestätigt, jeder eSmart3 weicht anders ab)
Mir sind die Werte auf der DC-Seite nicht so wichtig.
Ob Verluste (z.B. Kabel) oder Messfehler (Geräte), ist nicht so wichtig, solange die Regelung das auffängt.
AC-seitig sollte es schon genauer sein!
Ich meine, mal eine komplette Dokumentation des Datenpakets vom esmart gesehen zu haben, allerdings in chinesisch. Da musst du mal suchen!
Puhh aber ist es nicht gefährlich wenn der e-Smart immer 10% zu wenig anzeigt? Wenn man jetzt die maximale Abschaltspannung im Datenblatt setzt die Spannung aber eigentlich schon 10% höher ist, kann das ja den Akku zerstören.
Klar sollte das BMS der Batterie das abfangen aber dann braucht man es im Script auch nicht mehr...
Ist nicht im Script!?
Wenn du da Sorgen hast, solltest du nachmessen. Dann kannst du die Einstellungen im esmart entsprechend justieren!
@e-t0m Jo. Ich werde da vorsichtshalber Mal nachmessen . Leider traue ich meinem Billig Multimeter da auch nicht so. Mal gucken ob ich jemanden finde der was besseres hat zum messen 
Eine neu gebaute Anlage sollte immer gründlich geprüft und gemessen werden! ?
Moin @e-T0m. Darf ich nochmal fragen welchen Vorteil es hatte den Wechselrichter über den Last Ausgang des Ladereglers und nicht direkt an die Batterie anzuschließen?
Leider ist man beim esmart ja auf die 40A auch am Last Ausgang als Maximalstrom begrenzt. Die Batterie könnte aber ohne Probleme auch größere Entladeströme.
Bin am überlegen die Wechselrichter direkt an die Batterie zu klemmen.
Mfg Rainer
Der Vorteil ist eine einfache Verkabelung und Messwerte vom Lastausgang.
Ausserdem der Unterspannungsschutz gegenüber der Last.
Aber spätestens wenn man sich der 40A Grenze nur grob annähert, sollte man direkt an die Batterie.
Einen einzelnen Soyo kann man problemlos an den Esmart klemmen.
Jo. Ich denke ich werde es so machen dass ich den zweiten Soyo der bestellt ist dann direkt an die Batterie klemme und den ersten Soyo am Esmart lasse Sollte ja für das Script keinen Unterschied machen soweit ich das gesehen habe.
Danke für die schnelle Antwort
Wenn du die Soyos parallel steuerst, kannst du auch einen Multiplikator für die Messwerte vom Lastausgang einbauen. (Nachtrag: wurde genau so realisiert)
Wie hast du denn das Resourcenproblem gelöst?
Leider konnte ich das Problem nur mit einem Workaround lösen. Heisst einmal in der Nacht wird der Raspberry Pi automatisch neu gestartet.
Dann verliere ich zwar eine Minute Einspeisung aber damit kann ich erstmal leben. Dann steht immer genug RAM zur Verfügung und er läuft nicht voll.
Hatte mal den Apache PHP abgeschaltet und dann gibt es das Problem nicht mehr. Liegt also definitiv dort irgendwo begraben.
Wenn ich wieder mehr Zeit habe. Analysiere ich es wieder genauer. Eventuell verwende ich dann auch mal was anderes als den Apache PHP.
Kannst du nicht den Apache selbst neu starten?
Dann würde alles andere normal weiterlaufen.
Auch wenn die Erträge derzeit noch zu wünschen übrig lassen,
kann ich mich über schöne Tagesverläufe freuen. Darum mache ich das.
Angesichts des Akku-Unfalls in Österreich, habe ich die Alarmierungsfunktion im Script erweitert.
Jetzt haben Akku und Laderegler eine eigene Temperaturschwelle und Kommando zur Alarmierung.
Übrigens existieren bereits einige Zeilen Quellcode zur Mustererkennung des Verbrauchs,
mit dem Ziel wiederkehrende getaktete Lasten vorausschauend zu Regeln.
Die ersten Prognosen sind erstaunlich gut, aber ich würde mich auch weiterhin über Unterstützung freuen!
oder
oder
wären wünschenswert.
Für eine Veröffentlichung ist es noch etwas zu früh, aber es bleibt weiterhin sehr spannend.
Sonnige Tage an alle!
Ich wollte mich mal wieder zum Stand melden!
Habe dein Script jetzt erfolgreich bei mir und bei meinem Vater in Betrieb genommen und jetzt läuft es (fast) reibungslos.
Das Ressourcen Problem hatte seine Ursache übrigens im Push-Server des Volkszähler. Lässt man diesen aktiviert, wird der Speicher des Raspberry nach und nach aufgefressen. Habe es jetzt ausgestellt und seitdem läuft der Raspberry 24/7 ohne Probleme (Selbst mein veralteter Raspberry 2B).
Die einzige Sache die sporadisch noch auftritt ist dass das Script zwischendurch mal aussteigt bzw. es irgendwann einfach abbricht. Das kann mal nach einem Tag sein, mal nach zwei Tagen oder nur nach ein paar Stunden. Der Raspberry läuft dann fröhlich weiter aber "screen -r" meldet dann zurück "There is no screen to be resumed" was für mich heisst dass das Script beendet wurde.
Da meine Linux und Python Kenntnisse nur langsam größer werden, suche ich aktuell nach einem Weg um die Ursache herauszufinden. Falls du einen Tip hast, gerne her damit. Könnt es eventuell sein dass das Script abbricht wenn er den eSmart nicht erreichen kann?
Bzgl. deiner Erweiterungen:
Die Mustererkennung des Verbrauchs finde ich eine richtig spannende Sache. Hier melde ich mich gerne freiwillig es zu testen und weiter zu entwickeln. Da ich beruflich aus dem Bereich Regelungstechnik und Simulation komme, könnte ich die Regelung auch simulativ mit entsprechenden Datensätzen in Matlab bzw. Simulink testen und weiterentwickeln. Ich denke dass die Platform dafür die flexiblere ist.
Ich schaue mir die Sachen gerne an sobald sie da sind.
[quote data-userid="9945" data-postid="109394"].... und seitdem läuft der Raspberry 24/7 ohne Probleme (Selbst mein veralteter Raspberry 2B).[/quote] So soll das sein, sehr schön! ?
Probier es aus: zieh den Stecker vom eSmart ab!
Ist am Anfang keine Verbindung da, dann startet das script nicht, mangels Werten. Im Betrieb sollte es einfach stehen bleiben.
Merkwürdig ist, das der "screen" komplett weg ist. Screens sind dem Benutzer zugeordnet, vielleicht hattest du gerade den falschen Benutzer aktiv?
Wenn das script stehen bleibt, kann man immer! noch den screen öffnen und sehen, was passiert ist.
Danke! das freut mich sehr!
Im "Sandkasten" lassen sich nur die Muster an sich erforschen.
Wirklich testen kann man das ganze nur im live-Betrieb, da ja die "Überlagerung" der Einspeisekurve in Echtzeit stattfindet.
Soweit bin ich noch nicht!
Wenn du deine Volkszähler-Verläufe des "16.7" Kanals bei laufender Nulleinspeisung ansiehst, welche Geräte takten bei Dir konstant periodisch?
Konstant periodisch takten natürlich Waschmaschine, Trockner, Spülmaschine etc. die üblichen verdächtigen die du wahrscheinlich schon auf dem Schirm hast.
Oder zielt die Frage noch woanders hin?
Bei mir finde ich aktuell übrigens noch weitere Baustellen jetzt wo wir so schöne sonnige Tage haben und ich alles mal austesten kann :).
Der Grund ist folgender:
-> Wenn ich mein e-Auto per Wallbox "Überschussladung" lade sieht er denn eigentlich möglichen Überschuss der PV Anlage nicht da der Laderegler bei voller Batterie ja die PV-Leistung nach unten zieht und die eigentlich noch mögliche PV-Leistung nicht frei gibt. Das e-Auto regelt dann also nur -und ziemlich genau- auf den Überschuss der großen Anlage wobei er ja mehr haben könnte. Also den Überschuss der PV Anlage wo die Batterie angeschlossen ist.
Habe es im Script jetzt an folgender Stelle gelöst:
Ich sende also etwas weniger Leistung raus als von der PV kommt damit die Batterie ab 53V weiter laden kann bis zum Ziel und den Rest haue ich in Netz damit es die Wallbox als Überschuss sieht.
Ist noch nicht richtig elegant.
Denkst du es gibt eine elegantere Stelle im Script wo/wie man es lösen könnte das generell immer die PV-Leistung freigegeben wird die noch eingepeist ins Netz als Überschuss eingespeist werden könnte?
