Abfrage des Huawei SDongleA-05 verbessern (beschleunigen)

[TRON4R]

Meine PV-Anlage besteht aus einem Master-Wechselrichter Huawei SUN2000MA-10KTL-M1, einem Slave-Wechselrichter Huawei SUN2000MA-8KTL-M1, dem Huawei Smart Power Sensor DTSU666-H 100A und dem Speicher Huawei LUNA2000-15-S0.

Mit dem Template SUN2000 with SDongle & Power Sensor kann ich auch alle 4 Geräte grundsätzlich auslesen.

Allerdings ist der SDongleA-05, über den die Abfrage erfolgt, leider elend langsam. Wenn ich z.B. per Kommandozeile darauf zugreife, dann dauert es manchmal über 10 Sekunden, um nur eine Abfrage zu beantworten.

Damit also alle 4 Geräte sauber abgefragt werden, ohne dass ständig Timeout-Probleme auftauchen, musste ich schon in evcc unter Konfiguration → Allgemein → Regelverhalten das Aktualisierungsintervall auf 45 Sekunden hochsetzen.

Und selbst das reicht leider nicht immer. Vor allem, wenn man parallel noch mit der Huawei FusionSolar App (oder über die FusionSolar-Webseite) eine Abfrage macht oder eine Konfigurationsänderung durchführt, schlägt in 8 von 10 Fällen entweder der Änderungsrequest fehl oder evcc zeigt anschließend ein

und einen oder mehrere "timeout"-Einträge im Fehlerprotokoll an.

Außerdem ist ein Intervall von 45 Sekunden bei bewölktem Himmel ziemlich nervig, weil dann evcc sehr oft den Änderungen der Sonneneinstrahlung hinterherläuft. Es kommt eine Wolke, der Überschuss reicht nicht mehr aus und bis evcc den Ladestrom passend reduziert hat, lädt man das Auto ungewollt aus dem Stadtnetz oder Hausakku. Wenn evcc dann den Ladestrom reduziert hat, ist die Wolke oft schon wieder vorbei und der wieder vorhandene Überschuss landet nicht im Auto. Wenn evcc dann wieder hochgeregelt hat, schlägt schon die nächste Wolke zu. Usw.

Daher wäre meine Frage an diejenigen, die sich mit der Programmierung der Schnittstellen zu den Wechselrichtern beschäftigen, ob man vielleicht im Falle von Huawei die Abfrage so gestalten kann, dass man statt 4 einzelner Abfragen nacheinander (die dann 4x 10 Sekunden brauchen) alles in einer Abfrage an den Dongle zusammenfassen könnte, sodass das Ganze nur noch 10 oder vielleicht maximal 15 Sekunden benötigen würde.

Besteht da Hoffnung, dass man das entsprechend ändern könnte?

Das wäre mir sogar einen finanziellen Beitrag wert, weil die Alternative die Anschaffung einer EMMA-A02 oder eines Smartlogger3000A wäre, was ein paar Hundert Euro kostet UND das Risiko birgt, dass bei der Umstellung auf die neue Schnittstelle die historischen Daten in FusionSolar teilweise oder sogar ganz verloren gehen (die Aussagen in den Foren dazu sind da leider etwas widersprüchlich, auch was die richtige Reihenfolge bei der Umstellung angeht, aber es haben schon Huawei-Besitzer alle historischen Daten verloren).
Und es würde allen evcc-Nutzern zugute kommen, die Huawei bei sich im Einsatz haben.

[icke-pp]

Ich gehe mal davon aus das die Abfrage per Modbus erfolgt? Grundsätzlich sollte man nur 1 System haben das eine Modbus Abfrage durchführt, alles andere gibt immer Probleme wie du schon selbst gemerkt hast. Sobald du mehrere Systeme hast die ständig zugreifen wollen solltest du über einen Modbusproxy nachdenken. Dann ist dieser die zentrale Anlaufstelle für deine Abfragen. Das ist grundsätzlich der normale Weg. Da muss niemand was umprogrammieren.

https://docs.evcc.io/docs/reference/configuration/modbusproxy

[TRON4R]

Leider hast Du mich komplett missverstanden. Ich frage nicht mit mehreren Systemen den ModBus vom Dongle ab!

Sondern evcc schickt eindeutig sichtbar (wenn man in der Kommandozeile evcc meter eingibt) für jedes integrierte Template eine separate Abfrage an den SDongle.

D.h. nach Abschicken von evcc meter kommt bei mir nach ca. 10 Sekunden die Antwort für den Eintrag grid in der evcc.yaml, danach 10 Sekunden später die Antwort für das template pv-master, danach für pv-slave und zum Schluss für battery.

Meine Frage ist, ob man nicht diese Registerwerte alle MIT NUR EINEM REQUEST auf einmal abfragen kann statt 4 Stück abzuschicken?
Dazu wäre ein umprogrammieren von evcc leider nötig.

[RTTTC]

