Erfahrungen mit der Anbindung von Huawei Wechselrichtern?

[Phill]

Danke werde das Mal korrigieren.

Hier nur die zu korrigierenden Werte:

Code Auswählen Erweitern

h47081 unpack => 'n'
h47082 unpack => 'n', min => 12


Das Minimum von 12 bei MinSOC hatte ich auch gesehen. Ist aber etwas seltsam. Da ich auch geringere Werte übergeben kann und die Fusion App auch Werte von 0-20 zulässt. Vielleicht veraltete Grenzewerte?

Wo habt ihr eigentlich den MinSOC stehen. Mein Elektriker hat den Wert auf 20 gestellt mit der Aussage ist besser für den Akku. Huawei gibt ja eigentlich an die volle Kapazität nutzen zu können. Ich werde ihn vermutlich, wenn der Akku absehbar nicht voll wird bei 20 belassen. Ansonsten sehe ich hier eher Werte ab 5.

[TheTrumpeter]

Anmerkung:
Bie mir liefert das Register h37410 'SDongleA_Typ' den laut Doku nicht dokumentierten Wert 4, obwohl ich den WLAN-FE (Wert 5) habe 

Bei mir genauso.

Wofür sind die übrigen Werte gut, insbesondere was kann man damit "anstellen", da sie ja geändert werden könnten?

[bertl]

Hallo Leute,

habe mich mal ein bisschen mit den Stati und Alarmen des Huawei Wechselrichern gespielt und diese dann ins System eingepflegt.
Somit kann man dann auf diverse Änderungen reagieren.

Für alle die es interessiert, hier die Implementierung:

Modul 98_ModbusSun2000WR.pm:

Code Auswählen Erweitern

         "h32000" =>  {           expr => 'sprintf( "0b%010b",$val )',
                                   len => 1,
                               reading => "A_Status_1",
                                unpack => "n",
                      },
         "h32002" =>  {           expr => 'sprintf( "0b%03b",$val )',
                                   len => 1,
                               reading => "A_Status_2",
                                unpack => "n",
                      },
         "h32003" =>  {           expr => 'sprintf( "0b%02b",$val )',
                                   len => 2,
                               reading => "A_Status_3",
                                unpack => "N",
                      },
         "h32008" =>  {           expr => 'sprintf( "0b%016b",$val )',
                                   len => 1,
                               reading => "A_Alarm_1",
                                unpack => "n",
                      },
         "h32009" =>  {           expr => 'sprintf( "0b%016b",$val )',
                                   len => 1,
                               reading => "A_Alarm_2",
                                unpack => "n",
                      },
         "h32010" =>  {           expr => 'sprintf( "0b%014b",$val )',
                                   len => 1,
                               reading => "A_Alarm_3",
                                unpack => "n",
                      },
Das dazugehörige notify in FHEM:

Code Auswählen Erweitern

