Deye EV charger support (SUN-EVSE11K01-EU-AC)?

[trozman]

Firstly, kudos to this great integration.

I've noticed our local Deye supplier started to sell Deye EV chargers (SUN-EVSE11K01-EU-AC and SUN-EVSE22K01-EU-AC)

It looks like these chargers can be controlled from the inverter (via 'Smart Devices' menu).

Are there any plans to add entities related to EV charger to this integration?

[davidrapan]

Hi @trozman, unfortunately, this is currently almost impossible to do w/o updated Modbus documentation (if it uses it at all)..

[trozman]

Not sure if I understand. My inverter is 3 phase hybrid inverter and I use deye_hybrid.yaml in solarman integration. What am I missing?

[trozman]

I was wrong. My solarman integration uses deye_p3.yaml. The reason I thought it uses deye_hybrid.yaml is when I check solarman integration config page, it shows the latter:

Not sure why.

Nevertheless, I tried to add the following to the deye_p3.yaml:

#EV test
  - group: EV Charger
    items:
      - name: "EV Charge Control Power"
        l: 1
        class: "power"
        state_class: "measurement"
        uom: "W"
        rule: 1
        scale: 1
        registers: [0x02C5]
        icon: "mdi:car-electric"

It shows EV charger control power. If I understand correctly, this is not an actual charging power, only the allowed charging power by EV charger:

I can also set Max. charging power:

      - name: EV Max Charge power
        alt: EV Max Charge power
        platform: number
        class: "power"
        state_class: "measurement"
        uom: "W"
        scale: 1
        rule: 1
        registers: [0x0104]
        configurable:
          min: 0
          max: 22000
        range:
          min: 0
          max: 22000

[davidrapan]

Because Deye compatible devices undergo autodetection. 😉

[trozman]

Oh, that's really nice.

I was puzzled because UI didn't reflect which config file is used.

[davidrapan]

Yeah, I know.. maybe I'll add some config "overwrite" in future version. 😉

[trozman]

While waiting for Deye's support's answer about modbus registers for their EV charger, I managed to get some info (realtime charge power) directly from their local web interface. Maybe someone finds it useful:
https://blog.rozman.info/integrating-deye-ev-charger-to-home-assistant/

[DJm00n]

Thank you for the idea.
Here is package yaml for scrapping info from EVSE web interface without separate command line files:

