Erfahrungen mit der Anbindung von Huawei Wechselrichtern?

Begonnen von lingerb, 30 Oktober 2020, 20:02:56

Vorheriges Thema - Nächstes Thema

passibe

Selbst nicht, aber vielleicht mal im photovoltaikforum einen Thread starten oder den allgemeinen Huawei-Thread nutzen. Dort sind die meistens recht kompetent.

bertl

Zitat von: TheTrumpeter am 01 Juli 2024, 09:32:40mittlerweile habe ich ein "notify", das einen "nicht-normalen" WR-Status sofort meldet.
Um dem Fehler auf die Spur zu kommen, musst du die Alarme auswerten.

Sobald ein Alarm auftritt, bekomme ich eine Info über Telegram.
Die Auswertung habe ich wie folgt implementiert:

Zitat von: bertl am 16 Februar 2024, 12:53:15Hallo 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:

Was es zu bedenken gibt:
Wenn der Strom vom Wechselrichter weg ist, kann er dann noch die richtigen Stati und Alarme setzen?

Gruß, Robert

TheTrumpeter

Zitat von: bertl am 01 Juli 2024, 14:30:03
Zitatmittlerweile habe ich ein "notify", das einen "nicht-normalen" WR-Status sofort meldet.
Um dem Fehler auf die Spur zu kommen, musst du die Alarme auswerten.
Genau das hab' ich nun auch implementiert.

Zitat von: bertl am 01 Juli 2024, 14:30:03Sobald ein Alarm auftritt, bekomme ich eine Info über Telegram.
Die Auswertung habe ich wie folgt implementiert:
Tja, das muss ich wohl übersehen haben, denn dann hätte ich es nicht "nachimplementieren" müssen.

Zitat von: bertl am 01 Juli 2024, 14:30:03Was es zu bedenken gibt:
Wenn der Strom vom Wechselrichter weg ist, kann er dann noch die richtigen Stati und Alarme setzen?
Solange die DC-Seite zumindest ein bisschen Strom produziert, würd' ich sagen "ja".
Das erste Fehlerauftreten habe ich zwar erst nach ca. 30 Minuten gesehen, aber der "Device-Status" war da "Ausschaltfehler". (Habe damals nicht auf den Zeitstempel geschaut.)
Der 2. und 3. Fehler wurde dann aber durch den "Device-Status" getriggert sofort via Telegram gesendet.

Natürlich, in der Nacht wird's nicht gleich kommen, aber ich schätze, dass dann beim Einschalten der DC-Seite auch der entsprechende Status gemeldet würde.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

TheTrumpeter

So, mal ein Zwischenstand bzw. Übertrag aus dem PV-Forum:

Ich habe heute Früh die Gegenprobe gemacht und den FI-Schutzschalter händisch abgedreht. Das Fehlerbild vom/im Wechselrichter ist dann identisch zum bisher 3x beobachteten Verhalten kurz vor einem Abend-Gewitter.
Ursache für die Fehlermeldung scheint daher tatsächlich der ausgeschaltete FI zu sein und nicht umgekehrt.

Weiters haben wir im PV-Forum dann gemeinsam herausgefunden, dass ein etwaiger dem WR vorgeschalteter FI einen Fehlerstrom von mindestens 300 mA zulassen muss, wohl, weil der WR innerhalb seiner Spezifikation bis zu 299,99 mA Fehlerstrom erzeugt.
Bei mir hängt der WR allerdings hinter einem FI mit 30 mA.

Die Theorie ist nun also, dass der WR bei diesen speziellen Umweltbedingungen mehr als 30 mA Fehlerstrom verursacht und damit den FI zum Auslösen bringt.

Habe vorhin mit meinem Elektriker telefoniert, er wird das voraussichtlich übernächste Woche umbauen, sodass der WR vor dem FI hängt. (In Deutschland ist das lt. einer Aussage im PV-Forum wohl Vorschrift, in Österreich aber nicht.)
Ich hoffe, dass das Problem dann weg ist. (Urlaub steht an, die Gartenbewässerung hängt hinter demselben FI...)
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

edition

Guten Abend zusammen

