f-zappa

Die batteriebezogenen Features stehen zwar noch nicht in der API-Dokumentation, aber im MQTT sind sie ja zu finden: warp3/2auT/power_manager/config {"enabled":true,"phase_switching_mode":0,"excess_charging_enable":true,"default_mode":2,"meter_slot_grid_power":1,"meter_slot_battery_power":2,"battery_mode":1,"battery_inverted":false,"battery_deadzone":100,"target_power_from_grid":-50,"guaranteed_power":1380,"cloud_filter_mode":2} Was es anscheinend (noch) nicht gibt: eine Möglichkeit, die Speicherpriorität zur Laufzeit umzuschalten. Für den Lademodus (PV, schnell, min+PV, aus) gibt es ja dieses Topic: warp3/2auT/power_manager/charge_mode {"mode":1} Könnte man da analog ein battery_mode (und battery_mode_update) einrichten? Oder wird das prinzipbedingt nie ohne Reboot der Wallbox gehen?

Wir haben einen Nissan Ariya. Tolles Auto, aber das Ladelimit gibt es leider nicht :(

Die 2.3.0-6630b9e7 habe ich jetzt längere Zeit getestet - das PV-Überschussladen funktioniert damit prima! Ein großes Dankeschön dafür, dass ihr auch die WR-Konfiguration abseits von SunSpec so schnell möglich gemacht habt! Ich komme dadurch inzwischen ohne EVCC aus und habe nur ein paar Einstellmöglichkeiten in Home Assistant abgebildet. Das ist prima, weil es die Komplexität verringert und wir im Alltag mit einer einzelnen Bedienoberfläche auskommen. Gelegentlich kommt es übrigens vor, dass bei geringer werdendem PV-Ertrag nicht die Wallbox drosselt, sondern der Akku entsprechend ausgleicht. Die Wallbox sieht in diesem Moment eben nur, dass am Hausanschluss (fast) kein Strom fließt. Da ich für das Haus nur ~7kWh habe, sind die entsprechend schnell leer. Eine Unterstützung für Batteriespeicher wäre daher tatsächlich noch eine feine Sache.

👍 Das sieht jetzt tatsächlich sehr viel besser aus - abgesehen von den 5Hz, die da immer noch stehen :) Die anderen Werte stimmen mit denen in der Sungrow-GUI überein. Sind die Abfrageintervalle eigentlich für alle Daten identisch? Ansonsten könnte man das für die Energiewerte sicher auch reduzieren, so schnell ändern sich diese Werte ja nicht. Da jetzt aber eh nur noch vier Register abgefragt werden, ist das im Grunde auch nicht wichtig. Sobald man mit der Speicher-Vorlage irgendwann etwas machen kann, müssten aber mehr als zwei Zähler erlaubt werden :)

Log habe ich per PN geschickt.

Was mir bisher aufgefallen ist: - "Wirk­energie (Ein­speisung)" gibt nicht die Einspeisung an (13046), sondern die gesamt aus PV erzeugte Menge (13003) - die Frequenz wird falsch umgerechnet, bei mir steht da jetzt 5Hz - wichtigster Punkt: woher kommt eigentlich der "Leistung"-Wert? Nach meinem Verständnis müsste das eigentlich (13010) sein, aber die Werte weichen dort krass von dem ab, was ich zB in Homeassistant aus 13010 ziehe.

Darauf muss man erst mal kommen...

Ich habe aber einen WiNet-S - Hypothese leider falsifiziert. Dazu übrigens folgende Anmerkung: Der SH10RT (vermutlich auch weitere Modelle) verfügt mit angebautem WiNet-S Modul über mehrere LAN-Ports. Für den Modbus-Zugriff sollte der hintere Port direkt am WR verwendet werden, über den am WiNet-S angebauten Port sowie auch über WLAN kommen nicht alle Modbus-Register. Ich habe bisher nichts darüber gesagt, um es nicht noch komplizierter zu machen, habe aber bei den bisherigen Tests regelmäßig alle drei IPs (WR nativ, WiNet-S LAN, WiNet-S WLAN) getestet zzgl Proxy. Details und Bildchen dazu gibt's hier: https://github.com/mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant Natürlich ist es das, was ich möchte. Dh man braucht den Wert, der am Hausübergabepunkt gemessen wird (sprich: "Export Power", Register 13010). Bingo, zu mindestens kommen hier Werte! Ich werde das mal mit den Readings vergleichen, die der WR auf seiner GUI ausgibt, um die Zuordnung zu kontrollieren.

