Das Elend mit dem langsamen Huawei SDongleA-05 hat ein einfaches Ende

[TRON4R]

Das Problem:

Ich weiß nicht, wie es Euch geht, aber ich war mit meiner PV-Anlage von Huawei eigentlich insgesamt recht zufrieden.
Bis auf die Tatsache, dass es in der FusionSolar-App 5 Minuten dauerte, bis die Anzeige des momentanen PV-Ertrages geupdatet wurde.

Das Ganze wurde noch ein Stück unschöner, als ich evcc das erste Mal eingerichtet hatte und dabei feststellen musste, dass das Default-Intervall von 30 Sekunden für meine Anlage (Grid Meter, Master-Wechselrichter, Slave-Wechselrichter und LUNA-Batterie) zu kurz war und ich es auf 45 Sekunden hochsetzen musste, um die unschönen Fehlermeldungen im Logfile von evcc zu vermeiden.

45 Sekunden war allerdings nicht wirklich ideal. An wolkigen Tagen passierte es schnell, dass evcc regelmäßig der Entwicklung hinterherlief und erst dann die Ladeleistung herunterregelte, wenn die Wolke schon wieder fast vorbeigezogen war. Mit dem Effekt, dass der wolkenfreie Abschnitt nicht genutzt wurde und wenn evcc dann endlich wieder hochregelte, kam schon wieder die nächste Wolke und das Auto wurde mit viel zu viel Netzbezug geladen. 🤪

Irgendwann stieß ich dann auf den Tipp, die Baudrate im SDongle und den beiden Wechselrichtern auf 19.200 Baud hochzusetzen (Wer wissen möchte, wie das geht, findet hier eine Anleitung). Das erlaubte es mir wenigstens, das Intervall wieder auf 35 Sekunden zu reduzieren. Soweit war alles in Ordnung, bis dann mit dem Firmware-Update des Dongle auf die V200R022C10SPC200 durch meinen Solarteur das System plötzlich anfing, ab und zu mal Aussetzer zu haben.

Was bedeutete, dass die FusionSolar-App meine Anlage als offline anzeigte und evcc nur noch Timeouts bei der Abfrage der PV-Werte zurückmeldete. Anfangs trat das Problem nur alle paar Tage auf, aber mit der Zeit (und neueren Firmwares wie z.B. der V200R022C10SPC210) wurde es immer schlimmer und irgendwann war mein Alarm-Logfile für den Dongle in FusionSolar mit 2 bis 3 Netzwerkverbindungsfehler-Einträgen pro Tag gesegnet. Manche Aussetzer dauerten nur ein paar Minuten, andere aber gerne auch mal länger als eine halbe Stunde.

Auch ein Upgrade auf die V200R022C10SPC300 änderte daran leider gar nichts und das Upgrade auf ganz neue V200R025C00SPC100 wurde mir von der App mit dem Hinweis "falsche Hardware" verweigert.
Ein testweises Abschalten von evcc für 24 Stunden änderte ebenfalls nichts daran, dass ich 24 Stunden später wie immer mehrere Aussetzer im Huawei-Alarmbereich vorfand. evcc war also definitiv zwar betroffen, aber nicht ursächlich für die Problematik.

Als ich dann am 22. Juli mein Auto laden wollte und der Wagen mit 7,2 kW lud und dann der Dongle wieder einmal aussetzte und eine lange Wolkenschicht deswegen für eine halbe Stunde nicht berücksichtigt werden konnte, wurde es mir zu bunt. Am Abend waren es bereits 5 Aussetzer für den Tag und der letzte dauerte von 19:30 Uhr bis ich entnervt gegen 22:00 Uhr den Dongle aus dem Wechselrichter gezogen habe, um das WLAN des Dongle zu starten und die Firmware wieder auf die einige Monate alte V200R022C10SPC126 downzugraden.
Und siehe da, auch 24 Stunden später gab es keine neuen Alarmmeldungen in FusionSolar. Wenigstens etwas.

Das hätte aber jetzt faktisch bedeutet, dass ich bis zum Tod der Anlage voraussichtlich keinerlei Updates mehr würde einspielen können und es entsprechend nur noch eine Frage der Zeit sein würde, bis dann irgendwann auch die anderen Komponenten auf dem Firmwarestand eingefroren werden müssten, weil sie nicht mehr abwärtskompatibel mit dem alten Dongle sein würden.

Außerdem kam ich auch nie in den Genuss der neuen Features wie z.B. der Anzeige von Live-Daten oder des LUNA-SoC in der Tagesdiagramm-Ansicht von FusionSolar.

Einen Umstieg auf die neue EMMA oder den SmartLogger hatte ich bislang immer ausgeschlossen. 300 € nur für eine schnellere Datenübertragung auszugeben fand ich unverhältnismäßig, noch abschreckender war für mich aber die Aussicht, dass beim Umstieg möglicherweise meine ganze Historie in FusionSolar verloren gehen könnte. Obendrein brauche ich weder die Power eines SmartLoggers, der auf das Management von Großanlagen ausgelegt ist, noch eine - laut Aussage von vielen - nicht funktionierende KI, die die einzige Rechtfertigung für den hohen Preis der EMMA darstellt und dank evcc sowieso überhaupt nicht gebraucht wird.

Die Vorbereitung der Lösung

Und so war ich recht erstaunt, als ich vor wenigen Tagen darauf stieß, dass es mindestens drei verschiedene Hardware-Versionen des SDongleA-05 zu geben schien, von der zumindest eine die ganzen Probleme nicht (mehr) hatte. Nicht mehr, weil der stärkere Prozessor mit einem Firmware-Update dazu gebracht wird, die TLS-Encryption über einen integrierten AES-Zusatzchip abzuwickeln, sodass die CPU-Power für andere Tätigkeiten genutzt werden kann.

Mindestens diese Varianten des SDongleA-05 gibt es. Eine Unterscheidung ist durch das Etikett hinter PN/ITEM möglich:
02312QMV-005 → (alte?) Hardware mit STM32F427 CPU, welche weder Echtzeit- noch SoC-Anzeige in FusionSolar unterstützt und nur langsame ModBus-Abfragen bietet. Bis Firmware V200R022C10SPC126 noch erträglich, mit PC200, PC210 und PC300 gibt es häufige und längere Aussetzer sowohl in FusionSolar als auch mit evcc in der ModBus-Abfrage. Die allerneueste V200R025C00SPC100 lässt sich auch nicht auf dieser Hardware installieren.

02312QMV-004 → (neue?) Hardware mit HC32F4A0SITB CPU, welche ab Firmware V200R022C10SPC118 Echtzeit-Anzeigen unterstützt, seit einigen Wochen auch die SoC-Anzeige in FusionSolar bietet, keine Probleme mit PC200 und PC210 macht und ab PC300 sogar rasant schnelle ModBus-Abfragen z.B. mit evcc erlaubt. Ein Upgrade auf die allerneueste V200R025C00SPC100 ist möglich.

02312QMV (ja, ohne jedes Anhängsel) → die Wundertüte, wo sowohl die alte CPU als auch die neue CPU verbaut sein können.
a) Aber selbst wenn dort die neue HC32 CPU verbaut ist, unterstützt der Dongle wohl trotzdem oft keine Echtzeit-Anzeige in FusionSolar und auch nur langsame ModBus-Abfragen durch evcc. Egal, welche Firmware installiert ist. Ein Upgrade auf die allerneueste V200R025C00SPC100 ist wohl möglich, verbessert aber auch nichts. Ob der Batterie-SoC angezeigt wird, ist unklar.
b) Andere wiederum berichten, dass sie mit einem Dongle mit dieser Aufschrift die Echtzeit- und die SoC-Anzeige haben. Aber auch dann ist die ModBus-Abfrage relativ langsam und der Dongle mit einer höheren Firmware als der PC126 nicht mehr brauchbar.

02314ALM → laut Huawei sollte der theoretisch zumindest die Echtzeit-Daten unterstützen. Ansonsten ist mir über diese Variante des SDongle leider nicht viel bekannt, da bisher kein Huawei-Anlagenbesitzer diese im Einsatz zu haben scheint. Es handelt sich aber wohl auch um die 4G-Variante und keinen LAN/WLAN-SDongle.

Wenn man nachschauen möchte, ob man den schnellen HC32-Chip oder den langsamen STM32-Chip verbaut hat, dann muss man den Dongle aus dem Wechselrichter ziehen und die Clipse an der Seite leicht eindrücken und das Gehäuse auseinanderziehen. Dazu braucht es keine besondere Erfahrung und man kann den Dongle anschließend auch problemlos wieder so zusammenstecken (es gibt auch nur eine richtige Richtung, man kann also nichts verkehrt machen), dass man hinterher nicht sieht, dass er jemals geöffnet wurde.

Die Lösung

Nachdem klar wurde, dass nun die Möglichkeit bestand für knapp 60 € einfach auf einen schnelleren Dongle zu wechseln, was obendrein frei vom Risiko des Verlusts der historischen Daten in der Cloud zu sein schien, war ich angefixt.

Mindestens die folgenden beiden Onlineshops bieten explizit den SDongleA-05 in der schnellen Variante 02312QMV-004 an:
https://www.elektroshopwagner.de/product_info.php?info=p378369 (Aktuell 2 Tage Lieferzeit)
und
https://www.elektroland24.de/neue-energien/photovoltaik/zubehoer/huawei-02312qmv-004-smart-dongle-a-05-fuer-wlan-und-fast-ethernet-fe.html (Ein paar Euro günstiger, aber dafür aktuell 8 Tage Lieferzeit)

Jetzt, 2 Tage später, habe ich den Dongle erhalten und natürlich sofort eingesetzt.
Und in der Tat kann ich folgende Unterschiede bestätigen:

1. Die grüne LED vorne auf dem SDongle leuchtet jetzt meist dauerhaft und blinkt nur noch ganz selten
2. Das WLAN des SDongle ist jetzt dauerhaft aktiv und nicht nur kurze Zeit nach dem Einstecken des SDongle in den Wechselrichter (oder in eine andere Stromquelle)
3. Man kann sich nicht mehr mit dem Passwort Changeme am WLAN anmelden, sondern nur noch über das Scannen des QR-Codes vorne auf dem SDongle, da jetzt jedes Dongle einen individuellen Code aus Buchstaben und Zahlen zu haben scheint.
4. Das Einstellungsmenü beim Anmelden mit der FusionSolar-App direkt am SDongle ist viel umfangreicher (bietet 6 Kacheln statt nur 2)
5. In FusionSolar (WebPortal und App) ist endlich der Button Live Data verfügbar und der SoC meiner LUNA wird mir auch jetzt für jeden Tag als Kurve im Tagesdiagramm angezeigt! 🎉
6. Die Abfrage per ModBus z.B. via evcc geht dramatisch schneller (Ich konnte das Intervall in evcc auf 5 Sekunden(!) reduzieren und es gab immer noch keine Fehler im Logfile - vorher hatte ich bei einem 30 Sekunden großen Intervall schon regelmäßig Timeout-Fehlermeldungen im evcc-log). Und ich habe wie gesagt ein Setup mit 4 Devices. Da hat früher manchmal jede einzelne Geräteabfrage bis zu 10 Sekunden gedauert. Jetzt meldet sich evcc in der Kommandozeile nach spätestens einer Sekunde mit den Werten zurück.
7. Während evcc läuft (z.B. mit einem 15 Sekunden Intervall) kann ich in der FusionSolar-App z.B. den Min-SoC für die LUNA-Batterie verändern und der Befehl geht jedes Mal auf Anhieb durch. Vorher kam selbst bei einem 35 Sekunden Intervall in evcc in 2 von 3 Fällen ein “Operation fehlgeschlagen” zurück. Jetzt kann ich sogar mit einer zweiten evcc-Instanz manuelle Abfragen an evcc schicken und es kommt nur selten zu Timeouts in einer der beiden Instanzen.

Das wäre vorher alles völlig undenkbar gewesen!

Daher meine klare Empfehlung an jeden, der das Problem mit minimalem Aufwand erschlagen will:
Entweder den Dongle mit der PN/ITEM-ID 02312QMV-004 online kaufen oder der Huawei-Hotline solange auf den Geist gehen, bis sie einem den richtigen Dongle im Rahmen eines Austausches zuschicken. Das hat laut Aussage von einer Person, die sich immer wieder über die mehrfachen täglichen Aussetzer in FusionSolar bei der Hotline beschwert hat, auch geklappt.

HowTo - Wie kann ich den SDongle ohne Datenverlust austauschen?

Meine erste Überraschung heute:
Man braucht dazu keine Installer-Rechte im Web-Portal von FusionSolar. Der Button Replace Device war nur ausgegraut, weil das zu tauschende Gerät OFFLINE sein muss, um ersetzt werden zu können und nicht, weil ich mir die Rechte fehlten. Sobald es als offline erkannt wurde (das hat bei mir 20 Minuten gedauert!) konnte ich auch mit meinen normalen Userrechten den dann nicht mehr ausgegrauten Button anklicken.

D.h. jeder Nutzer sollte mit den folgenden Schritten den Austausch in der Web-Oberfläche von FusionSolar ohne Datenverlust vollziehen können (in der FusionSolar-App geht es wohl auch, aber dann sehen einige Schritte entsprechend ein bisschen anders aus):

1. Alten SDongleA-05 vom Wechselrichter abziehen, das Netzwerkkabel aus dem Dongle rausziehen.
2. Netzwerkkabel an neuen SDongleA-05 anstecken und das Ende gut zuschrauben.
3. Neuen SDongle in Wechselrichter einstecken und am USB-A-Port des Wechselrichters wie gewohnt festschrauben
4. Es kann beim ersten Start des SDongle länger als sonst dauern, bis die LED des Dongle angeht (bis zu 30 Sekunden)
5. Sobald der neue Dongle blinkt, muss man noch ca. 20 Minuten warten, bis FusionSolar merkt, dass der alte SDongle offline ist.
6. In FusionSolar auf den Namen der Anlage links oben klicken (NICHT auf den Dongle eine Ebene darunter klicken!)
7. Device Management → Checkbox vor dem grau (offline) angezeigten Dongle anklicken
8. Button Replace Device anklicken
9. In dem sich öffnenden Fenster wird links unter Source Device der alte Dongle angezeigt. In dem Bereich rechts daneben unter Target Device die neue Seriennummer (zu finden auf dem unteren Aufkleber des SDongle) eintragen und auf View klicken
10. Nach ein paar Sekunden werden einem die vollständigen Daten des neuen Dongle angezeigt
    (sollte das nicht klappen, einfach warten, bis die LED am neuen SDongle die meiste Zeit grün leuchtet und nicht mehr beständig blinkt. Das kann möglicherweise auch nochmal eine halbe Stunde dauern).