Ich bin seit heute auch stolzer Besitzer einer PV-Anlage mit Huawei Wechselrichter. Ich habe den Beitrag schon im Vorfeld verfolgt und zum testen fhem auf einen Raspi installiert.
Wenn ich versuche, über den Port 6607 eine Verbindung herzustellen, bekomme ich die Fehlermeldung: Can't connect - Connection refused (111).
Wie kann ich prüfen, ob Modbus TCP korrekt aktiviert ist? Kann ich das überhaupt, oder kann das nur der Installateur?

Gruß
edition

cs-online

#200
...also mein WR hängt mit dem WLAN Dongle im heimischen WLAN und ist über den Port 502 erreichbar.

Definition mit

defmod Sun2000 ModbusAttr 1 10 IP:502 TCP
IP natürlich durch deine ersetzen...
Vielleicht probierst du es da mal mit. Hat dein Installateur denn den Modbus freigeschaltet ?

Grüße Christian
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266/32 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20+S26,Shelly1/2/2.5, Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV+Speicher, alles auf einem RPI und da geht noch mehr

edition

#201
Guten Morgen

Bei mir hängt der WR mit dem Dongle mittels LAN Kabel am WLAN Repeater. Mit der definition bekomme ich ein "opend".
Ob die Modbus richtig freigeschaltet haben, weiß ich eben nicht. Darum würde ich es gerne prüfen, bevor ich mir einen Wolf suche.

edition

edit:
Es hat ein bisschen gedauert, aber es scheint jetzt doch zu funktionieren.
Auf dem Testsystem läuft das 98_ModbusSUN2000WR.pm Modul von Phill. Über den Port 502 bekomme ich nun Werte. Ist also doch korrekt freigeschaltet. Auch die Anbindung an das SolarForecast Modul funktioniert. Ich lasse das mal ein paar Tage laufen, bevor ich es auf meinem Prduktivsystem einbinde.

rallye

Zitat von: bertl am 10 April 2024, 16:08:56
Zitat von: rallye am 06 April 2024, 09:46:34Wie stelle ich das fest (mit einfachen Mitteln, die ich als nicht-Solateur zur Verfügung habe)? Mein Solateur kommt am Montag vorbei um an meiner Heizung weiterzuarbeiten, da könnte ich ihn ggf. darauf ansprechen es zu enablen

Hallo Rallye,

anpingen (ping 192.168.57.20) kannst du den SDongleA, oder?

Folgende Einstellungen müssen durch den Installateur oder falls du auch Zugriff auf deine Analge hast gesetzt sein (siehe Anhang):
  Modbus TCP - Verbindung - Aktivieren (uneingeschränkt)
  RS485_1 - Baudrate: 9600, Protokolltyp: MODBUS, Komm.adresse: 1, RS485-Bus-Fraem-Erfassung: 1

Die Komm.adresse benötigst du für die Gerätedefinition (in meinem Falls ist diese 1 - siehe oben).
defmod Sun2000 ModbusAttr 0 10 192.168.57.20:502 TCPIn deinem Fall müsste die Komm.adresse auf 0 stehen.

Wenn du diese Details geprüft hast, und es funktioniert immer noch nicht, dann suchen wir weiter.

Schönen Tag
Robert

Danke!!!

Mein Solateur kam nicht, ich war auf Urlaub und jetzt habe ich ihn gebeten mir den Port 502 zu öffnen. Das scheint nun der Fall zu sein:
Internals:
   DEF        0 10 192.168.57.20:502 TCP
   DeviceName 192.168.57.20:502
   EXPECT     idle
   FD         71
   FUUID      661028c7-f33f-55a1-d3c2-d7baccca3cd818d8
   FVERSION   98_ModbusAttr.pm:0.277000/2023-06-23
   IODev      Sun2000
   Interval   10
   LASTOPEN   1723472634.56539
   MODBUSID   0
   MODE       master
   MODULEVERSION Modbus 4.5.6 - 7.11.2023
   NAME       Sun2000
   NOTIFYDEV  global
   NR         537
   NTFY_ORDER 50-Sun2000
   PARTIAL   
   PROTOCOL   TCP
   STATE      opened
   TCPConn    1
   TYPE       ModbusAttr
   devioLoglevel 3
   devioNoSTATE 1
   eventCount 10
   nextOpenDelay 60
   FRAME:
   READ:
   READINGS:
     2024-08-12 16:23:54   state           opened
   REMEMBER:
     lid        0
     lname      Sun2000
     lsend      1723472273.97158
   UPDATECACHE:
   defptr:
     Sun2000    0
   lastRead:
Attributes:
   room       Development
bzw
defmod Sun2000 ModbusAttr 0 10 192.168.57.20:502 TCP
attr Sun2000 room Development

setstate Sun2000 opened
setstate Sun2000 2024-08-12 16:23:54 state opened
Und anpingen kann ich den SDongle auch. Wie bekomme ich nun die Werte ausgelesen? Die abgekupferten attr haben mir bisher nicht weitergeholfen, deshalb hab ich sie wieder gelöscht.

Danke
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

bertl

Zitat von: rallye am 12 August 2024, 16:27:46Wie bekomme ich nun die Werte ausgelesen? Die abgekupferten attr haben mir bisher nicht weitergeholfen, deshalb hab ich sie wieder gelöscht.

Ohne den attr-Definitionen funktioniert das Modbus-Modul aber nicht.
Also die attr-Definitionen wieder erstellen und dann im Logfile checken was für Fehler kommen.

Hast du bzw. dein Installateur auch folgende Einstellungen gemacht und überprüft:
  Modbus TCP - Verbindung - Aktivieren (uneingeschränkt)
  RS485_1 - Baudrate: 9600, Protokolltyp: MODBUS, Komm.adresse: 0, RS485-Bus-Fraem-Erfassung: 1

Falls nämlich die Komm.adresse wie in deinem Fall nicht auf 0 steht, bekommst du keine Werte, obwohl dein 'state' auf 'opened' steht.

Schönen heißen Tag
Robert

rallye

