Aktuelle Test Version
Veröffentlichungsdatum	01.07.2025
Github Link	https://github.com/bolliy/ioBroker.sun2000

Über eure Unterstützung würde ich mich sehr freuen.

Hallo zusammen,

ich habe für meinen Huawei Wechselrichter SUN2000 und Speicher LUNA2000 einen Adapter entwickelt, der die Registerdaten über modbus TCP ausliest und schreibt.

Bitte den Adapter über das Beta Repository oder npm installieren und nicht direkt über github - damit keine unfertige Version in ioBroker eingespielt wird.

Nun kann im sun2000 Adapter neben dem Smart Logger auch die Emma (Energiemanagementsystem von Huawei) auf einfache Weise integriert werden.

Feature list:

• Es können max. 5 sun2000 Wechselrichter (Master/Slave) mit mehreren Batterieeinheit verarbeitet werden.

• Battery Control
  Neben dem "Laden des Speichers über dynamische Stromtarife" können u.a. die Speicherladegrenzen eingestellt werden. Viele Beispielszenarien werden im Wiki beschrieben.

• Begrenzung Netzeinspeisung (Export Control)
  Über die Funktion Export control kann nun die Netzeinspeisung begrenzt oder unterbunden werden.
  Diese Funktion steht allerdings den SmartLogger Besitzern (noch) nicht zur Verfügung.

• Erzwungenes Laden/Entladen der Batterie (Forcible Charge/Discharge)
  Die Batterie kann für eine bestimmte Dauer oder auf einen bestimmten SoC-Wert zwangsweise aufgeladen oder entladen werden.

• Über den eingebauten modbus-proxy können Geräte von Drittanbietern (Wallbox, energy manger usw.) lesend und schreibend auf die Daten der Geräte per modbus tcp zugreifen. Da der modbus-proxy multi-client-fähig ist, kann der Zugriff von mehreren Clients gleichzeigit erfolgen. Darüber hinaus ist es möglich die Daten des Adapters auf eine andere Adapter Instanz zu spiegeln.
  Im Gegensatz zu dem SDongle ist der modbus-proxy deutlich schneller und stabiler.

• Wer ein SmartLogger sein Eigen nennen kann, ist sicher über die Integration des Huawei SmartLoggers erfreut.

• Mit der EMMA von Huawei kann der Energieverbrauch im Haus optimiert und die Energiekosten reduziert werden. Die Integration in den Adapter ist nun möglich. Die Leistungs- und Verbrauchsdaten werden im Pfad emma gespeichert.

• Bei der Verwendung von einem Wechselrichter werden nicht weniger als 148 Datenpunkte erzeugt.

• Live Daten wie Eingangsleistung (inputPower), Ausgangsleistung (activePower), Battery Lade-/Entladeleistung (charge and discharge Power) und der Netzbezug (activePower) des Smart power sensors werden in einem festen Intervall (default 20 Sekunden) ausgelesen und die entsprechenden Zustände geschrieben.

• Nur für geänderte Registerdaten werden Zustände (States) geschrieben. Das entlastet die ioBroker Instanz.

• Die States „inputPower“ oder „activePower“ im Pfad „collected“ können mit einem Trigger-Element „wurde aktualisiert“ überwacht werden. Da diese States im eingestellten Interwall immer gschrieben werden.

• Die Registerdaten werden über drei Intervalle gelesen und verarbeitet:
  high: Im engestellten Intervall werden auschließlich Echtzeitdaten wie PV Leistung, Inverterleistung, Ladeleistung und Zählerstände bedient.
  medium (30 Sek): Stringdaten, weitere Zählerdaten usw.
  low (60 Sek): die restlichen veränderbaren Informationen
  static: ist eigentlich kein Intervall, da dieser einmalig ausgeführt wird. Z.B. Bezeichnung und Model des Inverters

• Die summierten Leistungs- und Verbrauchsdaten des SDongles (sofern vorhanden) können im medium Interval gelesen und im Pfad sdongle gespeichert werden.