11. Nun unten rechts auf den Button Replace klicken
12. Nach wenigen Minuten (ggf. das Browser-Fenster von FusionSolar mit SHIFT+Reload refreshen) sollte einem die eigene Anlage wieder als grün (online) angezeigt werden
13. Im Dongle sollte man jetzt noch die Erstinstallation (Grundeinstellungen) aufrufen und durchgehen. Dazu am besten in der FusionSolar App sich über den Punkt "Inbetriebnahme" direkt am WiFi des neuen Dongle anmelden (das geht nur noch mittels QR-Code Scan, dass frühere Passwort Changeme ist Geschichte)

Folgende Dinge sollte man jetzt noch beachten bzw. checken, damit man keine Probleme mit evcc bekommt:

• Ist die IP wieder dieselbe wie vom alten SDongle? (sonst im Router bzw. DHCP-Server anpassen)
• Ist die ModBus ID wieder dieselbe wie vorher (einzelne User berichteten, dass sich die ModBus ID von 1 auf 2 erhöht habe. Das war bei mir allerdings NICHT der Fall. Bei mir war weiterhin der Slave auf ID 1 und der Master auf ID 16. Ich bin daher sehr skeptisch, ob das wirklich häufiger passiert, wollte es aber der Vollständigkeit halber hier erwähnt haben.)
• Falls man die Baudrate im Dongle und dem/den Wechselrichter(n) von 9.600 auf 19.200 erhöht hatte, muss man dies jetzt noch einmal in allen Geräten nachholen, denn meine Geräte hatten sich durch den Dongle-Wechsel alle automatisch wieder auf 9.600 Baud umgestellt. Wobei die Umstellung mit dem neuen schnelleren Dongle vielleicht auch gar nicht mehr erforderlich ist?
• ggf. die Firmware vom SDongle noch updaten (meiner wurde am 25.7.2025 mit der uralten V200R022C10SPC110 ausgeliefert!)

Wie schon gesagt, kann man jetzt theoretisch evcc sogar mit einem Aktualisierungsintervall von nur 5 Sekunden laufen lassen, ohne dass es seitens der Huawei-Devices zu Timeouts kommen würde, selbst wenn man wie ich vier abzufragende Devices hat.
So ein kurzes Intervall macht natürlich keinen Sinn, weil es dann zu einem Schwingen der Steuerung kommen kann und die Wallboxen völlig kirre werden. Aber zumindest mit Werten leicht unter 30 Sekunden werde ich auf jeden Fall mal rumexperimentieren.

Wenn es noch Fragen dazu geben sollte, einfach unten im Thread stellen. Aber ich hoffe, dass ich mit dieser Lösung alle relevanten Punkte nachvollziehbar und ausreichend detailliert erklärt habe.

Wer noch zur Klärung der unterschiedlichen Hardware-Varianten beitragen möchte, der kann seine SDongle-Daten und -Erfahrungen in diesem Sheet teilen, welches @CiNcH83 extra dafür angelegt hat.

[detlefheese]

Super! Das klingt hervorragend! Das mache ich auch!

[CiNcH83]

Das hat laut Aussage von einer Person, die sich immer wieder über die mehrfachen täglichen Aussetzer in FusionSolar bei der Hotline beschwert hat, auch geklappt.

Das war dann ich... Seit Dezember 2024 wurde mir zweimal eine FW auf meine Anlage gespielt, die mir die Überschusssteuerung quasi kaputt gemacht hat. Ein halbes Jahr und immer noch keine Lösung für das Problem. Dem Photovoltaikforum und meinem Installateur zufolge war ich auch bei weitem nicht der einzige, der darunter litt. Diesmal habe ich mich etwas wehementer an den Huawei-Support gewendet, der mir dann einen Tausch des Dongles vorgeschlagen hat. Es sollte ein 02312QMV-004 werden. Dieses Support-Dokument lag schon nahe, dass daran etwas anders ist. Bei Erhalt habe ich dann beide auseinander genommen und unterschiedliche Prozessoren gefunden. Auf den ersten Blick schien der HDSC HC32F4 lediglich ein Pin- und SW-kompatibler Nachbau des STM32F4 zu sein. Nach Studium der Datenblätter stellte sich jedoch heraus, dass der HC32F4 über einen AES Co-Prozessor verfügt, der mit neueren FW Versionen mutmaßlich für die Ver- und Entschlüsselung der Cloud-Kommunikation herangezogen wird und so für den großen Performance-Unterschied sorgt.

Ich habe per tshark auch noch die Modbus TCP Request/Response Zeiten ausgemessen. Was vorher im Sekunden-Bereich gedauert hat, dauert mit dem neuen Dongle noch im einstelligen Millisekundenbereich.

[TRON4R]

Wenn Du auch im Photovoltaikforum aktiv bist, dann warst das wohl in der Tat Du. Ich habe mit meiner "Lösung" hier versucht, den dort gesammelten Erkenntnissen noch mehr Sichtbarkeit zu geben, weil manche Huawei-Nutzer nur in GitHub unterwegs sind bzw. sich nicht für das Photovoltaik-Forum interessieren. Und als evcc-Nutzer ist man von dem langsamen SDongle ja auch noch wesentlich mehr gebeutelt, als als gewöhnlicher Huawei-Nutzer, dem am Ende dann halt mal für 1-2 h am Tag nur der Zugriff auf die eigene Anlage fehlt.

In jedem Fall möchte ich dann auch nochmal an dieser Stelle Dir ganz herzlich für Deine tolle Recherche-Arbeit danken ohne die ich mich immer noch mit meinem nervigen Schrott-005-SDongle herumschlagen würde.

[CiNcH83]

Ich habe das Setup jetzt übrigens seit über einer Woche mit evcc und einem 15s Zyklus am Laufen. Ich habe jetzt mal die evcc Docker-Logs nach Fehlern durchsucht und seit dem Umbau keinen einzigen Timeout mehr gefunden. Davor gab es täglich mehrere...

[TRON4R]

Bei mir das Gleiche. Seit der Installation des neuen Dongles trotz der V200R022C10SPC300 keine einziger Timeout-Alarm mehr in der FusionSolar-App oder im evcc-log. Vorher mit dem -005-Dongle hatte ich davon mindestens zwei, oft sogar mehr jeden Tag.

Den alten Schrott-Dongle auszutauschen war echt das Beste, was ich für mein PV-System und evcc tun konnte.

[CarG70]

vielen Dank für den sehr ausführlichen Bericht. Da ich auch eine Anlage von Huawei inkl. Dongle betreibe, hat mich dann doch mal interessiert, was bei mir da so verbaut ist. Es ist die Wundertüte QMV (ohne weiteren Zusatz). Dieser unterstützt bei mir die Echtzeitabfrage und auch die Anzeige des SoC. Anfangs hatte ich in evcc ein Intervall von 10 sek eingestellt, was der Dongle ohne Fehlermeldungen mitgemacht hat (inzwischen habe ich auf 15 sek gestellt). SW Version ist derzeit die V200R022C10SPC300. Ist also scheinbar eine weitere Variante für den QMV.
Zu meinen Rahmenbedingungen: Ein Wechselrichter, 10kWh Batterie, Anschluß mittels RJ45.

Edit: Ich habe nun ohne Probleme auf V200R025C00SPC100 aktualisiert. Läuft rund.

[flautze]

Ich hab auch den ohne Zusatz und Abfragen über 20 Sekunden Intervall sind problematisch. Aussetzer habe ich so 1-2 /Tag aber nur kurz.
Nur WR und Smartmeter, keine Luna.
Live-Daten gehen bei mir nicht. SW ist schon 210.

hab mir jetzt auch den von Wagner bestellt. Hoffe damit kann ich das Überschussladen besser steuern.

[CiNcH83]

Gerne dann auch Feedback hier.

[TRON4R]

@CiNcH83 Ich habe den Link zu Deinem GoogleSheet übrigens auch ans Ende meiner Lösung eingebaut.

[flautze]

Also ich muss sagen, dass der Dongle bei mir nicht wirklich besser läuft als der vorige. Könnte aber an der FW liegen.

Habe so ein zwei Aussetzer pro Tag (nur kurzer Verbindungsberlust), FW ist V100 und derzeit nur HA über Proxy dran. Die Daten an EVCC geb ich momentan per MQTT weiter.

Rollback müsste auch gehen oder? Welche FW ist dafür empfohlen? V118 oder so?

[TRON4R]

Das liegt definitiv an der Firmware. Der neue HS32-Chip mit der AES-Encryption Einheit wird erst ab einer höheren Firmware richtig ausgenutzt. Geh einfach auf die neue SPC300 und dann sollten Deine Problem verschwinden!

[CiNcH83]

02314ALM → laut Huawei sollte der theoretisch zumindest die Echtzeit-Daten unterstützen. Ansonsten ist mir über diese Variante des SDongleA-05 leider nicht viel bekannt, da bisher kein Huawei-Anlagenbesitzer diese im Einsatz zu haben scheint.

Das ist ein SDongleB-06 4G...

[TRON4R]

Ah, ok. Danke. D.h. der hat mit dem LAN/WLAN-Dongle eigentlich genau gar nichts zu tun...

[CiNcH83]

Richtig... ist der Mobilfunk-Dongle...

[LotharWoman]

Also so richtig verstehe ich das Problem trotzdem nicht. Ich habe seit 22 einen 02312QMV/HC32F4A0SITB im Einsatz und evcc seit etwa einem Jahr. In Homeassistant hat er schon immer seine Probleme, egal welche Firmware. Mit evcc hingegen noch nie, selbst mit 15sec Intervall läuft mein alter Dongle mit neuester Firmware wie eh und je.
Meine Frage wäre eher, was macht evcc so anders als HuaweiSolar? Sollte ich vielleicht doch mal den Proxy in evcc aktivieren? Hat der verwendete Proxy überhaupt Einfluss auf den Datenstrom?
Fragen, Fragen, Fragen.

[LotharWoman]

HA/huawei_solar liest so gut wie alles von WR/Batterie/SM in großen Registerbereichen aus.

Stimmt, aber. evcc hat alle Daten innerhalb 2sec.

[site ] DEBUG 2025/07/31 18:24:48 pv 1 power: 62W
[db:15 ] TRACE 2025/07/31 18:24:48 modbus: recv a4 b6 00 00 00 07 10 03 04 00 00 03 1a
[site ] DEBUG 2025/07/31 18:24:48 grid power: -794W
[db:19 ] TRACE 2025/07/31 18:24:48 modbus: send a4 b7 00 00 00 06 10 03 90 89 00 02
[db:19 ] TRACE 2025/07/31 18:24:48 modbus: recv a4 b7 00 00 00 07 10 03 04 00 00 00 15
[site ] DEBUG 2025/07/31 18:24:48 battery 1 power: -21W
[db:21 ] TRACE 2025/07/31 18:24:48 modbus: send a4 b8 00 00 00 06 01 03 7d 40 00 02
[db:21 ] TRACE 2025/07/31 18:24:50 modbus: recv a4 b8 00 00 00 07 01 03 04 00 00 01 0c
[site ] DEBUG 2025/07/31 18:24:50 pv 3 power: 268W
[db:21 ] TRACE 2025/07/31 18:24:50 modbus: send a4 b9 00 00 00 06 01 03 7d 6a 00 02
[db:21 ] TRACE 2025/07/31 18:24:50 modbus: recv a4 b9 00 00 00 07 01 03 04 00 06 c1 15
[db:20 ] TRACE 2025/07/31 18:24:50 modbus: send a4 ba 00 00 00 06 10 03 7d 40 00 02
[db:20 ] TRACE 2025/07/31 18:24:50 modbus: recv a4 ba 00 00 00 07 10 03 04 00 00 03 d5
[site ] DEBUG 2025/07/31 18:24:50 pv 2 power: 981W
[db:15 ] TRACE 2025/07/31 18:24:50 modbus: send a4 bb 00 00 00 06 10 03 90 f3 00 02
[db:15 ] TRACE 2025/07/31 18:24:50 modbus: recv a4 bb 00 00 00 07 10 03 04 00 00 00 6c
[db:19 ] TRACE 2025/07/31 18:24:50 modbus: send a4 bc 00 00 00 06 10 03 90 cc 00 02
[db:19 ] TRACE 2025/07/31 18:24:50 modbus: recv a4 bc 00 00 00 07 10 03 04 00 07 e1 fb
[db:20 ] TRACE 2025/07/31 18:24:50 modbus: send a4 bd 00 00 00 06 10 03 7d 6a 00 02
[db:20 ] TRACE 2025/07/31 18:24:50 modbus: recv a4 bd 00 00 00 07 10 03 04 00 24 c7 2b
[site ] DEBUG 2025/07/31 18:24:50 pv power: 1311W
[db:15 ] TRACE 2025/07/31 18:24:50 modbus: send a4 be 00 00 00 06 10 03 90 f5 00 02
[db:15 ] TRACE 2025/07/31 18:24:50 modbus: recv a4 be 00 00 00 07 10 03 04 00 00 00 a4
[db:19 ] TRACE 2025/07/31 18:24:50 modbus: send a4 bf 00 00 00 06 10 03 90 8c 00 01
[db:19 ] TRACE 2025/07/31 18:24:50 modbus: recv a4 bf 00 00 00 05 10 03 02 03 e8
[site ] DEBUG 2025/07/31 18:24:50 battery 1 soc: 100%
[db:15 ] TRACE 2025/07/31 18:24:50 modbus: send a4 c0 00 00 00 06 10 03 90 f7 00 02
[db:15 ] TRACE 2025/07/31 18:24:50 modbus: recv a4 c0 00 00 00 07 10 03 04 00 00 00 75
[site ] DEBUG 2025/07/31 18:24:50 grid currents: [-1.08 -1.64 -1.17]A
[db:15 ] TRACE 2025/07/31 18:24:50 modbus: send a4 c1 00 00 00 06 10 03 91 01 00 02
[db:15 ] TRACE 2025/07/31 18:24:50 modbus: recv a4 c1 00 00 00 07 10 03 04 00 08 fb 4c
[site ] DEBUG 2025/07/31 18:24:50 site power: -715W

In Huawei Solar kommen die Daten trotz der umfangreicheren Abfrage aber auch nicht langsamer. Protokoll sieht dort so aus und die Fehler hören sich für mich nicht nach Timeout an.

