Erfahrungen mit 2024.08.18 und Ideen zur Verbesserung

[Martin0475]

Zuerst einmal möchte ich mich bei allen bedanken die dieses Projekt betreuen und fleissig dran arbeiten.
Danke für eure Mühe.

Meine Erfahrungen mit der neuen Version:
Zuerst hatte ich viel mehr Abstürze als vorher (Inverter offline, nothing received, Radio ok?) usw Meldungen in der Konsole.

Dann habe ich auf gut Glück einfach mal das Netzteil getauscht, und zwar von dem bei der OpenDTU mitgelieferten 2.1A Netzteil auf eines mit 1A welches beim Marstek-Speicher dabei war.
Und siehe da, seitdem fast keine Probleme mehr.

Zum ersten mal sehe ich nun bei Infos im Status :
Reset Grund CPU 0 : Vbat power on reset
Vorher stand da immer was von "Software reset"

Was mir positiv aufgefallen ist: Das einstellbare Intervall bei der Abfrage des Powermeters und das setzen des Limits in Zehntel%.
Der angestrebte Wert der Nulleinspeisung wird nun viel genauer getroffen.

Trotzdem hätte ich ein paar Ideen was man am Ablauf des DPL verbessern könnte, bin aber kein Programmierer von daher Entschuldigung wenn ich Blödsinn erzähle.
Ich sehe das eher als Anregung zur Diskussion.

1, (Allgemein) Es wäre schön wenn der db-Wert bein Live-View-Fenster angezeigt würde, so könnte man evtl schneller einen optimalen Standort finden.

2, (DPL) Soweit ich verstanden habe funktiniert die Hysterese so: Das neue Limit wird berechnet und mit dem aktuellen Limit verglichen und nur wenn der berechnete Wert um mehr als die Hysterese abweicht wird das neue Limit gesendet.

Wie wäre es wenn man stattdessen den gemessen Wert des Powermeter verwendet ?
z.B. Angestrebter Wert = -5 , Hysterese ist 10: Dann wäre alles in Ordnung zwischen -15 und +5 Watt.

Ablauf:
1. Inverter-Daten werden empfangen -> löst eine Abfrage des Powermeter aus (so sind die Werte etwa gleich aktuell)
2. Ist der Power-Wert innerhalb -15 und +5 Watt ? JA: dann kann der DPL übersprungen werden und zurück zu 1
oder: Wert liegt unter -16 oder über 6 Watt -> DPL wird aufgerufen, berechnet das neue Limit, es wird an den Inverter
gesendet und zurück zu 1.

         Meiner Meinung nach würde das CPU Zeit sparen, da der DPL nur dann berechnet wird wenn es nötigt ist.
         Sinnvoll oder nicht ? 

und Punkt 3 (Overscaling):
das DPL overscaling ist eine super-Idee, es klemmt sich jedoch machmal bei mir fest:
Beispiel: Der Inverter ist auf 250 Watt gesetzt, aus irgendeinem Grund wern aber nur 230 Watt geliefert... es könnte aber mehr geliefert werden da an einem Eingang eine Batterie B2500 mit max 800Watt Entladeleistung ist..

Soll das Limit nun erhöht werden , steht in der Console (All Channels are shaded) und der das neue Limit wird nicht gesetzt,

Vielleicht könnte man diese Erkennung etwas weniger streng ansetzen ?

Danke fürs Lesen!

[Akhilananda]

Meine Erfahrungen mit der neuen Version: 2024.08.18 und openDTU Fusion 2.1
Einstellungen:
Dynamik Power Limiter
Maximales Leistungslimit wurde auf 250 W gesetzt.
Stromzähler: shelly 3em Abfrage funktioniert.
Problem: Nulleinspeisung funktioniert nicht, es wird immer 250 W eingespeist.
Hat sich bei den Einstellungen etwas geändert?

Die Firmware 2024.01.26 funktioniert einwandfrei.

[Akhilananda]

