Deye SUN-12K-SG04LP3 mit Modbus auslesen

[Gisbert]

Wenn du das auf einem ESP realisieren möchtest, gibt es doch schon dieses Projekt:
Deye ESP bridge
Da brauchste das Rad nicht neu zu erfinden 

Hallo,
gibt es irgendwo eine Bezugsquelle für die Platine, oder alternativ einen Datensatz bzw. Datei, damit man die Platine selbst bestellen kann?

Viele Grüße Gisbert

[Nobbynews]

oder alternativ einen Datensatz bzw. Datei, damit man die Platine selbst bestellen kann?

Auf github gibt es doch ein Verzeichnis 'gerber'.
Das sollte das Gesuchte doch sein.

[Gisbert]

Hallo zusammen,
in der Zwischenzeit hatte ich den Gerberfile gefunden und direkt geordert. Da die Mindestbestellanzahl 5 Stück beträgt, ich aber max. 3 Stück benötige - falls überhaupt -, könnte ich demnach 2 Stück abgeben gegen Portoersatz. Bei Interesse bitte melden. Die Lieferzeit beträgt vermutlich 14 Tage.
Viele Grüße Gisbert

[Jojo11]

Wenn du das auf einem ESP realisieren möchtest, gibt es doch schon dieses Projekt:
Deye ESP bridge
Da brauchste das Rad nicht neu zu erfinden 

interessant, das kannte ich noch nicht... Allerdings ziemlich aufwändig da eine eigene Platine notwendig ist
Ich erfinde auch nicht neu, ich muss ausschließlich  eine JSON Config anpassen damit es läuft. Das Projekt läuft bereits mit unterschiedlichen Wechselrichtern bereits

Was die Platine macht, kannst du auch selber verdrahten. Wenn du dein File vervollständigen möchtest, lohnt sicher ein Blick auf dieses Projekt. Die Register sollten ziemlich vollständig implementiert sein soweit ich das verfolgt habe. Ich persönlich sehe den Mehrwert im Vergleich nicht und bin selber ohnehin nicht an einer drahtlosen Lösung interessiert.

[Manfi]

Habe seit einigen Tagen meinen 12K in Betrieb und habe mir nach Muster von mfischer-ffb ein FHEM device aufgesetzt. Ich bekomme auch Daten jedoch gibt es sporadisch Fehlermeldungen im Log:

Code Auswählen Erweitern

2023.08.08 15:06:37 3: Modbus_Deye: Timeout waiting for a modbus response, current frame / read buffer: 0103020000, id 1, fCode 3,
request: id 1, read fc 3 h679, len 1, master device Deye, reading PV2_I (getUpdate for PV2_I len 1), queued 7.62 secs ago, sent 3.00 secs ago, error: Invalid checksum 0000 received. Calculated a131
2023.08.08 15:22:18 3: Modbus_Deye: Timeout waiting for a modbus response, read buffer empty,
request: id 1, read fc 3 h522, len 2, master device Deye, reading Netzbezug_Kwh (getUpdate for Netzbezug_Kwh len 2), queued 3.90 secs ago, sent 3.00 secs ago
2023.08.08 15:24:18 3: Modbus_Deye: Timeout waiting for a modbus response, read buffer empty,
request: id 1, read fc 3 h518, len 2, master device Deye, reading Akku_Entladen_kWh (getUpdate for Akku_Entladen_kWh len 2), queued 3.46 secs ago, sent 3.00 secs ago
2023.08.08 15:26:32 3: Modbus_Deye: Timeout waiting for a modbus response, read buffer empty,
request: id 1, read fc 3 h516, len 2, master device Deye, reading Akku_Laden_kWh (getUpdate for Akku_Laden_kWh len 2), queued 3.32 secs ago, sent 3.00 secs ago
woran kann das liegen?

MfG

Manfi

[Manfi]

Um mir Einiges an Verkabelung zu sparen, habe ich jetzt die Kommunikation auf eine Serial-TCP Bridge mit ESP-01 (Tasmota) und RS485-TTL Adapter umgestellt. Es kommen zwar immer noch sporadisch timeouts, aber es läuft soweit. Deye is auf Slave Addresse 01 eingestellt. Spannungsversorgung von den RSD (12V) Klemmen im WR

Du darfst diesen Dateianhang nicht ansehen.

[Gisbert]

Wenn du das auf einem ESP realisieren möchtest, gibt es doch schon dieses Projekt:
Deye ESP bridge
Da brauchste das Rad nicht neu zu erfinden 

