Deye SUN-12K-SG04LP3 mit Modbus auslesen

Begonnen von mfischer-ffb, 09 April 2023, 22:18:26

Vorheriges Thema - Nächstes Thema

Jojo11

Die Daten konnte ich auch noch nicht abfragen. Ich lese mein Seplos BMS aber direkt aus.

HansiMaier2

Ich lese über Node-Red bspw. Register 500 (Health) mit Modbus_Flex-Getter und den Argumenten
msg.payload = { value: 2, 'fc': 3, 'unitid': 1, 'address': 500, 'quantity': 1 } ;

Gisbert

Hallo zusammen,

ich wollte mal meine Erkenntnisse hier kundtun.

Ich nutze eine Installation, die von bagges auf GitHub (https://github.com/bagges/deye-esp32-bridge) veröffentlicht wurde, allerdings ohne Akku (davor hatte ich einen - und demnächst wieder einen). Da ich das Board also schon hatte, habe ich es weiterbenutzt. Im Deye hängt das Board am BMS-Ausgang.

Die genutzte Firmware ist ESPHome, was anscheinend eng mit Home Assistant verbandelt ist, weshalb ich mich mit letzterem auseinandergesetzt habe. Mein Ziel war es den Deye nicht nur auszulesen sondern auch schreibend darauf zuzugreifen. Die Motivation hierfür war, dass der Deye einen vglw. hohen Standy-Verbrauch hat, was unschön ist, wenn keine PV-Leistung (nachts) vorhanden ist und der Akku leer ist (also nachts im Winter). Wenn man auf "No Batt" umstellt, dann braucht der Deye statt 70~80 W nur 20 W. Das Schreiben wollte ich mit Home Assistant machen, aber ich habe eine viel schönere Lösung gefunden, die ohne Home Assistant auskommt und sehr gut in Fhem funktioniert.

1. Änderung: MQTT im ESPHome-Code aufgenommen
2. Änderung: Schreibbefehle im MQTT-Part aufgenommen (Publishen vom ESP32 aus geht auch)
mqtt:
  broker: !secret my_broker
  port: !secret my_port
  topic_prefix: "/DEYE"
  username: !secret my_username
  password: !secret my_password
  on_message:
    - topic: /DEYE/Batt/off
      then:
        - select.set:
            id: ${device_type}_Battery_Mode
            option: "No Batt"
        - mqtt.publish:
            topic: /DEYE/Batt/state
            payload: "Battery is OFF!"         
    - topic: /DEYE/Batt/on
      then:
        - select.set:
            id: ${device_type}_Battery_Mode
            option: "Use Batt V"
        - mqtt.publish:
            topic: /DEYE/Batt/state
            payload: "Battery is ON!"
3. Änderung: Passendes Register ergänzt
select:
#Register 111
#https://www.akkudoktor.net/forum/postid/169630/
#https://www.akkudoktor.net/forum/deye-wechselrichter/deye-nachts-ausschalten-wenn-akku-leer-ist-haesphome-ha-automatisierungen/paged/2/
#https://dy-support.org/community/allgemeine-fragen/idee-auto-shutdown-des-wr-wenn-battery-leer-und-kein-pv-bezug/
  - platform: modbus_controller
    optimistic: true
    use_write_multiple: true 
    modbus_controller_id: ${modbus_controller_id}
    id: ${device_type}_Battery_Mode
    name: "${device_type}-battery-mode"
    address: 111
    value_type: U_WORD
    optionsmap:
      "Use Batt V": 0
      "Use Batt %": 1
      "No Batt": 2

Hinweise:
Wenn man "Use Batt V" wählt, dann geht der Deye von einer Blei-Batterie aus. Deshalb muss man sich ggf. noch mit dem folgenden Register beschäftigen:
#Register 98: 1=Lithium, 0=Lead
#https://www.akkudoktor.net/forum/postid/169630/
  - platform: modbus_controller
    use_write_multiple: true
    modbus_controller_id: ${modbus_controller_id}
    name: ${device_type}-battery-typ
    register_type: holding
    address: 98
    bitmask: 1
    entity_category: config
    icon: "mdi:toggle-switch"

Wie oben im Code zu sehen ist, möchte ich von "Use Batt V" auf "No Batt" umstellen. Es geht, indem man das passende Topic zum ESP32 publisht, wobei der die Payload egal ist (ich sende eine "1"). Benutzung auf eigene Gefahr. Da ich derzeit keinen Akku dran hab, geht der Deye auf Störung, wenn ich "Use Batt V" einstelle.

Angehängt ist die gesamte yaml-Datei, die bei mir auf dem ESP32 läuft.

-----
Hallo HansiMaier2,
ZitatIch lese über Node-Red bspw. Register 500 (Health) mit Modbus_Flex-Getter und den Argumenten
msg.payload = { value: 2, 'fc': 3, 'unitid': 1, 'address': 500, 'quantity': 1 } ;
Kannst du hierzu mehr Informationen liefern? Ich würde es, wenn möglich im ESPHome-Code benutzen.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Tobias

auch den Deye kann man schon sauber mit meinem ModbusMQTTGateway auslesen und mit FHEM weitervearbeiten
https://github.com/tobiasfaust/SolaxModbusGateway/
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

peter.oehlmann@web.de

Hallo,
ich habe einen  deye-sun-5k-sg03lp1. Ich habe dank Eurer Vorarbeit am BMS Anschluss über die im Menu eingestellte Slave Adresse
Kommunikation mit dem Deye bekommen.  Es kommen soweit keine Fehlermeldungen , der Log läuft prima durch.
Aber leider sind alle Werte 0. Stelle ich eine andere Slave adresse ein hört die Kommunikation auf. Benutze ich einen anderen
Port geht auch nichts. Jetzt habe ich natürlich nur den einphasigen Deye , aber auch wenn die Modbusliste für diesen anders wäre,
müssten doch ein paar Werte kommen.
Firmware habe ich gerade vergeblich bei Deye gesucht. Muss man wohl anfragen.
Hat jemand die Kommunikation mit dem einphasigen Deye am laufen oder jemand eine Idee?
Gruß Peter


2024-03-18 19:12:27 ModbusAttr Mod_Deye WR_L2_W: 0
2024-03-18 19:12:27 ModbusAttr Mod_Deye WR_L3_W: 0
2024-03-18 19:12:27 ModbusAttr Mod_Deye PV1_W: 0
2024-03-18 19:12:27 ModbusAttr Mod_Deye PV2_W: 0
2024-03-18 19:12:27 ModbusAttr Mod_Deye PV1_V: 0
2024-03-18 19:12:28 ModbusAttr Mod_Deye PV1_A: 0
2024-03-18 19:12:28 ModbusAttr Mod_Deye PV2_V: 0
2024-03-18 19:12:28 ModbusAttr Mod_Deye PV2_A: 0
2024-03-18 19:12:29 ModbusAttr Mod_Deye Akku_Laden_kWh_Tag: 0
2024-03-18 19:12:29 ModbusAttr Mod_Deye Akku_Entladen_kWh_Tag: 0
2024-03-18 19:12:29 ModbusAttr Mod_Deye Akku_Laden_kWh: 0
2024-03-18 19:12:29 ModbusAttr Mod_Deye Akku_Entaden_kWh: 0
2024-03-18 19:12:29 ModbusAttr Mod_Deye Netzbezug_Kwh_Tag: 0
2024-03-18 19:12:29 ModbusAttr Mod_Deye Netzbezug_Kwh: 0
2024-03-18 19:12:29 ModbusAttr Mod_Deye PV_kWh_Tag: 0
2024-03-18 19:12:29 ModbusAttr Mod_Deye PV_kWh: 0
2024-03-18 19:12:29 ModbusAttr Mod_Deye Temp_DC: -100.0
2024-03-18 19:12:29 ModbusAttr Mod_Deye Temp_AC: -100.0
2024-03-18 19:12:30 ModbusAttr Mod_Deye Akku_V: 0.0
2024-03-18 19:12:30 ModbusAttr Mod_Deye Akku_SOC: 0
2024-03-18 19:12:30 ModbusAttr Mod_Deye Akku_A: 0
2024-03-18 19:12:30 ModbusAttr Mod_Deye L1: 0.0
2024-03-18 19:12:30 ModbusAttr Mod_Deye L2: 0.0
2024-03-18 19:12:30 ModbusAttr Mod_Deye L3: 0.0
2024-03-18 19:12:30 ModbusAttr Mod_Deye Netzfrequenz: 0.00
2024-03-18 19:12:30 ModbusAttr Mod_Deye Netzbezug_W: 0
2024-03-18 19:12:30 ModbusAttr Mod_Deye WR_L1_A: 0
2024-03-18 19:12:30 ModbusAttr Mod_Deye WR_L2_A: 0
2024-03-18 19:12:30 ModbusAttr Mod_Deye WR_L3_A: 0
2024-03-18 19:12:30 ModbusAttr Mod_Deye WR_L1_W: 0
2024-03-18 19:12:30 ModbusAttr Mod_Deye WR_L2_W: 0
2024-03-18 19:12:30 ModbusAttr Mod_Deye WR_L3_W: 0
2024-03-18 19:12:30 ModbusAttr Mod_Deye PV1_W: 0
2024-03-18 19:12:30 ModbusAttr Mod_Deye PV2_W: 0
2024-03-18 19:12:30 ModbusAttr Mod_Deye PV1_V: 0
2024-03-18 19:12:31 ModbusAttr Mod_Deye PV1_A: 0
2024-03-18 19:12:31 ModbusAttr Mod_Deye PV2_V: 0
2024-03-18 19:12:31 ModbusAttr Mod_Deye PV2_A: 0
2024-03-18 19:12:32 ModbusAttr Mod_Deye Akku_Laden_kWh_Tag: 0
2024-03-18 19:12:32 ModbusAttr Mod_Deye Akku_Entladen_kWh_Tag: 0
2024-03-18 19:12:32 ModbusAttr Mod_Deye Akku_Laden_kWh: 0
2024-03-18 19:12:32 ModbusAttr Mod_Deye Akku_Entaden_kWh: 0
2024-03-18 19:12:32 ModbusAttr Mod_Deye Netzbezug_Kwh_Tag: 0
2024-03-18 19:12:32 ModbusAttr Mod_Deye Netzbezug_Kwh: 0
2024-03-18 19:12:32 ModbusAttr Mod_Deye PV_kWh_Tag: 0
2024-03-18 19:12:32 ModbusAttr Mod_Deye PV_kWh: 0

HansiMaier2

Zitat von: peter.oehlmann@web.de am 18 März 2024, 19:16:57Ich habe dank Eurer Vorarbeit am BMS Anschluss über die im Menu eingestellte Slave Adresse
Kommunikation mit dem Deye bekommen. 

Wieso BMS Anschluß?
Für Modbus solltest Du an den Modbus-Anschluß.

Marlon

  • Mein FHEM-Raspi hängt auch am Modbus-Anschluss und und ich spreche den Deye über Modbus-ID 1 an. Nur diese ID hat bei mir funktioniert. Andere nutzen erfolgreich den BMS-Anschluss. Wenn man das BMS kommunikativ mit dem Deye koppelt, ist der BMS-Anschluss allerdings normalerweise dafür belegt.
  • Den Deye kann man auch nativ über FHEM Ein- und Ausschalten. Dafür ist kein anderes Modul nötig als zum Lesen. Ich wollte das allerdings nicht zeitgesteuert machen, sondern abhängig davon, wann mein Fronius PV-Wechselrichter genug PV-Leistung liefert, damit mehr als ca. 150 W eingespeist werden. Die Daten liegen bei mir allerdings nur auf der CCU3 vor und die müssten dann erst zum Raspi übertragen werden. Bisher habe ich nur die Übertragung von FHEM zur CCU3 realisiert. Hat jemand einen Tipp, wie der umgekehrte Weg am sinnvollsten zu realisieren ist?

peter.oehlmann@web.de

Ja , am BMS Anschluss. Der SUN-5K-SG03LP1-EU hat keinen Anschluss mit ModeBus. Am Port des BMS sind 1,2 und 7,8 für RS485
Kommunikation. Kommunikation ist da. Man sieht am Dongle RX und TX , wenn man eine andere Slave Adresse am Umrichter einstellt
endet die Kommunikation , zieht man das in FHEM nach legt die Kommunikation wieder los. Habe mal verbose5 eingestellt und sehe
folgendes:
request: id 1, read fc 3 h514, len 4, master device Mod_Deye, reading Akku_Laden_kWh_Tag (getUpdate for combined h514 len 1 Akku_Laden_kWh_Tag with h515 len 1 Akku_Entladen_kWh_Tag and h516 len 2 Akku_Laden_kWh)
2024.03.19 18:35:48 4: Mod_Deye: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h518, len 3, master device Mod_Deye, reading Akku_Entaden_kWh (getUpdate for combined h518 len 2 Akku_Entaden_kWh with h519 len 1 Akku_W and h520 len 1 Netzbezug_Kwh_Tag)
2024.03.19 18:35:48 4: Mod_Deye: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h522, len 2, master device Mod_Deye, reading Netzbezug_Kwh (getUpdate for Netzbezug_Kwh len 2)
2024.03.19 18:35:48 4: Mod_Deye: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h529, len 1, master device Mod_Deye, reading PV_kWh_Tag (getUpdate for PV_kWh_Tag len 1)
2024.03.19 18:35:48 4: Mod_Deye: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h534, len 2, master device Mod_Deye, reading PV_kWh (getUpdate for PV_kWh len 2)
2024.03.19 18:35:48 4: Mod_Deye: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h540, len 2, master device Mod_Deye, reading Temp_DC (getUpdate for combined h540 len 1 Temp_DC with h541 len 1 Temp_AC)
2024.03.19 18:35:48 4: Mod_Deye: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h587, len 5, master device Mod_Deye, reading Akku_V (getUpdate for combined h587 len 1 Akku_V with h588 len 1 Akku_SOC and h591 len 1 Akku_A)
2024.03.19 18:35:48 4: Mod_Deye: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h598, len 3, master device Mod_Deye, reading L1 (getUpdate for combined h598 len 1 L1 with h599 len 1 L2 and h600 len 1 L3)
2024.03.19 18:35:48 4: Mod_Deye: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h609, len 1, master device Mod_Deye, reading Netzfrequenz (getUpdate for Netzfrequenz len 1)
2024.03.19 18:35:48 4: Mod_Deye: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h625, len 1, master device Mod_Deye, reading Netzbezug_W (getUpdate for Netzbezug_W len 1)
2024.03.19 18:35:48 4: Mod_Deye: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h630, len 5, master device Mod_Deye, reading WR_L1_A (getUpdate for combined h630 len 1 WR_L1_A with h631 len 1 WR_L2_A and h632 len 1 WR_L3_A and h633 len 1 WR_L1_W and h634 len 1 WR_L2_W)
2024.03.19 18:35:48 4: Mod_Deye: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h635, len 1, master device Mod_Deye, reading WR_L3_W (getUpdate for WR_L3_W len 1)
2024.03.19 18:35:48 4: Mod_Deye: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 1, read fc 3 h672, len 5, master device Mod_Deye, reading PV1_W (getUpdate for combined h672 len 1 PV1_W with h673 len 1 PV2_W and h676 len


Irgend eine Idee? Fehlermeldungen sehe ich eigentlich keine. Wenn ich wüsste , wo man die neueste Firmware herbekommt würd ich das mal probieren


peter.oehlmann@web.de

So , ich habe es jetzt. Der einphasige Deye SUN-5K-SG03LP1-EU sendet seine Daten auf anderen Adressen.
Habe jetzt mal unten zu sehendes drin und bekomme Werte. Formatierung muss ich noch schauen.Für die Weitergabe
an meine Wago SPS benutze ich Notify`s. Für die ganzen Werte muss ich dann aber auch undendlich Notify anlegen.
Lese jetzt schon stundenlang, finde nix einfacheres. Weis da jemand eine Abkürzung?

[/define MF162_NF notify Mod_Deye:Akku_SOC:.* set MF162 $EVTPART1]




define Mod_Deye ModbusAttr 3 5
setuuid Mod_Deye 65f5bf0a-f33f-7006-d8fc-763ca0b46d122e1d
attr Mod_Deye IODev Modbus_Deye
attr Mod_Deye dev-h-combine 5
attr Mod_Deye dev-h-defPoll 1
attr Mod_Deye dev-h-defUnpack n
attr Mod_Deye obj-h108-expr $val * 0.1
attr Mod_Deye obj-h108-reading PV_kWh_Tag
attr Mod_Deye obj-h109-expr $val * 0.1
attr Mod_Deye obj-h109-format %.1f
attr Mod_Deye obj-h109-reading PV1_V
attr Mod_Deye obj-h110-reading PV1_A
attr Mod_Deye obj-h164-expr $val * 0.01
attr Mod_Deye obj-h164-format %.1f
attr Mod_Deye obj-h164-reading Inverter_Current_L1
attr Mod_Deye obj-h169-reading total_grid_power_W
attr Mod_Deye obj-h173-reading Inverter_L1_Power
attr Mod_Deye obj-h175-reading total_power_W
attr Mod_Deye obj-h183-expr $val * 0.01
attr Mod_Deye obj-h183-format %.1f
attr Mod_Deye obj-h183-reading Akku_V
attr Mod_Deye obj-h184-format %.1f
attr Mod_Deye obj-h184-reading Akku_SOC
attr Mod_Deye obj-h186-reading PV1_W
attr Mod_Deye obj-h190-expr $val * 0.01
attr Mod_Deye obj-h190-reading Akku_W
attr Mod_Deye obj-h191-expr $val * 0.01
attr Mod_Deye obj-h191-reading Akku_A
attr Mod_Deye obj-h192-expr $val * 0.01
attr Mod_Deye obj-h192-reading Netzfrequenz_Hz
attr Mod_Deye obj-h70-expr $val * 0.1
attr Mod_Deye obj-h70-reading Akku_Laden_kWh_Tag
attr Mod_Deye obj-h71-expr $val * 0.1
attr Mod_Deye obj-h71-reading Akku_Entladen_kWh_Tag
attr Mod_Deye obj-h72-expr $val * 0.1
attr Mod_Deye obj-h72-len 2
attr Mod_Deye obj-h72-reading Akku_total_charge_kWh
attr Mod_Deye obj-h74-expr $val * 0.1
attr Mod_Deye obj-h74-len 2
attr Mod_Deye obj-h74-reading Akku_total_discharge_kWh
attr Mod_Deye obj-h76-expr $val * 0.1
attr Mod_Deye obj-h76-reading Netzbezug_Kwh_Tag
attr Mod_Deye obj-h90-expr ($val -1000) * 0.1
attr Mod_Deye obj-h90-format %.1f
attr Mod_Deye obj-h90-reading Temp_DC
attr Mod_Deye obj-h91-expr ($val -1000) * 0.1
attr Mod_Deye obj-h91-format %.1f
attr Mod_Deye obj-h91-reading Temp_AC
attr Mod_Deye obj-h96-expr $val * 0.1
attr Mod_Deye obj-h96-len 2
attr Mod_Deye obj-h96-reading PV_kWh
attr Mod_Deye room DEYE
attr Mod_Deye stateFormat Inverter_L1_Power
 ]

Jojo11

Kannst du nicht einfach ein einziges notify nehmen, welches bei jedem Wert-Update auslöst? Im notify rufst du eine sub auf und da rein packst du alle Befehle, die zur Weitergabe notwendig sind. Gibst halt jedes Mal alle Werte weiter.