• Ein Huawei Smart Charger (Wallbox), die über eine Emma integriert ist, wird nun automaitsch erkannt und die Daten im charger Pfad gespeichert. Die Berechnung der aktuelle Ladeleistung erfolgt über die Änderung des Wertes totalEnergyCharged und wird im Unterpfad derived abgelegt.

Über Tests und euer Feedback freue mich sehr.

Installation:

Den Adapter über das Beta Repository oder npm installieren installieren, damit keine unfertige Version in ioBroker eingespielt wird.
Durch Änderungen am js-controller werden vom sun2000 Adapter nur noch node 18.x und höher unterstützt!

Ich freue mich auf eure Mitwirkung!

Neue Testversion sun2000 Adapter Version v2.3.4 released.

Die Installation erfolgt über npm oder morgen über das Beta Repository.

Mich hat schon lange gestört, dass der collected.dailInputYield nicht richtig mit dem Yield-Wert aus der FuisonSolar übereinstimmt. Besonders große Abweichungen zwischen den Werten ergaben sich beim Laden der Batterie aus dem Netz. In Diesem Zusammenhang ist mir irgendwann aufgefallen, dass der dailyEnergyYield (Register 32114) nicht die zeitliche Summe aus den Leistungswerten (Integral) aus activePower (Register 32080) sein kann.
Ab sofort wird eine Riemannsche Summe aus activePower im Datenpunkt sun2000.0.inverter.x.derived.dailyActiveEnergy gespeichert.
Nun sollten die beiden Werte sun2000.0.collected.dailyInputYield und sun2000.0.collected.houseConsumption erstaunlich gut mit den entsprechenden Werten aus FusionSolar übereinstimmen.
Hinweis: Die korrekten Werte stellen sich erst am Folgetag ein.

Ich bin auf eure Beobachtung gespannt!

Changelog:

2.3.4 (2025-11-01)

• dependency and configuration updates
• new state collected.dailyExternalYield Riemann sum of collected.externalPower

2.3.3 (2025-10-31)

• Improved verification of the adapter configuration
• new state inverter.x.derived.dailyActiveEnergy Inverter daily active energy, which is determined via the Riemann sum of inverter.x.activePower
• state collected.dailyInputYield was redisigned based on inverter.[0..n-1].derived.dailyActiveEnergy

Stephan

@blechbixn hast du den SmartLogger aktiviert?
Die Fehlermeldung ist von der modbusID 11 !

Die ModbusID 11 ist der Smart Meter, der am SmartLogger angebunden ist.

Da du kein SmartLogger hast (vermute ich mal), solltest du die Einstellung deaktivieren.

LG Stephan

Neue Testversion sun2000 Adapter Version v0.15.0 released.
Nun können auch Registerdaten über den modbus-proxy geschrieben werden.

Die Installation erfolgt über npm oder morgen über das Beta Repository.

Release v0.15.0
• dependency and configuration updates
• display a clearly legible table bar #121
• modbus-proxy write data also to the read cache #119

Hintergrund: Über das open source Energiemanagmentsystem evcc kann eine Wallbox betrieben werden. Damit sich beim Laden des E-Autos der Hausspeicher nicht unnnötig entleert, wird das BMS über den modbus-proxy entsprechend gesteuert.

Ich freue mich auf eure Kommentare!

LG Stephan

Neue Testversion sun2000 Adapter Version v1.0.0 released.

Ich habe u.a. Anpassungen für einen zukünftigen Adapter vorgenommen. Der neue Adapter soll im ersten Step das prognosebasierte Laden des Solarspeichers (Luna) ermöglichen. Das Laden der Batterie erfolgt auf Basis der Erzeugungs-, Verbrauchsprognose sowie der dynamischen Strompreisentwicklung (Tibber).