Firmware 2024.08.18
DPL ausführliche Protokolierung ist eingeschaltet!
In der Konsole ---KEINE--- [DPL::loop] ******************* ENTER ********************** (wird nicht angezeigt)
Keine dpl Daten

Firmware 2024.01.26
DPL ausführliche Protokolierung ist eingeschaltet!
In der Konsole [DPL::loop] ******************* ENTER ********************** (wird angezeigt)
20:43:22.663 > [DPL::loop] battery interface enabled, SoC: 94 %, StartTH: 80 %, StopTH: 20 %, SoC age: 0 s
20:43:22.711 > [DPL::loop] dcVoltage: 26.50 V, loadCorrectedVoltage: 26.60 V, StartTH: 26.00 V, StopTH: 25.80 V
20:43:22.757 > [DPL::loop] StartTH reached: yes, StopTH reached: no, inverter is producing
20:43:22.803 > [DPL::loop] SolarPT disabled, Drain Strategy: 0, canUseDirectSolarPower: no
20:43:22.852 > [DPL::loop] battery discharging allowed, PowerMeter: 11 W, target consumption: 10 W
20:43:22.896 > [DPL::setNewPowerLimit] requested: 103 W, (re-)sending limit: 103 W
20:43:22.944 > [DPL::loop] ******************* Leaving PL, calculated limit: 103 W, requested