deye_evse:
  command_line:
    - sensor:
        name: Deye EVSE Power
        unique_id: deye_evse_power
        command: |
          sh -c '
          DATA=$(curl -s -m 12 -u admin:admin http://192.168.88.38/status.html 2>/dev/null)
          if [ -z "$DATA" ]; then
            exit 1
          fi

          p1=$(echo "$DATA" | grep -oP "webdata_power1 = \"\\K[0-9]+")
          p2=$(echo "$DATA" | grep -oP "webdata_power2 = \"\\K[0-9]+")
          p3=$(echo "$DATA" | grep -oP "webdata_power3 = \"\\K[0-9]+")

          wm1=$(echo "$DATA" | grep -oP "webdata_wm1 = \"\\K[0-9]+")
          wm2=$(echo "$DATA" | grep -oP "webdata_wm2 = \"\\K[0-9]+")
          lora=$(echo "$DATA" | grep -oP "webdata_lora_rate = \"\\K[0-9]+")
          limit=$(echo "$DATA" | grep -oP "webdata_charge = \"\\K[0-9]+")

          sn=$(echo "$DATA" | grep -oP "webdata_sn = \"\\K[^\"]+" | head -1 | xargs)
          fw=$(echo "$DATA" | grep -oP "cover_ver = \"\\K[^\"]+" | head -1)
          mode=$(echo "$DATA" | grep -oP "cover_wmode = \"\\K[^\"]+" | head -1)
          ssid=$(echo "$DATA" | grep -oP "cover_sta_ssid = \"\\K[^\"]+" | head -1)
          ip=$(echo "$DATA" | grep -oP "cover_sta_ip = \"\\K[^\"]+" | head -1)
          mac=$(echo "$DATA" | grep -oP "cover_sta_mac = \"\\K[^\"]+" | head -1)

          printf "{\"total\":%d,\"l1\":%d,\"l2\":%d,\"l3\":%d,\"working_mode\":%d,\"wifi_mode\":%d,\"lora_channel\":%d,\"power_limit\":%d,\"serial\":\"%s\",\"firmware\":\"%s\",\"network_mode\":\"%s\",\"wifi_ssid\":\"%s\",\"ip\":\"%s\",\"mac\":\"%s\"}" \
              $((p1+p2+p3)) \
              "${p1:-0}" "${p2:-0}" "${p3:-0}" \
              "${wm2:-0}" "${wm1:-0}" "${lora:-0}" "${limit:-0}" \
              "${sn:-unknown}" "${fw:-unknown}" "${mode:-unknown}" "${ssid:-unknown}" "${ip:-unknown}" "${mac:-unknown}"
          '

        value_template: "{{ value_json.total | default(0) }}"
        json_attributes:
          - l1
          - l2
          - l3
          - working_mode
          - wifi_mode
          - lora_channel
          - power_limit
          - serial
          - firmware
          - network_mode
          - wifi_ssid
          - ip
          - mac
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        scan_interval: 10
        command_timeout: 15

  template:
    - binary_sensor:
        - name: Deye EVSE Available
          unique_id: deye_evse_available
          state: >
            {{ states('sensor.deye_evse_power') not in ['unavailable', 'unknown']
                and state_attr('sensor.deye_evse_power', 'power_limit') is not none }}
          delay_off:
            seconds: 30

    - number:
        - name: Deye EVSE Power Limit
          unique_id: deye_evse_power_limit
          unit_of_measurement: "W"
          min: 0
          max: 22000
          step: 1000
          availability: >
            {{ is_state('binary_sensor.deye_evse_available', 'on') }}
          state: >
            {{ state_attr('sensor.deye_evse_power', 'power_limit') | int(0) }}
          set_value:
            - action: script.deye_evse_set_power_limit
              data:
                power: "{{ value | int }}"

  script:
    deye_evse_set_power_limit:
      sequence:
        - action: rest_command.deye_evse_set_power_limit
          data:
            power: "{{ power | int }}"
        - delay: "00:00:01"
        - action: rest_command.deye_evse_restart

  rest_command:
    deye_evse_set_power_limit:
      url: "http://192.168.88.38/do_cmd.html"
      method: POST
      username: admin
      password: admin
      headers:
        Content-Type: "application/x-www-form-urlencoded"
        Origin: "http://192.168.88.38"
        Referer: "http://192.168.88.38/status.html"
      payload: >-
        webdata_wm2={{ state_attr('sensor.deye_evse_power', 'working_mode') | int }}
        &webdata_lora_rate={{ state_attr('sensor.deye_evse_power', 'lora_channel') | int }}
        &webdata_charge={{ power | int }}

    deye_evse_restart:
      url: "http://192.168.88.38/success.html"
      method: POST
      username: admin
      password: admin
      headers:
        Content-Type: "application/x-www-form-urlencoded"
        Origin: "http://192.168.88.38"
        Referer: "http://192.168.88.38/do_cmd.html"
      payload: "HF_PROCESS_CMD=RESTART"

  sensor:
    - platform: integration
      name: "Deye EVSE Energy"
      source: sensor.deye_evse_power
      unit_prefix: k
      round: 3
      method: trapezoidal

  utility_meter:
    deye_evse_energy_daily:
      name: "Deye EVSE Energy Daily"
      source: sensor.deye_evse_energy
      cycle: daily

[Stormhand]

Did you find any new documentation about this charger integration? Im also interested.

[trozman]

Unfortunately, no. Still waiting for the reply. I'll nudge them again.

[DJm00n]

@trozman #1065 can you please take a look on your side?

[trozman]

? sorry, don't understand wdym 'on your side'.

[DJm00n]

I meant - can you please test it with your config/hardware? It works on my side.

[Stormhand]

I took different path. The charger has its own logger so i used pysolarman to debug its registers directly, bypassing the inverter. This is what i found:

reg 10 → Lora communication frequency (0..9)
reg 18 → Charging power upper limit (W)
reg 56 → Max charger power (W),  22000
reg 0/41/44 - x10 = current Voltage 

im continuing to test the other.

[DJm00n]

Do you have draft yaml file for its logger?

[Stormhand]

Do you have draft yaml file for its logger?

No, im starting from scratch with simple python script trying to back-map the values from the web ui for start. So I change some value in the ui then scan again what changed in the registers.

[trozman]

please let us know about your progress, i'm interested.
scraping the charger's web interface to get power values works (i'm using it for a month), but it's not as elegant as via modbus :)