Zitat von: bertl am 13 August 2024, 14:15:43Ohne den attr-Definitionen funktioniert das Modbus-Modul aber nicht.
Also die attr-Definitionen wieder erstellen und dann im Logfile checken was für Fehler kommen.
OK, hab ich erledigt. Das Ergebnis ist wie zuletzt ernüchternd - alles Null bzw leer. Im Log alle 10 Sekunden folgende Meldungen:
2024.08.13 18:32:45 3: 192.168.57.20:502 disconnected, waiting to reappear (Sun2000)
2024.08.13 18:32:45 4: IP: 192.168.57.20 -> 192.168.57.20
2024.08.13 18:32:45 3: 192.168.57.20:502 reappeared (Sun2000)
2024.08.13 18:32:45 4: Sun2000: UpdateTimer called from OpenCB with cmd start sets timer to call update function in 1.1 sec at 18:32:46.808, interval 10
2024.08.13 18:32:46 4: Sun2000: GetUpdate (V4.5.6 - 7.11.2023) called from Fhem internal timer
2024.08.13 18:32:46 4: Sun2000: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 10.0 sec at 18:32:56.809, interval 10
2024.08.13 18:32:46 4: Sun2000: CombineUpdateHash objHash keys before combine: h32114,h32080,h37113,h32016,h32106,h32064,h32078,h32017,h32086,h32087,h32089
2024.08.13 18:32:46 4: Sun2000: GetUpdate will now create requests for h32016 len 1 (PV1_voltage), h32017 len 1 (PV1_current), h32064 len 2 (Input_power), h32078 len 2 (Peak_active_power), h32080 len 2 (Active_power), h32086 len 1 (Efficiency), h32087 len 1 (Internal_temperature), h32089 len 1 (Device_status), h32106 len 2 (Accumulated_energy_yield), h32114 len 2 (Daily_energy_yield), h37113 len 2 (PM_active_power)
2024.08.13 18:32:46 4: Sun2000: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 0, read fc 3 h32016, len 1, tid 10, master device Sun2000, reading PV1_voltage (getUpdate for PV1_voltage len 1)
2024.08.13 18:32:46 4: Sun2000: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 0, read fc 3 h32017, len 1, tid 147, master device Sun2000, reading PV1_current (getUpdate for PV1_current len 1)
2024.08.13 18:32:46 4: Sun2000: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 0, read fc 3 h32064, len 2, tid 235, master device Sun2000, reading Input_power (getUpdate for Input_power len 2)
2024.08.13 18:32:46 4: Sun2000: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 0, read fc 3 h32078, len 2, tid 121, master device Sun2000, reading Peak_active_power (getUpdate for Peak_active_power len 2)
2024.08.13 18:32:46 4: Sun2000: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 0, read fc 3 h32080, len 2, tid 237, master device Sun2000, reading Active_power (getUpdate for Active_power len 2)
2024.08.13 18:32:46 4: Sun2000: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 0, read fc 3 h32086, len 1, tid 208, master device Sun2000, reading Efficiency (getUpdate for Efficiency len 1)
2024.08.13 18:32:46 4: Sun2000: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 0, read fc 3 h32087, len 1, tid 146, master device Sun2000, reading Internal_temperature (getUpdate for Internal_temperature len 1)
2024.08.13 18:32:46 4: Sun2000: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 0, read fc 3 h32089, len 1, tid 121, master device Sun2000, reading Device_status (getUpdate for Device_status len 1)
2024.08.13 18:32:46 4: Sun2000: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 0, read fc 3 h32106, len 2, tid 123, master device Sun2000, reading Accumulated_energy_yield (getUpdate for Accumulated_energy_yield len 2)
2024.08.13 18:32:46 4: Sun2000: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 0, read fc 3 h32114, len 2, tid 203, master device Sun2000, reading Daily_energy_yield (getUpdate for Daily_energy_yield len 2)
2024.08.13 18:32:46 4: Sun2000: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 0, read fc 3 h37113, len 2, tid 16, master device Sun2000, reading PM_active_power (getUpdate for PM_active_power len 2)
2024.08.13 18:32:46 4: Sun2000: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 11, sending 000a0000000600037d100001 via 192.168.57.20:502, read buffer empty,
request: id 0, read fc 3 h32016, len 1, tid 10, master device Sun2000, reading PV1_voltage (getUpdate for PV1_voltage len 1), queued 0.00 secs ago
2024.08.13 18:32:48 3: Sun2000: Timeout waiting for a modbus response, read buffer empty,
request: id 0, read fc 3 h32016, len 1, tid 10, master device Sun2000, reading PV1_voltage (getUpdate for PV1_voltage len 1), queued 2.00 secs ago, sent 2.00 secs ago
2024.08.13 18:32:48 4: Sun2000: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 10, sending 00930000000600037d110001 via 192.168.57.20:502, read buffer empty,
request: id 0, read fc 3 h32017, len 1, tid 147, master device Sun2000, reading PV1_current (getUpdate for PV1_current len 1), queued 2.00 secs ago
2024.08.13 18:32:50 3: Sun2000: Timeout waiting for a modbus response, read buffer empty,
request: id 0, read fc 3 h32017, len 1, tid 147, master device Sun2000, reading PV1_current (getUpdate for PV1_current len 1), queued 4.00 secs ago, sent 2.00 secs ago
2024.08.13 18:32:50 4: Sun2000: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 9, sending 00eb0000000600037d400002 via 192.168.57.20:502, read buffer empty,
request: id 0, read fc 3 h32064, len 2, tid 235, master device Sun2000, reading Input_power (getUpdate for Input_power len 2), queued 4.01 secs ago
2024.08.13 18:32:52 3: Sun2000: Timeout waiting for a modbus response, read buffer empty,
request: id 0, read fc 3 h32064, len 2, tid 235, master device Sun2000, reading Input_power (getUpdate for Input_power len 2), queued 6.01 secs ago, sent 2.00 secs ago
2024.08.13 18:32:52 4: Sun2000: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 8, sending 00790000000600037d4e0002 via 192.168.57.20:502, read buffer empty,
request: id 0, read fc 3 h32078, len 2, tid 121, master device Sun2000, reading Peak_active_power (getUpdate for Peak_active_power len 2), queued 6.01 secs ago
2024.08.13 18:32:54 3: Sun2000: Timeout waiting for a modbus response, read buffer empty,
request: id 0, read fc 3 h32078, len 2, tid 121, master device Sun2000, reading Peak_active_power (getUpdate for Peak_active_power len 2), queued 8.01 secs ago, sent 2.00 secs ago
2024.08.13 18:32:54 4: Sun2000: ProcessRequestQueue (V4.5.6 - 7.11.2023) qlen 7, sending 00ed0000000600037d500002 via 192.168.57.20:502, read buffer empty,
request: id 0, read fc 3 h32080, len 2, tid 237, master device Sun2000, reading Active_power (getUpdate for Active_power len 2), queued 8.01 secs ago