How is your dongle connected to the internet? Wifi ? Is the signal strong ? (You can see this when conected to the main inverter’s internal management wifi, and logged in as installer)

Is your network reliable high quality and without any problems?

Perhaps try to connect it using ethernet cable?

[TRON4R]

The dongle is connected using a LAN cable. My switch is capable of Gigabit speed. My network is very reliable and not the cause of this. Many other people report the same issue that the dongle is slow as hell if queried using modbus.

I am quite versed with IT stuff, so I know what I am doing and where I can look for the cause of problems. The only thing I can't do is write code in modern languages (I programmed in Assembler back in the day on an Amiga 500).

So I appreciate your concern and suggestions, but unfortunately, this issue can only be solved either by replacing the dongle with a faster one or by optimizing how evcc queries the dongle, ideally by merging the four requests into a single larger one.

[RTTTC]

Strange..
I have a Huawei inverter, with a weak wifi signal (unable to wire up ethernet to it) and it still performs quite good, with some occational timeouts
Less devices though, no battery and no second inverter.

But that should not matter for evcc - as it reads each “meter” sepperately. . ?

Do you stop evcc prior to runing evcc meter command?? (If you do not stop it - it would be trying to access your dongle as a two separate evcc instances at the same time causing delay/timeout)

Firmwares are latest on all your Huawei devices?

[RTTTC]

Or - perhaps try a direct RS485 conection to the main inverter?

[TRON4R]

1. If you have no battery and no second inverter, you're saving 50% of the requests since you only need to query two devices: the inverter and the grid meter. So of course you're done in roughly 20 seconds. Which is a major difference.
2. the quality of the connection between evcc and the dongle doesn't really matter much (as long as it isn't abysmally bad), since the amount of data transferred is absurdly low. Just a few numbers and that's it. So that's not really relevant in my case.
3. Yes, of course I stop the evcc running on my Synology before starting the command line queries. As I said I am relatively tech-savvy and know the basics well enough to not query the dongle from two different places at the same time.
4. Yes, I am using the latest firmware. But the response time of the Dongle has been bad since day one and the many firmware updates in the meantime haven't noticeably changed that. This is not a relevant factor for this whole issue as well.

The issue can only be solved by replacing the dongle with a faster one or by optimizing how evcc queries the dongle, ideally by merging the four requests into a single one.

[mdkeil]

Die Frage ist, ob es am dongle selbst liegt oder schlicht die rs485-Schnittstelle(n) zu langsam sind.. man könnte ggfs. mit einem esp/raspi (mit installiertem modbus-proxy) direkt an die schnittstelle rangehen und die "Netzfunktionalität" liefert der esp/raspi.. Aber am Ende wird der dongle auch nichts anderes machen.

Zumindest widerspricht es diametral der Idee, evcc für die breite Masse tauglich(er) zu machen.

gibt ich dir recht.. es steht ja auch frei ein entsprechendes Feature Request aufzuzmachen. Sollte es nicht betrachtet werden, bin ich mir sicher, dass dies auch begründet wird.

[mdkeil]

Das ist genau der Punkt.. evcc ließt jedes meter sequentiell aus-- wobei in diesem Fall auch das parallele Auslesen eher kontraproduktiv wäre- Dadurch dass er aber 3 seperate Anfragen an den dongle schickt (pv, slave, battery) dauert es einfach gefühlt unendlich lange.. Da ich nicht glaube, dass sich das evcc team diesem Problem annehmen wird (was durchaus verständlich ist) würde ich mir selbst eine komplettabfrage in node-red erstellen und diese Daten via mqtt zur Verfügung stellen. pv, slave und battery dann entsprechend als custom meter einbinden.. problematisch wird dann nur die aktive batterie-Steuerung. Alternativ nur pv und slave als custom-meter einbinden und in evcc zusätzlich den modbus-proxy aktivieren und die Batterie weiterhin via evcc auslesen und steuern lassen.. in noder-red dann zumindest pv und slave noch in einen rutsch auslesen.. dann aber die Abfrage an den modbus-proxy senden.

[TRON4R]

Da ich leider keine Ahnung habe, was node-red ist und ein zusätzlicher modbus-proxy die Sache auch eher komplizierter als einfacher machen würde, wird das vermutlich kein realistischer Weg für mich sein. Und selbst wenn ich mich durchfummeln und das halbwegs passabel ans Laufen bekommen sollte, dann wäre das keine leicht nachvollziehbare Lösung für die vielen anderen Huawei-Besitzer, die evcc einsetzen wollen.

Zumindest widerspricht es diametral der Idee, evcc für die breite Masse tauglich(er) zu machen.