[Stormhand]

@trozman i found the most important of them and created separate config.

just found wrong formatting of the Current. Should be 8.8A

[DJm00n]

Nice find!

This is what Deye support answered me when I asked for Modbus spec for EVSE:

[Stormhand]

Ok, after a full day debugging this is what i found and where im still struggling. You dont need to use the Web to change the Watts for charge. I created a solarman yaml to control the value from HA. The charger doesnt accept anything between 0 and 1000. The moment you set 0W it makes hard stop and my tesla port lights red for failure.
Ive used an LLM to format the results:

Deye EVSE local Modbus findings (SUN-EVSE22K01-EU-AC via Solarman logger)

We did a local reverse-engineering pass on a Deye EVSE and wanted to share confirmed mappings + open questions.

Test setup

• Device: SUN-EVSE22K01-EU-AC
• Access path: local Solarman logger (TCP 8899)
• Modbus slave: 3
• Read works reliably with FC03
• Write is reliable with FC16 (FC06 is often timeout-prone)

---

1) Confirmed register range and key mappings

We currently have stable, useful data in the low holding range 0..80.

Register	Meaning	Notes
2..6	Packed serial (ASCII)	Decodes to EVSE serial string
10	LoRa channel	Matches UI value
18	Charging power limit (W)	Writable (FC16), immediate effect
38/39/40	Power L1/L2/L3	Scale x10 W
47	Current L1	Scale x10 A (deci-amps)
56	Max charger power	22000 on 22kW unit
60/61	Over/under voltage thresholds	Scale 0.1V (2665 = 266.5V, 1820 = 182.0V)
21	Packed working mode candidate	See section 3

Other recurring telemetry-like words:

• 34, 35 appear as raw diagnostic channels (units/scaling still unknown)
• 36, 57, 76/77/78 behave like state/status words

---

2) Clean stop problem (IEC 61851 behavior)

Our main practical issue is clean stop.

• Setting reg18 = 0 does stop charging, but often leads to a bad state:
  • EVSE state word goes to fault-like pattern (reg57=641 in our runs)
  • Tesla may eventually show red charge port / charge fault behavior
• This strongly suggests a non-ideal sequence vs IEC 61851 expectations (hard cut style behavior instead of proper C->B transition flow).

In contrast, stopping from Tesla app / certain EVSE-internal transitions can produce non-fault idle states (e.g. reg57=392), indicating there is an internal cleaner path.

---

3) Working mode packed register (candidate: reg21)

Observed combinations:

• 0 = WiFi + Plug&Play
• 1 = WiFi + Appointment
• 256 = LoRa + Plug&Play
• 257 = LoRa + Appointment

So reg21 appears bit-packed:

• low byte = Working Mode 1 (P&P vs Appointment)
• high byte = Working Mode 2 (WiFi vs LoRa)

However, writes to reg21 can auto-revert in some conditions (firmware/state-manager override), so it is not always a stable control path.

---

4) State words observed (still partly speculative)

reg57 values repeatedly seen:

• 416 (0x01A0) charging/active context
• 392 (0x0188) idle/clean stop-like context
• 385 (0x0181) unplugged/transition-like
• 641 (0x0281) fault/disabled-like (often after reg18=0)
• 897 (0x0381) seen in one hardware-button stop scenario

reg76/77/78 look like status bits, but:

• reg77 and reg78 did not behave as reliable writable controls in our tests (write ACK may happen, read-back not persistent).

---

5) What is still uncertain

1. Exact semantic/bit-level decode of reg57, reg36, reg76/77/78
2. Whether there is a true writable “clean stop” command exposed in this local map
3. Physical meaning/scaling of reg34/reg35 (currently treated as raw diagnostics)