define ntf_mdbsWR notify mdbsWR:A_.*:.* {
  my %mdbsWREvents = (
    A_Status_1 => [ 'standby',
                    'grid connected',
                    'normally',
                    'with derating due to power rationing',
                    'with derating due to internal causes of the solar inverter',
                    'stop normal',
                    'stop due to faults',
                    'stop due to power rationing',
                    'shutdown',
                    'spot check', ],
    A_Status_2 => [ 'status unlocked',
                    'PV status connected',
                    'DSP data collection yes',
                    'status locked',
                    'PV status disconnected',
                    'DSP data collection no', ],
    A_Status_3 => [ 'grid off',
                    'grid switch off',
                    'grid on',
                    'grid switch on', ],
    A_Alarm_1  => [ 'High String Input Voltage - 2001',
                    'DC Arc Fault [1] - 2002',
                    'String Reverse Connection - 2011',
                    'String Current Backfeed - 2012',
                    'Abnormal String Power - 2013',
                    'AFCI Self-Check Fail [1] - 2021',
                    'Phase Wire Short-Circuited to PE - 2031',
                    'Grid Loss - 2032',
                    'Grid Undervoltage - 2033',
                    'Grid Overvoltage - 2034',
                    'Grid Volt. Imbalance - 2035',
                    'Grid Overfrequency - 2036',
                    'Grid Underfrequency - 2037',
                    'Unstable Grid Frequency - 2038',
                    'Output Overcurrent - 2039',
                    'Output DC Component Overhigh - 2040', ],
    A_Alarm_2  => [ 'Abnormal Residual Current - 2051',
                    'Abnormal Grounding - 2061',
                    'Low Insulation Resistance - 2062',
                    'Overtemperature - 2063',
                    'Device Fault - 2064',
                    'Upgrade Failed or Version Mismatch - 2065',
                    'License Expired - 2066',
                    'Faulty Monitoring Unit - 61440',
                    'Faulty Power Collector [2] - 2067',
                    'Battery abnormal - 2068',
                    'Active Islanding - 2070',
                    'Passive Islanding - 2071',
                    'Transient AC Overvoltage - 2072',
                    'Peripheral port short circuit [3] - 2075',
                    'Churn output overload [4] - 2077',
                    'Abnormal PV module configuration - 2080', ],
    A_Alarm_3  => [ 'Optimizer fault [5] - 2081',
                    'Built-in PID operation abnormal [6] - 2085',
                    'High input string voltage to ground - 2014',
                    'External Fan Abnormal - 2086',
                    'Battery Reverse Connection [7] - 2069',
                    'On-grid/Off-grid controller abnormal [4] - 2082',
                    'PV String Loss - 2015',
                    'Internal Fan Abnormal - 2087',
                    'DC Protection Unit Abnormal [8] - 2088',
                    'EL Unit Abnormal - 2089',
                    'Active Adjustment Instruction Abnormal - 2090',
                    'Reactive Adjustment Instruction Abnormal - 2091',
                    'CT Wiring Abnormal - 2092',
                    'DC Arc Fault (ADMC Alarm to be clear manually) - 2003', ],
  );
  my $mdbsWRreading = ( split( ":",$EVTPART0 ) )[0];
  my $val = oct( $EVTPART1 );
  my $message = "";

  foreach my $group (keys %mdbsWREvents) {
    if( $group eq $mdbsWRreading ) {
      my $imax = $#{ $mdbsWREvents{$group} };
      if( $mdbsWRreading eq "A_Status_2" || $mdbsWRreading eq "A_Status_3" ) {
        $imax = ( $imax - 1 ) / 2;
      }
      for( my $i = 0; $i <= $imax; $i++ ) {
        if( $val>>$i & 1 ) {
          if( $message ne "" ) {
            $message .= " + ";
          }
          $message .= $mdbsWREvents{$group}[$i];
        } else {
          if( $mdbsWRreading eq "A_Status_2" || $mdbsWRreading eq "A_Status_3" ) {
            if( $message ne "" ) {
              $message .= " + ";
            }
            $message .= $mdbsWREvents{$group}[$i+$imax+1];
          }
        }
      }
      if( $mdbsWRreading ne "A_Status_1" && $mdbsWRreading ne "A_Status_2" ) {
        Log 3, "$SELF: $mdbsWRreading - Bit-Aenderung von '".OldReadingsVal( $NAME,$mdbsWRreading,'-' )."' auf '$EVTPART1'";
        Log 3, "$SELF: $mdbsWRreading - $message";
      }
      if( $mdbsWRreading =~ "A_Alarm_" ) {
        fhem( "set Telegram message \@User_Name $SELF: <b>$mdbsWRreading</b>\n$message" );
      }
      last;
    }
  }
}
Schönen Tag
Robert

[passibe]

Werte der Wallbox

Zur Wallbox: Da geht noch nix. Siehe v.a. hier und hier.

