Just an update:

 

Comms are fine for 9hrs, then i start receiving garbage values. Even if i restart the ESP or reprogram, the values are garbage. My only conclusion is that there is a bug in the RS comms on the inverter.

Another update.

 

Saw on this thread 

someone with similar issue but with the 16kW version. Moved my RJ45 to Meter_CON port, values are now normal/correct. 

 

Let's monitor and see how it goes.

10 hours ago, BugsRSA said:

Another update.

 

Saw on this thread 

someone with similar issue but with the 16kW version. Moved my RJ45 to Meter_CON port, values are now normal/correct. 

 

Let's monitor and see how it goes.

That's me @BugsRSA

Just try restarting your inverter, that's what sorted it out for me 🙂 

6 hours ago, Sc00bs said:

That's me @BugsRSA

Just try restarting your inverter, that's what sorted it out for me 🙂 

How often do you have to restart, does it recur? Had this issue once. 

1 hour ago, abd7 said:

How often do you have to restart, does it recur? Had this issue once. 

Just the once

Happened once, restarted, happened the next day again. Then without restarting I moved the RJ45 to Meter_com port and it worked. 

 

Also emailed China support. They sent me a new firmware. Think I'll wait with flashing until something happens again. 

Your issue sounds more like an EMI or software issue on your end, I don't think changing your inverter firmware will fix it.

Internally, the Meter_com and RS485 are the same thing, pin 1 is connected to pin 8, 2 to 7:

Edited April 19, 20242 yr by P1000

I tried both pin 1 and 2 and also 7 and 8 on the same port with no difference. Moved the plug to the dedicated Meter_Con port without restarting the inverter and the values that came through were all correct.