2025-07-31 18:41:22.040 DEBUG (MainThread) [pymodbus.logging] recv: 0x0 0x3 0x0 0x0 0x0 0x2b 0x10 0x3 0x28 0x0 0x6 0x0 0x2 0x0 0x6 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xc1 0x1d 0x14 0xe1 0x0 0x81 0xb 0x33 0x0 0x6d old_data:  addr=None
2025-07-31 18:41:22.041 DEBUG (MainThread) [pymodbus.logging] Processing: 0x0 0x3 0x0 0x0 0x0 0x2b 0x10 0x3 0x28 0x0 0x6 0x0 0x2 0x0 0x6 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xc1 0x1d 0x14 0xe1 0x0 0x81 0xb 0x33 0x0 0x6d
2025-07-31 18:41:22.042 DEBUG (MainThread) [pymodbus.logging] decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[6, 2, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 49437, 5345, 129, 2867, 109], status=1) 
2025-07-31 18:41:22.043 DEBUG (MainThread) [pymodbus.logging] Frame advanced, resetting header!!
2025-07-31 18:41:22.044 INFO (MainThread) [backoff] Backing off _do_read(...) for 1.0s (huawei_solar.exceptions.SlaveBusyException: Mismatch between number of requested registers (52) and number of received registers (20))
2025-07-31 18:41:22.045 DEBUG (MainThread) [huawei_solar.huawei_solar] Received <class 'huawei_solar.exceptions.SlaveBusyException'>: backing off reading for 1.0 seconds after 1 tries
2025-07-31 18:41:23.048 DEBUG (MainThread) [pymodbus.logging] send: 0x0 0x5 0x0 0x0 0x0 0x6 0x10 0x3 0x7d 0x40 0x0 0x34
2025-07-31 18:41:24.393 DEBUG (MainThread) [pymodbus.logging] recv: 0x0 0x4 0x0 0x0 0x0 0x6b 0x10 0x3 0x68 0x0 0x0 0x3 0x99 0xf 0xf5 0x10 0xa 0x10 0x9 0x9 0x2e 0x9 0x42 0x9 0x49 0x0 0x0 0x5 0x3d 0x0 0x0 0x5 0x35 0x0 0x0 0x5 0x37 0x0 0x0 0x29 0xa7 0x0 0x0 0x3 0x99 0xff 0xff 0xff 0xff 0x3 0xe8 0x13 0x85 0x27 0x10 0x1 0xbf 0xb 0xb8 0x2 0x0 0x0 0x0 0x68 0x8b 0x21 0xcf 0xff 0xff 0xff 0xff 0x0 0x0 0x3 0xa5 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1 0xe2 0xbf 0x0 0x24 0xc7 0x41 0x0 0x27 0x14 0x21 0x68 0x8b 0xc6 0xe5 0x0 0x0 0x0 0x42 0x0 0x0 0x7 0x86 old_data:  addr=None
2025-07-31 18:41:24.393 DEBUG (MainThread) [pymodbus.logging] Processing: 0x0 0x4 0x0 0x0 0x0 0x6b 0x10 0x3 0x68 0x0 0x0 0x3 0x99 0xf 0xf5 0x10 0xa 0x10 0x9 0x9 0x2e 0x9 0x42 0x9 0x49 0x0 0x0 0x5 0x3d 0x0 0x0 0x5 0x35 0x0 0x0 0x5 0x37 0x0 0x0 0x29 0xa7 0x0 0x0 0x3 0x99 0xff 0xff 0xff 0xff 0x3 0xe8 0x13 0x85 0x27 0x10 0x1 0xbf 0xb 0xb8 0x2 0x0 0x0 0x0 0x68 0x8b 0x21 0xcf 0xff 0xff 0xff 0xff 0x0 0x0 0x3 0xa5 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1 0xe2 0xbf 0x0 0x24 0xc7 0x41 0x0 0x27 0x14 0x21 0x68 0x8b 0xc6 0xe5 0x0 0x0 0x0 0x42 0x0 0x0 0x7 0x86
2025-07-31 18:41:24.394 DEBUG (MainThread) [pymodbus.logging] decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[0, 921, 4085, 4106, 4105, 2350, 2370, 2377, 0, 1341, 0, 1333, 0, 1335, 0, 10663, 0, 921, 65535, 65535, 1000, 4997, 10000, 447, 3000, 512, 0, 26763, 8655, 65535, 65535, 0, 933, 0, 0, 0, 0, 0, 0, 1, 1, 58047, 36, 51009, 39, 5153, 26763, 50917, 0, 66, 0, 1926], status=1) 
2025-07-31 18:41:24.394 DEBUG (MainThread) [pymodbus.logging] Frame advanced, resetting header!!
2025-07-31 18:41:24.395 DEBUG (MainThread) [custom_components.huawei_solar] Finished fetching BT22C086_inverter_data_update_coordinator data in 22.351 seconds (success: True)
2025-07-31 18:41:24.405 DEBUG (MainThread) [huawei_solar.bridge] Batch update of the following registers: power_meter_active_power, active_grid_power_factor, active_grid_frequency, grid_exported_energy, grid_accumulated_energy, active_grid_A_power, active_grid_B_power, active_grid_C_power
2025-07-31 18:41:24.406 DEBUG (MainThread) [huawei_solar.huawei_solar] Sleeping for 0.038665 seconds before making next call
2025-07-31 18:41:24.445 DEBUG (MainThread) [huawei_solar.huawei_solar] Reading register 37113 with length 25 from slave 16
2025-07-31 18:41:24.445 DEBUG (MainThread) [pymodbus.logging] send: 0x0 0x6 0x0 0x0 0x0 0x6 0x10 0x3 0x90 0xf9 0x0 0x19
2025-07-31 18:41:26.525 DEBUG (MainThread) [pymodbus.logging] recv: 0x0 0x5 0x0 0x0 0x0 0x6b 0x10 0x3 0x68 0x0 0x0 0x3 0x9b 0xf 0xf5 0x10 0xd 0x10 0xc 0x9 0x2e 0x9 0x43 0x9 0x4b 0x0 0x0 0x5 0x48 0x0 0x0 0x5 0x41 0x0 0x0 0x5 0x43 0x0 0x0 0x29 0xa7 0x0 0x0 0x3 0x9b 0xff 0xff 0xff 0xff 0x3 0xe8 0x13 0x85 0x27 0x10 0x1 0xbe 0xb 0xb8 0x2 0x0 0x0 0x0 0x68 0x8b 0x21 0xcf 0xff 0xff 0xff 0xff 0x0 0x0 0x3 0xa6 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xff 0xff 0xff 0xfc 0x0 0x1 0xe2 0xbf 0x0 0x24 0xc7 0x41 0x0 0x27 0x14 0x21 0x68 0x8b 0xc6 0xe5 0x0 0x0 0x0 0x42 0x0 0x0 0x7 0x86 old_data:  addr=None
2025-07-31 18:41:26.526 DEBUG (MainThread) [pymodbus.logging] Processing: 0x0 0x5 0x0 0x0 0x0 0x6b 0x10 0x3 0x68 0x0 0x0 0x3 0x9b 0xf 0xf5 0x10 0xd 0x10 0xc 0x9 0x2e 0x9 0x43 0x9 0x4b 0x0 0x0 0x5 0x48 0x0 0x0 0x5 0x41 0x0 0x0 0x5 0x43 0x0 0x0 0x29 0xa7 0x0 0x0 0x3 0x9b 0xff 0xff 0xff 0xff 0x3 0xe8 0x13 0x85 0x27 0x10 0x1 0xbe 0xb 0xb8 0x2 0x0 0x0 0x0 0x68 0x8b 0x21 0xcf 0xff 0xff 0xff 0xff 0x0 0x0 0x3 0xa6 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xff 0xff 0xff 0xfc 0x0 0x1 0xe2 0xbf 0x0 0x24 0xc7 0x41 0x0 0x27 0x14 0x21 0x68 0x8b 0xc6 0xe5 0x0 0x0 0x0 0x42 0x0 0x0 0x7 0x86
2025-07-31 18:41:26.527 DEBUG (MainThread) [pymodbus.logging] decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[0, 923, 4085, 4109, 4108, 2350, 2371, 2379, 0, 1352, 0, 1345, 0, 1347, 0, 10663, 0, 923, 65535, 65535, 1000, 4997, 10000, 446, 3000, 512, 0, 26763, 8655, 65535, 65535, 0, 934, 0, 0, 0, 0, 0, 65535, 65532, 1, 58047, 36, 51009, 39, 5153, 26763, 50917, 0, 66, 0, 1926], status=1) 
2025-07-31 18:41:26.527 DEBUG (MainThread) [pymodbus.logging] Frame advanced, resetting header!!
2025-07-31 18:41:26.528 INFO (MainThread) [backoff] Backing off _do_read(...) for 1.0s (huawei_solar.exceptions.SlaveBusyException: Mismatch between number of requested registers (25) and number of received registers (52))
2025-07-31 18:41:26.529 DEBUG (MainThread) [huawei_solar.huawei_solar] Received <class 'huawei_solar.exceptions.SlaveBusyException'>: backing off reading for 1.0 seconds after 1 tries
2025-07-31 18:41:26.561 DEBUG (MainThread) [pymodbus.logging] recv: 0x0 0x6 0x0 0x0 0x0 0x35 0x10 0x3 0x32 0x0 0x0 0x2 0xc1 0x0 0x0 0x0 0x8d 0xfc 0xd0 0x13 0x85 0x0 0x1e 0xa9 0x8a 0x0 0x8 0xfb 0x4c 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x0 0xf 0xf7 0x0 0x0 0x10 0xc 0x0 0x0 0xf 0xfc 0x0 0x0 0x0 0xd7 0x0 0x0 0x1 0x6f 0x0 0x0 0x0 0x7a old_data:  addr=None
2025-07-31 18:41:26.561 DEBUG (MainThread) [pymodbus.logging] Processing: 0x0 0x6 0x0 0x0 0x0 0x35 0x10 0x3 0x32 0x0 0x0 0x2 0xc1 0x0 0x0 0x0 0x8d 0xfc 0xd0 0x13 0x85 0x0 0x1e 0xa9 0x8a 0x0 0x8 0xfb 0x4c 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x0 0xf 0xf7 0x0 0x0 0x10 0xc 0x0 0x0 0xf 0xfc 0x0 0x0 0x0 0xd7 0x0 0x0 0x1 0x6f 0x0 0x0 0x0 0x7a
2025-07-31 18:41:26.562 DEBUG (MainThread) [pymodbus.logging] decoded PDU function_code(3 sub -1) -> ReadHoldingRegistersResponse(dev_id=0, transaction_id=0, address=0, count=0, bits=[], registers=[0, 705, 0, 141, 64720, 4997, 30, 43402, 8, 64332, 0, 0, 1, 0, 4087, 0, 4108, 0, 4092, 0, 215, 0, 367, 0, 122], status=1) 
2025-07-31 18:41:26.562 DEBUG (MainThread) [pymodbus.logging] Frame advanced, resetting header!!
2025-07-31 18:41:26.562 ERROR (MainThread) [homeassistant] Error doing job: Fatal error: protocol.data_received() call failed. (None)
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/asyncio/selector_events.py", line 1019, in _read_ready__data_received
    self._protocol.data_received(data)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
  File "/usr/local/lib/python3.13/site-packages/pymodbus/transport/transport.py", line 304, in data_received
    self.datagram_received(data, None)
    ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/pymodbus/transport/transport.py", line 338, in datagram_received
    cut = self.callback_data(self.recv_buffer, addr=addr)
  File "/usr/local/lib/python3.13/site-packages/pymodbus/transaction/transaction.py", line 183, in callback_data
    self.response_future.set_result(pdu)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^
asyncio.exceptions.InvalidStateError: invalid state

Daten trag ich in die Tabelle gern noch ein.

[TRON4R]

Ich bin mir nicht ganz sicher, ob man dem evcc-Logfile wirklich auf die Sekunde genau trauen kann... mir kommt es so vor, als ob die Einträge in einem Rutsch geschrieben werden, egal wie lange die Abfrage gedauert hat.

[CiNcH83]

Modbus ist in der Regel synchron, sprich du schickst eine Anfrage, wartest auf die Antwort und schickst dann die nächste Anfrage...

[TRON4R]

Ja, das ist die Abfrage. Aber weißt Du genau, wie der Teil funktioniert, der fürs Logging verantwortlich ist?
Bei evcc läuft super viel komplett asynchron, wieso sollte ausgerechnet der Logger jetzt perfekt synchronisiert sein?

Ich habe mir mal ein altes Logfile noch aus den -005er Dongle-Zeiten rausgekramt:

[site  ] DEBUG 2025/03/27 16:12:32 ----
[lp-1  ] DEBUG 2025/03/27 16:12:32 charge power: 1305W
[lp-4  ] DEBUG 2025/03/27 16:12:32 charge power: 0W
[lp-2  ] DEBUG 2025/03/27 16:12:32 charge power: 0W
[lp-3  ] DEBUG 2025/03/27 16:12:32 charge power: 0W
[lp-4  ] DEBUG 2025/03/27 16:12:33 charge currents: [0 0 0]A
[lp-2  ] DEBUG 2025/03/27 16:12:33 charge currents: [0 0 0]A
[lp-3  ] DEBUG 2025/03/27 16:12:33 charge currents: [0 0 0]A
[site  ] DEBUG 2025/03/27 16:12:33 grid power: -4928W
[site  ] DEBUG 2025/03/27 16:12:34 battery 1 power: -12W
[site  ] DEBUG 2025/03/27 16:12:35 pv 2 power: 1670W
[site  ] DEBUG 2025/03/27 16:12:38 pv 1 power: 5339W
[site  ] DEBUG 2025/03/27 16:12:42 pv power: 7009W
[site  ] DEBUG 2025/03/27 16:12:42 grid currents: [-7.88 -7.2 -6.88]A
[site  ] DEBUG 2025/03/27 16:12:43 battery 1 soc: 100%
[site  ] DEBUG 2025/03/27 16:12:44 site power: -4740W
[lp-4  ] DEBUG 2025/03/27 16:12:44 charge total import: 545.370kWh
[lp-4  ] DEBUG 2025/03/27 16:12:45 charger status: A
[lp-4  ] INFO 2025/03/27 16:12:45 car disconnected
[lp-4  ] DEBUG 2025/03/27 16:12:45 set battery boost: false
[lp-4  ] DEBUG 2025/03/27 16:12:45 set session soc limit: 0
[lp-4  ] DEBUG 2025/03/27 16:12:45 set session energy limit: 0
[site  ] DEBUG 2025/03/27 16:12:45 solar forecast: accumulated 0.191kWh, produced 0.230kWh, scale 1.204
[site  ] DEBUG 2025/03/27 16:13:07 ----

Wenn man sich das so anschaut, könnte man glatt den Eindruck bekommen, die Abfragen des SDongle wären in 11 Sekunden komplett durchgewesen (von 16:12:33 bis 16:12:44).
Komisch ist dabei nur, dass die Einträge im Logfile bunt gemischt sind.
grid power ist Teil der Abfrage evcc meter grid
battery 1 power ist klar Teil der Abfrage evcc meter battery
Dann kommen nacheinander pv2 und pv1 also evcc meter pv2 und evcc meter pv1 soweit so gut.
Aber dann kommt mit grid currents wieder ein Wert von der Abfrage evcc meter grid
Und danach nochmal mit _battery 1 soc" ein Wert von der Abfrage evcc meter battery