Inzwischen scheint es so, dass die Wallbox keinen eigenen Modbus-Server hat, den man auslesen kann. Stattdessen sieht es so aus, als würde die Wallbox nur unterstützen, dass es einen externen Modbus-Server (!) gibt, der Daten (z.B. zur aktuellen Überschussleistung usw., also ähnlich des Stromzählers) an die Wallbox schickt. Die Unterstützung für externe Modbus-Server ist wohl auch das, was mit dem letzten Firmware-Update hinzugefügt wurde (und leider nicht, wie ich ursprünglich mal dachte, dass die Wallbox selbst einen Modbus-Server bekommt).

Ist aber alles noch etwas unklar und ich hatte noch keine Zeit dem Huawei-Support zu schreiben und mal nachzufragen wie die sich das eigentlich vorstellen ...

[bertl]

Soweit ich die Philosophie von Huawei verstanden habe, ist der Aufbau meistens wie folgt:

Es gibt 1 Master (Server) der der erste Wechselrichter ist. Schließt man einen zweiten Wechselrichter an, ist das ein Slave (Client) zum ersten. Und auch alle weiteren Wechselrichter. Die Batterie, der DTSU666 (Stromzähler) und der SDongleA sind alles Slaves (Clients), welche an den ersten Wechselrichter berichten und sich austauschen.
Somit fragt man sämtliche Daten aller Geräte vom ersten Wechselrichter ab. Dieser steuert auch alle angeschlossene Geräte über Morbus.

Sollte also für die Wallbox auch so funktionieren. Man muss nur die richtigen Register kennen (Modbus Definition).

Soweit mein Verständnis von System - bitte berichtigt mich, falls ich hier einen Blödsinn schreibe!

Gruß, Robert

[miguelito]

Moin,

Habe mit FHEM mal vor vielen Jahren gestartet, dann ist es eingeschlafen und letztes Jahr wieder reaktiviert wegen HEMS.
Cool, dass es hier schon ein Grüppchen um den Huawei Sun 2000 gibt und, dass ihr schon so viel geleistet habt.

Dank dieser Info bin ich auch gleich mit der FHEM modbus Integration durchgestartet. Fürs erste interessiert mich mal nur die active power des inverters (32080) um das in meiner ftui3 neben dem Hausverbrauch darzustellen.

Ne Anmerkung, ich denke ich habe es beim drüberlesen im Thread noch nicht gesehen.
Wer mit RTU arbeiten möchte (was ich initial eigentlich wollte bzw. wg Simulation DTSU666 noch machen werde):

Wenn ihr den (WLAN) Dongle drin habt, dann ist Modbus Slave am physischen Modbus (Pins 7,9 für den Smartmeter lt Handbuch) nicht mehr verfügbar.

Als Master geht er natürlich noch wg Anschluss SM - wenn ich in den Geräteeinstellungen den Smartmeter aktiviere und am Bus mittrace, dann kommt da schön die erste Abfrage an den SM, ID11, Register 2001 (Spannung Phase A oder sowas).

Meine erste Idee war auch mich an den physischen Bus dran zu hängen um dort als Master die Inverterdaten abzugreifen und in weiterer Folge als Slave dem Inverter die Smartmeterwerte einzuspeisen. Wenn ich dann mal ne Batterie angeschlossen habe..

Deswegen meine Frage an die, die den DTSU666 installiert haben.
Den Smartmeter braucht der Inverter ja um die Batterie zu steuern - wann benötigt das Haus Energie (weil sonst zugekauft werden müsste).

Ich habe aber, wie Trumpeter, meinen eigenen Smartmeterhandler (Raspberry 2, der auch FHEM hostet), der am Smartmeter meines Energieversorgers die Daten alle 5Sek über Mbus raus bekommt und über MQTT in FHEM reinballert. Dieser geeichte Smartmeter des Energieversorgers ist imho im Vergleich zum Zangenabgriff eines DTSU eher das Maß der Dinge..

Diese Daten würde ich dem Inverter dann als Slave mit ID 11 zur Verfügung stellen (d.h. ich Simuliere den DTSU666).