Must also point out that everything ran fine on the RS485 port for roughly 8 to 9 hrs before the values became garbage. (Garbage meaning grid freq had values in the 300's, SoC went into the 2000%, etc)

 

Non the less, I might one day move back to the RS485 port and start a structured fault-finding expedition to isolate the fault. For now, all is working past the dreaded 9hr mark 🙂

 

3 hours ago, P1000 said:

Your issue sounds more like an EMI or software issue on your end, I don't think changing your inverter firmware will fix it.

Internally, the Meter_com and RS485 are the same thing, pin 1 is connected to pin 8, 2 to 7:

Further update:

This morning some signals started again to display weird values every 12min or so. Tried to see if I could find any correlation. Then I remembered your comment about EMI.

My ESP is right next to the inverter. So as a test I moved the ESP and just let it hang, about 30cm away. Thus far I have not seen any signal with weird values…. Planning to extend all wiring and place the ESP further away from the inverter. If it is really EMI, then the EMI levels get too much when the DC from the panels goes above a certain value, as this does not happen at night when no DC is being generated.

The above is still a theory for now 😊

8 hours ago, P1000 said:

Your issue sounds more like an EMI or software issue on your end, I don't think changing your inverter firmware will fix it.

Internally, the Meter_com and RS485 are the same thing, pin 1 is connected to pin 8, 2 to 7:

I don't think that is correct @P1000

When I was having issues with my regular RS485 port not working, I split my BMS port out to the RS485 & Canbus and it worked on the RS485 port there without problem.

I thought that it was a faulty board in the inverter because I was having the same issue with multiple RS485 boards connecting to it. 

I managed to get a technician from DEYE to come onsite to have a look at it (luckily the Kyalami office is about 2km away) and when he checked it out it was all working. 

The only thing I could think was that the inverter had been restarted during the time that I was using the split port and the RS485 port had restarted. 

A few days later the RS485 port stopped working again, I had the firmware updated, restarted the inverter and haven't had an issue since. 

 

 

 

 

 

@Sc00bs are you referring to the 16kW Deye or is it a 8kW? Just asking as Deye sent me 2 bin files. One for inverter and one for the screen. Don't want to flash unless nothing else works. 

3 hours ago, BugsRSA said:

@Sc00bs are you referring to the 16kW Deye or is it a 8kW? Just asking as Deye sent me 2 bin files. One for inverter and one for the screen. Don't want to flash unless nothing else works. 

I have a 16kw, just get them to do an update for you. 

There is a DEYE whatsapp group, if you message me a photo of your dongle I will send it to them and ask them to run an update for you if you like

 

The first group is full but you can join the second one on https://chat.whatsapp.com/C2jvUO7Cqej1l0d0adZcpH and request the update there yourself if you like.

I am trying to get this working, but i am seeing nothing on the logs at all

When i reset the esp32, i see the following, and nothing more

I don't even see anything about even trying to connet to my wifi SSID

I tried the ESPHome-1P-Sunsynk-Deye.yaml from slipx06 github page, and i now tried the code from Muttley in this thread too - but the same result with both

8 minutes ago, championc said:

I am trying to get this working, but i am seeing nothing on the logs at all

When i reset the esp32, i see the following, and nothing more

I don't even see anything about even trying to connet to my wifi SSID

I tried the ESPHome-1P-Sunsynk-Deye.yaml from slipx06 github page, and i now tried the code from Muttley in this thread too - but the same result with both

What boards are you using , esp32 & RS485?

If those are your logs then I would guess that you are probably not loading the firmware onto the board correctly cause it doesn't look like ESPHome is seeing the board

I would start by onboarding the ESP32 and check the logs before you update the firmware with the SLIPX06 code.

From Grok:

The ESPHome log you provided shows a boot sequence for a device, likely an ESP32 or ESP8266, with timestamps from July 29, 2019. The log indicates a power-on reset and a successful boot via SPI fast flash boot. However, the repeating [18:22:11][mode: DIO, clock div: 2] and subsequent load messages followed by an entry point suggest the device is attempting to load firmware or configurations but may be encountering issues.

Here are potential problems and explanations:

1. Corrupted Firmware or Configuration:

   • The load entries (e.g., 0x3fff0030, 0x40078000, 0x40080400) indicate the bootloader is trying to load segments of the firmware into memory. If the firmware or configuration file (e.g., YAML file in ESPHome) is corrupted or incompatible with the device, it might fail to proceed beyond this point.

   • Solution: Recompile and reflash the firmware using ESPHome. Ensure the YAML configuration matches your device's specifications (e.g., correct board type, memory layout).

2. Incorrect Flash Mode or Clock Settings:

   • The log shows mode: DIO, clock div: 2, which refers to the flash mode (Dual I/O) and clock divider. If the flash mode or clock settings are incorrect for your specific hardware, the device might fail to read the firmware properly.

   • Solution: In your ESPHome YAML, explicitly set the flash mode to match your hardware (e.g., flash_mode: dio or flash_mode: dout). Also, check the clock frequency—clock div: 2 implies a slower clock, which might not be optimal for your setup.

3. Hardware Issue (Flash Memory or Power Supply):

   • If the flash memory chip is faulty or there’s a power supply issue (e.g., insufficient voltage or current), the device might struggle to read the firmware, leading to a boot loop or failure.

   • Solution: Verify the power supply (e.g., use a stable 3.3V source with enough current). Check the flash chip connections and consider replacing the chip if it’s damaged.

4. Bootloader or Partition Table Issue:

   • The entry 0x400805e4 indicates the bootloader is trying to jump to the firmware entry point. If the partition table is misconfigured or the bootloader is outdated, it might fail to execute the firmware.

   • Solution: Ensure the partition table in your ESPHome configuration is correct. You might need to update the bootloader by flashing a fresh ESPHome firmware.

5. ESPHome Version or Compatibility:

   • Since the log is from 2019, you might be using an older version of ESPHome that has compatibility issues with your device or firmware.

   • Solution: Update to the latest version of ESPHome and reflash the device. Check the ESPHome documentation for any breaking changes since 2019.

Next Steps:

• Recompile and reflash the firmware with a minimal ESPHome configuration to rule out YAML errors.

• Double-check your hardware setup (power, flash chip, etc.).

• If the issue persists, enable more verbose logging in ESPHome (e.g., logger: level: DEBUG) to get more details on the failure.

Thanks for the quick reply

I have Logger set to DEBUG. I have an ESP32-WROOM-32 and a MAX485 board (with R7 removed). When selecting the Device, I selected "ESP32". Where do I tell it that I have a MAX485 board ?

I also tried the code in "frankthetank"'s first post in this thread and got the same blank screen

Edited April 21, 20251 yr by championc
Amended actual ESP32 board name

Problem solved

I needed this for the esp32-wroom-32. Thanks @Sc00bs

esp32:
  board: esp32dev
  framework:
    type: esp-idf

Edited April 24, 20251 yr by championc

I know this is not really the place for this question but I'll ask anyway

I am using Slipx06's script ESPHome-1P-Sunsynk-Deye.yaml but when I browse to my ESP32, I can see the options to change the Work Mode and the Max Sell Power, but within Home Assistant, neither option has appeared within the Controls section of my ESPHome device, meaning I cannot change either with Automations.

Anyone any ideas ?

EDIT: I think a restart of HA fixed it :)

Edited April 22, 20251 yr by championc