---

6) What we need help validating

• Has anyone identified a reliable local command for IEC-friendly stop (no red-port fault), without cloud dependency?
• Any known bit map for this EVSE family around reg57 / reg36 / reg76-78?
• Any official/public map for this EVSE logger profile beyond inverter-oriented docs?

---

If useful, we can share redacted state transition snapshots (charging -> stop -> unplug -> replug) and corresponding register diffs.

If you want to take this and test further please update with any finding.

[DJm00n]

@trozman this is how minimum charging power 4 kW issue looks like even after I rerouted charger to single phase AC outlet:

I sent email to Deye support with a full report..

[narkoskatona]

@Stormhand Could you please share the details on how to access the Deye EVSE via local Modbus? Is it accessible through the inverter, or is there another way?

I was able to read the inverter registers using:

PySolarmanV5(INVERTER_IP, LOGGER_SN, port=8899, mb_slave_id=1, socket_timeout=10, auto_reconnect=True)

However, I can't read the charger registers. I need to obtain the actual charging power from the EVSE. Could you provide some guidance on how to access those registers?

[DJm00n]

@narkoskatona it uses mb_slave_id=3. See #1073 and #1065.

[narkoskatona]

Thanks for the quick response.

I tried using slave ID 3, but it is not working. I get an AcknowledgeError.

I am a little confused about the overall setup. Can the charger be accessed through the inverter's Solarman logger, or does the charger have its own logger?

If the charger has its own logger, which mode should it be configured in to obtain an IP address and allow Modbus communication?

Also, could you please share the charger firmware version and the inverter's Solarman logger version from a working configuration?

Thanks!

[Stormhand]

@narkoskatona you don't need to allow modbus communication. You directly communicate with the EVSE bypassing the inverter.

[DJm00n]

I made PR based on @Stormhand findings. See #1073 and #1065.

[DJm00n]

@krasovskiyd here is a bunch of wrappers for compatibility with ha-ev-smart-charger https://gist.github.com/DJm00n/a4411fd1209f6133104ff7dff87ece47

[Mights001]

Hello I'm very intressted about this Topic i integrate the EV Charger in HA with a copy from David 3p Definitions and i add this Values

parameters:

• group: Wallbox
  items:

  • name: Wallbox Max Power
    platform: number
    class: "power"
    state_class: "measurement"
    uom: "W"
    rule: 1
    registers: [0x0104]
    range:
    min: 0
    max: [11000]

  • name: "Wallbox Power"
    class: "power"
    state_class: "measurement"
    uom: "W"
    rule: 1
    registers: [0x02C5]
    icon: "mdi:ev-station"

  • name: Wallbox Solar Energy only > 95%
    platform: "switch"
    rule: 1
    registers: [0x0103]
    value:
    bit: 0

  • name: Wallbox EV Charge Free Work
    platform: "switch"
    rule: 1
    registers: [0x0103]
    value:
    bit: 1
    icon: "mdi:car-electric"

  • name: Wallbox EV Charge connect at Grid
    platform: "switch"
    rule: 1
    registers: [0x0103]
    value:
    bit: 4
    icon: "mdi:power-plug"

  • name: Wallbox EV Charge connect at Load
    platform: "switch"
    rule: 1
    registers: [0x0103]
    value:
    bit: 5
    icon: "mdi:power-plug"

@DJm00n where you get the Status?

    - name: "EV Charger Status Mapped"
      unique_id: ev_charger_status_mapped
      state: >
        {% set s = states('sensor.deye_evse_charging_operational_state') %}
        {% set limited = 'Limited' in states('sensor.deye_evse_charging_control_state') %}
        {% if s == 'Available' and not limited %}charger_free
        {% elif s == 'SuspendedEV' and not limited %}charger_free
        {% elif s in ['Available', 'SuspendedEV', 'Preparing', 'SuspendedEVSE', 'Faulted'] %}charger_wait
        {% elif s == 'Charging' %}charger_charging
        {% elif s == 'Finishing' %}charger_end
        {% else %}charger_free
        {% endif %} 

[DJm00n]

@Mights001 you can get this state information directly from EV charger. See #1073

[Mights001]