Nun kommts: Hat jemand schon mal die Frequenz rausgemessen (modbus trace), mit der der DTSU666 vom Inverter abgefragt wird?

Da ich "nur" alle 5sek Daten bekomme frage ich mich wie rasch der DTSU666 Daten liefert -> vonwegen möglichst exakte Batteriesteuerung (Netzbezug vermeiden). Da der Modbus mit 9600Baud läuft kann die Frequenz ja nur überschaubar sind. Je nachdem wie viele Register übertragen werden.

Ich vermute mal active Power / Hausverbrauch wird häufiger übertragen, die restlichen Register, die hauptsächlich dem Mapping in den Invertradressraum dienen, damit man sie über den Inverter (ID1) abfragen kann, nicht so häufig.

Können die Zangen des DTSU zur Installation geöffnet werden - d.h. "nachträgliches" drüberschieben möglich ohne abzuklemmen? Falls ich ihn nachrüsten möchte.

Btw. weil ich irgendwo hier auch gelesen habe, dass jemand die Verbindung zum DTSU auswerten wollte: Beim Mittracen des Busses mit entsprechendem Werkzeug (PC) greift man nicht aktiv ins Geschehen ein (d.h. sendet nicht) sondern lauscht nur - damit gibts auch keine Probleme vonwegen 2 Master.


Viele Grüße
Michael

Du darfst diesen Dateianhang nicht ansehen.

[bertl]

Hallo Michael,

Deswegen meine Frage an die, die den DTSU666 installiert haben.
Den Smartmeter braucht der Inverter ja um die Batterie zu steuern - wann benötigt das Haus Energie (weil sonst zugekauft werden müsste).

ich habe den DTSU666 installiert obwohl ich keine Batterie habe.
Der Grund dafür ist, dass in Österreich (Netz-OÖ) viele Besitzer einer PV-Anlage eine Einspeisebeschränkung wegen Netzüberlastung haben - in meinem Fall maximal 4 kWh.
d.h. sobald meine PV-Anlage mehr produzieren würde als der Hausverbrauch + die 4 kWh sind, regelt der Wechselricht ab. Daher der DTSU666.

Nun kommts: Hat jemand schon mal die Frequenz rausgemessen (modbus trace), mit der der DTSU666 vom Inverter abgefragt wird?

Nein, wie macht man das, welche Tools (entsprechende Werkzeuge) werden dafür benötigt?

Können die Zangen des DTSU zur Installation geöffnet werden - d.h. "nachträgliches" drüberschieben möglich ohne abzuklemmen? Falls ich ihn nachrüsten möchte.

Ja, das ist möglich!

Gruß, Robert

[TheTrumpeter]

d.h. sobald meine PV-Anlage mehr produzieren würde als der Hausverbrauch + die 4 kWh sind, regelt der Wechselricht ab. Daher der DTSU666.

Das kann man grundsätzlich auch ohne DTSU nur mit den Daten vom Smartmeter machen, einfach das Register "Fixed_active_power_derated_W" auf den gewünschten Wert setzen.
Ich habe auch mit dem Huawei-Support abgeklärt, ob das Register beliebig oft geändert/geschrieben werden darf, Antwort war "ja".

[bertl]

Ja das stimmt!
Man müsste den Smartmeter anzapfen/auslesen und in FHEM übernehmen/implementieren (bei mir nicht vorhanden).
Mit dem DTSU666 funktioniert alles 'out of the box'.

Was natürlich perjekt wäre, wenn der Ansatz von Michael funktioniert, indem man die Smartmeter-Werte dem Wechselrichter übergibt.

Diese Daten würde ich dem Inverter dann als Slave mit ID 11 zur Verfügung stellen (d.h. ich Simuliere den DTSU666).

Toll wäre es natürlich, wenn hier beide Möglichkeiten fix fertig beschrieben sind, und sich jeder je nach Gegebenheit, die für ihn beste Lösung auswählen kann 