Zitat von: bertl am 13 August 2024, 14:15:43Hast du bzw. dein Installateur auch folgende Einstellungen gemacht und überprüft:
  Modbus TCP - Verbindung - Aktivieren (uneingeschränkt)
  RS485_1 - Baudrate: 9600, Protokolltyp: MODBUS, Komm.adresse: 0, RS485-Bus-Fraem-Erfassung: 1
Ob diese Einstellungen gemacht wurden kann ich nicht sagen. Explizit danach habe ich nicht gefragt das so einzurichten. Kann ich das selbst irgendwie überprüfen/einrichten oder muss ich dazu wieder meine Solateur bemühen? Ich habe nämlich zum ersten Mal über diese Einstellungen bzw. die Möglichkeit diese Einstellungen vorzunehmen gelesen. Gibt es sonst noch etwas worauf ich achten muß? (Ich bin ganz ehrlich: mit DOIF kenne ich mich aus, in dieser Ecke {Solar2000} weiss ich nicht ganz genau was ich tue :o )


Zitat von: bertl am 13 August 2024, 14:15:43Falls nämlich die Komm.adresse wie in deinem Fall nicht auf 0 steht, bekommst du keine Werte, obwohl dein 'state' auf 'opened' steht.
Wo genau steht diese ominöse Komm.adresse? Ich kann sie bei meinem "list" aber auch meiner "Raw Definition" nicht wirklich ausmachen.

Zitat von: bertl am 13 August 2024, 14:15:43Schönen heißen Tag

Danke, den habe ich genossen

Dir einen schönen angenehmen Abend - hoffentlich im Freien

Rallye
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

bertl

Zitat von: rallye am 13 August 2024, 18:51:26Wo genau steht diese ominöse Komm.adresse? Ich kann sie bei meinem "list" aber auch meiner "Raw Definition" nicht wirklich ausmachen.

Die Einstellungen der Komm.adresse sowie der Baudrate und des Protokolltyp werden direkt am Wechselrichter über die FusionSolar App vorgenommen.
Anleitungen wie man sich auf den Wechselrichter verbindet gibt es genug im Internet (z.B. FusionSolar App Quick Guide)
Dazu benötigst du aber das Installer-Kennwort/Passwort (probiere einfach mal das Initial-Kennwort laut Anleitung, vielleicht hat dein Installateur das nicht geändert).

Wenn du mit dem Wechselrichter als Installer verbunden bist, gehst du auf 'Einstellungen' -> 'Kommunikationskonfiguration' -> 'RS485' -> 'RS485_1'
Dort kannst du dann die Baudrate, den Protokolltyp und die Komm.adresse ändern.

Unter 'Einstellungen' -> 'Kommunikationskonfiguration' -> 'Dongle-Parametereinstellungen' -> 'Modbus TCP' -> 'Verbindung' wird Modbus TCP aktiviert.
Einfach 'Aktivieren (uneingeschränkt)' auswählen.

Je nach Firmware sehen die Menüs etwas unterschiedlich aus (meine Firmware des Wechselrichters: V100R001C00SPC165).

Dann solltest du auch Daten bekommen.

Gruß, Robert

maximalz

Hallo zusammen und vielen Dank für die Moduldefinition in den Anhängen der Posts.
Habt ihr schon mal überlegt, das Modul nach Github zu legen, so dass es versioniert wird und durch alle leicht ergänzbar ist?
THZ (403 SOL), OBIS (2x EDL21), SolarEdge (SE10k), Sun+Luna 2000

rallye

Zitat von: bertl am 14 August 2024, 16:09:31Die Einstellungen der Komm.adresse sowie der Baudrate und des Protokolltyp werden direkt am Wechselrichter über die FusionSolar App vorgenommen.
Anleitungen wie man sich auf den Wechselrichter verbindet gibt es genug im Internet (z.B. FusionSolar App Quick Guide)
Dazu benötigst du aber das Installer-Kennwort/Passwort (probiere einfach mal das Initial-Kennwort laut Anleitung, vielleicht hat dein Installateur das nicht geändert).