Hallo zusammen,

ich hab das oben zitierte Projekt umgesetzt. Ich kann damit sowohl den DEYE als auch den Akku (mit PACE-BMS) per MQTT abfragen, bzw. erhalte Werte. Es läuft nahezu perfekt, lediglich Fhem macht Schwierigkeiten, wenn ich neue Topics subskribiere. Ich benutze noch die alte Methode mit externem MQTT Broker (im nächsten Winter versuche ich die Umstellung auf MQTT2).

Viele Grüße Gisbert

[Jojo11]

Hallo zusammen,

hat zufällig schon jemand hier erfolgreich Register 146 (die time of use Tabelle) implementiert und beschrieben? Ich verstehe nicht wie ich die einzelnen Bits für die Wochentage unterscheiden muss 

schöne Grüße
Jojo

[HansiMaier2]

hat zufällig schon jemand hier erfolgreich Register 146 (die time of use Tabelle) implementiert und beschrieben? Ich verstehe nicht wie ich die einzelnen Bits für die Wochentage unterscheiden muss 

schöne Grüße
Jojo

Wochentage? Bei mir hat diese Time-of-use Tabelle 6 verschiedene Zeitbereiche EINES Tages.
Und da ich faul bin nutze ich nur den ersten davon, er geht von 00:00 bis 23:55.
Der zweite Zeitbereich von 23:55 bis 00:00, alle anderen von 00:00 bis 00:00 damit sind die praktisch disabled.
Um 23:45 stelle ich die Uhr im Deye auf 23:30, um 00:00 wieder auf die aktuelle Zeit.
Damit nutzt der Deye immer nur den ersten Zeitbereich, in dessen SOC Setting schreibe ich jede Minute den gewünschten Wert.
Läuft prima.

[Jojo11]

Meine ich ja. Im Modbus-Doc von Deye steht monday, tuesday, ... - keine Ahnung was die sich dabei gedacht haben wie man das nutzt.
Mir geht es auch nicht darum, wie man das am Deye am besten einstellt (da nutze ich ohnehin identische Werte in allen Intervallen), sondern wie ich das hier mit dem Modbus-Modul in FHEM richtig auslese und beschreibe 
Hast Du das schon umgesetzt?

[HansiMaier2]

Nee, lese hiermit wg. Deye, bin aber mit Node-Red unterwegs.
Mit dem Register 146 mach ich allerdings gar nix.
OK: bisher noch keinen Zweirichtungszähler, also darf ich ohnehin noch nicht einspeisen.
Testweise hatte ich es mal an, lief problemlos ohne 146er-settings.

Aus der Beschreibung des 146er Registers werde ich auch nicht schlau, ich sehe auch keinen Use Case dahinter, nur an bestimmten Wochentagen einspeisen zu wollen.
Liest aber sich fast so, als könne man hier definieren, ob (für Peak shaving / valley filling) hier auch die Batterieenergie genutzt werden soll. Will ich eh nicht, möchte nur Solar-Überschuß einspeisen.

[Jojo11]

Ok, wenn jemand das schon umgesetzt hat, bin für Hinweise dankbar

[Gisbert]

Ok, wenn jemand das schon umgesetzt hat, bin für Hinweise dankbar

Wie wäre es hiermit?

Viele Grüße Gisbert

[Jojo11]

Habe es zwischenzeitliche hinbekommen. Denkfehler meinerseits  Die Endzeit vom Intervall n ist die Startzeit vom Intervall n+1. Ist im Deye auch so. Hatte ich übersehen.
WLAN (und somit ESP) versuche ich nach Möglichkeit zu vermeiden. Setze das lieber direkt in fhem um 

[Marlon]

In der Deye-Registerbeschreibung gibt es in der "5.3.03battery read only area" ja auch Daten für die Batterie ab Register 500.
Hat es schon jemand geschafft, auf diese Daten zuzugreifen, denn ab Register 500 gibt es ja die eigentlichen Deye-Daten mit allen Messwerten in der "5.2.03Read-only real-time attribute area."
Ich habe den Raspi zum Auslesen an die RS485-Buchse des Deye angeschlossen und kann den Deye auch immer nur unter Modbus-ID 1 ansprechen, egal welche Adresse im Deye eingestellt ist. Eine andere ID zum Zugriff auf die Batteriedaten ist daher auch keine Option. Möglicherweise bezieht sich diese Einstelladresse nur auf den Modbus am BMS-Anschluss.