[TheTrumpeter]

Toll wäre es natürlich, wenn hier beide Möglichkeiten fix fertig beschrieben sind, und sich jeder je nach Gegebenheit, die für ihn beste Lösung auswählen kann

Hier meine Lösung, die ich genutzt habe, solange die große Anlage keine Betriebserlaubnis hatte. Da ich zusätzlich ein genehmigtes Balkonkraftwerk hatte, habe ich keine "Nulleinspeisung" umgesetzt, sondern zwischen 300 W Einspeisung und 50 W Bezug zugelassen.
Zusätzlich habe ich versucht die Anzahl der Änderungen des WR-Registers etwas zu begrenzen (auch wenn der Huawei-Support bestätigt hat, dass ich den Wert beliebig oft ändern kann, wollte ich es nicht unnötig ausreizen), indem ich auf einen 60s-gefilterten Stromverbrauch getriggert habe und zusätzlich zwischen aktiver Limitierung durch den WR und Limitierung durch die Umweltbedingungen unterschieden habe.
(In den ca. 2,5 Monaten, wo die Limitierung aktiv war, habe ich das Register im Schnitt ca. 40 mal pro Tag geändert, wobei ich die Limits anfangs enger hatte, ich meine auf max. 200 W Einspeisung.)

Code Auswählen Erweitern

defmod myHuawei.Nulleinspeisung notify SmartMeterRestAPI:activepoweroffset_mean_1min:.* \
IF ((([myHuawei:Active_Power:d]+[SmartMeterRestAPI:activepoweroffset:d]-[myHuawei:Fixed_active_power_derated_W:d]) > 50) || (([myHuawei:Active_Power:d]+[SmartMeterRestAPI:activepoweroffset:d]-[myHuawei:Fixed_active_power_derated_W:d]) <= -300))\
(\
IF ([myHuawei:Device_status] eq "Leistung begrenzt")\
(\
set myHuawei Fixed_active_power_derated_W {([myHuawei:Active_Power:d]+[SmartMeterRestAPI:activepoweroffset:d]+150)},\
setreading myHuawei.Nulleinspeisung Zaehler {([myHuawei.Nulleinspeisung:Zaehler:d]+1)}\
)\
ELSE\
(\
IF (([myHuawei:Device_status] eq "Netz verbunden") && ([myHuawei:Active_Power:d]>([myHuawei:Active_Power:d]+[SmartMeterRestAPI:activepoweroffset:d]+300)))\
(\
set myHuawei Fixed_active_power_derated_W {([myHuawei:Active_Power:d]+[SmartMeterRestAPI:activepoweroffset:d]+150)},\
setreading myHuawei.Nulleinspeisung Zaehler {([myHuawei.Nulleinspeisung:Zaehler:d]+1)}\
)\
)\
)
attr myHuawei.Nulleinspeisung disable 1
attr myHuawei.Nulleinspeisung disabledAfterTrigger 15

[miguelito]

Hallo,

wow, gleich voll viel response

@Bertl, ich bin aus Salzburg aber bei uns noch keine Beschränkung - mir kommt vor, noch bis vor 1 Jahr haben sie das mit den PV Anlagen vom Land her noch voll promoted z.B. bei der Energieberatung. Jetzt wird es schon zu viel...? Gut sieht man ja am Einspeiseentgelt. Mit dem PV Überschuss pumpen sie bei uns das Wasser kostenfrei hoch in den Mooserboden um den Saft dann Nachts teuer wieder zu verkaufen 

Wenn Du aus OÖ bist hast Du sicher auch einen Kaifa Smartmeter von der OÖ Netz -> Mbus Adapter bauen oder ein Chinateil USB für Raspberry, wenn Du wie ich den FHEM Berry gleich im Schaltschrank hast. Sonst genügt natürlich ein ESP derivat vollauf für Auslesen serielle Schnitte & decipher der verschlüsselten Daten. Schnittstelle ist alles dokumentiert vom Hersteller. Der Meter pusht ein Paket mit den OBIS Werten alle 5sek.