Auf opendtu fusion v2.1 funktioniert nur die Firmware 2024.01.26 einwandfrei, alles andere ist fehlerhaft :-(

[Akhilananda]

Und jetzt?

[schlimmchen]

Und jetzt prüfst du einmal in Ruhe, warum denn da keine Ausgaben auf der Konsole kommen. Jedenfalls liegt es nicht an der Firmware. Zumindest nicht im Code. Welche variante hast du installiert? Schaust du in die WebKonsole oder per USB Kabel drauf?

Außerdem ist es dringend erfolderlich, dass du weniger schnippisch und etwas freundlicher, geduldiger, und dankbarer bist. Und ganz wichtig: Dich dafür öffnest, dass du etwas falsch gemacht haben könntest das dazu führt, dass "alle Firmwares fehlerhaft sind außer 2024.01.26", denn diese Aussage ist grober Unsinn.

[Akhilananda]

Schnippisch? Eher angesäuert. Dankbar für was? Wo haben sie mir geholfen?
Ihr Vorwurf, ich zitiere: Da du außer einer merkwüdigen Diskussion kein Issue und auch sonst nichts von dir hast hören lassen, kann niemand wissen, dass du dein Fusion nicht in Gang bringen kannst. An der Firmware liegt es jedenfalls nicht.

Selbstverständlich kann ich meine Opendtu Fusion mit der Firmware 2024.01.26 in Gang bringen.
Es funktioniert mit dieser Firmware alles tadellos Nulleinspeisung mit Victron mppt 100 20 und Victron Battery shunt.
Wenn für sie diese Aussage Unsinn ist dann ist das halt für sie so.

Ich hatte gefragt ob sich mit der neuen Firmware etwas geändert hat. Die Frage wurde mit ja beantwortet. Dann muss sich wohl auch etwas an den Einstellungen geändert haben und sie werfen mir das als Fehler vor weil ich nicht die für die Firmware 2024.08.18 erforderlichen Einstellungen, die sich ja offensichtlich verändert haben vornehme.

Aktuell habe ich die Firmware 2024.01.26 installiert da diese einwandfrei auf mein System läuft. (Danke an die Entwickler)

Firmware 2024.08.18 opendtu-onbattery-generic_esp32s3_usb.factory.bin (opendtu Fusion)
pinmapping.json wurde von 2024.01.26 übernommen.
Victron mppt 100 20 und Victron Battery shunt zeigt Daten an In Ordnung
Powermeter mit Einstellungen: Basic und Passwort. Test verläuft positiv In Ordnung
Ich schaue in die Webkonsole.
DPL Einstellungen: oberes Leistungslimit auf 300 Watt gesetzt.
Problem: Es wird immer das obere Leistungslimit also 300 W eingespeist egal wieviel Strom gerade verbraucht wird.

Es war nicht Meine Absicht sie unter Druck zu setzen.
Das wars dann Vielen Dank für ihre Hilfe. Sie haben mir wirklich enorm geholfen.
Ende des Dialogs. :-(

[madmartin]

Außerdem ist es dringend erfolderlich, dass du weniger schnippisch und etwas freundlicher, geduldiger, und dankbarer bist. Und ganz wichtig: Dich dafür öffnest, dass du etwas falsch gemacht haben könntest das dazu führt, dass "alle Firmwares fehlerhaft sind außer 2024.01.26", denn diese Aussage ist grober Unsinn.

@schlimmchen Ich fühle mit Dir, das Engagement für freie Software wird einem nicht immer gedankt.... Und ich finde Du hast den Punkt gut getroffen und die Worte gut gewählt!

[spcqike]

Zu 1.
sowas wurde bereits gewünscht und, meiner Meinung nach zurecht, abgelehnt. Der dB wert ist mehr eine Schätzung seitens des Systems und, wie du auch sagst, nur zur Installation interessant. Steht da System einmal stabil an Ort und Stelle, bietet der dB wert keinen Mehrwert, und braucht „Platz“ auf der Seite.
auch ich bin der Meinung, dass dieser in den Logs (eventuell noch auf einer Info Seite) ausreicht. Aber nicht auf der Start Seite.

Zu 2.
Kommt das nicht aufs selbe raus? Immerhin bedingen sich der power Meter wert und die Erzeugung. Bzw der powermeter ist abhängig von der Erzeugung. Beide Werte gehen in die Berechnung ein.

JA: dann kann der DPL übersprungen werden und zurück zu 1

so einfach geht es nicht. Immerhin regelt der DPL auch Werte ein, die den Zielwert nicht erreichen. Stichwort solar passthrough. Zusätzlich prüft er, ob die Batterie überhaupt noch entladen werden darf, und weiteres. Was nützt es, wenn du -5W hast, aber die Batterie grade tiefenentladen wird?

Meiner Meinung nach würde das CPU Zeit sparen, da der DPL nur dann berechnet wird wenn es nötigt ist.
Sinnvoll oder nicht ?

Ich denke, Menschen sind nicht gut darin, CPU Zeit zu berechnen oder abzuschätzen, ob sich da was lohnt zu sparen. Der ESP betreibt keine großen Berechnungen und befeuert kein LLM. Der DPL Zyklus dauert wenige ms. Der sollte schon mehrmals pro s laufen können.

Zu 3.
hier wäre ein log schön. Ich hatte solche Probleme anfangs ebenfalls, dachte aber diese wurden mit den letzten Anpassungen beseitigt. Zumindest läuft es bei mir seither tadellos.

[Martin0475]

Entschuldigt bitte, ihr habt recht.... das neue Limit wird gesetzt wenn es größer ist .
Auch trotz der Meldung All Channels are shaded.

Lag wohl tatsächlich an der Batterie.

Um die Fragen noch zu beantworten: Jeder Speicher hat 2 Ausgänge mit je 10A und rund 40Volt.
Ich habe momentan nur einen Anschluss genutzt und da gehen max 375 Watt.
Warum da bei knapp 200 watt Schluss war weiss ich nicht.

Aktuell gehts wieder.

[AndreasBoehm]

Auch trotz der Meldung All Channels are shaded.

Diese Meldung taucht nicht auf wenn das neue Limit gesetzt wird weil es größer ist.

[madmartin]

Zu 1. sowas wurde bereits gewünscht und, meiner Meinung nach zurecht, abgelehnt. Der dB wert ist mehr eine Schätzung seitens des Systems und, wie du auch sagst, nur zur Installation interessant. Steht da System einmal stabil an Ort und Stelle, bietet der dB wert keinen Mehrwert, und braucht „Platz“ auf der Seite. auch ich bin der Meinung, dass dieser in den Logs (eventuell noch auf einer Info Seite) ausreicht. Aber nicht auf der Start Seite.

@spcqike
Eine Möglichkeit den "Empfangspegel" (so ungenau er auch sein mag) als Live-Wert angezeigt zu kriegen wäre vielleicht schon nicht schlecht. Ich könnte mir vorstellen diesen Wert auf der Web-Console im 1-2-3 Sekunden Abstand zu loggen, natürlich über einen Menüpunkt an- und abschaltbar. Ich kann mich der Argumentation daß das auf der Haupt-Info-Seite nichts zu suchen hat voll anschliessen. (und ich müsste mal schauen ob die Web-Console schon im OpenDTU Projekt drin ist, wenn ja wäre das ein Feature Request für OpenDTU).

[Martin0475]

zu dem Empfangspegel: der wird ja in der Konsole angezeigt wenn man das verbose logging einschaltet. Allerdings müllt man sich die Konsole mit jeder Menge TX und RX daten zu.

Wie wäre es wenn man bei ausgeschaltetem verbose logging den dbm wert hinter dem Sucess schreibt ?

fetch inverter....
...
...
sucess @ -65dBm

oder so ähnlich?

[schlimmchen]

Falls diese Info in diesem Moment recht einfach abzurufen ist, macht das Sinn. Erstelle ein Feature-Request (Issue).

[schlimmchen]

Zu 2: Es gibt einen weiteren Grund: Die WR erreichen mitunter das gesetzte Limit nicht. Nehmen wir einen festen Verbrauch an, dann läuft der WR auch theoretisch immer auf den gleichen Limit. Wenn er aber 20W daneben liegt und die Hysterese ist bei 10W, dann erhält er in jedem DPL Durchlauf ein neues Limit, nämlich jenes, das er schon hat. Das wird nur noch schlimmer mit solarbetriebenen WR. Die Hysterese an das eingestellte Limit zu knüpfen ist daher wichtig.

Zu 3:

da an einem Eingang eine Batterie B2500 mit max 800Watt Entladeleistung ist..
Das klingt stark danach als wurde hier ein WR mit verschieden gespeisten Eingängen (solar und Batterie) verbaut. Dafür gibts von mir keine Unterstützung, weil das Projekt dieses Setup ausdrücklich nicht unterstützt.

[schlimmchen]

@Martin1275 Schau mal die aktualisierte Doku. Du kannst es dir sparen eine Datei zu editieren, geht per GUI.

Was den Fehler betrifft: Kann ich nicht nachvollziehen. Warst du zwischendurch mal ungeduldig und hast auf Abbrechen geklickt, während PlatformIO initialisierte?

[Martin0475]

Ich habe mal komplett neu aufgesetzt nach der neuen Doku:

1. Install GIT: Folgendes in der Powershell eingeben: winget install --id Git.Git -e --source winget
2. Install Visual Studio Code: VSCodeUserSetup-x64-1.92.2.exe starten.
3. PlatformIO hinzufügen: Auf der PlatformIO Seite den grünen Install Button klicken.
4. Den Anweisungen gefolgt und das Repository geklont
5. Webapp bauen ; NodeJS installieren; (Im Terminal von VSCode eingeben:)
   `

installs fnm (Fast Node Manager)

winget install Schniz.fnm

configure fnm environment

fnm env --use-on-cd | Out-String | Invoke-Expression

download and install Node.js

fnm use --install-if-missing 20

verifies the right Node.js version is in the environment

node -v # should print v20.17.0

verifies the right npm version is in the environment

npm -v # should print `10.8.2``

danach im VSCode Terminal, während das Projekt geöffnet ist:

cd webapp yarn install yarn build

eingeben.

6. Port ausgewählt (COM4) bei meinem PC
   (Hab VScode neugestartet, dann hat er nochmals Abhängigkeiten installiert.)

7. Die "4MB_no_ota" ausgewählt.

Auf den Pfeil nach rechts klicken:

 *  Executing task: C:\Users\Martin\.platformio\penv\Scripts\platformio.exe run --target upload --environment generic_esp32_4mb_no_ota --upload-port COM5 

Processing generic_esp32_4mb_no_ota (board: esp32dev; framework: arduino; platform: [email protected])
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
Firmware Revision: v24.8.5-22-g9ebbc58
Firmware Branch: development
No custom_patches specified
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html
PLATFORM: Espressif 32 (6.8.1) > Espressif ESP32 Dev Module
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, esp-bridge, esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:
 - framework-arduinoespressif32 @ 3.20017.0 (2.0.17)
 - tool-esptoolpy @ 1.40501.0 (4.5.1)
 - tool-mkfatfs @ 2.0.1
 - tool-mklittlefs @ 1.203.210628 (2.3)
 - tool-mkspiffs @ 2.230.0 (2.30)
 - tool-openocd-esp32 @ 2.1100.20220706 (11.0) 
 - toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 56 compatible libraries
Scanning dependencies...
Dependency Graph
|-- ESPAsyncWebServer @ 3.1.2
|-- ArduinoJson @ 7.1.0
|-- espMqttClient @ 1.7.0+sha.70d3113
|-- RF24 @ 1.4.9
|-- U8g2 @ 2.35.19
|-- sunset @ 1.1.7
|-- TaskScheduler @ 3.8.5+sha.16ec5be
|-- mcp_can @ 1.5.1+sha.f97ed43
|-- EspSoftwareSerial @ 8.2.0
|-- LittleFS @ 2.0.0
|-- Hoymiles @ 0.0.1
|-- ESPmDNS @ 2.0.0
|-- WiFiClientSecure @ 2.0.0
|-- SPI @ 2.0.0
|-- Frozen
|-- Ethernet @ 2.0.0
|-- WiFi @ 2.0.0
|-- Update @ 2.0.0
|-- VeDirectFrameHandler
|-- CpuTemperature
|-- ResetReason
|-- MqttSubscribeParser
|-- Ticker @ 2.0.0
|-- DNSServer @ 2.0.0
|-- HTTPClient @ 2.0.0
|-- TimeoutHelper @ 0.0.1
|-- SdmEnergyMeter
|-- SMLParser
Building in release mode
Compiling .pio\build\generic_esp32_4mb_no_ota\src\Battery.cpp.o
Compiling .pio\build\generic_esp32_4mb_no_ota\src\BatteryCanReceiver.cpp.o
Compiling .pio\build\generic_esp32_4mb_no_ota\src\BatteryStats.cpp.o
Compiling .pio\build\generic_esp32_4mb_no_ota\src\Configuration.cpp.o
In file included from C:/Users/Martin/.platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal.h:83,
                 from C:/Users/Martin/.platformio/packages/framework-arduinoespressif32/cores/esp32/Arduino.h:36,
                 from include/PinMapping.h:4,
                 from include/Configuration.h:4,
                 from src/Configuration.cpp:5:
C:/Users/Martin/.platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-gpio.h:29:10: fatal error: pins_arduino.h: No such file or directory

**********************************************************************
* Looking for pins_arduino.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:pins_arduino.h"
* Web  > https://registry.platformio.org/search?q=header:pins_arduino.h
*
**********************************************************************

 #include "pins_arduino.h"
          ^~~~~~~~~~~~~~~~
compilation terminated.
*** [.pio\build\generic_esp32_4mb_no_ota\src\Configuration.cpp.o] Error 1
In file included from C:/Users/Martin/.platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal.h:83,
                 from C:/Users/Martin/.platformio/packages/framework-arduinoespressif32/cores/esp32/Arduino.h:36,
                 from .pio/libdeps/generic_esp32_4mb_no_ota/ArduinoJson/src/ArduinoJson.hpp:18,
                 from .pio/libdeps/generic_esp32_4mb_no_ota/ArduinoJson/src/ArduinoJson.h:9,
                 from .pio/libdeps/generic_esp32_4mb_no_ota/ESPAsyncWebServer/src/AsyncJson.h:37,
                 from include/BatteryStats.h:6,
                 from src/BatteryStats.cpp:4:
C:/Users/Martin/.platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-gpio.h:29:10: fatal error: pins_arduino.h: No such file or directory

**********************************************************************
* Looking for pins_arduino.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:pins_arduino.h"
* Web  > https://registry.platformio.org/search?q=header:pins_arduino.h
*
**********************************************************************

 #include "pins_arduino.h"
          ^~~~~~~~~~~~~~~~
compilation terminated.
*** [.pio\build\generic_esp32_4mb_no_ota\src\BatteryStats.cpp.o] Error 1
In file included from C:/Users/Martin/.platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal.h:83,
                 from C:/Users/Martin/.platformio/packages/framework-arduinoespressif32/cores/esp32/Arduino.h:36,
                 from .pio/libdeps/generic_esp32_4mb_no_ota/ArduinoJson/src/ArduinoJson.hpp:18,
                 from .pio/libdeps/generic_esp32_4mb_no_ota/ArduinoJson/src/ArduinoJson.h:9,
                 from .pio/libdeps/generic_esp32_4mb_no_ota/ESPAsyncWebServer/src/AsyncJson.h:37,
                 from include/BatteryStats.h:6,
                 from include/Battery.h:8,
                 from src/Battery.cpp:2:
C:/Users/Martin/.platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-gpio.h:29:10: fatal error: pins_arduino.h: No such file or directory

**********************************************************************
* Looking for pins_arduino.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:pins_arduino.h"
* Web  > https://registry.platformio.org/search?q=header:pins_arduino.h
*
**********************************************************************

 #include "pins_arduino.h"
          ^~~~~~~~~~~~~~~~
compilation terminated.
In file included from C:/Users/Martin/.platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal.h:83,
                 from C:/Users/Martin/.platformio/packages/framework-arduinoespressif32/cores/esp32/Arduino.h:36,
                 from .pio/libdeps/generic_esp32_4mb_no_ota/ArduinoJson/src/ArduinoJson.hpp:18,
                 from .pio/libdeps/generic_esp32_4mb_no_ota/ArduinoJson/src/ArduinoJson.h:9,
                 from .pio/libdeps/generic_esp32_4mb_no_ota/ESPAsyncWebServer/src/AsyncJson.h:37,
                 from include/BatteryStats.h:6,
                 from include/Battery.h:8,
                 from include/BatteryCanReceiver.h:4,
                 from src/BatteryCanReceiver.cpp:2:
C:/Users/Martin/.platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-gpio.h:29:10: fatal error: pins_arduino.h: No such file or directory

**********************************************************************
* Looking for pins_arduino.h dependency? Check our library registry!
*
* CLI  > platformio lib search "header:pins_arduino.h"
* Web  > https://registry.platformio.org/search?q=header:pins_arduino.h
*
**********************************************************************

 #include "pins_arduino.h"
          ^~~~~~~~~~~~~~~~
compilation terminated.
*** [.pio\build\generic_esp32_4mb_no_ota\src\Battery.cpp.o] Error 1
*** [.pio\build\generic_esp32_4mb_no_ota\src\BatteryCanReceiver.cpp.o] Error 1
================================================================================ [FAILED] Took 11.33 seconds ================================================================================

Environment               Status    Duration
------------------------  --------  ------------
generic_esp32_4mb_no_ota  FAILED    00:00:11.330
=========================================================================== 1 failed, 0 succeeded in 00:00:11.330 ===========================================================================

 *  The terminal process "C:\Users\Martin\.platformio\penv\Scripts\platformio.exe 'run', '--target', 'upload', '--environment', 'generic_esp32_4mb_no_ota', '--upload-port', 'COM5'" terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it. 

Hier hänge ich nun.
Tut mir Leid wenn ich mit meinen Anfängerproblemen nerve... Aber vielleicht hilft diese Schritt für Schritt Anleitung später jemand anderen auch.

[Martin0475]

Nach nochmaligen neuen aufsetzen, diesmal nach dem Video aus dem OpenDTU Wiki hat es mit dem kompilieren geklappt. :-)

[schlimmchen]

Merkwürdig. Ich hoffe aber sehr, dass weniger das Video geholfen hat und mehr das Neuinstallieren von vscode. Oder kennst du die konkrete Ursache für dein Problem? Jedenfalls schön, dass es geklappt hat! 💪

[Martin0475]

Ich kann nur vermuten dass der Windows installer von nodejs das was vermurkst hat . der hat in einer Powershell jede Menge Tools nachgelsden mit vielen Fehlermeldungen.

Danach hab ich Platformio in vscode nochmal neu installiert (also die toolchain und compiler neu heruntergeladen/aktualisiert) danach lief es ohne probleme durch.

[rainer667]

Herzlichen Dank an alle zu dieser Version!!
Bei mir läuft das alles sehr gut! Keine Klagen.
Als einziges würde ich mir wünschen einen 2. Wechselrichter dazu haben. Aber evtl. läßt sich das Problem mit den neuen Hoymiles MiT-4000-8T erledigen.

[schlimmchen]

Als einziges würde ich mir wünschen einen 2. Wechselrichter dazu haben.

Ja, da gibts es ja schon Issues/Requests und ich bin dran und werde demnächst etwas liefern (zumindest für Systeme wo alle WR an der Batterie hängen).

[rainer667]

Klasse!

[tobi0171]

Herzlichen Dank für euren unermüdlichen Einsatz in diesem Projekt an alle Beteiligten und für die ständigen Optimierungen.

Die vielen neuen Features sind klasse, ebenfalls die neue Webansicht und zusätzlichen Fenster.

Was mir aufgefallen ist (Anwenderfehler nicht ausgeschlossen), ist jedoch, das der ESP (S3-16mb) etwas holpriger läuft als zuvor und sich auch einmal komplett verhaspelt hatte (kam nicht nochmal vor, seit Update auf dev-Build).
Gefühlt ist die Regelung und Genauigkeit des DPL leider etwas träger und ungenauer geworden, vielleicht könnte sich das nochmal jmd. ansehen (sofern ich kein Einzelfall bin).
Ich nutze aber inzwischen das dev-Build g9ebbc58.

(Nachtrag nach 3 Wochen dauereinsatz... leider friert mir die DTU gelegentlich ein... hab eine Meldung in den Diskussionen dazu gemacht)

Freuen würde ich mich tatsächlich (nur als Ideen), wenn:

• irgendwann 2 WR dynamisch regelbar wären (scheinbar schon in Arbeit)
• der Pylontech über RS485 im Detail abgefragt werden kann (+Mini-Doku). (Scheinbar ebenfalls schon in Arbeit)
• sich der DPL anhand des Ladezustandes(z.B >90%) und vorhandener MPPT Leistung (z.B 1122W) ohne Limit (z.B mit einem HM1500 oder HMS2000) ans Maximum der vorhandenen MPPT-Leistung, möglichen WR Leistung (je nach WR) und dem benötigtem Netzbezug anpassen könnte (sofern ausreichend Solarleistung z.B 1600W) ansteht, um so das maximale "ernten" und den Bedarf noch optimaler decken zu können. (Falls das überhaupt irgendwie realisierbar ist).
• Eventuell für den ein oder anderen interessant wäre es ggf, wenn man den solar-passthrough in der Leistung begrenzen könnte. Z.B "aktuelles Limit + XXX W (z.B 100W), das wäre genug um eine interne/externe Überschussregelung/Huawei anzusprechen, würde aber nicht unnötig den WR zu (hoch) Leistung zwingen (ggf höhere Temperaturen), für Leistung die notfalls dann eh im Netz verschwindet.

Danke euch.