Daher ist meine Hoffnung, dass vielleicht einer der Devs im evcc-Team, der auch Besitzer einer Huawei-PV-Anlage ist, sich der Sache annimmt und die Queries in einer zusammenfassen könnte. Ich habe keine Ahnung, wieviel Aufwand das wäre, aber vielleicht hält er sich ja in Grenzen, weil nichts wirklich Neues gemacht werden muss, sondern nur 4 Abfragen in einer zusammengefasst werden müssten? Möglicherweise ist es aber auch total kompliziert, weil evcc im Kern darauf nicht vorbereitet ist und man ganz viele Purzelbäume im Code schlagen müsste, um diese Abfrage von 3 oder 4 devices dann zusammenzufassen und trotzdem die Ergebnisse an der richtigen Stelle auszuspielen?

Vielleicht kann ja jemand mit genug Kenntnissen von evcc wie z.B. @premultiply dazu etwas sagen, wie aufwendig so eine Zusammenfassung wäre? Also ob es realistisch wäre, auf soetwas zu hoffen oder ob das nie kommen wird, weil es einfach zu sehr außerhalb des vorgesehenen Gerüsts von evcc liegt.

[premultiply]

Daher ist meine Hoffnung, dass vielleicht einer der Devs im evcc-Team, der auch Besitzer einer Huawei-PV-Anlage ist, sich der Sache annimmt und die Queries in einer zusammenfassen könnte.

Die Hoffnung ist unbegründet.
Niemand im Core-Team hat eine solche Anlage.

Angeblich funktioniert der Direktzugriff per RS485 ja ganz normal. Nur dieses Dongle soll die bekannten Probleme machen.
Also einfach direkt per RS485 dran?

[TRON4R]

Als Nicht-Entwickler weiß ich leider nicht, wie ich direkt per RS485 an meinen Dongle rankomme.
Aber danke Dir für die schnelle Rückmeldung, dass keiner vom Kernteam etwas ändern kann. Dann werde ich mir den Smartlogger3000A dochmal näher anschauen, da der in sekundenschnelle reagieren soll. Die EMMA-A02 scheint bisher wenig positives Feedback bei den Nutzern zu produzieren und da weiß ich auch nicht, ob evcc die überhaupt schon supportet.

Vielleicht weiß ja jemand hier, wer damals das Modul für die Huawei-Wechselrichter geschrieben hat und könnte diesen Dev hier noch kurz verlinken? Möglicherweise hat der ja Zeit und Lust, die Abfrage zu optimieren? Mir wäre das wie gesagt auch einen finanziellen Beitrag wert.

[mucki12]

Oder einen AP zwischenschalten und direkt die WR per WLAN auslesen. Habe ich selber aber nie umgesetzt, da ich keine Performanceprobleme habe (habe allerdings auch keinen Slave-WR).

[RTTTC]

You would connect RS485 directly to the main inverter’s COM port - such an easy and cheap thing to try :)

[TRON4R]

If you're a developer or well versed with RS485 this might be true. Unfortunately my IT knowledge ends at the SysAdmin level. I can setup or manage an existing infrastructure, but I wouldn't even know which hardware is needed to connect directly to the COM port and how to talk to that hardware.

On top of that all the connectors of my inverter are already occupied. According to the inverter manual the COM seems to be the one where the 3 orange LAN cables are connected to at the moment. So that raises the question how I maintain the communication to those 3 devices that I need to unplug to connect whatever is needed to talk RS485 directly with the inverter?

So maybe your idea is a cheap thing to try, but certainly not an easy one (for me).
And I would assume the same applies for the majority of the other Huawei inverter owners using evcc.
But thank you for your suggestion. Maybe it helps people that are more familiar with RS485.

I had thought consolidating the data request from 4 to 1 might be a feasible and easy solution to speed things up fourfold and for all evcc users with Huawei hardware. But I guess that question can only be answered by the guy who developed the evcc moduls for Huawei inverters.

[CiNcH83]

Why are there four orange cables? It should be three, no? Cascaded inverter, battery and power sensor? Each device requires one wire pair. Each of those orange cables has 4 wire pairs. So you have plenty of spare wire pairs. Take one and connect it to either pins 1 and 3 or 2 and 4, depending on which of the two is free (one of those two is used for the cascaded inverter). Or add a fourth cable...

[TRON4R]

There are actually only 3 orange cables. I understand that the image makes it look like as if there could be 4 cables, because the most right one is running below the other two and connecting more on the left in the socket. But I just checked and there are definitely only 3 orange cables going into that socket.

Nonetheless, I still have no clue where to connect those free wires with on either side.

[CiNcH83]

Which device does evcc run on? I use a Raspberry Pi together with this RS-485 to USB adapter. Worked out of the box without any manual driver installtion. Two wires are actually enough. Additionally you can connect the shield of the CAT cable to the PE of the inverter (pin 5 or 6):

The slave inverter is most likely connected to 1/3. So you may want to use 2/4, or the other way around. You can also connect multiple devices to the same RS-485 pins. Power sensor and battery are connected to 7/9. My power sensor is actually connected to the LUNA and the LUNA to the inverter.

[CiNcH83]

Forgot the evcc config:

- name: sun2000
  type: template
  template: huawei-sun2000
  usage: pv

  modbus: rs485serial
  id: 1
  device: /dev/ttyUSB0
  baudrate: 19200
  comset: "8N1"