Wenn du mit dem Wechselrichter als Installer verbunden bist, gehst du auf 'Einstellungen' -> 'Kommunikationskonfiguration' -> 'RS485' -> 'RS485_1'
Dort kannst du dann die Baudrate, den Protokolltyp und die Komm.adresse ändern.

Unter 'Einstellungen' -> 'Kommunikationskonfiguration' -> 'Dongle-Parametereinstellungen' -> 'Modbus TCP' -> 'Verbindung' wird Modbus TCP aktiviert.
Einfach 'Aktivieren (uneingeschränkt)' auswählen.

Je nach Firmware sehen die Menüs etwas unterschiedlich aus (meine Firmware des Wechselrichters: V100R001C00SPC165).

Dann solltest du auch Daten bekommen.

Ich habe nun seit einiger Zeit alle Zugangsdaten von meinem Solateur erhalten und mir für https://intl.fusionsolar.huawei.com/ für meine Anlage einen Installer-Account angelegt. Die App SUN2000 kann ich mit meinem Wechselrichter auch verbinden, allerdings nur als Benutzer. Das Installer-Password das mir mein Solateur gegeben hat ist nicht korrekt, er selbst weiss es allerdings auch nicht mehr und aufgeschrieben hat er es auch nicht.
Nun habe ich doch einige Zugriffe auf meine Anlage und ich habe mir auch die von dir angeführte Doku angesehen. Dort steht auch drinnen, dass man die Anlage "resetten" kann un das PW für SUN2000 zurückzusetzen. Aber ich getraue mich ehrlich gesagt nicht drüber da ich nicht wirklich weiß was ich da tue und welche Auswirkungen es hat.

Ich habe in FusionSolar unter Überwachung->Dongle gesehen, dass man ein Passwort zurücksetzen kann. Allerdings weiss ich nicht um welches PW es sich hier handelt.

Um also weiter zu kommen würde ich bitte Unterstützung bzw. eine Anleitung benötigen. Weil "abschießen" will ich mir die Anlage nicht.

@Robert: könnten wir das evtl. bitte direkt machen (PM), da hier doch anlagesensitive Daten im Spiel sind und jeder Internetbenutzer mittels Google hier mitlesen könnte.

Danke

 Du darfst diesen Dateianhang nicht ansehen.
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

horchundkuck

#208
Ergänzung zum Mapping in der 98_ModbusSUN2000WR.pm

@passibe filtert 'BAT_Leistung_W' bekanntermaßen wie folgt, wenn die Batterie im Ruhezustand ist:

"h37001" => { expr    => 'my $newval = $val == 2147483647 ? 0 : $val; return $newval',
              len    => 2,
              reading => "BAT_Leistung_W",
              unpack  => "N!",
            }

Analog dazu kann auch 'BAT_Ladestand' richtig gemappt werden, wenn die Batterie im 'sleep_mode'ist (bei mir war der Anzeigewert dann 6554, und abhängige DOIFs reagierten falsch):

"h37004" =>  { expr => 'my $newval = $val == 65535 ? 0: sprintf( "%.0f", $val/10 ); return $newval', 
                len => 1,
            reading => "BAT_Ladestand",
            unpack => "n",
      },

So wird dann richtigerweise '0' angezeigt, und abhängige DOIFs arbeiten korrekt.
Du darfst diesen Dateianhang nicht ansehen.

rhoffm34

Hallo zusammen,

ich brauch Unterstützung bei den Begriffen.

Es gibt so viele Bezeichnungen die eigendlich klar sind, bei genauerer Betrachtung sind die Werte aber unplausibel, z.B.:

WR_Energie_Tag_kWh = Ertrag pro Tag? ==> heute 3,87 lt. FusionSolarApp 7,62

Statistics:

statWR_Gesamtertrag_kWhDay rechnet mit anhand von WR_Gesamtertrag_kWh einen Ertrag von 3,5 aus, also 0,37 weniger als WR_Energie_Tag_kWh. Hier vermute ich die Differenz aufgrund des Huawei Eigenverbrauch, aber ist das so?

Ich finde auch keinen Wert was im Haus direkt von der PV Energie verbraucht wird. Und mit meinem Halbwissen kann ich diesen Wert auhc nicht berechnen...

Kann jemand Licht ins Dunkle bringen?