Jump to content

MatzeTF

Administrators
  • Gesamte Inhalte

    414
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    32

Posts erstellt von MatzeTF

  1. Wo nimmst du „power“ her? Da das wohl ein Leistungswert sein wird, wird der nicht direkt etwas mit dem „allowed_charging_current“ zu tun haben, was ein Stromwert ist.

    Die Wallbox kann vom Zustand „ladebereit“ jederzeit wieder in „Lädt“ wechseln, wenn das Auto wieder Strom haben will. Es kann z.B. sein, dass du abends voll lädst, der Zustand dann auf „Ladebereit“ wechselt, aber morgens die Standheizung anspringt und das Auto dafür Strom aus der Wallbox nimmt, statt aus dem Akku. Dann springt der Zustand wieder auf „Lädt“, obwohl die Energie nur in die Heizung geht. Das Gleiche bekommst du auch hin, wenn das Auto erst bist 80% lädt, dann aufhört, und du später doch voll laden willst.

  2. Wenn du eine Smart oder Pro hast, kannst du im Webinterface ganz oben auf der Startseite den Ladestatus sehen. Fertig ist dein Auto, wenn der Status von „Lädt“ auf „Ladebereit“ springt. Dann gibt die Wallbox Strom frei aber das Auto will nicht mehr, also ist es wohl fertig.

    Wenn du nichts besonderes eingerichtet hast, wie z.B. EVCC oder anderes PV-Überschussladen, gibt die Wallbox dauerhaft den gleichen Strom frei und das Auto kann sich aussuchen, wie viel im Rahmen des Erlaubten es ziehen möchte. Bei ausreichend leerer Batterie wird das Auto die maximal erlaubte Ladeleistung auch ziehen, sofern es einen entsprechenden Onboard-Lader hat. Wenn sich der Fahrzeugakku füllt, wird das Auto gegen Ende von sich aus die Ladeleistung reduzieren. Wenn du eine Pro hast, kannst du dir die Live-Daten oder die Daten der letzten drei Stunden ansehen und wirst sehen können, wie die Ladeleistung runter geht. Ob die Reduktion langsam oder abrupt passiert, ist je nach Fahrzeughersteller unterschiedlich. Ein Renault Zoe reduziert langsam, ein Opel eCorsa reduziert abrupt.

  3. Das von dir beschriebene Problem ist, dass nach einem Moduswechsel über die Buttons im Webinterface immer gewartet wird. Im Log kann ich allerdings sehen, dass die Buttons häufig kurz nacheinander betätigt werden. Anscheinend machst du entweder einen Doppelklick oder klickst nach dem ersten Klick nochmal hinterher weil die Buttons nicht sofort umspringen. Die zweite Betätigung des Buttons führt allerdings dazu, dass ein neuer Moduswechsel angestoßen wird, der dann feststellt, dass nichts zu tun ist. Daraufhin greift dann die Abkürzung zum Überspringen der Wartezeit nicht. Ich habe mir nochmal dein Log vom 10. April angesehen und dort sind auch an mehreren Stellen doppelte Moduswechsel zu finden.

    Bitte probier doch nächstes Mal, nur einmal zu Klicken. Tritt das Problem dann immer noch auf oder wird dann wie gewünscht geladen?

    Ich werde jetzt noch mit einbauen, dass derartige doppelte Moduswechsel blockiert werden.

  4. Ich kann dein Problem mit dem Umschalten auf Min+PV leider nicht nachstellen. Wenn ich versuche, den Ablauf in deiner ersten Grafik nachzustellen, wird nach dem Umschalten zu Min+PV eine Phasenumschaltung durchgeführt und dann immer ohne Verzögerung eine Ladung freigegeben. Ohne ein Event-Log aus dem fraglichen Bereich komme ich da nicht weiter.

    Bitte installiere mal diese Firmware. Die gibt in einem Fall, wenn kein Strom freigegeben wurde, eine zusätzliche Meldung im Log aus.

    Wenn dir das Problem nochmal auffällt, gleich ein Log runterladen und gerne zusammen mit einer Grafik hier hochladen.

    energy_manager_firmware_2_1_0_662bab4a_97884bf056af3f5_merged.bin

  5. Ich bin nun endlich dazu gekommen, mir deine neuen Grafiken anzusehen, musste aber gerade feststellen, dass der Text in den Grafiken nur schwer lesbar ist. Hast du sie zufällig noch in Originalgröße? Poste nächstes Mal bitte keine verkleinerten Bilder sondern nur in Originalgröße.

    Zu deinen Fragen: Bei Reglern gibt es zwei grundsätzliche Ursachen für Überschwingen: zu aggressive PID-Parameter und zu kurzer Regelzyklus.

    Beispielsweise sieht der Regler 200 W Überschuss am Hausanschluss und gibt dem Auto exakt 200 W mehr. Leider treffen die meisten Autos nicht exakt die vorgegebene Leistung und in diesem Fall nimmt das Auto 300 W mehr. Daraufhin sieht der Regler 100 W Bezug und gibt dem Auto 100 W weniger. Daraufhin springt das Auto wieder um 300 W runter und das Ganze wiederholt sich. Diesen Fall haben wir übrigens exakt so mit einigen Fahrzeugen beobachtet. Im diesem Fall waren die PID-Parameter ungünstig, weshalb der WEM aktuell einen P-Regler mit adaptiver Schrittweitenregelung verwendet. Soll bedeuten, dass bei großen Leistungsunterschieden 90 % der überschüssigen oder fehlenden Leistung an das Auto weitergegeben wird. Bei kleinen Leistungsunterschieden reduziert sich das bis auf 50 %, was Überschwingen recht gut dämpft.

    Für das zweite Problem sehen wir uns dein Auto an: Zu Beginn der Ladung sieht der Regler Überschuss am Hausanschluss und gibt 6 A frei. Nach 10 s hat das Auto noch nicht angefangen zu laden und der Regler sieht immer noch Überschuss am Hausanschluss. Daraufhin gebt er 10 A frei. Nach insgesamt 18 s beginnt das Auto zu laden, allerdings hat der Regler das aufgrund von Verzögerungen in der Messkette zwei Sekunden später noch nicht gesehen und gibt 14 A frei. Da das Auto nun lädt, springt es schnell auf diese 14 A. Das ist natürlich viel zu viel, weshalb der Regler wieder Strom zurücknimmt. Hätte der Regler eine Zykluszeit von 25 s, hätte er beim zweiten Mal Nachschauen am Hausanschluss bereits die Ladeleistung vom Auto gesehen und hätte sie nicht unnötig erhöht. Hier ist also nicht die Wahl der PID-Parameter das Problem, sondern die Zykluszeit.

    Das Überschwingen aufgrund trödeliger Autos lässt sich aktuell nicht gut verhindern, ohne den Regler so langsam zu machen, dass dadurch das Nachregeln auf die PV-Leistung schlechter wird. Ansonsten liegt das Überschwingen in deiner zweiten Grafik voll im Rahmen. Dass das Überschwingen bereits nach zwei Perioden abgeklungen ist, bedeutet, dass der Regler eine gute Dämpfung hat. Vielleicht können wir da mit der anstehenden Überarbeitung des Lastmanagements trotzdem noch etwas was verbessern. Mal sehen.

    Dein Problem mit der ersten Grafik schaue ich mir gleich noch genauer an, allerdings bräuchte ich dafür eigentlich das Ereignis-Log, das du gerade in diesem Fall leider nicht hast.

  6. Es gibt dafür keine API vom Brick, aber du kannst wie in deinem Beispiel direkt mit den esp_* Funktionen reden. Beachte allerdings, dass der Rest des Projekts nicht erwartet, schlafen gelegt zu werden. Es kann z.B. sein, dass dein Projekt vom Watchdog neugestartet wird oder dass du verschiedenste Timeouts bekommst. Außerdem wirst du die WLAN-Verbindung verlieren, sofern du nicht auch noch spezielle Einstellungen für WLAN-Schlafen einbaust.

  7. Das Problem dabei ist, dass die Wirleistung den Spannungsabfall der Zuleitung beinhaltet. Kommen bei deiner Wallbox nur noch 220 V an und das Auto lädt schon mit 16 A, siehst du 10560 W. Teilst du das durch 230*3 und schlussfolgerst, dass du bei 15,3 A noch 0,7 A mehr geben kannst, bist du dann in Wirklichkeit schon bei 16,7 A. In unserem alten Firmengebäude kamen teilweise nur 210 V bei den Wallboxen an. Wäre man da von 230 V ausgegangen, wäre man schon 1,4 A drüber gegangen.

    Ich habe gerade gestern bei einem Ladevorgang Strom und Leistung verglichen. Da ich sonst immer nur die Leistungskurve im Webinterface der Wallbox gesehen habe, dachte ich, dass das Fahrzeug einfach schwankend Leistung bezieht. Stellte sich heraus, dass der Ladestrom die ganze Zeit konstant war und die Schwankungen in der Leistung nur durch die schwankende Netzspannung verursacht wurden.

    Den Ladestrom nur anhand eines Leistungswertes, egal ob Wirk- oder Scheinleistung, einzustellen, halte ich daher für problematisch.

  8. Sungrow mag anscheinend nicht so viele Anfragen. Deine Logs bestehen praktisch nur aus Lesefehlern.

    Kannst du testweise mal einen SunSpec-Zähler ohne Suche anlegen und von Hand die Geräteadresse 247, Model 701 und Instanz 0 eingeben? Sowohl mit als auch ohne Proxy? Werden da (nach einem Neustart) irgendwann Werte beim Zähler angezeigt?

  9. Hängst du die Logs auch hier an? 🙂

    Für die meisten Sungrow-Bugs haben wir Workarounds. Was bleibt, sind häufige Lesefehler bei gleichzeitigen Modbus-Zugriffen. Wenn du da noch mit OpenHAB oder einer App draufhängst, wird das irgendwann unbenutzbar.

    Wechselrichter würden wir gerne bauen, allerdings ist die Konkurrenz bei Wallboxen schon schwierig. Das wird bei Wechselrichtern noch schlimmer sein.

  10. Wenn die Wallbox längere Zeit im Status „ladebereit“ bleibt, heißt das entweder, dass das Fahrzeug voll ist oder dass es aus anderen Gründen nicht laden möchte, z.B. wegen 80%-Limit. Etwas besseres gibt es da aktuell nicht.

    Längere Zeit „ladebereit“, obwohl das Fahrzeug laden möchte, kann nur im Fehlerfall auftreten, wenn das Fahrzeug die Ladefreigabe nicht annimmt.

  11. On 4/21/2024 at 7:59 AM, poohnet said:

    Ich hatte diese Informationen bei pyPLC gefunden:

    https://github.com/uhi22/pyPLC/blob/master/doc/EvseMode.md

    Hat ein CCS-Stecker da evtl. einen 1K5-Widerstand integriert?

    Der Widerstand zwischen PP und PE codiert die Belastbarkeit des Kabels. 1k5 bedeutet, dass es ein 13 A-Kabel ist. Meine Vermutung ist, dass für ISO15118 ein korrekter PP-Widerstand angelegt werden muss und pyPLC an der Stelle einfach den größtmöglichen Widerstand gewählt hat, da sie die AC-Leitung nicht nutzen. Der tatsächliche Wert des PP-Widerstands kann für CCS nicht verwendet werden, da sich damit maximal 63 A codieren lassen, DC-Lader aber mit bis zu 500 A laden.

  12. Aktuell gibt es noch keine besondere Unterstützung für Batteriespeicher in der WARP, ist allerdings für die Zukunft geplant. Aktuell kann man das Regelverhalten des PV-Überschussladens so einstellen, dass entweder das Fahrzeug oder der Batteriespeicher bevorzugt geladen wird. Wird der Speicher bevorzugt, wird sämtliche darüber hinausgehende Energie trotzdem dem Fahrzeug bereitgestellt. Wenn der Speicher also von 98 bis 100% langsam lädt, ist das kein Problem. Ist genug Sonne da, gibt die Wallbox schon vorher den Strom frei, da sie nur die Netzeinspeisung betrachtet und den Speicherstand ignoriert.

    On 4/21/2024 at 12:13 PM, ses said:

    Soll tatsächlich vom Hausakku ins Fahrzeug geladen werden? Wenn irgend möglich wird das meist vermieden um nicht die doppelten Verluste zu haben.

    Das ist eine viel zitierte Aussage, die allerdings auf einer im Allgemeinen falschen Annahme beruht.

    Die Annahme ist, dass DC Speicher -> AC Netzspannung -> DC Fahrzeug zu mehr Verlusten führt und deswegen das Fahrzeug nicht aus dem Batteriespeicher versorgt werden soll, sondern nachts das Haus.

    Nehmen wir mal einen Wandlerverlust von 5% an. Vereinfacht gesagt gibt pro geladene Kilowattstunde 5% Verluste im Batteriespeicher und 5% Verluste im Auto-Lader, macht 10% Verluste, also 100 Wh pro Kilowattstunde.

    Lädt man das Fahrzeug mit Strom aus dem Netz, gibt es nur 5% Verluste im Auto-Lader, also 50 Wh. Hört sich also besser an, allerdings wird dann ja nachts das Haus aus dem Speicher versorgt und dort gibt es 5% Verluste, also 50 Wh. Zählt man das zusammen, kommt man genauso auf 100 Wh Verluste pro Kilowattstunde, die ins Fahrzeug geladen bzw. aus dem Speicher entnommen wurde.

    Das Fahrzeug nicht aus dem Batteriespeicher zu laden hat also keine Vorteile; die  Verluste entstehen nur zu einer anderen Tageszeit. Interessant wäre das vielleicht mit dynamischen Strompreisen, allerdings würde ich dann davon ausgehen, dass der Strom tagsüber teuer ist und es erst recht sinnvoll ist, ein Fahrzeug aus dem Speicher zu laden und nachts den billigen Strom fürs Haus zu nutzen. Wenn man das Fahrzeug nicht aus dem Speicher lädt, sehe ich eher das Problem, dass der Speicherinhalt nachts gar nicht aufgebraucht wird, und der Speicher somit gar nicht vollständig genutzt wird. Alles, was morgens noch im Speicher ist, ist verschenkte Kapazität, die man besser zum Laden des Fahrzeuges verwendet hätte. Ein weiteres Szenario: Der Speicher wurde vormittags voll geladen und mittags wird bei nicht ausreichend PV-Leistung ein Fahrzeug geladen. Lädt das Fahrzeug aus dem Netz, bleibt der Speicher voll und kann nachmittags, wenn das Fahrzeug nicht mehr lädt, keine weitere Energie aufnehmen. Hätte man das Fahrzeug mittags aus dem Speicher geladen, hätte man nachmittags den Speicher ein zweites Mal voll laden können. Den Speicher generell zum Laden des Fahrzeuges zu nutzen, ist daher sogar sinnvoller.

  13. Zählermodelle auszuwählen, die während der Suche nicht gefunden wurden, wird nicht funktionieren. Nach dem Verbindungsaufbau wird nämlich genau dieses Modell gesucht. Wird es nicht gefunden, werden auch keine Daten ausgelesen. Findet die Suche es nicht, findet der Verbindungsaufbau es auch nicht.

    Dass der Wechselrichter als einphasig erkannt wird, ist kein Problem. Das einphasige Modell kann exakt die gleichen Daten beinhalten wie das dreiphasige Modell. Der einzige Unterschied ist, dass beim einphasigen Modell nur die Werte für Phase 1 verpflichtend sind, die für Phase 2 und 3 optional. Beim dreiphasigen Modell sind die Werte für alle drei Phasen verpflichtend.

    So wie ich das sehe, läufst du aktuell in ein Problem mit Sungrow-Wechselrichtern, das wir vor Kurzen gefunden haben. Das Ende der Modellliste wird anscheinend nicht konform zum SunSpec-Standard gekennzeichnet, wodurch die Suche endlos weiterläuft, bzw. bis sie irgendwann abstürzt. In den nächsten Tagen sollte es eine Test-Firmware geben, die das Problem umgeht und das nicht-standardkonforme Ende der Modellliste erkennt.

    Die Hoffnung wäre, dass dein WR auf einer anderen Adresse noch einen weiteren Zähler meldet, der dann die Werte von deinem Hausanschluss hat. Der eine aktuell gefundene Zähler ist ziemlich offensichtlich nur für den WR bzw. Speicher, nicht für den Hausanschluss. Aktuell stirbt die Suche, bevor der möglicherweise vorhandene zweite Zähler abgefragt wird.

  14. Du brauchst auf jeden Fall ein Hardware-Modul, da ISO 15118 CAN über IPv6 über PowerLAN über die CP-Leitung ist. Dafür hat der XMC1400 keine Hardware onboard. 😉

    Das Problem bei der SwitchEV-Implementierung ist, dass sie Python benötigt, unsere Firmware aber in C/C++ geschrieben ist. MicroPython hilft uns da meines Wissens nicht weiter.

    Dazu kommt, dass wir aktuell immer noch in dringenderen Aufgaben versinken und niemand Zeit hat, um auszuprobieren, was von den vorhandenen Open Source Lösungen man für die Wallbox nutzen könnte.

  15. Quote

    Die Sache hat sich aufgeklärt und funktioniert jetzt wie gewünscht. Neben der notwendigen Geduld, half es dann noch auf Start zu drücken, nachdem ich gestern den Min+PV manuell gestoppt hatte :-D

    Sieh beim nächsten Mal auf der Statusseite beim erlaubten Ladestrom nach. Wenn du die Ladung gestoppt hast, steht da „Blockiert durch Manuelle Lade­freigabe oder Taster“.

    On 4/19/2024 at 5:23 PM, Chaos said:

    Wie wäre es wenn ein Stromzähler einfach ein anderes MQTT Topic subscriben könnte und daraus seine Daten bekommt?

    Das Feature hätten wir auch gerne. Problem: Woher weiß die Wallbox, welches Format die Daten auf dem MQTT Topic haben? Es gibt dafür keinen Standard. Ist es einfach nur eine Zahl? Wenn ja, was für ein Wert ist das? Leistung? Spannung? Es es ein Array von Werten? Wenn ja, was bedeuten die ganzen Werte? Ist es ein assoziatives Array? Wenn ja und da "power" steht, ist das in Watt oder Kilowatt? Und so weiter…

    Wir haben intern zum Testen ein MQTT-Zählermodul, mit dem wir uns auf die Zähler von anderen Wallboxen hängen können. Das klappt aber nur, weil wir wissen, dass die Zählerdaten unser bekanntes Format haben.

×
×
  • Neu erstellen...