Hi, i make some additonal things, because i use EVCC and many others too, i use your definitions and make this in adv.

  - name: "Charging Operational State EVCC"
    description: "EV charger operational state derived from the internal charging state machine for EVCC."
    rule: 1
    registers: [0x0039]
    mask: 0x007F
    lookup:

      # State 0
      #
      # CP = +12V (no PWM).
      # Charger available and idle.
      #
      # Observed when:
      # - no EV is connected
      # - charger is available
      # - charging session fully ended
      #
      # Corresponds roughly to:
      # IEC 61851 State A
      - key: 0x0001
        value: "A"
      # State 3
      #
      # PWM active and current is being offered to the EV,
      # but charging current is not currently flowing.
      #
      # EVSE is actively advertising available current.
      #
      # Roughly corresponds to:
      # IEC 61851 State B with PWM active
      - key: 0x0008
        value: "B"

      # State 5
      #
      # Active charging state.
      # PWM active, relay closed, current flowing.
      #
      # Corresponds roughly to:
      # IEC 61851 State C
      - key: 0x0020
        value: "C"

      # State 6
      #
      # Faulted or protection-lock state.
      #
      # Triggered when the charger safety logic detects
      # a relay fault or abnormal condition.
      #
      # Specific fault causes are reported separately
      # by dedicated protection/fault registers.
      - key: 0x0040
        value: "F"

to Sureplus PV Charging i add a small Automation

alias: EVCC Amper to Wallbox Watt
description: ""
triggers:

• trigger: state
  entity_id:
  • input_number.deye_eves_current
    conditions: []
    actions:
• action: number.set_value
  metadata: {}
  target:
  entity_id: number.esphomedeye_sun12k_ev_charge_power
  data:
  value: >-
  {{ (states('input_number.deye_eves_current') | float(0) * 230 * 3 * 0.9)
  | round(0) }}
  mode: single

at the moment i can't test it de e-Care is comming soon :-)
Thanks for your Work

[trozman]

Hi, do setting bits work for you in this case (modifying modbus register 0x0103)? I tried modifying this register but now Charge Control Power from Inverter is always 0 (it looks stuck)...

Hello I'm very intressted about this Topic i integrate the EV Charger in HA with a copy from David 3p Definitions and i add this Values

parameters:

* group: Wallbox
  items:
  
  * name: Wallbox Max Power
    platform: number
    class: "power"
    state_class: "measurement"
    uom: "W"
    rule: 1
    registers: [0x0104]
    range:
    min: 0
    max: [11000]
  * name: "Wallbox Power"
    class: "power"
    state_class: "measurement"
    uom: "W"
    rule: 1
    registers: [0x02C5]
    icon: "mdi:ev-station"
  * name: Wallbox Solar Energy only > 95%
    platform: "switch"
    rule: 1
    registers: [0x0103]
    value:
    bit: 0
  * name: Wallbox EV Charge Free Work
    platform: "switch"
    rule: 1
    registers: [0x0103]
    value:
    bit: 1
    icon: "mdi:car-electric"
  * name: Wallbox EV Charge connect at Grid
    platform: "switch"
    rule: 1
    registers: [0x0103]
    value:
    bit: 4
    icon: "mdi:power-plug"
  * name: Wallbox EV Charge connect at Load
    platform: "switch"
    rule: 1
    registers: [0x0103]
    value:
    bit: 5
    icon: "mdi:power-plug"

[Mights001]

I had the same problem, a Modbus register on the inverter wasn't set correctly. Deye sent me a command code to fix the register setting, and then the charging station worked.

You can send this command over the cloud here this is the command 0110010300010232ee238F

This has something todo with the Reg 259

[DJm00n]

Without my code fixes from PR #1065, this YAML will overwrite adjacent bits in register 0x0103 (259), since multiple entities share the same register.

Command 0110010300010232ee238F writes 0x32EE to register 0x0103, which decodes as:

• Power Mode: Free Work
• Inverter Port: Load Port
• Off-Grid SOC: 50%

It also preserves several other unknown bits used by the charger firmware. Without read-modify-write support, changing a single setting would overwrite both the known fields and these unknown bits, potentially changing undocumented charger behavior.