Ich glaube aber kaum, dass evcc so ineffizient ist und in einem Zyklus erst das grid abfragt und nur die Hälfte davon auswertet, dann die Batterie abfragt und nur die Hälfte auswertet, dann pv2 und pv1 abfragt, dann nochmal genau 3 Sekunden braucht, um den Wert aus pv2 und pv1 zu addieren, und dann nochmal das grid abfragt und die andere Hälfte auswertet und dann die Batterie ein zweites Mal abfragt und die andere Hälfte auswertet. Das wäre ja völliger Wahnsinn.

Deswegen meine Vermutung, dass die Zeiten im Logfile nicht auf die Sekunde genau stimmen, sondern der Logger asynchron zur Abfrage läuft und ich daher sehr vorsichtig damit wäre, zu meinen, man könnte aus den Sekundenunterschieden im Logfile die tatsächliche Abfragegeschwindigkeit des Dongle herauslesen.

[flautze]

Außerdem scheinst Du mit Deinem Dongle dann halt einfach Glück gehabt zu haben. Du hast bereits den schnellen HC32-Prozessor und insofern natürlich auch die Probleme von uns -005-Besitzern nie erlebt.

Wenn Du noch so nett könntest, Deine Daten in der Tabelle einzutragen, weil gerade bei Deinem Dongle mit einer ITEM-Nr. ohne -004 oder -005 am Ende eben alles drin sein kann. Du würdest unserer Datensammlung damit sehr helfen.

Hab jetzt mal meinen alten auseinander gebaut, und der hat tatsächlich nen HC32F4 drin. Livedata ging bei dem aber nie. Wenn ich das gestartet hab hatte ich timeouts in HA/EVCC.
HA lief auf jeden Fall immer mit 1 Minuten Intervall stabil, weiter runter war ich nicht. Die Tage dann noch EVCC mit 30 Sekunden dazu gehabt seit 2 Wochen. Bis auf die Nachtaussetzer und sporadische timeouts auch unproblematisch.

Vermutlich hätte ich meinen nicht tauschen müssen. Aber der neue scheint auf jeden Fall dennoch stabiler.

Dongle sind beide in der Liste drin.

[martin8310]

@TRON4R: Danke für den Ausführlichen Bericht ;-)

[TRON4R]

Gerne. Ich hoffe, er hilft möglichst vielen, die auch von dem langsamen Dongle so frustriert waren, wie ich.

[flautze]

@TRON4R mit welcher Software / App richtest du den Dongle ein?
Ich bekomm sowohl Sun2000 als auch Fusion immer die Meldung dass WLAN auf dem Gerät nicht verfügbar ist….

ich konnte zwar mein Passwort angeben/definieren beim Dongle aber anmelden kann ich mich nicht.

Probiert auf nem alten Android Tablet, sowie iPhone mkt Sun2000 oder Fusion App….

ModbusDaten kommen aber schon, IP habe ich auf derselben vom alten Dongle.

[TRON4R]

Ich benutze dazu die FusionSolar App von Huawei. Dort dann auf den Button Service in der untersten Reihe klicken und dann links oben Inbetriebnahme des Gerätes auswählen. Es gibt von Huawei dazu aber auch Schritt-für-Schritt-Anleitungen mit Screenshots etc.

[flautze]

Ja, quasi das mache ich auch, bzw ich geh auf wlan-Konfiguration… muss ich sonst mal den Inbetriebnahme Punkt testen….
Der Rest weiß ich auch wie es geht… konnte mittlerweile mit Sun2000app verbinden, aber da nur die angebotene v118 installieren…Datei teilen geht damit nicht…

[flautze]

Ok. Wlan Konfiguration ist das Problem. Mit Inbetriebnahme gehts.

[TRON4R]

Ja, früher habe ich auch immer den Punkt WLAN Konfiguration benutzt, weil ich bei Inbetriebnahme die Sorge hatte, dass man damit irgendeinen First-Time-Initialisierungsprozess auslösen würde Aber inzwischen gehe ich nur noch über Inbetriebnahme.

[flautze]

Jo. Mittlerweile hatte sich auf dem Dongle automatisch - oder vom Installateur getriggert - die SPC300 installiert. Nun konnte ich dann auch auf einmal die C025 SPC100 sehen und installieren.

[Mike-the-Brain1]

Hallo hier im Forum!

Bin zufällig auf diesen tollen Threat gestoßen und bin genauso gebeutelt mit der ModBus Abfrage wie viele hier!
Habe den Dongle ohne 004 oder 005 am System hängen mit der HC CPU und der 300er FW. Ich hatte bis zur FW 126 keine Probleme aber nach dem Update ging nix mehr.

Hab mir jetzt 2 Stück 004er besorgt (beide neu) und heute, genau nach der tollen Erklärung von TRON4R, versucht einzubinden.
Danke dir für die wirklich gute Aufschlüsselung und Erklärung, traumhaft!
Alles lief wie erklärt bis zum Punkt 9. Wenn ich die Ser Nummer eingebe und auf View klicke, erhalte ich folgende Fehlermeldung:
"Error The device of the SN cannot be found in the system"

Der Dongle ist via LAN Kabel an einer Fritzbox, er hat natürlich auch eine IP erhalten und ist per ping ansprechbar!
Ich habe beide Dongle ausprobiert, mit beiden das selbe Ergebnis.

Wenn ich mich mit den Dongle via Hdy verbinde komm ich rein und wenn ich bei Grundeinstellungen rein schau sehe ich das die Verbindung zum Router grün ist aber zum Managementsystem ins Internet rot.
Wenn ich mich verbinden möchte kommt eine Meldung ich sollte die Verbindung zum Router prüfen und kann nicht auf weiter klicken.
Aber die Router-Verbindung steht ja?

Wo könnte ich jetzt ansetzen?
Bitte um Hilfe und vielen Dank an alle!

[TRON4R]

Hmm... ich bin ehrlich gesagt etwas ratlos und kann jetzt nur drauflos spekulieren.

1. Bist Du sicher dass Du die richtige Seriennummer eingegeben hast (die steht hinter SN und sollte mit zwei Buchstaben wie z.B. TA anfangen
2. Hast Du gecheckt, dass im Feld für die Seriennummer nicht am Ende vielleicht ein Leerzeichen zuviel oder so drin steht? Bei schlecht programmierten Interfaces reicht das manchmal, um einen Match zu verhindern
3. Hast Du mal versucht, den Dongle Switch nicht im FusionSolar Webportal sondern in der App durchzuführen?
4. Hast Du mal probiert, direkt am Dongle ein Firmware-Update durchzuführen? Vielleicht löst das die Verbindungsprobleme zum Internet? (Welche Firmware ist aktuell drauf?)
5. Vielleicht blockt Dein Router die Kommunikation ins Internet aus irgendeinem Grund. Hast Du mal versucht, die IP vom neuen Dongle auf die IP des alten zu ändern? Oder geschaut, ob die Firewall von Deinem Router für die IP des neuen Dongle wirklich NAT-seitig alles zulässt?

[mikeharris2017]

[...]

Alles lief wie erklärt bis zum Punkt 9. Wenn ich die Ser Nummer eingebe und auf View klicke, erhalte ich folgende Fehlermeldung: "Error The device of the SN cannot be found in the system"
[...]
Wo könnte ich jetzt ansetzen? Bitte um Hilfe und vielen Dank an alle!

Moin @Mike-the-Brain1
ich bin vielleicht etwas spät dran, aber ich hatte diese Woche das gleiche Problem.
Ich hatte über das Menü "Inbetriebnahme" den Dongle mit dem WLAN verbunden und auch Daten über die FS App und das Portal bekommen.
Allerdings tauchten beide Dongle in der Geräteübersicht auf. Der alte als offline, der neue als online. beide hatten meine WR und den Akku bei sich. Geht man auf die Historischen Daten, sind beim Offline alle Daten bis zum Wechsel gespeichert. Im Online-WR die historischen Daten ab dem Wechsel.
Zusätzlich sind alle Daten in die FS Cloud geladen worden.
Zudem wird permanent ein Communication Error Fehler gemeldet, weil der alte Dongle ja offline ist.

Heißt: Du hast den neuen Dongle als eigenständige Anlage erstellt und unter der werden nun die Logs gesammelt.

Lösung:

1. Du muss den neuen Dongle in FS Portal löschen.
2. Dann kannst Du auf den offline Dongle gehen und "Replace Device" aufwählen.
3. Da der neue Dongle nun keiner Anlage zugeordnet ist, kannst Du nun die Seriennummer eingeben, über "view" suchen und bestätigen. 4) Danach ist der neue Dongle mit der bestehenden Anlage verbunden.

[Mike-the-Brain1]

Guten morgen!
Punkt 1 uns 2 kann ich ausschließen die hab ich mehrmals eingegeben und 10x auf Richtigkeit geprüft (beginnt einmal mit TA und einmal mit HV)
Punkt 3,4 und 5 mach ich heute noch und melde mich, danke und LG

[TRON4R]

Gerne. Es würde übrigens die Übersichtlichkeit erhöhen, wenn Du solche Antworten direkt unter meine Antwort schreiben könntest, statt einen neuen sub-thread zu eröffnen. Ich weiß, Github macht es einem da nicht immer ganz leicht, den richtigen Punkt zu erwischen.
Aber Du könntest Deine Text hier immer noch mit Copy&Paste ja auf die richtige Ebene kopieren und den Post hier löschen.

[Mike-the-Brain1]

So, hab es endlich geschafft den Dongle zu integrieren 👍
Der Fehler war das ich anscheinend zu ungeduldig gewesen bin. Die Anleitung von dir passt zu 100% aber genau so lange wie der alte Dongle braucht um aus dem System zu verschwinden, genauso lange dauerte es bei mir das er vom System anerkannt wurde. Der Zufall brachte mich dorthin. Ich habe alles angesteckt gelassen und musste für eine Stunde jemanden was helfen, als ich zurück kam blinkte der neue Dongle nicht mehr sondern leuchtete dauerhaft grün. Ich dachte mir probiere es jetzt nochmal und auf anhieb akzeptierte das System die neue SerNr SUPER!!

Leider ist das Ursprüngliche Problem aber noch nicht behoben, er hatte die Uralte FW V200R22C10SPC110 drauf und ich habe erstmal die wissentlich funktionierende FW126 raufgepackt. Leider noch immer gleich, der HomeAssistant fragt alle 30sec ab und ich habe ständig Aussetzer... Wo ich nur einen WR hatte lief alles problemlos, erst mit der Kaskadierung fingen die Probleme an. Kann das sein weil es mittlerweile fast 550 Entitäten in der PV Anlage sind das ich nicht mehr so schnell alles abrufen darf?

Noch ne Idee?
Lieben Gruß

[TRON4R]

Mit dem neuen -004-Dongle solltest Du auf eine aktuelle Firmware SPC300 oder die ganz neue R025 gehen.
Es gibt keinen Grund auf der alten SPC126 sitzen zu bleiben. Ich habe gerade die genaue Firmware-Nummer nicht mehr im Kopf, aber Huawei hat ab einer Firmware dann für den HS32-Prozessor den Encryption-Chip aktiviert und damit erst den Geschwindigkeitsvorteil gegenüber den Dongles mit STM32-Chip möglich gemacht.

[Mike-the-Brain1]

Hab die Updateintervalle vom HA jetzt auf 60 sec gesetzt und habe seit 10min noch keinen Aussetzer, sieht erstmal vielversprechend aus...
Werde es über die Nacht mal laufen lassen und wieder berichten...

LG

[Mike-the-Brain1]

Danke Tron4r für die Antwort!
Ok verstehe ... Das klingt plausiebel. Gesagt getan oder besser versucht zu tun.

Habe mir die neueste FW von Photomate gezogen kann sie aber leider nicht raufladen da sie anscheinend die 300er zuvor verlangt.
Ich kann die 300er jedoch nirgend mehr wo finden und würde sie dringend benötigen. Ich hab schon im Photovoltaikforum darum gebeten, vielleicht ist hier auch jemand so nett und stellt sie mir zur Verfügung, wär toll!
Danke sehr und lieben Gruß

[Mike-the-Brain1]

So, ich habe meinen Leidensweg auch schon im PV Forum heute gepostet, wen meine Probleme interessieren hier die Zusammenfassung:

Seit ich mich mit der ModBus Geschichte rumspiele kommt mir vor es geht von Tag zu Tag und von Setup zu Setup schlechter;(

Alle Probleme kamen mit der Kaskadierung eines weiteren WR, seit dem Tag an war die Home Assistant Integration unbrauchbar. Zuvor lief das ganze fast ein Jahr Aalglatt und ich hatte wunderschöne Anzeigen im HA ohne Aussetzer.

Meine Hoffnung lag jetzt wirklich am -004 Dongle und an der neuen FW aber auch mit dieser will es "noch" nicht besser werden...

An ein Netzwerkproblem kann ich fast nicht glauben, der Dongle hängt direkt mit LAN Kabel fix an einer Fritzbox. Ich kann ihn auch problemlos ansprechen, Im Netzwerk hängen noch ca 60 Netzwerkteilnehmer dran und die FB ist damit nur 30-40% ausgelastet.

Die ModBus TCP Kommunikation ist natürlich am Dongle auf uneingeschränkt gestellt, die Dongle IP Adresse ist fix vergeben und ändert sich nicht, die ID der Wechselrichter sind bekannt und richtig in der Huawei Integration konfiguriert. Alle Entitäten der Anlage werden gefunden ich sehe beide Wechselrichter, alle Batterien, den Stromzähler, alle Optimierer usw... Wenn ich da in der Kofig was falsch machen würde könnte ich die ganzen Baugruppen doch nicht sehen, oder?

Aber jetzt kommt´s : die Daten sind halt nur von Zeit zu Zeit mal da, ich weiß, das könnte jetzt ein Timing Problem sein, klar, ich habe mir aber schon in der const.py Datei der Huawei Integration die Finger wund getippt und alle möglichen Update Zeiten und Timeouts in verschiedensten Varianten ausprobiert...

Ich hab den HA heute schon zurückgesetzt auf einen mir bekannt guten Konfigurationsstand und selbst der geht kaum mehr...

Ich hab anscheinend wirklich noch ein anderes grundlegendes Problem

Wenn jemand noch einen Tipp für mich parat hat bitte gerne posten, ich werde nicht aufgeben und mich weiter schlau machen warum das bei mir um die Burg nicht laufen will.

Ihr hört von mir und wenn es läuft natürlich auch die Lösung!

Liebe Grüße

Ach ja Dongle FW ist mittlerweile die 300er und WR 172

[Mike-the-Brain1]

[CarG70]

Du kannst Dir einfach über das Huawei Uniportal eine ID anlegen und die Software dort selber herunterladen.

[flautze]

Ich hatte die im Portal angebotene 118 installiert. Über Nacht hatte sich anscheinend automatisch die 300er installiert, so dass danach die 025er auch zu installieren ging.

[detlefheese]

So liebe Dongle-Gemeinde,

BÄMMMM 😀

Nun habe ich auch Echtzeitdaten und das Teilchen antwortet wie Bolle.

Was ist Eure "beste evcc-Regelzeit"?

Ich weiß immer gar nicht, wie hoch meine Wertschätzung für ein solches Forum ist. Dass es "Freaks" gibt, die sich nicht mit dem Status Quo zufrieden geben und was rausfinden. @TRON4R ... Lieber Olaf, ganz lieben Dank für Deine tolle ausführliche Anleitung, die in mir die Hoffnung befördert hat, durch einen Dongle-Wechsel quai eine neue Anlage zu haben. Danke, danke, danke!!!

Ich hab schon wieder Ausbaugedanken + 5,5 kWP damit noch mehr für die Wärmepumpe, die nächstes Jahr im Mai kommt, genutzt werden kann. Dass wir mit Cupra und Tesla (zusammen ~ 60000km im Jahr) so gut rumkommen, hätte ich nie gedacht. (22,18€ monatliche Energiekosten als Durchschnitt im Jahr).

Ich hab meinen Frieden mit Huawei und hoffe, dass meine Abbrüche im kaskadierenden 2 WR-System auch weniger werden.

[TRON4R]

Freut mich, dass es bei Dir auch so gut geklappt hat. Genau das war die Motivation für mich, in dieser Solution hier auf GitHub alles zusammenzufassen, was viele Leute darunter u.a. @CiNcH83 im Huawai-Thread des Photovoltaik-Forums zusammengetragen haben. Insofern vielen Dank für Dein nettes Feedback!

Ich hätte noch vor einigen Monaten selbst nicht geglaubt, dass man für nur 50 EUR so einfach eine Verbesserung herbeiführen könnte, die sich fast wie eine neue Anlage anfühlt. Ein Wechsel zu Smartlogger oder EMMA hat mich irgendwie nie wirklich überzeugt.

Aber jetzt gibt es Echtzeitdaten, SoC-Anzeige und finally ein evcc Abfrage-Intervall von 30 Sekunden und weniger ohne jegliche Timeouts und das alles ohne Risiko für einen Datenverlust.

So macht die Huawei-Anlage endlich wirklich rundherum Spaß.

[LotharWoman]

Falls mal jemand im PLZ Bereich 08 so einen -004 kurz zu verleihen hat würde ich mich echt freuen.
Die Aussagen zum HC32 Dongle sind ja sehr gemischt und ich würde gern mal HC32alt vs HC32neu(-004) direkt vergleichen.

[TRON4R]

Selbst wenn Du jemanden finden solltest, der dazu bereit ist und nur 30 Minuten weg wohnt, wäre das eine Stunde Fahrerei um am Ende 50 EUR zu sparen.

Oder auch nicht, wenn der -004 Dongle tatsächlich besser laufen sollte und Du ihn dann sowieso kaufen musst.

Da würde ich lieber blind den -004 Dongle kaufen und dann nach dem Test einen der beiden Dongle bei eBay verkaufen.

Ich wäre aber auch überrascht, wenn jemand bereit wäre, seine Anlage einen Tag ohne Dongle laufen zu lassen.

[LotharWoman]

Hat sich nach den neuesten Posts eh erledigt. Zusammenfassend kann mal wohl sagen, positiv überrascht werden nur Leute mit STM Prozessor und recht einfacher Konstellation. Sobald Kaskade ins Spiel kommt und HuaweiSolar entspricht der -004 auch nur dem alten HC32.
Wer also in FusionSolar schon den Echtzeit-Button sieht, kann sich die Euros sparen und sollte tunlichst die die neue R25...SPC100 meiden.

[CiNcH83]

Nach Sammlung und Analyse der Daten von verschiedenen Usern (LINK) komme ich zum selben Schluss.

Nach den ganzen Performanceproblemen mit Kaskade hat Huawei in aktuellen FW Versionen die Regelung wohl aufgebohrt, scheinbar zu Lasten von Modbus Clients, die größere Registerbereiche abfragen. Ihr könnt euch jetzt nur zusammen tun und euch an den Huawei Support wenden. Je mehr sich melden, desto mehr Bewegung dürfte in die Sache kommen.

[TRON4R]

Das stinmt vermutlich, Wenn Du jetzt schon den Echtzeit-Button siehst, dann wird ein Wechsel auf den -004 Dongle nicht mehr viel bringen. Denn dann hast Du im Zweifel ja schon die volle Performance. Meine Lösung richtet sich daher primär auch an Leute, die eben genau diese Dinge (Echtzeit, SoC, schnelle Modbus-Abfrage) vermissen.

Eine Kaskade aus 2 Wechselrichtern und einer LUNA2000 habe ich allerdings auch.

[Mike-the-Brain1]

So liebe Leidensgenossen, endlich kann ich positives vermelden!

Meine ModBus Abfragen kommen nun wieder, seit fast einer Woche Beobachtungszeitraum, pünktlich und ohne Aussetzer an!

Wie habe ich das Problem lösen können:
Nachdem ich leider keine Verbesserung mit einem neuen 004er Dongle hatte (zuvor hatte ich einen ohne Zusatzbezeichnung jedoch mit dem HC32 Chip), und egal mit welcher FW, nicht mit der 126 oder der 300 oder der neuen 100er, verbrachte ich 3 Nächte im Bastelkeller und analysierte das Problem von der Pike auf...

Long story short: Mein Problem lag wirklich nur an der Überforderung des Dongles mit meinen mittlerweile zu vielen Entitäten (knapp 600 im Huawei System) und zu häufigen Abfragen und auch noch mehreren Endgeräten die ich überall installieren wollte. Ich habe im Home Assistent einen ModBus Proxy eingerichtet und dachte das wäre nun das einzige Gerät das auf den Dongle zugreift und ich könnte bedenkenlos mehrere Clients (meine alten Android Geräte mit PVvis) hinzufügen, denn die würden ja nur den ModBus Proxy beschäftigen und nicht den Dongle. Das stimmt aber nicht, der Proxy routet nur alle Anfragen der Clients zum Dongle, (bessert mich aus wenn ich mich falsch ausdrücke) die ständigen Anfragen aller Endgeräte führen dann unweigerlich zu Timeouts, sogar bis zum kompletten Zusammenbruch der Kommunikation via MB! Erkennen konnte ich dies sehr schön im Protokoll vom ModBus Proxy im HA, ab dieser Erkenntnis ging es schnell voran!

Die Lösung in meinem Fall war folgende: Ich habe alle Entitäten die ich nicht benötige im HA deaktiviert. Es blieben knapp 60 übrig die mich interessierten. Dann auf allen Android Geräten die HA App installiert und die PVvis App entfernt. Im HA ein schönes, Android freundliches Dashboard eingerichtet mit allen Anzeigen die mich interessieren und nun ruft nur noch der HA alleine alle 30 sec den Dongle ab was wunderbar und ohne Aussetzer klappt! Die Android Geräte dienen jetzt als abgesetzte HA Displays.

Seit fast einer Woche alles top!

Da ich über die Fritzbox einen VPN mit WireGuard eingerichtet habe kann ich problemlos auch von unterwegs mit der HA App alle meine Werte auslesen, besser als je zuvor sogar!

Ich hoffe wenn es einen weiteren Leidensgenossen wie mich gibt, dass mein Lösungsansatz vielleicht behilflich sein kann.

Seid alle gegrüßt von mir und gutes Gelingen!

[CiNcH83]

Ja, der Proxy leitet nur durch, sodass der Dongle glaubt, alles käme vom selben Client bzw. derselben IP.

[TRON4R]

Gilt das für den HA Proxy oder auch für den evcc Proxy?

[CiNcH83]

Beide.

[j1gg3]

Ich habe ein Ticket bei Huawei aufgegeben und nach einem neuen Dongle gefragt, zwei Tage später ging die 004er Version in den Versand.

[HansPeterMeier]

Na toll, eigentlich komme ich von der cfos Welt und dem iobroker mit dem huawei Adapter, der als Modbus Proxy dient. Mein Dongle, der ist wohl schon 6 Jahre alt, hat eigentlich immer genervt mit Modbus. mit der V100R001C00SPC133 ging es dann einigermaßen und ein Update habe ich seitdem auch nicht mehr gemacht.
Da es bei Cfos aber keine Wallboxen mehr gibt und mich die Software nervt, wollte ich jetzt wieder zu EVCC zurück.
Um später für verwandte usw. das ebenfalls zu testen, da eAutos immer mehr werden, brauch ich auch ne neue Wallbox, billig sollte Sie sein, die logik kommt ja aus EVCC. Die EM2GO scheint mit der aktuellen Software die günstigste zu sein.

Naja, ich habe zunächst mal ein Ticket bei Huawei aufgemacht, bin gespannt ob ich einen neuen Dongle bekomme, damit mein System zu Hause mal auf den aktuellen Stand bekomme.

Gruß und Danke für den Thread hier.

[HansPeterMeier]

Also, per Ticket konnte ich nichts erreichen, die wollten nichts machen, weil der Dongle außerhalb der Garantie ist. Und die sind richtig hartnäckig und wollen kein Support leisten.
Wie alt waren denn eure Dongles?

[TRON4R]

Ich hatte wegen 50 € keine Lust auf einen Tanz mit dem Support, daher habe ich mir einfach einen SDongle bestellt. Einigen hatten Glück und haben ohne Diskussionen einen neuen SDongle bekommen, andere wurden auch abgelehnt.
Ich würde an Deiner Stelle einfach einen zweiten Anlauf bei denen versuchen und wenn der auch abgelehnt wird, dann kann man sich die Frage stellen, wieviel einem die eigene Lebenszeit wert ist und ob man sich das Teil nicht einfach über einen der Bestelllinks oben bestellt.

[HansPeterMeier]

ja, das habe ich mir auch gedacht. Habe jetzt einen bei Kleinanzeigen besorgt. Er hat noch einige davon anscheinend und gibt sein Geschäft auf. Mal schauen wann der ankommt.
Danach kann ich mich dann wieder mit evcc beschäftigen. Ich muss noch mal irgendwie gucken, dass ich die Cfos nur noch dumm laufen lasse oder mit eine neue billige wallbox besorgen ala em2go home, aber ich brauche noch einen MID Zähler für die Abrechnung. Mal gucken ob EVCC einen Mid Zähler kann, der zusätzlich in der UV steckt, aber dann müsste der wieder Modbus TCP können.
Modbus RTU direkt an die Wallbox und dann weiter zu EVCC wäre sicherlich einfacher.

[FlaTEriC1983]

ich war tatsächlich noch im Gewährleistungszeitraum, vielleicht war es daher für die OK mit dem Tausch...

[december-soul]

Ich habe eine Frage.
Ich habe ein ähnliches Problem, aber ich weiß nicht, ob es das gleiche ist.

Ich habe den gleichen WR, die gleiche Batterie, den gleichen DTSU666 und den gleichen Dongel.
Der Dongle hat keine Versionserweiterung.

Zwei Jahre lang lief bei mir alles bestens.
Seit ein paar Monaten meldet die Anlage jedoch immer öfter, dass der Stromzähler einen Fehler hat. Gelegentlich auch, dass der Akku abnormal ist.
Wenn ich dann alles stromlos mache und neu starte, läuft wieder alles. Der Fehler tritt nach Stunden oder Tagen wieder auf.

Ich habe jetzt EVCC mal ausgeschaltet. Mal sehen, ob es an zu vielen Anfragen liegt.
Die Kabel habe ich überprüft. Es lief ja auch lange sehr gut.

Kann es das gleiche Problem sein, wie hier beschrieben?

[CiNcH83]

Sie hängen halt beide am 2. RS485 Port vom Wechselrichter. Wie das dann genau verkabelt ist, obliegt dem Installateur, sprich ob der den Zähler zusammen mit dem SUN2000 an den Port der LUNA2000 oder direkt an den 2. Port vom SUN2000 hängt, oder ob er irgendwo dazwischen abzweigt... mit RS485 alles möglich. Dass gerade die beiden Probleme machen, zeigt schon, dass da bei der Verkabelung in dem Strang etwas unsauber ist.

[mikeharris2017]

Ich kann leider nicht erkennen welchen WR ihr habt. Ich hab den Sun2000-10KTL-M1.

Hier das Bild wie meine Verkabelung erfolgt ist. Das ist sehr fummelig.

Aus: https://support.huawei.com/enterprise/de/doc/EDOC1100173913/f4c05d41

[CiNcH83]

Mein Installateur hat den Zähler deshalb wohl an der LUNA angeklemmt...

Ich hab an dem Stecker allerdings auch schon zweimal Kabel nachgerüstet. Ging eigentlich ganz gut...

[december-soul]

Ja, das mit dem Kabel ist wirklich nicht optimal gelöst. Normale Aderendhülsen sollte man da nicht verwenden, da sie zu kurz sind, um im Stecker Kontakt zu haben. Ich habe den LUNA jetzt erst einmal abgeklemmt und nur den DTSU666-H im System.
Leider wird der DTSU-666H jetzt nicht mehr erkannt. Auch nach dem Wechsel des Kabels.
Im Photovoltaikforum gibt es dazu einen langen Thread. Da spielen wohl ein paar Versionen und Komponenten nicht gut zusammen.

[TRON4R]

Im Zweifel mal alles auf einen konsistenten Versionsstand updaten und dann mal weiterschauen.

[thbed88]

Würde mit der "neuen" Version auch die Möglichkeit bestehen das man mehr als 2 Modbus Teilnehmer bzw abfragen macht. Habe das Problem wenn ich beide wallboxen anhabe knickt mir die Verbindung zu meinem Loxone miniserver ein.

[TRON4R]

Das kann ich Dir leider nicht mit Sicherheit sagen, weil ich bisher von niemandem gelesen habe, dass er sich von Huawei zwei Wallboxen gekauft hätte. Der -004-SDongle läuft grundsätzlich deutlich schneller, weil ab der -200 Firmware die ganze Verschlüsselungsarbeit von dem AES-Zusatzchip übernommen wird, was die Haupt-CPU massiv zu entlasten scheint.

Am Ende hilft wohl nur ausprobieren. Eine Alternative sehe ich nicht, es sei denn, Du willst auf die EMMA wechseln.

Ruf doch die Hotline an und leier denen einen -004 aus den Rippen. Das haben viele schon erfolgreich hinbekommen und wenn Du als treuer Huawei-Kunde sogar die Wallboxen von denen gekauft hast und das jetzt nicht sauber funktioniert, hast Du ja nun wirklich mehr als genug Gründe für Huawei, Dir einen ordentlichen SDongle zuzuschicken.

[thbed88]

Das heisst ich brauche den -0004 mit dem würde das besser funktionieren? LG Olaf ***@***.***> schrieb am Fr., 1. Mai 2026, 11:23:

…

Das kann ich Dir leider nicht mit Sicherheit sagen, weil ich bisher von niemandem gelesen habe, dass er sich von Huawei zwei Wallboxen gekauft hätte. Der -004-SDongle läuft grundsätzlich deutlich schneller, weil ab der -200 Firmware die ganze Verschlüsselungsarbeit von dem AES-Zusatzchip übernommen wird, was die Haupt-CPU massiv zu entlasten scheint. Am Ende hilft wohl nur ausprobieren. Eine Alternative sehe ich nicht, es sei denn, Du willst auf die EMMA wechseln. Ruf doch die Hotline an und leier denen einen -004 aus den Rippen. Das haben viele schon erfolgreich hinbekommen und wenn Du als treuer Huawei-Kunde sogar die Wallboxen von denen gekauft hast und das jetzt nicht sauber funktioniert, hast Du ja nun wirklich mehr als genug Gründe für Huawei, Dir einen ordentlichen SDongle zuzuschicken. — Reply to this email directly, view it on GitHub <#22534 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BU5UXVNNRNMD2UAOCESLNJ34YRUJLAVCNFSM6AAAAACCM4P5MSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNZXHA2TAOA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[TRON4R]

Ah super. Das ist in der Tat gut zu wissen, dass der SDongle nur für max. 1 Wallbox ausgelegt ist und alles darüber eine EMMA benötigt.

Bist Du eigentlich zufrieden mit der Huawei-Wallbox? Ohne evcc soll das Überschuss-Laden damit ja wohl nur relativ bescheiden funktioniert.

[CiNcH83]

Wo gibt es diese Spezifikation? Das glit halt, wenn du innerhalb des Huawei Ökosystem bleibst..

[thbed88]

Den Screenshot hat mir Huawei zugesandt kann ich leider nicht sagen aber ich kann nochmal nachhaken wenn es für dich wichtig ist ? LG

[CiNcH83]

Danke. Musst du nicht. Aber damit halt jeder weiß, dass dieses Limit nur gilt, wenn man komplett auf das Huawei Ökosystem setzt. Wenn man den Dongle mit evcc betreibt, kann man auch 10 Wallboxen steuern, aber dann bitte keinen Huawei SCharger.

[TRON4R]

Ja, das stimmt natürlich. Mit evcc und Wallboxen von einem anderen gut mit evcc zusammenarbeitenden Hersteller gibt es kein derartiges Limit. Diese Beschränkung auf genau eine Wallbox gilt natürlich nur, wenn man alle von Huawei direkt steuern lässt (Was angeblich laut diverser Foreneinträge auch nicht so richtig rund laufen soll).
Danke für die Klarstellung @CiNcH83.

[Django-05]

Auch von mir ein erst einmal ein Dankeschön für Deine klasse Anleitung!
Ich habe ohne Installateurrechte den alten SDongle mit WLAN Verbindung gegen einen Neuen ausgetauscht, allerdings mit LAN-Kabel. Hat auch alles soweit funktioniert.
Nur blinkt die grüne LED dauerhaft und im Router ist der Dongle nicht zu finden. Kann es sein, dass ich irgendwo noch WLAN auf LAN sowie DHCP anpassen muss? Geht das überhaupt ohne einen Installateur Account?

[TRON4R]

Ohne Installateur-Account ist schwierig. Aber hol Dir den doch lokal am Dongle direkt. Und ja, wenn der alte per WLAN angeschlossen war, kann es sein, dass der neue das jetzt auch erstmal versucht. Das die LED anders leuchtet/blinkt als vorher heißt erstmal nichts. Der Dongle verhält sich diesbezüglich generell anders als der alte.

[Django-05]

Ich habe das Netzwerkkabel für 10 Minuten ausgesteckt und dann wieder verbunden - jetzt funktioniert es auf einmal (LED blinkt nicht mehr, ist jedoch im Router noch immer nicht sichtbar). Vielleicht dauert es damit ja auch länger…:)
Das mit dem zusätzlichen lokalen Installateur-Account muss ich noch recherchieren.
Danke für die schnelle Rückmeldung!