Falls Du bei der Entwicklung eines "virtuellen" DTSU unterstützen und tracen würdest - am physischen Modbus genügt jeder freie serielle Port Monitor (PC Software) - USB Modbus Adapter vorausgesetzt. Bei TCP könntest Du auf eines der freien Modbus Tools (GIThub) zurückgreifen: qModMaster z.B. heißt eines. Ich schreibe Euch das noch hier rein. Für den DTSU müssen wir aber an der physischen Schnitte tracen, wo der DTSU angeschlossen ist. Abzeigkabel an den Pins 7,9 am Wechselrichter zum Modbus Adapter am PC - fertig.

Meine Idee ist einfach auch ein ESP derivat (die schöpfen ja auch aus dem unendlichen arduino SW Ecosystem) beim Inverter zu plazieren, der mit WLAN / MQTT an meinem FHEM berry hängt und über die Modbus slave implementierung / RS232 Modbus Adapter dem Inverter die relevanten Register zur Verfügung stellt. Ad relevante Register - hier kommt dann ggF der trace dann ins Spiel

Viele Grüße
Michael (HoizMichl)

[bertl]

Hallo Michael,

ich habe einen Siemens AMIS Multifunktionszähler TD3511 verbaut, welcher mit einem AES Code verschlüsselt ist.
Diesen Code bekommt man zwar von der Netz OÖ, aber leider verarbeitet das OBIS-Modul noch keine AES Verschlüsselungen.
Mein Raspi befindet sich auch im Schaltschrank, somit könnte ich die optische Schnittstelle des Zählers einfach per USB an den Raspi hängen.
Aber leider gibt es (soweit mir bekannt ist) in FHEM noch kein Modul, welches AES verschlüsselte OBIS Zählerdaten einbindet.

Dann gäbe es zwar noch den AMIS Leser - https://www.mitterbaur.at/amis-leser.html, welcher das alles könnte, dieser funktioniert aber nur über WLAN.

Oder weißt du, wie ich die es anstellen muss, um die OBIS verschlüsselten Daten zu dekodieren?

Für den DTSU müssen wir aber an der physischen Schnitte tracen, wo der DTSU angeschlossen ist.

Da kann ich mich mittels USR-TCP232-304 (RS485-Serial to TCPIP-Ethernet) reinhängen. qModMaster habe ich auch.
Du musst mir nur sagen, wie ich alles einstellen muss, um passend zu tracen.

Gruß, Robert

[miguelito]

Hallo Bertl,

Der Siemens hat eine optische Schnittstelle habe ich gesehen. Habe ich keine Erfahrung, trotzdem M-Bus was ich weiß.
Ich habe noch kein FHEM Modul programmiert bis dato - aber das kommt sicher auch noch: Möchte ja meine Wallbox gemäß Überschuss steuern und diverse andere Geräte im Haushalt automatisieren - z.B. start Waschmaschine über Relais parallel zum "Start" Knopf der Waschmaschine etc.

Habe den Smartmeter einfach in python (am Raspi naheliegend  ) programmiert. Bei python haste halt alle libraries z.B. für das deciphern des verschlüsselten Telegramms vom smartmeter fertig verfügbar. Weiß nicht, wie das bei FHEM / perl auf dem Berry ist...
Aber ich denke mit dem Smartmeterthema entfernen wir uns hier im Thread zu weit vom Thema sun2000. Das sollte man ggF wo anders vertiefen.

Btw, weil vorher im Thread das Thema Wallbox fiel: Habe mir die Heidelberg WB mit Modbus Schnittstelle geholt und über das wbec Projekt über WLAN / MQTT in FHEM eingebunden. Da brauchte ich noch nicht mal selber was programmieren. Die Box kostet 250.- wovon ich mir 125 von der Förderung zurück geholt habe. Kann das Teil schwer empfehlen: Qualität ist top. Die haben offenbar einen Generationenwechsel und schmeißen die alten Teile günstigst raus. Nehme an, weil die wenigsten mit dem Modbusinterface was anfangen können, bzw eine Integration out of the box nicht so einfach ist. Im Gegensatz zu z.B. go-e wo das Teil schon eine WLAN Schnitte mit http API oder gar OCPP oder ähnlichem anbietet..