Default baudrate of the SUN2000 is 9600. But if you set it to 19200 in the inverter, you will also have to set it in the evcc configuration.

If you use Docker, you will have to pass the USB adapter (/dev/ttyUSB0) into the container...

docker run:

--device=/dev/ttyUSB0

docker-compose:

    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0

[CiNcH83]

Hier mal ein kleines "Optimierungs-Tutorial" für Huawei...

Es ist in der Tat so, dass Huawei bei Einzelabfragen sehr langsam ist. Man liest deshalb besser mehrere Register, sprich Registerbereiche, mit einer einzigen Abfrage aus. Ich lese WR+Batterie+EnFluRi zum Beispiel in 3 Abfragen aus:

• 30000-30072 (allgemeine Infos zum Wechselrichter)
• 32000-32114 (Ströme/Spannungen/Leistung/Energie-Register Wechselrichter)
• 37000-37121 (Batterie/EnFluRi)

Eine weitere Optimierung ist es, die Verbindung nur ein Mal aufzumachen und diese persistent zu halten, sprich die Verbindung nicht mit jedem Zyklus neu aufzumachen, da der Verbindungsaufbau zum WR recht lahm ist und die erste Abfrage im Anschluss i.d.R. in die Hose geht, sofern man nicht einen kurzen Sleep einbaut.

Last but not least kann man die Abfragegeschwindigkeit enorm beschleunigen, indem man die RS485 Baudrate auf 19.200 hoch setzt (Default=9.600). Das MUSS man sowohl im SDongle als auch im SUN2000 machen, da sich die beiden sonst nicht mehr verstehen. Dazu bedarf es Installer-Rechten. Auf den SDongle kommt man per WLAN und FusionSolar App. Dieser spannt, nachdem er neu gesteckt wurde, ein Konfigurations-WLAN auf. Und ja, die RS485 Einstellung hat auch auf den SDongle großen Einfluss. Ich gehe davon aus, dass das ein Serial-USB-Converter ist. Damit kann ich die oben genannten Registersätze von einem WR und einer Batterie in deutlich unter 5s auslesen.

Was mir ja vorschwebt ist ein "intelligenter" Proxy mit Cache, der periodisch große Register-Bereiche asynchron von den Geräten ausliest und vorhält. Mehrere Clients könnten sich dann auf den Proxy verbinden und Einzel- oder Bereichsabfragen tätigen, die aus dem Cache bedient werden.

[CiNcH83]

Da ich nur einen WR habe, werde ich jetzt aber auf RS485 umsteigen. Das soll wohl deutlich stabiler laufen. Wieso man für die Kaskade den Dongle braucht, ist mir sowieso schleierhaft.

[CiNcH83]

Gut möglich. Aber selbst eine einzelne Abfrage nur des Master-Wechselrichters kann mit evcc mal in 2 Sekunden und mal erst nach 10 Sekunden mit einem Ergebnis zurückkommen. Das Teil ist einfach nicht das schnellste.

Kann ich hier nicht nachvollziehen. Aber wenn da halt noch ein weiterer WR im Verbund hängt, wird die Kommunikation untereinander zur Aussteuerung der Kaskade wohl mit hoher Priorität laufen. Andere Dinge könnten dann verhungern. Vor allem, weil der Dongle wohl auch die Aussteuerung macht. Aus meiner Sicht ist das konzeptioneller Mist.

[TRON4R]

Das wird dann wohl vermutlich der Grund sein, dass der zweite Wechselrichter die Antwortzeiten vom Dongle derart ausbremst. Wieso man im Jahr 2025 noch ein System baut, welches auf normale Abfragen von vielleicht 10 Werten mit einer derartigen Verzögerung reagiert, ist mir auch ein Rätsel. Der Smartlogger 3000 und die EMMA reagieren ja angeblich auch deutlich schneller.

[CiNcH83]

Gibt ja auch noch andere Performance-Probleme mit Kaskade siehe hier.

[CiNcH83]

So. Heute mal mit diesem günstigen Adapter auf RS-485 umgestellt. Der Raspberry Pi hat auch schon die Treiber dafür im Bauch. Läuft bislang sehr gut. Bei Docker muss man beachten, dass man das /dev/ttyUSB0 Gerät durchschleifen muss. Damit sollte jetzt die Performance eines SmartLogger3000 drin sein.

Vor ich mich entgültig von der Cloud verabschiede, brauche ich jetzt noch einen Langzeit-Data-Logger und Visualisierer. Evtl. Home Assistant mit huawei_solar Integration? Und das ganze dann über den modbusproxy.

[RTTTC]

Another thing to try with multiple Huawei inverters OR when Huawei + non Huawei inverter is measured via sepparate smart meter and gathered by SDongle and shown in Fusion solar is to get all the PV data from the SDongle itself.
Then instead of calling all the inverters sepparately, total system PV generation data is taken directly from SDongle
That is what I do:

- name: pvTOTAL # Sdongle Solar generation power data from all connected devices
  type: custom
  power:
    source: modbus
    timeout: 10s
    connectdelay: 2s
    uri: x.x.x.x:502
    id: 100 # 100 sdongle direct data
    register:
      address: 37516 # 37516 Sdongle Total Active  Power from all connected devices
      type: holding
      decode: int32

@andig - could we add this to the template/ UI please ? (PS- connect delay of 2s is important and needed)
This is the only thing still left for me in yaml, everything else is in UI 😎

[TRON4R]

Ok, I found the register definitions in this document from Huawei: SDongle V200R022CC10 MODBUS Interface Definitions.pdf

But it seems to me as if we can't get all the data we need from the SDongle directly.
I could find terms like "total input power", "load power", "grid power", "total battery power", "total active power" (the one you're using), but that seems to be about it.

Unfortunately to be able to benefit from the full feature set that evcc offers, we also need values like SoC, Energy etc. and an option for evcc to lock/unlock the battery with regards to charging/discharging to allow for the various battery features to work:

But maybe we can replace at least the definitions for grid, pv-master and pv-slave by your SDongle template? 🤔
I will take a closer look when I have the time.

[RTTTC]

Grid has no currents - not good for my load management.
But total PV system active AC generation power works wonderfully for me. (I do not have home battery)

[RTTTC]

Maybe you should start a new topic regarding this request...

Most evcc users do not have a need for this, and solution for me personally will arrive when custom meters will be added to UI, so all is good.

[TRON4R]

I just created a yaml-definition to access all five parameters offered by Huawei through the SDongle according to their official documentation.

So it seems as if those five values

• total input power = total production of all inverters
• load power = total power consumption of household
• grid power = net power flow from/to the grid (positive = import/buy, negative = export/sell)
• total battery power = net battery power (positive = charging, negative = discharging - note: sign is reversed to "meter battery")
• total active power = total production including battery charging

are the only energy related values that the SDongle officially offers. Which makes sense to a degree, since it's kind of aggregating the data from all the attached devices (grid, inverters and batteries).

I also haven't found the exact difference between "load power" and "total active power" yet. Both seem to present very similar results over time. Doesn't matter if the battery is charging or discharging. Maybe it will reveal itself with different weather. Right now it's pretty cloudy and already late afternoon.
ChatGPT (fed with the official Huawei PDF, my yaml and the measured results) agreed that there should be an actual significant difference, because "load power" should only include the household load and "total active power" should include the load, the pv production and the battery. But with my PV production being 500 W and the battery discharge being 1700 W, it makes no sense that both values are very similar over time.

BTW: I also tried registers outside the documentation (down to 37494 and up to 37520), but they either returned a simple 0 or an error message. Except for 37514, which returns very large values like for example 1639562 or 1639565. It seems to count the total power generated by the inverters (which in my case is 9767.2 + 6628.5 = 16396.7 kWh (sum of Energy when querying my pv-master and pv-slave) multiplied by 100).

Here's the yaml-definition in case someone wants to play around with it.

meters:
- name: dongle-totalinput # SDongle Total input power - seems to be combined PV-production of all inverters
  type: custom
  power:
    source: modbus
    timeout: 10s
    connectdelay: 2s
    uri: 192.168.2.5:502
    id: 100 # 100 sdongle direct data
    register:
      address: 37498 # SDongle Total input power - seems to equal meter "pv-master + pv-slave"
      type: holding
      decode: int32

- name: dongle-load # SDongle Load power - seems to be the total power consumption of the household
  type: custom
  power:
    source: modbus
    timeout: 10s
    connectdelay: 2s
    uri: 192.168.2.5:502
    id: 100 # 100 sdongle direct data
    register:
      address: 37500 # SDongle load power - seems to equal pv-totalinput + pv-totalbattery
      type: holding
      decode: int32

- name: dongle-grid # SDongle grid power - showing consumption from grid or excess to grid
  type: custom
  power:
    source: modbus
    timeout: 10s
    connectdelay: 2s
    uri: 192.168.2.5:502
    id: 100 # 100 sdongle direct data
    register:
      address: 37502 # SDongle grid power - seems to equal meter "grid" (positive = buy, negative = sell)
      type: holding
      decode: int32

- name: dongle-totalbattery # SDongle Total battery power - combined battery consumption or discharge
  type: custom
  power:
    source: modbus
    timeout: 10s
    connectdelay: 2s
    uri: 192.168.2.5:502
    id: 100 # 100 sdongle direct data
    register:
      address: 37504 # SDongle total battery power (positive = charge, negative = discharge - sign is reverse to "meter battery"!)
      type: holding
      decode: int32

- name: dongle-totalactive # SDongle combined total energy production including battery
  type: custom
  power:
    source: modbus
    timeout: 10s
    connectdelay: 2s
    uri: 192.168.2.5:502
    id: 100 # 100 sdongle direct data
    register:
      address: 37516 # 37516 SDongle Total Active - seems to equal "pv-master + pv-slave - battery"
      type: holding
      decode: int32

[TRON4R]

And here's another screenshot of the values showing that PV production also doesn't explain the nearly identical outputs of “load” and “totalactive”:

Maybe load = total power consumption (house + loadpoints like my heat pump),
and totalactive = total power generation (PV + battery),
and that's why the two values are always so close together at the moment?

[RTTTC]

[CiNcH83]

So they only support DTSU666 via Modbus RTU? Then the control loop could also run in the inverter itself.

[CiNcH83]

I just checked SDongleA settings myself:

I hoped you could actually use any Modbus RTU and TCP capable inverter or meter and just specify device and register address to retrieve active power from the respective device. But it looks like this only works with meters available from Huawei.

[CiNcH83]

I did a quick and superficial performance comparison...

Modbus TCP:

[site ] DEBUG 2025/04/15 16:14:22 grid power: -1350W
[site ] DEBUG 2025/04/15 16:14:23 pv 1 power: 1716W
[site ] DEBUG 2025/04/15 16:14:24 battery 1 power: -5W
[site ] DEBUG 2025/04/15 16:14:27 grid currents: [-2.33 -1.59 -2.16]A
[site ] DEBUG 2025/04/15 16:14:28 battery 1 soc: 100%
[site ] DEBUG 2025/04/15 16:14:28 site power: -1355W

Modbus RTU via RS485:

[site ] DEBUG 2025/04/15 16:18:52 grid power: -989W
[site ] DEBUG 2025/04/15 16:18:52 pv 1 power: 1353W
[site ] DEBUG 2025/04/15 16:18:52 battery 1 power: -6W
[site ] DEBUG 2025/04/15 16:18:52 grid currents: [-1.88 -1.07 -1.81]A
[site ] DEBUG 2025/04/15 16:18:52 battery 1 soc: 100%
[site ] DEBUG 2025/04/15 16:18:52 site power: -995W

Modbus TCP is clearly a second class citizen.

[RTTTC]

Great test!
Would you please provide more data on how it was all connected for both tests?

[CiNcH83]

Modbus TCP:
Raspberry Pi and SDongleA connected via same Ethernet switch (PV, Raspi and heatpump share an exclusive switch).

Modbus RTU:
Raspberry Pi with USB Serial Converter directly connected to the SUN2000's 485A1 pins.

Baudrate in both cases has been set to 19.200 bps.

Hope this answers your question...

[detlefheese]

That sound great!

[CiNcH83]

I now have a SDongleA-05 02312QMV-004 which can do real-time data monitoring (see manual). evcc can read data from inverter/battery/meter in milliseconds, just like with RS485 directly to the SUN2000.

[TRON4R]

Same here with STM32 dongle. Ask the installer or Huawei to revert to SPC126 if you do not have installer rights yourself.

I don't have installer rights in the FusionSolar Cloud, but I do have local installer rights for the inverters and the dongle. Which is how I was able to upgrade to the FW V300.

but after he made a complete factory reset of the dongle, it suddenly ran much faster.

How would you factory reset the dongle?

I have no idea (yet). I am just quoting what he said in the forum. I will try to find that post again. And ask him that.

Is there any way for me to find out which hardware revision of the SDongleA-05 (i.e. which processor) I have without having to dismantle it and to try to read the inscriptions on the chips?

If you do not see real-time data in FS portal after FW V200 SPC118, you in fact have the STM32 dongle, not the HC32.

That is definitely the case. I never got the real-time option with any firmware, be it SPC118, 126 or higher.

No. There is no data loss when switching the dongle. I only had complete data loss after switching the inverter. So it looks like data is rather bound to the inverter than to the dongle.

Which I think is weird, because why would the cloud erase historical data that has already been stored in the cloud, just because you replaced a device?

But there certainly is data loss on some detail level if you replace the Dongle with a Smartlogger. Several incidences have been reported in the forums. The amount of data loss also depended on the order in which things have been replaced.
There are at least two options: introduce the new dongle/longer first and then take out the old dongle. Or delete the old dongle and then install the new one. I think the second path causes more data loss if I recall correctly.

To know which one you have, look at the sticker on the back of the dongle, line with (1P)PN/ITEM:

The sticker does not give a definitive answer. Only PN 02312QMV-004 is HC32 for sure. Others can be both. From information gathered so far, PN 02312QMV can be both, PN 02312QMV-005 may be STM32 only.

I just checked and the sticker on the back of my SDongleA-05 says 02312QMV-005.
That combined with the fact that I never got to see the real-time data option seems to confirm your assumption that the 02312QMV-005 is probably STM32 only.

Funny that the worse hardware has a higher revision number (-005) than the better performing hardware (-004).

If you use the FusionSolar cloud, you will have to replace the dongle S/N in the web interface so that the system knows via which dongle your plant connects to the cloud.

Good point. Can I do that in the FusionSolar cloud if I do NOT have installer rights in the cloud? (Because having to do that with my PV installer would require me to get ahold of the respective guy which would be a lot more time consuming than just doing it myself.)
I was just about to order a 02312QMV-004 for 50 Euros and do the replacement myself, but when I need to go back to my PV installer anyway, I can also let him do the whole thing.

Can someone confirm that you can move your own system out of the control of the PV installer company without losing any historical data in the FusionSolar cloud?

[CiNcH83]

I don't have installer rights in the FusionSolar Cloud, but I do have local installer rights for the inverters and the dongle. Which is how I was able to upgrade to the FW V300.

You should still be able to downgrade via file. But you need to disable anti-rollback protection.

Funny that the worse hardware has a higher revision number (-005) than the better performing hardware (-004).

Dongles with HC32 have been identified dating back to at least 2022. Suppose it was never meant as a faster replacement of the STM32 but in order to diversify supply chains during the Corona pandemic.

Guess they only recently found out about the AES capabilities as it has first been implemented in mid-2024.

Can I do that in the FusionSolar cloud if I do NOT have installer rights in the cloud?

It is a cloud thing. So it can only be done there with Installer privileges.

I was just about to order a 02312QMV-004 for 50 Euros and do the replacement myself, but when I need to go back to my PV installer anyway, I can also let him do the whole thing.

There are reports that those dongles are still slow for some. But those people typically have large systems with several inverters and/or battery towers/packs. More devices = more data = more problems.

Can someone confirm that you can move your own system out of the control of the PV installer company without losing any historical data in the FusionSolar cloud?

Did you know that FusionSolar only stores data for one year?

I switched the dongle twice and the historic data never got lost. It only did after replacing the SUN2000. Guess that the inverter is the root node for all the data. So all the data will still be in the cloud after a replacement but just not accessible anymore.

[TRON4R]

I don't have installer rights in the FusionSolar Cloud, but I do have local installer rights for the inverters and the dongle. Which is how I was able to upgrade to the FW V300.

You should still be able to downgrade via file. But you need to disable anti-rollback protection.

I just successfully downgraded from V200R022C10SPC300 back to V200R022C10SPC126. Since I don't have an installer account in the FusionSolar cloud, I had to do it locally at the Dongle directly, but it worked without invoking any special settings.

Guess they only recently found out about the AES capabilities as it has first been implemented in mid-2024.

Yes, that could very well be.

Can I do that in the FusionSolar cloud if I do NOT have installer rights in the cloud?

It is a cloud thing. So it can only be done there with Installer privileges.

Ok, thank you. So I will need the support of my installer to replace my old dongle with a 02312QMV-004.

There are reports that those dongles are still slow for some. But those people typically have large systems with several inverters and/or battery towers/packs. More devices = more data = more problems.

I do have two inverters and a battery. I hope that my problems will be solved. If not, I'd have to return the dongle and probably switch to an EMMA. Which I'd like to avoid because of the 10x higher costs and the risk of data loss in the cloud.

Can someone confirm that you can move your own system out of the control of the PV installer company without losing any historical data in the FusionSolar cloud?

Did you know that FusionSolar only stores data for one year?

No, I did not. Why is that? That is weird.

I switched the dongle twice and the historic data never got lost. It only did after replacing the SUN2000. Guess that the inverter is the root node for all the data. So all the data will still be in the cloud after a replacement but just not accessible anymore.

Great design. So if your inverter dies, you basically lose all data except the last year? This is insane. I think, I will now seriously consider installing my own data logger to be independent from this Huawei nonsense. Thank you for the warning.

[CiNcH83]

No, I did not. Why is that? That is weird.

Storage costs money and is not infinite ;) . If you really care about that data you probably want to set up your own DB server. I already prepared the switch by installing an USB RS485 converter which gets the data from the inverter directly without needing the dongle anymore. The primary reason however is that I want to cut off Huawei. I will keep the dongle installation for as long as I still have a service contract with my installer.