[SchneHa]

Welche Firmware habt ihr auf dem 004-Dongle, SPC300? Es gibt ja mittlerweile auch die SPC320, sollte man diese installieren?

[SchneHa]

Das ist schon klar, hatte ich gesehen. Aber wie kann ich von SPC300 auf SPC320 updaten?

[SchneHa]

Keiner eine Idee, wie ich auf SPC320 komme? Angeboten wird mir über das Webinterface nur noch der R025-Pfad. Vielleicht geht es ja, wenn man das über die FusionSolar app macht, aber dabei bräuchte ich auch Hilfestellung. Scheinbar geht das downloaden über einen PC aber in welches Verzeichnis auf dem Smartphone muss die dann rein und wie?

[TRON4R]

Warum willst Du unbedingt auf die SPC320? Vor allem, wenn Huawei Dir den R025-Pfad aktiv anbietet?

Und ja, Du kannst es lokal per FusionSolar-App direkt am Dongle versuchen. Ob es klappt, kann Dir keiner vorhersagen. Die Chancen sind vorhanden, aber eine Garantie gibt es nicht. Und zum "wie mache ich das?":
Dazu gibt es von Huawei detaillierte Schritt für Schritt Anleitungen. Einfach mal googlen oder auf den Huawei-Seiten suchen. Oder frag irgendeine halbwegs gescheite KI, wie z.B. Gemini 3, ChatGPT 5.5 oder Claude Sonnet 4.6 oder Opus 4.7. Die erklären es Dir auch so haarklein detailliert wie Du es brauchst.

Und ja, das Verzeichnis auf Deinem Handy ist egal, solange Du Dir am Ende merkst, wo Du die Datei heruntergeladen hast und dann in der FusionSolar-App wieder genau das Verzeichnis bzw. die darin liegende Firmware-Datei auswählst. Aber warum sich das Leben schwer machen? Leg die Firmware-Datei in Android einfach in den Folder "Downloads" oder "Documents" und gut ist's.

[SchneHa]

Warum willst Du unbedingt auf die SPC320? Vor allem, wenn Huawei Dir den R025-Pfad aktiv anbietet?

Weil ich vom R025-Pfad nicht zurück kann. Das Dongle läuft mit SPC300 noch nicht zufriedenstellend, auch nicht mit 19200 Baud.
Deshalb wollte ich erst der SPC320 eine Chance geben.

Und ja, Du kannst es lokal per FusionSolar-App direkt am Dongle versuchen. Ob es klappt, kann Dir keiner vorhersagen. Die Chancen sind vorhanden, aber eine Garantie gibt es nicht. Und zum "wie mache ich das?": Dazu gibt es von Huawei detaillierte Schritt für Schritt Anleitungen. Einfach mal googlen oder auf den Huawei-Seiten suchen. Oder frag irgendeine halbwegs gescheite KI, wie z.B. Gemini 3, ChatGPT 5.5 oder Claude Sonnet 4.6 oder Opus 4.7. Die erklären es Dir auch so haarklein detailliert wie Du es brauchst.

Leider nicht! Wie es theoretisch geht, weiß ich, es hapert an der praktischen Umsetzung.

Und ja, das Verzeichnis auf Deinem Handy ist egal, solange Du Dir am Ende merkst, wo Du die Datei heruntergeladen hast und dann in der FusionSolar-App wieder genau das Verzeichnis bzw. die darin liegende Firmware-Datei auswählst. Aber warum sich das Leben schwer machen? Leg die Firmware-Datei in Android einfach in den Folder "Downloads" oder "Documents" und gut ist's.

Leider auch das nicht, ich habe keinen Zugriff auf ein Android sondern auf Apple Geräte. Und auf diesen legt FusionSolar kein Verzeichnis an, in das ich das rein kopieren könnte.

[TRON4R]

Wenn solche Infos von Dir hier nur tröpfchenweise kommen, ist es schwierig, Dir gezielt Infos geben zu können.
Das von Dir beschriebene Verhalten von Apple iPhones ist übrigens genau einer der Gründe, warum ich kein iPhone habe. Da kauft man sich für über 1.000 EUR einen Computer und dann versteckt das UI regelrecht das Dateisystem vor den Nutzern. Für IT-Uninteressierte mag das genau richtig sein, für alle anderen ist es blanker Irrsinn.

Insofern kann ich aber leider auch nicht weiterhelfen, da ich genau 0 Erfahrung mit iPhone und Huawei habe. Du könntest Dir aber vielleicht von jemandem ein Android-Phone leihen und es dann damit mal versuchen. Damit klappen Updates direkt am Gerät (Dongle oder Wechselrichter) nach meiner Erfahrung eigentlich recht gut.

[patrickfischerv]

Ich weiß, ich weiche etwas vom Thema ab aber hier sind viele schlaue Leute die mir vielleicht helfen können.
Mein WR erkennt den DTSU666-H ja leider überhaupt nicht mehr. Ich bin kurz davon mir einen neuen zu besellen.

Ich bekomme es einfach nicht hin, daher fasse ich nun alles zusammen.

Die Anlage lief 1,5 Jahre ohne Probleme.

Dann ist der Stromzähler immer häufiger ausgefallen und ließ sich durch einen Neustart des WR wieder reaktivieren.

Die Ausfälle wurden immer häufiger.

Nachdem ich die Kabel ausgetauscht hatte, wurde der Stromzähler überhaupt nicht mehr erkannt.

Ich habe anschließend die Software aktualisiert (ich hoffe, das war kein Fehler).

Hier ein paar Daten:
Gerätemodell: SUN2000-8KTL-M1
Software: V100R001C00SPC165

MBUS: V100R001C00SPC344.

Gerätemodell SDongleA-05, Software V200R025C00SPC130.

LUNA2000-5KW-C0 ist aktuell nicht angeschlossen. Ausgeschaltet und RS45 sind nicht angeschlossen.

Stromzähler: DTSU666-H

Ich habe jetzt die Spannung zwischen Pin 7 & 9 gemessen. Sind ca 0,5V. Das soll bedeutet das der WR eigentlich am suchen ist.

Ich habe die RS45-Leitungen mehrmals auf Richtigkeit überprüft.

Dabei habe ich auch die Verbindungen 7&9 probiert.

Die Stecker habe ich durchgemessen. An zu kurzen Kabelenden oder Aderendhülsen kann es nicht liegen.
Den WR für 10 Minuten stromlos zu machen, habe ich auch schon mehrmals versucht.

Installateur-Account habe ich.

[TRON4R]

Sorry, aber das klingt in der Tat nach einem möglichen Defekt. Ich würde mal den Support von Huawei kontaktieren. Vielleicht können die den Fehler besser eingrenzen über ihre Diagnostic oder schicken die Dir auf Garantie einen neuen DTSU666-H zu...

[december-soul]

Ich hatte mir einen neuen DTSU666-H bestellt.
Gestern Abend eingebaut.
Läuft!

War, bei mir, also wirklich ein HW defekt.

[TRON4R]

Klang alles danach. Danke für Dein Feedback. Immer gut, wenn eine Geschichte auch einen klaren Abschluss findet. Das hilft den Lesern nach uns und den KIs beim Recherchieren wegen Problemen.

[thbed88]

Die Schwiegereltern habe das aktuell so und klagen nicht, haben aber auch eine EMMA (wobei nur eine Wallbox) aber vielleicht liegt es daran das es besser passt, da man so den Akku auch sperren kann ging ja mit dem Dongle nicht, da wusste ich aber von EVCC noch nichts - aber ich denke der einfachheit halber werden wir dort auch mal HA Green mit EVCC einbauen glaube das ist wesentlich Benutzerfreundlicher. Ich habe es zu Hause jetzt mit EVCC, 2 Huawei Scharger, 2 Tesla am laufen inkl ESP´s da mir das mit myteslamate und der api von Tesla selbst zu blöd war und ich irgendwie immer über die 10€ nach ein paar tagen kam. Alles in allem bin ich mit den Wallboxen aber zufrieden finde ich auch optisch schön und machen was sie sollen - sind auch nicht so teuer man kommt mit dem Kabel überall schön rein wo man möchte ist ja auch nicht so bei jedem Hersteller, und da wir eben Huawei als WR sowie Batterie haben war es naheliegend die zu nehmen - sofern mal irgendwas abschmiert kann ich dennoch so laden. Am Do., 14. Mai 2026 um 16:06 Uhr schrieb Olaf ***@***.***>:

…

Ah super. Das ist in der Tat gut zu wissen, dass der SDongle nur für max. 1 Wallbox ausgelegt ist und alles darüber eine EMMA benötigt. Bist Du eigentlich zufrieden mit der Huawei-Wallbox? Ohne evcc soll das Überschuss-Laden damit ja wohl nur relativ bescheiden funktioniert. — Reply to this email directly, view it on GitHub <#22534 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BU5UXVO4CRALXYDCEDCTJFT42XHGFAVCNFSM6AAAAACCM4P5MSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMOJRHE3DONA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[zr2002]

@TRON4R : VIELEN DANK für die tolle Anleitung. Nachdem ich ein Ticket bei Huawei geöffnet und etwas mit denen kommuniziert habe, habe ich einen neuen Stick (02312QMV-004) erhalten und konnte diesen problemlos (anhand Deiner Anleitung) austauschen. Bislang keine Aussetzer, aber OK er läuft erst eine Stunde :)

[TRON4R]

Gerne. Freut mich, dass es bei Dir auch so gut geklappt hat. Auch wenn die Stichprobe noch recht klein ist, aber die Zahl der Fälle, wo der Huawei-Support den Dongle kostenlos ausgetauscht hat, scheint doch deutlich größer zu sein als die Zahl der Fälle, wo diese Bitte abgelehnt wurde. Jetzt bedaure ich es ja fast schon, dass ich damals direkt den Dongle gekauft habe. Aber meine Erfahrungen mit Hotlines im Allgemeinen sind inzwischen unterm Strich so unschön, dass ich keinen Bock mehr auf Diskussionen mit Leuten habe, die oft nicht mal mehr eine E-Mail richtig lesen und man dann nach 1 Woche Wartezeit mit einer unpassenden Template-Antwort abgefertigt wird und wieder von vorne anfangen muss.

[Jfreund10]

Hallo Olaf,
Vielen Dank für Ihre sehr ausführliche Beschreibung. Ich habe nun von Huawei auch einen neuen SDongleA-5 mit 02312QMV-004 bekommen. In Ihrer Anleitung bis zum Schritt 12 sind alles dargestellt. Können Sie vielleicht den Schritt 13 etwas ausführlicher beschreiben (am besten SchrittfürSchritt)? Ich habe nur User Recht. kein Installateur Recht. Vielen Dank!!