[horchundkuck]

Dank eurer vielen Arbeit, Zeit, Hilfen, Beiträge, Links, Wiki's usw., die ich aufmerksam lese, konnte ich erfolgreich unsere PV-Anlage in das seit über 10 Jahren genutzte FHEM (raspberry) einbinden, anpassen und mit je 2 Devices auslesen (WR-WLAN) und steuern (Dongle-WLAN). Das wäre ohne euch nicht möglich gewesen. Herzlichen Dank dafür!

Die gerade erzeugte PV-Leistung pro String konnte ich in den Modbus Interface Definitionen allerdings nicht finden. Diese berechne ich daher für meine 2 Strings (Süd & West) im userReading wie folgt:

Code Auswählen Erweitern

attr SUN2000 userReadings\
WR_Leistung_String1_W:(WR_Spannung_String1|WR_Strom_String1).* {\
    my $leistungmom = ReadingsNum($NAME,"WR_Spannung_String1","0") * ReadingsNum($NAME,"WR_Strom_String1","0");;\
        return round($leistungmom,0);;\
},\
WR_Leistung_String2_W:(WR_Spannung_String2|WR_Strom_String2).* {\
    my $leistungmom = ReadingsNum($NAME,"WR_Spannung_String2","0") * ReadingsNum($NAME,"WR_Strom_String2","0");;\
        return round($leistungmom,0);;\
}
Die Summe der beiden Strings, WR_Leistung_String1_W (Spannung [h32016] * Strom [h32017]) und WR_Leistung_String2_W (h32018 * h32019), entspricht allerdings nie der ausgelesenen Gesamteingangsleistung 'WR_Leistung_EingangSolar_W' (h32064).
Die Differenz variiert dabei, je nach Sonneneinstrahlung und liegt auch mal im 3-stelligen Bereich.

Grundsätzlich würde mir auch der jeweilige prozentuale Anteil an der Gesamterzeugung reichen. Das ist auch so möglich:

Code Auswählen Erweitern

WR_Leistung_String2:(WR_Spannung_String1|WR_Strom_String1|WR_Spannung_String2|WR_Strom_String2).* {\
    my $leistung1 = ReadingsNum($NAME,"WR_Spannung_String1","0") * ReadingsNum($NAME,"WR_Strom_String1","0");;\
my $leistung2 = ReadingsNum($NAME,"WR_Spannung_String2","0") * ReadingsNum($NAME,"WR_Strom_String2","0");;\
if (my $gesamtleistung = $leistung1 + $leistung2) {\
        return round($leistung2 * 100 / $gesamtleistung,1);;\
    }\
    else {return 0;;}\
}

Aber den Grund für die Differenz würde ich schon verstehen wollen. Woran liegt das? Blindleistung/Wirkleistung/erzeugte Leistung/nutzbare Leistung/Denkfehler/Rechenfehler ...?

[bertl]

Hallo horchundkuck,

also bei mir passt die Berechnung zum  Werte von 'WR_Leistung_EingangSolar_W' auf 4 Watt genau.
Falls du meine Modbus-Definition verwendet hast, ist bei diesen 5 Werten ein Polldelay von x180 hinterlegt, da ich diese Werte nicht verwende.
Somit kann es durchaus zu Inkonsistenzen führen, wenn der eine Wert noch alt ist und der andere schon neu.

Lösche mal das Polldelay aus Definition bei diesen 5 Werten und prüfe erneut, ob diese dann passen.

Falls nicht, kann ich dir auch nicht weiterhelfen!

Gruß, Robert