[TRON4R]

Yes, Storage costs money. But seriously, what amount of data are we talking about here?
A few measurements every 5 minutes. That is nothing compared to the storage capacity needed for a service such as Facebook or Gmail or anything else that stores images, music or worse videos. Those few kWh-yield and -consumption values are a joke in comparison.

[RTTTC]

Well, I can confirm that new Part number SDongle works like a charm. 😎 Now this is the dongle, that Huawei should have made from the start!
It does have the new part number printed on the back. (And on the small box it comes in)
I had to do "replace device" procedure using installer rights, on Huawei app, it is fast and fairly simple.

Thanks @CiNcH83 for your discovery!

[TRON4R]

I just replaced my old Huawei SDongleA-05 02312QMV-005 with the Huawei SDongleA-05 02312QMV-004, which was delivered to me today. And I can confirm that the slowness of the Dongle is a thing of the past now. No more timeouts in evcc, no more periods of my Huawei system being shown as offline in FusionSolar and finally an evcc interval value of 30 (or even shorter) has become possible.

The new SDongle with the HC32F4A0SITB CPU is so much faster, it's amazing. Finally the Huawei system performs as I had it expected to perform from day one. evcc meter grid, evcc meter battery etc. all return values in less than one second now.

I think replacing your slow SDongle with the -004 revision is the cheapest (less than 60 €), easiest (just switch the hardware and then use the replace function in FusionSolar for which you don't even need to have installer rights) and safest (no data loss as you might experience by replacing the SDongle with a SmartLogger or EMMA) thing you can do to make your system as fast as it should be to allow evcc to perform at its best.

If anyone's interested, I bought my new SDongle by Wagner, because this was the only shop advertising the revision 02312QMV-004 explicitly, having it on stock and offering a delivery time of 2 days:
https://www.elektroshopwagner.de/product_info.php?info=p378369

I am not associated with the store in any shape or form. I am merely a happy customers since the package arrived today around noon.

If you want to know how to execute the actual device change in the best order, you can find a step by step HowTo here.

[detlefheese]

Olaf ... wir sind ja "Leidensgenossen" ... den Dongle nuss ich auch installieren! Was machen Deine Abfall-Situationen bei klarem Sonnenschein. Wird das auch besser oder muss man da anders ran. Mein Solarteur meinte er könnte die zwei Wechselreichter trennen und damit ein glatte Ertragslinie "erzeugen" ...

(PS: wir kennen uns vom Fotografieren)

[TRON4R]

Hi Detlef. Also der manchmal mittags aussetzende "Referenz"-Optimierer in dem großen String am Master-Wechselrichter hat sich schon vor langer Zeit durch irgendetwas selbst repariert. Entweder durch irgendein Firmware-Update im Wechselrichter (die Optimierer laufen immer noch auf der V100R002C10SPC019) oder durch pures Glück. Auf jeden Fall habe ich mich vor einiger Zeit mal durch die historischen Daten für diesen Optimierer durchgeklickt und keine Unterbrechungen mehr gesehen.

Und den Dongle-Tausch kannich ansonsten wirklich nur dringend empfehlen. Ist echt, als ob ich eine komplett neue Anlage hätte. SoC im Diagramm, Echtzeit-Daten in der App und evcc testweise mit einem Intervall von 20 Sekunden. Mein einziges Problem gerade ist, dass alle meine Autos vollgeladen sind und ich evcc bisher noch nicht mit dem neuen Intervall zum Laden benutzen konnte. 😄

Sieh nur zu, dass Du wirklich den -004-Dongle bekommst. Wenn irgendwas anderes auf dem zugesandten Gerät stehen sollte, schick den gleich wieder zurück.

[Bonvogel]

Nur nochmal vorsorgliche Nachfrage, damit ich mir nicht das laufende System zerschieße:
Ich muss einfach nur (nach Abschaltung) den alten Dongle entfernen, den neuen (-004) rein und dann in der Fusion Solar App über Geräte/Dongel --> auf Gerätewechsel und dem Dialog folgen.
Weiteres ist nicht notwendig?

[TRON4R]

Ich bin mir nicht ganz sicher, was Du mit "(nach Abschaltung)" genau meinst (also was konkret Du abschalten willst. Den Wechselrichter musst Du für den Dongle-Tausch jedenfalls nicht abschalten), aber ja, das sind ganz grob die Schritte, die Du durchführen musst, um den Dongle in FusionSolar zu tauschen.
Anschließend musst Du Dich noch am neuen Dongle direkt anmelden und dort die Inbetriebnahme-Routine (zu finden unter Grundeinstellungen) einmal durchführen.
FusionSolar scheint zwar auch ohne diesen Schritt schon Daten vom Dongle zu empfangen, aber der Dongle schien ein paar wichtige Erkennungsschritte intern durchzuführen, bei denen ich nicht weiß, was langfristig passiert, wenn man den Punkt auslässt.

Wenn Du es ganz genau als Step by Step-Anleitung haben willst, empfehle ich Dir, hier meine "Lösung" durchzulesen.
Du kannst direkt zur Überschrift HowTo - Wie kann ich den SDongle ohne Datenverlust austauschen? springen.

[CiNcH83]

I started a sheet [LINK] where people can add their dongle configurations...

[detlefheese]

@CiNcH83 I could not update to ...118. My Firmware ist ...110. So I have to wait for an Update from my Dealer on Monday

[CiNcH83]

@detlefheese I see. So your firmware is wrong then in the list... I changed it. You may change it back as soon as you have the update together with Live Data...

[TRON4R]

@detlefheese Why can't you update? Can't you connect to the local WiFi of the Dongle?

The old default password "Changeme" isn't valid anymore for this Dongle. You have to scan the QR-Code on the Dongle to get access!
And then it let's you choose your local Installer-Password.
So I don't see any other reason why you shouldn't be able to upgrade.

[CiNcH83]

@detlefheese So what's the current state?

[detlefheese]

@CiNcH83 ich probiere es die Woche mal und berichte sofort