13. Im Dongle sollte man jetzt noch die Erstinstallation (Grundeinstellungen) aufrufen und durchgehen. Dazu am besten in der FusionSolar App sich über den Punkt "Inbetriebnahme" direkt am WiFi des neuen Dongle anmelden (das geht nur noch mittels QR-Code Scan, dass frühere Passwort Changeme ist Geschichte.

[Weafdinstel]

Punkt 13. kannst du meiner Meinung nach weglassen. Ich wechsle öfter mal zwischen zwei Dongle und die Anlagendaten/Einstellungen ändern sich durch den Wechsel nicht.

[Jfreund10]

Hallo, vielen Dank für eure Rückmeldungen!
Das Problem war ständige LAN und WLAN Abbrüche mit dem alten doogle. Huawei support hat nach log files Untersuchung festgestellt, der Sdongle sei defekt. Dank Olaf's Hinweis habe ich nun von Huawei den 02312QMV-004 dongle erhalten und wollte gegen den defekten (z.Z. noch eingesteckt, offline) austauschen. Bis auf Schritt 13 habe ich alles verstanden. Deshalb war meine Frage zu pkt 13, bevor ich mit dem Austausch beginne.

[TRON4R]

Punkt 13. kannst du meiner Meinung nach weglassen. Ich wechsle öfter mal zwischen zwei Dongle und die Anlagendaten/Einstellungen ändern sich durch den Wechsel nicht.

Wenn Du beide SDongle schon (identisch) durchkonfiguriert hast, ist das vermutlich der Fall. Dann musst Du da anscheinend nicht noch einmal durch, nur weil Du wieder den einen Dongle gegen den anderen tauschst. Wenn Du jedoch einen nagelneuen SDongle zum ersten Mal in Deine Anlage hängst, dann ist Schritt 13 m.E. schon notwendig, um sicherzustellen, dass man Ende alles richtig konfiguriert ist.

Aber das ist wie gesagt kein Hexenwerk. Bisher ist da jeder gut durchgekommen. Einfach machen und ansonsten zur Not halt KI oder den Support fragen. Da es der letzte Schritt ist, ist es ja nicht so tragisch, wenn der erst am nächsten Tag passieren sollte.

[Jfreund10]

Hallo,
Ich habe heute den neuen dongle eingesetzt. Auf dem Dongle ist software V200R025C00SPC110 drauf. In KI heißt diese Version ist genau die richtige für den ..004 dongle. In chat hier wurde aber SPC300 oder R025 als neue berichtet die ich aber in FusionSolar App nicht sehe. Wie lade ich die FW auf den dongle?
Der Dongle ist nur über LAN mit Route verbunden. Gleichzeitig mit WLAN ging nicht. Der alte Dongle konnte es.

[RTTTC]

Latest version today is V200R025C00SPC130

[FlaTEriC1983]

Hi,
vielen Dank für diesen tollen, hoffnungsbringenden Thread.
Mein Use-Case ist ein etwas anderer, die Probleme scheinen aber ähnlich. Ich nutze die Modbus-Abfrage um mittels CUxDaemon Daten in eine Homematic CCU3 hineinzubekommen, was zwar grundsätzlich funktioniert, aber da ich aus 3 Geräten (Batterie, WR und Meter) jeweils den ein oder anderen Wert haben wollte, 3 separate Abfragen bedeutet. Damit die Kombination der Werte, und die sich daraus zu errechnenden Werte halbwegs Sinn ergeben, muss die Abfragen-Serie ja recht schnell hintereinander erfolgen, was aber dann oft dazu führt, dass mindestens ein Gerät keine Antwort schickt. Sogar bei Abfrage lediglich im 2-min-Takt kann manchmal über 10min kein vollständiger Wertesatz ausgelesen werden, was für viele Zwecke, aber insbesondere eine PV-Überschuss-Lade-Steuerung natürlich eine bescheidene Situation ist.

Ich habe Huawei nun auch einen 004er abgeschwatzt, der heute angekommen ist. Bevor ich das aktuell fragile Gebilde, was aber immerhin halbwegs funktioniert, riskiere, habe ich aber noch einige Fragen:

• kann ich den neuen Dongle mit Strom befeuern, ohne am WR zu hängen, und ihn so schon vollständig einrichten/konfigurieren?
• fährt bei der Aktualisierung der FW immer noch die ganze PV-Anlage herunter, obwohl es nur der Dongle ist, der aktualisiert wird? Das hatte ich leider jedes Mal... oder kann man das irgendwie verhindern?!
• im Modbus-Interface-TCL-Skript, welches jemand Homematic-Forum postete, sollte man für die Nutzung mit dem Huawei-Dongle eine Wartezeit von 2000ms zwischen Öffnen des Ports und der Registerabfrage reinschreiben, sonst ging da mal gar nichts. Hat jemand eine Ahnung, ob man sich das nun sparen kann?

Lieben Dank,
beste Grüsse,
Eric

[j1gg3]

Hab den Dongle ebenfalls getauscht aber die Modbus Fehler haben sich nicht verbessert.
Was letztlich geholfen hat, ist die Modbus Abfragen zu reduzieren in dem ich alles in EVCC via MQTT angebunden habe. Jetzt kann ich mir den Proxy auch sparen…

Bei mir gab es übrigens eine Änderung an der Modbus ID für den Master und zwar von 1 auf 3

[TRON4R]

Das ist seltsam. Dann musst Du Deinen Modbus aber ganz schön mit Anfragen zuballern, denn meiner produziert keine Fehler, solange sich "nur" evcc und HA (über den Modbus-Proxy) alle 15 Sekunden (evcc) bzw. 30 Sekunden (HA) am Dongle melden.
Und natürlich muss er noch zusätzlich die Daten an die FusionSolar-Cloud liefern.

Erst wenn ich dann noch auf der Kommandozeilen-Ebene evcc Abfragen wie z.B. evcc meter grid oder evcc meter pv-slave machen lassen, tauchen (je nach abgefragtem Gerät, der pv-slave scheint eher Fehler zu produzieren als das grid oder der pv-master) die ersten Timeout-Fehlermeldungen auf.

Auch spannend, dass bei Dir der Tausch zu einer Änderung der Modbus-ID geführt hat. Das ist bei 99% der Leuten hier nicht der Fall gewesen (es gab erst einen Post hier, der das auch berichtet hat). Hast Du beim Dongle-Tausch irgendwas abweichend von den von mir oben beschriebenen Schritten gemacht? Daran könnte man vielleicht herausfinden, was den ID-Tausch triggert und wie man ihn dann vermeiden oder auch provozieren kann, wenn mas möchte.

[j1gg3]

Die Ausfälle sind seit dem Umstieg bei EVCC auf MQTT leicht zurückgegangen. Mir ist sonst kein anderer Client bekannt, der den Dongle mit Modbus Anfragen überfordert, auch im Modbus Proxy Log konnte ich hier nichts erkennen. Wo ich mich schwer mit getan habe, sind die richtigen Einstellungen hinsichtlich Connection Time und Timeout herauszufinden. Ende vom Lied, ich bin durch Zufall auf https://github.com/tma/mbproxy gestoßen. Dieser Modbus Proxy erlaubt einen Delay einzubauen, nachdem ich einen Delay von 200ms gesetzt habe, sind die Fehler bisher ganz ausgeblieben.

Von den jeweils über 40 Entitäten, habe ich mehr als 20 deaktiviert, einen Unterschied konnte ich jedoch nicht feststellen.

Bzgl. Tausch des Dongles, bin ich, soweit ich mich erinnere wie oben beschrieben vorgeangen. Ins Fusion Portal anmelden und den als Offline anzeigten Dongle ersetzen. Schritt 13 habe ich mir gespart, ggf. hätte ich dort die Modbus ID verändern können.

[CiNcH83]

mbproxy hatte ich hier schon vorgeschlagen. Der kann die komplette Kommunikation entzerren.

Und NIEMALS etwas am Proxy vorbei direkt auf der Anlage machen!

[j1gg3]

also was wirklich geholfen hat, war die Erhöhung der Baud Rate auf 19200, seit dem ist Ruhe.

[achtbitunix]

Ein herzliches Danke an @TRON4R!

Habe eben an meiner Anlage den SDongleA-05 QMV gegen einen QMV-004 getauscht. Hat alles wunderbar funktioniert.
Ich habe hierfür die FusionSolar App verwendet.
Wenn der Dongle offline ist, kann dieser wie hier beschrieben getauscht werden.
https://support.huawei.com/enterprise/de/doc/EDOC1100319316/a43a080e

Meine Heruasforderung, ich bin von WLAN auf FE umgestiegen und wollte die DHCP IP-Adresse gegen eine feste Adresse tauschen.
Hierfür sind folgende Schritte notwendig:

• aus dem QR-Code des Dongels das WLAN-Passwort auslesen. Dies kann mit einem modernen Smartphone erfolgen, es wird Text angezeigt, diesen kopieren. Darin ist auch das benötigte Passwort
• Mit dem WLAN des Dongles mit dem neuen Passwort verbinden (das bekannte Ch***** funktioniert nicht mehr)
• FusionSolar App öffnen und die Beschwerden es sei kein Internet vorhanden ignorieren
• In FusionSolar -> Services -> Inbetriebnahme des Gerätes
• Verbindung zum SDongelA auswählen
  --> an dieser Stelle wurde ich aufgefordert dem "Installer" ein Passwort zu vergeben. Was ich getan habe
  Der Rest leider aus der Erinnerung, die APP lässt in dem Zustand keine Screenshots zu
• Unter Einstellungen / Routereinstellungen DHCP deaktivieren und in den entsprechenden Feldern eine IP-Adressen vergeben -> speichern
  Nach kurzer Zeit ist der Dongel mit fester IP Online. Bei mir in der FritzBox ist der mit dem Namen "lwip" aufgetaucht.

Huawei Solar in HomeAssistant hat die Arbeit nach dem IP-Tausch natlos aufgenommen.

Das Ganze hat etwa 50 Minuten gedauert. 30 für die Suche nach dem passenden WLAN-Passwort ...

Ach ja, ich habe hierfür keinerlei FW-Update eingespielt oder einspielen müssen und dieses Live-Data Gedöns ist nun auch da.
SDongeleA V200R022C10SPC210
Inverter V100R001C00SPC156

Grüße
Reinhold

[CiNcH83]

Ich persönlich würde bei DHCP bleiben und im Router eine Adressreservierung vornehmen.

[Weafdinstel]

Wer nutzt Kaskade mit Batterie am sDongle mit Firmware 140 und mbproxy? mbProxy verbessert bei mir die Lage am Dongle kaum spürbar, der Cache fängt nur wenige Anfragen ab. Mehrere Logs über Tags hab ich mal von KI auswerten lassen und das Ergebnis:
Kernbefund: Genau die Register mit fett markierter Ø Attempt-Dauer (≈3,6–4,0 s statt sonst üblichen 5 ms) sind die großen Blöcke, die vom Config-Coordinator (15-min-Intervall, 47xxx-Speicherparameter) bzw. den 30s-Coordinatoren (32000, 32064 qty=56, 37001) gelesen werden – genau diese liefern auch praktisch alle 42 Fehler. Die kleinen Einzelwert-Register laufen dagegen durchgehend sauber im ms-Bereich. Das deutet darauf hin, dass der sDongle bei großen zusammenhängenden Leseblöcken intern länger braucht
Stecke ich meinen anderen sDongle an, der noch mit R22er Software läuft gibts keine Hänger. Damit läuft aber auch jeder andere Proxy fehlerfrei.
Ergebnis für mich, das Dongleproblem ist nicht nur der Hardware geschuldet, sondern auch der Umstellung auf den R25er Zweig, denn die Probleme begannen extrem mit den für den Umstieg vorbereitenden Updates R022C10SPC201/R022C10SPC210 und verbesserten sich nach der Umstellung dann wieder schrittweise. Sind aber immer noch weit entfernt von der Stabilität vor der Umstellung.

[CiNcH83]

2 Ansatzpunkte hätte ich noch...

• Prüfe mal deine Netzwerk-Config und stelle die Firewall nicht zu restriktiv ein. Dem Dongle schmeckt es wohl nicht, wenn er nicht nach außen pingen kann, sprich der ICMP ins Internet geblockt ist.
• LUNA2000 und Smart Power Sensor werden üblicherweise am RS485_2 vom Wechselrichter angeschlossen. Theoretisch kann man sie aber zusammen mit dem kaskadierten WR und dem SDongle auf den RS485_1 hängen. Huawei gibt an, dass in dem Fall nur noch 3 kaskadierte WR möglich sind, was darauf schließen lässt, dass die Performance dann massiv in die Knie geht. Prüfe also, ob Batterie und Zähler ordnungsgemäß am RS485_2 hängen.

Aber Huawei hat in den letzten Jahren definitiv am Kaskadenfall herumoptimiert. Ich glaube schon, dass Modbus TCP deshalb nun weniger CPU- und Bus-Zeit bekommt. evcc liest hauptsächlich auf dem SDongle gecachte Register.

[CiNcH83]

Das es auch sauber funktionieren kann zeigt Huawei mit den Schnittstellen direkt auf den WR-WiFi Hotspots.

Das ist ein grundlegend anderer Fall. Der SDongle hängt per RS485_1 auf dem Wechselrichter. Der WiFi-Hotspot hat da wahrscheinlich einen direkteren Draht, wo auch keine Ausregelung der Kaskade stattfindet.

[Weafdinstel]

ICMP (StealthMode) ist in der Fritzbox nicht aktiv. Batterie und Zähler sind auf RS485_2 und der Slave_WR auf RS485_1.
Im Endeffekt gebe ich es jetzt auf, da ich eh nix dran ändern kann.
Egal was ich versuche, die Logs sagen immer Ursache sind die zu langen Antwortzeiten des Dongle, dadurch stauen sich Anfragen irgendwann auf und der client wird nicht mehr innerhalb timeout bedient.

[CiNcH83]

Ohne eine weitere Runde über Huawei zu drehen, kommen wir da wahrscheinlich auch nicht weiter. Wenn man gute Infos hat, kommt man da in der Support-Hierarchie allerdings immer schnell höher...

Einzige Erklärung, die ich habe, ist, dass der Kaskadenfall so weit optimiert wurde, dass Modbus TCP weniger CPU- und Bus-Zeit bekommt.

[Weafdinstel]

Ich hab Heute mal auf der Fritzbox eth1 zum Dongle mit SPC140 mitgeschnitten und auswerten lassen. War zwar nur eine Stunde, aber so schlecht war das Ergebnis nicht, dass für meine Begriffe ein 30sec Abfrageintervall ihn aus dem Tritt bringen dürfte. Das ist die Auswertung von Claude:

Wichtig — Scope der Aufzeichnung: Es ist ausschließlich Verkehr zwischen 192.168.1.6 (Proxy) und 192.168.1.73 (sDongle) enthalten. Kein direkter Verkehr von 192.168.1.8 (HA/evcc) zum sDongle — bestätigt, dass beide Clients korrekt über den Proxy laufen.

Nebenbefund: Der sDongle unterhält parallel eine eigene TCP-Verbindung zu einer externen IP (80.158.17.31 — vermutlich Huawei-FusionSolar-Cloud-Anbindung), allerdings mit sehr geringem Volumen (135 Pakete / 62 Minuten). Das dürfte keine relevante Zusatzlast darstellen.

---

2. Latenzmessung: Proxy → sDongle (aus echtem Paketmitschnitt)

Gemessen: Zeitdifferenz zwischen gesendeter Anfrage und Antwort mit identischer Modbus-Transaction-ID.

2.1 Gesamtstatistik

Metrik | Wert -- | -- Zeitraum | 15:06:04 – 16:08:10 Uhr (62 Minuten) Anzahl gemessener Request/Response-Paare | 1.181 Unbeantwortete Anfragen | 0 Antworten ohne passende Anfrage | 0 Minimum | 2,1 ms Maximum | 15.575 ms (≈ 15,6 s) Durchschnitt | 1.587 ms Median | 7,1 ms

Auf der reinen Proxy↔Dongle-Verbindung gab es in diesem Fenster keine einzige Fehlzuordnung — jede Anfrage bekam genau eine Antwort mit der richtigen Transaction-ID. Das ist ein gutes Zeichen für die Stabilität dieser speziellen Verbindung.

2.2 Latenz-Verteilung

Latenz-Bereich | Anzahl | Anteil -- | -- | -- < 50 ms | 623 | 52,8 % 50 – 200 ms | 0 | 0,0 % 200 ms – 1 s | 6 | 0,5 % 1 – 5 s | 459 | 38,9 % 5 – 10 s | 78 | 6,6 % > 10 s | 15 | 1,3 %

Wichtiger Befund: Die hohen Latenzen sind über die gesamte Aufzeichnung gleichmäßig verteilt, nicht auf eine bestimmte Lastspitze konzentriert.

2.4 Alle Latenzen > 10 Sekunden

Zeit | Latenz -- | -- 15:11:17 | 10.934 ms 15:11:28 | 12.944 ms 15:16:32 | 10.160 ms 15:27:08 | 10.932 ms 15:27:19 | 13.427 ms 15:27:32 | 10.538 ms 15:32:36 | 13.240 ms 15:43:14 | 15.575 ms (Maximum) 15:43:29 | 12.201 ms 15:48:21 | 11.257 ms 15:48:32 | 11.970 ms 15:53:56 | 12.277 ms 15:59:16 | 10.159 ms 15:59:27 | 10.933 ms 16:04:56 | 10.426 ms

Bleibt die Frage, warum kommt der langsame aber stabile Datenfluß mit vielen Aussetzern in HA/evcc an? Und warum nur bei Verwendung von Firmware neuer als R22...SPC126?
Mal schauen ob ich der Sache noch mit gleichzeitigem Mitschnitt von Proxy und wlcr debug auf die Schliche komme.

[Mike-the-Brain1]

Hallo Leidgeplagte!

Auf die Gefahr hin, dass es hier im Thread schon mal erwähnt wurde – ich habe mich nicht durch die kompletten Seiten gewühlt –, möchte ich kurz meine Lösung mit euch teilen.

Ich habe eine Anlage mit einer Kaskade aus 2 Wechselrichtern und 3 Luna-Speichern am Laufen, alles auf dem aktuellsten Firmware-Stand. Auch ich hatte massiv mit Timeouts in Home Assistant zu kämpfen.

Was ich alles probiert habe...
Ich habe unter anderem den SDongleA-QMV auf den SDongleA-004 getauscht, doch das Ergebnis blieb zunächst das gleiche.

Der Game Changer: Baudrate erhöhen!
Was bei mir zu 100 % auf einen Schlag alle Probleme gelöst und für absolute Stabilität gesorgt hat, war die Umstellung der Baudrate von 9600 auf 19200.

Mit alter Version 1.6 der HA Integration: Polling war alle 30 Sekunden für ca. 200 Entitäten möglich (von rund 604 bereitgestellten).

Mit neuer Version 2.x: Polling zwar nur im Minutentakt, dafür aber völlig fehlerfrei und ohne einen einzigen Aussetzer.

Ich verwende den Modbus-Proxy, wobei die Kommunikation über TCP direkt zum Dongle läuft und durch die Integration sowie Home Assistant gesteuert wird (also mit zwei Geräten)

Wichtige Hinweise für die Umsetzung:
Nach Firmware-Updates am Wechselrichter muss die Baudrate von 19200 neu aktiviert werden. Das ist bei beiden Wechselrichtern und dem Dongle aber in 2 bis 3 Minuten erledigt.

Unbedingt nur den RS485-Bus zwischen den Wechselrichtern und dem Dongle auf 19200 Baud stellen. Den RS485-Bus zur Luna und zum Smart Power Sensor (Smart Meter) muss zwingend auf 9600 Baud belassen werden!

Vielleicht hilft das dem ein oder anderen von euch ebenfalls weiter!

[CiNcH83]

Stellt sich eigentlich eher die Frage, warum hat Huawei nicht schon intern auf 19200baud als Standard umgeschrieben?

Das habe ich bei meinem letzten Kontakt mit der Huawei-Entwicklung auch gefragt. Und warum sich die Baudrate ständig zurücksetzt (z.B. nach FW-Update). Kam dann aber keine sinnvolle Antwort mehr zurück. Allerdings empfiehlt tatsächlich auch Huawei, die Baudrate für bessere Performance hochzusetzen. Registerabfragen bzw. Kommandos auf RW-Register profitieren sehr davon, zumal hier ein Roundtrip über RS485 vonnöten ist. Bei bereits auf dem Dongle gecachten Registern (viele RO-Register) hat es natürlich keine direkten Auswirkungen. Dennoch sinkt die Buslast natürlich generell. Auch gecachte Register müssen natürlich periodisch aktualisiert werden.

[Mike-the-Brain1]

@Kugelfang666
wenn ich am Abend zuhause bin und kurz Zeit habe schaue ich nach wo die Einstellungen sind im Kopf hab ich sie im Moment nicht...
@Weafdinstel
Ich habe eine Vermutung wegen der 9600: Nicht jeder verbindet seine Kaskade mit hochwertigen geschirmten Kabeln wie wir. Manche Wechselrichter sind meterweit auseinander. Da die Verbindung zur FS Cloud kaum Traffic benötigt, reichen 9600 Baud völlig aus – hier geht eben Stabilität vor Geschwindigkeit.

[Kugelfang666]

Danke ich hab es aber gestern hinbekommen. Irgendwie hing das UI vom dongle, nach einem Neustart konnte ich die baudrate einstellen!

[Mike-the-Brain1]

Freut mich, dass es nach einem Neustart geklappt hat!
Auf den Abruf der FS-App hat die Änderung zwar keinen großen Einfluss, aber für Home Assistant und Modbus TCP über den Dongle sind das echt Welten!

Ich habe das Ganze eben noch einmal zu meiner Auffrischung nachgesehen und vielleicht hilft es ja doch noch jemand anderem auch weiter!

Hier ist eine kurze Anleitung, wie ihr die Baudrate der RS485-Kommunikation von 9600 auf 19200 Baud anheben könnt:

1. Dongle:

• Einloggen
• Auf Einstellungen -> Kommunikationskonfiguration -> RS485 gehen
• Baudrate auf 19200 ändern
• Mit den Pfeiltasten zurückgehen und ausloggen

2. Master-Wechselrichter:

• Einloggen
• Auf Einstellungen -> Kommunikationskonfiguration -> RS485 gehen
• Bei RS485_1 den Wert auf 19200 stellen
• WICHTIG: RS485_2 unbedingt auf 9600 belassen (das ist die Kommunikation zwischen Wechselrichter, LUNA und Smart Meter!)
• Mit den Pfeiltasten zurückgehen und ausloggen

3. Slave-Wechselrichter:

• Genauso vorgehen wie beim Master

Fertig!

Ein kleiner Praxis-Tipp: Zieht zügig durch alle drei Komponenten durch. Wenn ihr zu lange braucht, stellt sich das System nach gefühlten fünf Minuten von selbst wieder auf 9600 Baud zurück.

Und noch ein Hinweis zur Verkabelung:
Voraussetzung für einen reibungslosen Betrieb sind natürlich kurze Leitungswege zwischen den Komponenten – am besten mit geschirmten Twisted-Pair-Kabeln (mit "alten" Netzwerkkabeln habe ich sehr gute Erfahrungen gemacht). Wenn das passt, steht diesem Setup nichts mehr im Wege und der Dongle erledigt seine Arbeit in einem Bruchteil der Zeit.

Viele Grüße!

[Mike-the-Brain1]

P.S.: Danke an das Forum für die kreative Eigeninterpretation meiner Sätze – da greift wohl eine automatische Textverbesserung ein. 😅Nicht wundern, wenn sich manches komisch liest!

[Weafdinstel]

Ich hab Heut Abend noch mal bei mir den Proxy und evcc gekappt und an den sDongle nur HA wlcr/huaweisolar per Direktverbindung laufen lassen.
Das klappt mit SPC140 noch viel schlechter als mit Proxy. Neu konfigurieren mit der Dongle IP geht recht flott, es kommen auch kurz Daten, aber danach nur noch Fehler und keine Daten mehr.
Dann noch mal den SPC126 Dongle angesteckt, wlcr/huaweisolar auf dessen IP neu konfiguriert, auch das geht wieder flott und danach kommen Daten lückenlos über Stunden.
Während SPC140 lief hab ich mal den Netzwerkverkehr zum Dongle mitgeschnitten und auch gleichzeitig ein Debuglog in wlcr/huaweisolar gestartet.

Claud meint zu den Daten es wäre ein 10sec timeout fest in einer "tmodbus" Bibliothek hinterlegt, nur wo soll das sein? wlcr/huaweisolar steht auf 30sec Intervall und 29sec timeout.

`

1. Was das pcap zeigt (mit sauberer TCP-Stream-Rekonstruktion)

Metrik | Wert -- | -- Zeitraum | 22:44:37 – 23:03:45 Uhr (19 Min.) Gesendete Anfragen (HA → Dongle, direkt) | 104 Echte Modbus-Antworten (verifiziert über IP-Gesamtlänge, nicht nur Capture-Länge) | 3 Davon Exception 0x06 ("SLAVE DEVICE BUSY") | 2 Davon echte Nutzdaten-Antwort | 1 Anfragen ohne jede Antwort (reines TCP-ACK, keine Modbus-Payload) | 101 (97,1 %) Proxy-Altverbindung (192.168.1.6) | FIN um 22:44:44, RST um 22:45:15 — sauber beendet

`

2. Der wichtige Fund im HA-Log: Client-eigener 10-Sekunden-Timeout
   23:03:17.409 Backing off for 0.0s after exception response
   Response timeout after 10 seconds for transaction with ID 0xa8

Das ist kein proxy- oder integrationsseitig konfigurierter Wert — das ist ein fest in tmodbus (der zugrunde liegenden Transport-Bibliothek) einprogrammierter 10-Sekunden-Timeout, unabhängig von UPDATE_TIMEOUT oder sonstigen Einstellungen. Das erklärt auch, warum wir vorher nie auf diesen Wert gestoßen sind: Er kam bislang durch den Proxy (der selbst schon vorher reagierte) nie zum Tragen. Jetzt, ohne Proxy, ist er die maßgebliche Grenze — und bei 97 % Nichtantwort ist er in der Praxis fast immer die Ursache des Abbruchs.

[Weafdinstel]

Ja. Der HC32 ist in beiden verbaut. Soweit ich es verstanden habe ist der Chip für die Hardwareverschlüsselung direkt darin integriert. Oder müsste sich ein separater Chip auf der Platine finden lassen?
Bin jetzt erst mal auf weiteren Supportverlauf gespannt, bisher haben die Ingenieure nur Timingvorschläge gebracht. 😁

[CiNcH83]

Oder müsste sich ein separater Chip auf der Platine finden lassen?

Kein separater Chip, nein. Anders als der STM32F427, verfügt der HC32F4A0SITB über eine Crypto-Einheit (AES/HASH) direkt auf dem Chip.

[TRON4R]

Ich hatte primär auf die zweite Tabelle geschaut. Da war der Unterschied nicht ganz so krass. Nur eine Erhöhung im Bereich 1-5 Sekunden, der Rest ziemlich ähnlich. Aber die erste Tabelle ist in der Tat keine Werbung für R025, wenn man eine Kaskade hat. Da bin ich froh, dass ich von R025 bisher die Finger gelassen habe.

Schade nur, dass wir nicht 100%ig sicher sein können, ob die "Wundertüte" unter R025 wirklich exakt genauso performed wie der -004. Aber bisher sehe ich sowieso keinen Anlass den R022-Zweig zu verlassen. Ich hoffe, mein Solarteur kommt nicht irgendwann auf die Idee, zu wechseln. 🙈

[CiNcH83]

Da bin ich froh, dass ich von R025 bisher die Finger gelassen habe.

Wenn ich das allerdings recht in Erinnerung habe, hast du eine FW, die deutlich neuer als die R022 SPC126 ist. Da hatte @Weafdinstel schon lange massive Probleme...

[TRON4R]

Ich habe aktuell die V200R022C10SPC300 drauf. Und eigentlich keine Probleme.

Wenn @Weafdinstel mit der Version massive Probleme hat, dann ist entweder bei ihm im Setup etwas anders oder seine Wundertüte ist am Ende doch nicht genauso gut wie die -004.

Ich habe eine Kaskade aus einem 10er und einem 8er Wechselrichter mit einem 15 kWh LUNA2000 S0-Turm. Die Geschwindigkeit steht auf 19200 Baud.

Und neben evcc im 15 Sekunden Takt fragt auch noch HA im 30 Sekunden Takt den SDongle -004 ab. Allerdings durch den Modbus-Proxy von evcc.

Wenn ich dann noch eine zweite evcc-Instanz auf meinem Windows-Rechner in der Kommandozeile eine Abfrage durchführen lasse (z.B. ein evcc meter grid oder evcc meter pv-master), dann produziert das in etwas mehr als der Hälfte des Fälle einen teilweisen Modbus-Error im Output. Die geht allerdings auch nicht durch den Modbus-Proxy, insofern ist das keine Überraschung.

Verstehe ich Dich richtig, dass ich in diesem Falle eigentlich doch auch auf R025 upgraden könnte?