[trozman]

I had the same problem, a Modbus register on the inverter wasn't set correctly. Deye sent me a command code to fix the register setting, and then the charging station worked.

You can send this command over the cloud here this is the command 0110010300010232ee238F

Is this where you enter the command? (Device/Inverter)

[trozman]

I contacted the support and Deye updated the firmware (of inverter, charger, etc.). It partially fixed the problem, but introduced some new (e. g. EV charging works only only wifi mode, not in lora mode. Also 'solar only' mode dissapeared from deye app. And Charging limit on Inverter screen and Deye app doesn't match anymore. And Control power is always 0 :(

[DJm00n]

@trozman What are the current firmware versions for your inverter and EVSE?
I have:
Inverter SUN-12K-SG05LP3-EU-SM2: 2107-1175-1809 / 1001-C070 / LSW5_32_5406_SS_04_00.00.00.11
Charger SUN-EVSE22K01-EU-AC: C020 / MW4_01_5429_SS_04_00.00.00.07

[trozman]

Inverter: SUN-12K-SG04LP3-EU, MAIN：2006-1183-1807,HMI：1001-C072, Protocol Version：0104, LSW3_32_5406_SS_04_00.00.00.0B

EV charger: SUN-EVSE22K01-EU-AC, MW4_01_5429_SS_04_00.00.00.07

[Mights001]

If Solar only dissapered you must turn on in the cloud on the charager lora, is i littel bit confusing about the settings.

[trozman]

Thanks. I've changed to Lora mode (in Deye portal), but it won't charge in lora mode. Switching back to wifi, it charges.
Where/how exactly do you send the command to restore 0x0103 register on the inverter? To me it seems that undocumented bits are used for something related to lora and syncing inverter/sending commands to charger (via lora).

[trozman]

... contd. I can confirm writing 0x32EE (13038 decimal) to 0x0103 register restored EV charger - it's working again (in lora mode too).
Damn, that scared me.

[Mights001]

sorry i had no time to send you a answare, but i make me happy if it work for all others under Devices on the Inverter in the Deye Cloud you can send this command

[yordanov6835]

Single-phase Deye EVSE, local Solarman logger (TCP 8899, mb slave 3), profile deye_evse.yaml.
Model: Deye SUN-EVSE (single-phase AC), no display, controlled only via Deye Cloud app.

Confirmed working registers on THIS unit (Solarman V5, FC03 read):

• 0x0026 = charging power (x10 -> W) [verified, matches car ~5.8 kW]
• 0x002F = L1 current (deci-amps)
• 0x0038 = reads 22000; FC16 write is ACKed but REVERTS to 22000 (no effect on power)
• 0x0039 = state, mask 0x7F: 0x20 = charging (IEC C), 0x01 = idle (IEC A) [verified]

Registers 0x0100 / 0x0103 / 0x0104 from earlier posts DO NOT EXIST here (read timeout),
so that map is for another model/firmware.

The Deye Cloud app CAN start/stop charging (verified: stop -> 0 W), so a writable command
register exists via the logger - but I can't identify it for this low-register variant.

Question: which register + value + function code actually STICKS to (a) set charge
current/power, and (b) start/stop charging on this variant? Is there a control-enable or
working-mode register that must be set first before 0x0038 (or equivalent) is accepted?

[DJm00n]

  - group: Control
    update_interval: 5
    items:
      - name: "Charging Power Limit"
        description: "Active charging power limit setpoint. The inverter/EMS may update this register dynamically; it can also be written directly. Setting 0 withdraws the CP PWM and stops charging. Non-zero values below the IEC 61851 minimum (6 A per phase) are internally clamped to ~1.4 kW single-phase or ~4.1 kW three-phase. Maximum supported power is 11 kW three-phase (11 kW EV Charger) or 7 kW single-phase / 22 kW three-phase (22 kW EV Charger)."
        class: "power"
        uom: "W"
        rule: 1
        registers: [0x0012]
        icon: "mdi:lightning-bolt-circle"
        configurable:
          min: 0
          max: 22000
          step: 100
          mode: box

[yordanov6835]

Thanks a lot for the quick answer! Appreciate! It's working. Have a good weekend!