Darüber hinaus läuft die Unterstützung der node.js V18 (LTS) bald aus (https://endoflife.date/nodejs). Deshalb gibt es ein neues Major Release!
Bitte vor der Installation node auf die Version 20 oder 22 heben. https://github.com/bolliy/ioBroker.sun2000/wiki/Update-node.js

Die Installation erfolgt über npm oder morgen über das Beta Repository.

Changelog
1.0.0 (2025-02-10)
• dependency and configuration updates
• updated case sensitivity of the object status name
• Interval time of the slave inverter increased slightly
• Register data is not read in "Standby: detecting irradiation" (0x0002) of the slave inverter
• Control: battery.maximumDischargePower is deprecated use "maximumDischargingPower" instead
• Control: battery.maximumChargePower is deprecated use "maximumChargingPower" instead
• breaking changes
◦ Node.js 20 or higher required
◦ ioBroker host (js-controller) 6.0.1 or higher
◦ ioBroker admin 6.13.16 or higher

Stephan

Neue Testversion sun2000 Adapter Version v1.2.2 released.

Die Installation erfolgt über npm oder morgen über das Beta Repository.

Nun kann auf die Berechnung des states usableSurplusPower über Parameter im Pfad sun2000.x.control.usableSurplus Einfluss genommen werden. usableSurplusPower Werte kleiner als 0.1 kW werden auf 0 gesetzt. Negative nutzbare Überschussleistungswerte gehören der Vergangenheit an.

minSoc
Unterhalb des minSoc (%) Wertes hat die Ladung der Hausbatterie Vorrang. Der nutzbare Überschuss wird ausschließlich durch die Netzeinspeiseleistung bestimmt. Steht unterhalb dieses Wertes mehr Erzeugungsleistung zur Verfügung als der Batteriespeicher aufnimmt, wird diese als Überschuss berücksichtigt. Ab dem minSoc Wertes wird neben der Netzeinspeiseleistung auch die Ladeleistung der Batterie als Überschussleistung gewertet.

bufferSoc
Erlaubt die zusätzliche Nutzung der Hausbatterieleistung oberhalb des bufferSoc (%) Wertes mit dem angegebenem bufferPower (W) Wert.

bufferPower
siehe bufferSoc

residualPower
Sofern sich der Soc der Hausbatterie zwischen minSoc und bufferSoc befindet, legt der residualPower Wert den Soll-Arbeitspunkt der Überschussberechnung (Regelung) fest. Werte größer 0 verschieben den Arbeitspunkt in Richtung Hausspeicher-Laden bzw. Netzeinspeisung; kleiner 0 Werte in Richtung Netzbezug.

1.2.2 (2025-04-01)

• dependency and configuration updates
• fix: Object state sDongle.OSVersion to short
• new setting path for controlling the usableSurplusPower parameters control.usableSurplus

Neue Testversion sun2000 Adapter Version v2.1.1 released.

Die Installation erfolgt über npm oder morgen über das Beta Repository.

Ich habe ein paar Fehler bereinigt und Abhängigkeiten aufdatiert.
Darüber hinaus wurde der usableSurplusPower in den Unterpfad surplus.usablePower verlegt und ein neuer Wert collected.surplus.power kreiert. Dieser beinhaltet die Überschußleistung der PV ohne BufferPower der Batterie.

Changelog
2.1.1 (2025-09-24)

• dependency and configuration updates
• fix: adjust event value limits based on usableSurplus parameters
• fix: swap register values for power consumption in Emma driver #190
• emma: improve power calculation with exponential moving average in EmmaCharger
• update surplus power state definitions and deprecate old identifiers

Stephan

Neue Testversion sun2000 Adapter Version v2.2.0 released.

Die Installation erfolgt über npm oder morgen über das Beta Repository.

Achtung! Für alle diejenigen, die eine Emma im Einsatz haben und den Datenpunkt sun2000.0.meter.activePower (Wirkleistung des electric energy sensor) z.B. in einer Vis verwenden. Bitte nutzt zukünftig den neuen Datenpunkt sun2000.x.meter.derived.feed-inPower! Ansonsten wird sich das Vorzeichen der Wirkleistung umdrehen.

Hintergrund: Vielleicht ist dem einen oder anderen aufgefallen, dass der positive Wert sun2000.0.meter.activePower bei der Nutzung des internenen Energy meter der Emma im Vergleich zum Sdongle+Smart Power Sensor nicht die Einspeiseleistung sondern den Netzbezug aufweist (anderes Vorzeichen). Damit nun beim Umstieg vom SDongle zur Emma für bestehende scripte (js/blockly) oder Vis möglichst reibungslos vonstatten gehen kann, wurden im meter Pfad zwei neue Datenpunkte eingeführt.

meter.derived.signConventionForPowerFeed-in
meter.derived.feed-inPower

Sign convention for power feed-in soll die Vorzeichen Konvention bei Stromeinspeisung bzw. Strombezug verdeutlichen.

Der State meter.derived.signConventionForPowerFeed-in ist beim Einsatz des SDongles oder des SmartLoggers =1:
bei Einspeisung: active power hat ein positives Vorzeichen (>0)
bei Bezug: active power hate ein negatives Vorzeichen (<0)

Der State meter.derived.signConventionForPowerFeed-in ist beim Einsatz der Emma =-1:
bei Einspeisung: active power hat ein negatives Vorzeichen (<0)
bei Bezug: active power hat ein positves Vorzeichen (>0)

Im DP meter.derived.feed-inPower wird nun entsprechend der Vorzeichen Konvention die Einpeiseleistung des DP sun2000.0.meter.activePower abgelegt.

Changelog
2.2.0 (2025-10-05)
• dependency and configuration updates
• new state meter.derived.signConventionForPowerFeed-in sign of meter.activePower that is currently being fed into the power grid
• new state meter.derived.feed-inPower electric power that is supplied to a grid ("fed in")

Stephan

@marcelinho es müsste Grid Power sein (>0 : Netzbezug, <0 : Netzeinspeisung). Du findest die notwendigen Informationen in den Interface definitions https://github.com/bolliy/ioBroker.sun2000/blob/main/docs/definitions.md

Stephan

Hallo Zusammen, ich habe mein Huawai Wechselrichter dank des JS script von @chrisB gut im Griff. Nun ist mir allerdings aufgefallen, dass die Funktion/Methode "readHoldingRegisters" mit einem Callback aufgerufen wird. Der Callback führt zu einem asynchronem Programmablauf. Deshalb muss die Abfrage der Register zeitverzögert erfolgen, da die die Modbus-Schnittstelle nur seriell angsprochen werden kann. Es kann also die nächste Abfrage erst nach dem Modbus-Response erfolgen.

Die Funktion readHoldingRegisters gibt aber auch ein Promise zurück - also ein Versprechen auf einen Wert, der später kommt.
Die Lösung: async/await! Unter der Haube arbeitet ein Promise, aber wir werden von den ganzen Unannehmlichkeiten befreit. Nun habe ich die Funkion "readRegisterSpace" umgebaut. Der Programmablauf ist nun synchron. Der Aufruf "await client.readHoldingRegisters" wartet bis das Ergebnis vorliegt ohne zu blockieren!

async function readRegisterSpaceAsync(id, address, length) {  
    try {
      //console.log('ReadRegisters 1');  
      await client.setID(ModBusIDs[id-1]);
      //console.log('ReadRegisters 1');
      let data = await client.readHoldingRegisters(address, length);
      //console.log('ReadRegisters 2');
      return data.data;    
    } catch (err) {
       //console.error("Error received writing adress "+ address + " from id: " +  ModBusIDs[id-1] + " with error: " + modbusErrorMessages[err.modbusCode], err);
       //return -1;
       throw err; //Fehler weiterreichen
    }
    
}

Mein readRegisters kann nun als synchroner Programmablauf - recht schnell - die Register auslesen.

async function ReadRegister(Reg) {
    for (let id = 1; id <= ModBusIDs.length; id++) {
        for (let i = 0; i < Reg.length; i++) {
            let address = Reg[i][0];
            let length = Reg[i][1];
            try { 
              console.debug("Try to read data from id/address " + ModBusIDs[id-1] + "/" + address);
              let data = await readRegisterSpaceAsync(id, address, length);
              console.debug("Read data from id/address " + ModBusIDs[id-1] + "/" + address + "\nData is: " + data);
              for (var y = 0; y < length; y++) Buffer[id-1][address + y - BufOffset] = data[y]; 
            } catch(err) {
                // if error, handle them here (it should not)
                if (err.modbusCode == null) {
                  console.warn("Lost connection to client. ");
                }  else { 
                  console.error("Error received writing adress "+ address + " from id: " +  ModBusIDs[id-1] + " with error: " + modbusErrorMessages[err.modbusCode], err);
                }  
                return -1;           
            } 
           
        }      
    }     

}

Hier eine gute Erklärung zum Thema asynchroner Code: link text

Lg Stephan

Neue Testversion sun2000 Adapter Version v2.3.4 released.

Die Installation erfolgt über npm oder morgen über das Beta Repository.

Mich hat schon lange gestört, dass der collected.dailInputYield nicht richtig mit dem Yield-Wert aus der FuisonSolar übereinstimmt. Besonders große Abweichungen zwischen den Werten ergaben sich beim Laden der Batterie aus dem Netz. In Diesem Zusammenhang ist mir irgendwann aufgefallen, dass der dailyEnergyYield (Register 32114) nicht die zeitliche Summe aus den Leistungswerten (Integral) aus activePower (Register 32080) sein kann.
Ab sofort wird eine Riemannsche Summe aus activePower im Datenpunkt sun2000.0.inverter.x.derived.dailyActiveEnergy gespeichert.
Nun sollten die beiden Werte sun2000.0.collected.dailyInputYield und sun2000.0.collected.houseConsumption erstaunlich gut mit den entsprechenden Werten aus FusionSolar übereinstimmen.
Hinweis: Die korrekten Werte stellen sich erst am Folgetag ein.

Ich bin auf eure Beobachtung gespannt!

Changelog:

2.3.4 (2025-11-01)

• dependency and configuration updates
• new state collected.dailyExternalYield Riemann sum of collected.externalPower

2.3.3 (2025-10-31)

• Improved verification of the adapter configuration
• new state inverter.x.derived.dailyActiveEnergy Inverter daily active energy, which is determined via the Riemann sum of inverter.x.activePower
• state collected.dailyInputYield was redisigned based on inverter.[0..n-1].derived.dailyActiveEnergy

Stephan

@bf0911 ich habe die SDongle Problematik in das Wiki https://github.com/bolliy/ioBroker.sun2000/wiki/Fehlerprotokollierung-und-Fehlerbehebung-(troubleshooting)
aufgenommen.

Falls du die SDongle Firmware immer noch suchst, kannst du mir PN mit Email-Adresse schicken

@bf0911 hier noch einige interessante Infos zu den alten/neuen SDongles:
https://github.com/evcc-io/evcc/discussions/22534
und hier gibt es noch weitere Anleitungern rund um Huawei Solar:
https://wattkraft-de.zendesk.com/hc/de-de/sections/17283302480530-Fragen-und-Anleitungen

@cksoft der proxy sucht nach einer TreiberIntanz mit der modbus id 0. Leider gab es in deinem Fall 2 Instanzen mit der selber modbus id. Da hat er sich den Inverter geschnappt, der keine Daten zur Verfügung hat. Denn einen WR mir der modbus id 0 gibt ja nicht.

@bf0911 dann würde ich auf die sDongle Firmware V200R022C10SPC121 oder ...126 zurückgehen.

@cksoft genau das wollte ich sehen. Da kommt nur die modbus id des WR rein und nicht die der Emma. Die hat immer die modbus id 0 und das weiß der Adapter.

Also nur die 12 !

Das werde ich zukünftig abtesten und den Adapter mit einer entsprechenden Fehlermeldung beenden;)

@bf0911 zu welcher Uhrzeit tauchen die Timeouts auf und wieviele sind es ca. Am Tag?

@cksoft zeig mal deine Adapter Konfiguration.

@cksoft welche app hast du verwendet?

@bf0911 ok, seit wann sind dir die Timeouts aufgefallen?
Wie alt ist der Sdongle bzw. dein PV-Anlage? Ältere SDongles haben teilweise Probleme mit neuer Firmware.
https://www.facebook.com/groups/653371832541018/posts/1297435441467984/
https://www.photovoltaikforum.com/thread/247370-huawei-sun2000-dongle-verbindungsprobleme-per-lan/