Nichts leichter als das, dazu muss ich ja nur den modbusproxy-Container kurz stoppen. Allerdings kommt leider der gleiche Effekt: Starting scan Resolving 10.3.7.3 Connecting to 10.3.7.3:502 Using device address 247 Using base address 40000 Reading SunSpec ID Reading timed out, retrying Reading timed out, retrying Reading timed out, retrying Reading timed out, retrying Reading timed out, retrying Could not read SunSpec ID (error: TIMEOUT [228]) Disconnecting from 10.3.7.3 Scan finished Ich habe das mehrfach probiert, immer die gleiche Ausgabe. Genau so zuverlässig kommt aber auf dem Gerät 1 immer das Modell 101 (was mir ja nix bringt). Da wird es zwischen meinem Setup und dem des anderen Kunden wohl irgendeinen Unterschied geben - andere HW/FW ist natürlich möglich, aber vielleicht halt auch ein anders angebundenes Smartmeter, so dass der WR wie von mir oben schon spekuliert einfach als Bridge fungiert, was er mit einem anders angebundenen Meter nicht kann?

Ich habe es schon fast befürchtet. Kann man evtl in die Firmware einbauen, dass man das fragliche Modbus-Register von Hand einträgt? Es ist ja da, nur halt nicht via SunSpec. Und nur mal für mich zum Verständnis: sowohl der Zähler als auch die Batterie sind in meinem Fall wohl über CAN-Bus an den WR angeschlossen. Wenn das stattdessen über Modbus realisiert wäre, dann könnte ich durch den WR quasi "durchgucken" und auf einer anderen Slave-Adresse direkt die Register der angeschlossenen Geräte sehen?

Da wird zwar das Log überschaubarer, aber ansonsten passiert das gleiche: Starting scan Resolving 10.3.7.3 Connecting to 10.3.7.3:502 Using device address 247 Using base address 40000 Reading SunSpec ID Reading timed out, retrying Unknown read error, retrying Unknown read error, retrying Unknown read error, retrying Unknown read error, retrying Could not read SunSpec ID (error: CONNECTION_LOST [229]) Disconnecting from 10.3.7.3 Could not disconnect from 10.3.7.3 Scan finished

So richtig? Gibt keine Werte, auch über den Proxy nicht :(

Sorry, jetzt sind die versprochenen Logs auch da :) Wegen der Lesefehler habe ich vor einigen Tagen den Modbusproxy eingerichtet. Bislang hat nur Home Assistant die Daten abgegriffen, als der WARP und evcc dazu kamen, fingen die Probleme an (obwohl der WR angeblich drei konkurrierende Zugänge können soll, funktioniert aber wohl nicht).

Moin, ich habe zwei Logs erzeugt - beim ersten gehe ich direkt an den WR, beim zweiten über einen Modbusproxy. Letzteres sieht im Log ein wenig anders aus und der Scan dauert länger, aber führt letztlich zum gleichen Resultat. Evtl macht der Proxy einfach selbst ein paar zusätzliche Retries. Wenn die SunSpec-Implementierung von Sungrow Mist ist, würde ja evtl ein Firmwareupdate helfen. Das war auch bislang über die Sungrow-App möglich, wurde vor kurzem aber für Enduser aus der App entfernt 🤬. Das Update soll eine Fachfirma einspielen, aber da das hier zu großen Teilen ein DIY-Haushalt ist, habe ich gar keine. Widerliches Verhalten. Hallo Tinkerforge, bitte baut als nächstes einen Wechselrichter 🙃 sun-spec-scan-log-warp3-2auT-2024-04-23T16-50-54-463.proxy.txt sun-spec-scan-log-warp3-2auT-2024-04-23T16-49-25-592.txt

Ich mach dir mal einen Screenshot. Die Werte "Anzeigename, Geräteadresse, Eindeutige ID" werden vom Scan ausgelesen, aber das scheint mir nur zu Anzeigezwecken zu dienen: Die Musik spielt wohl bei "Modell", "Geräteadresse" und "Modellinstanz". Da kannst du aber nicht Hersteller/Typ auswählen sondern die nach SunSpec definierten Datenmodelle. Eigentlich ist es ja auch Sinn des Standards, dass er herstellerübergreifend funktioniert, aber irgendwas passt hier noch nicht.