Deye SUN600G3-EU-230 with MW3_SSL_5408_1.0B - cannot get data from the inverter

[mario37359]

I tried to setup my Deye Inverter in the HA with your ha-solarman extension, but cannot establish a connection. I tried several config files, the Inverter is reachable through the browser. Can you give me any hints on the issue or what to change in the config or parameters? Could not find anything helpless for my problem in the documentation or Q+A section. TY!

[davidrapan]

You gonna have to give me debug logs from device addition flow:

1. Delete device
2. Enable debug by clicking on the "Debug Protokollierung aktivie..."
3. Try add device and wait for couple of minutes
4. Disable debug by clicking on the "Debug Protokollierung aktivie..."
5. Attach the file it just downloaded for you here in the thread.

😉

[davidrapan]

Fuh, ok so you gonna have to ssh into your HA and run: ha core rebuild

[mario37359]

I tried this and reinstalled, without success. Send the log to check again... TY
home-assistant_solarman_2024-09-03T05-40-16.206Z.log

[davidrapan]

So initial problem has been fixed. Now you are maybe using wrong inverter profile..

What exact model of the inverter do you have?

[mario37359]

My current inverter is a Deye SUN600G3-EU-230

[davidrapan]

@mario37359 so you are just using incorrect profile, you can find the correct one here: https://github.com/davidrapan/ha-solarman/wiki/Supported-Devices

[PV-Joe]

I found something that could be related to the problem.

The problem seems to start with the Firmware: "MW3_SSL_5408_1.0B"

Unfortunately this is in German.

https://dy-support.org/community/deye-micro-inverter/port-48899-nach-ota-firmwareupdate-gesperrt/

Maybe it helps?

[davidrapan]

They are saying that just the 48899 for the discovery is closed but that it still normally works over 8899. 😉

Edit: But nevertheless I really don't like what they are doing with those changes. Yeah it's just the discovery out for now but who knows what will be next... It can end up real bad for us...

[mario37359]

I'am in Germany, so the article is no problem for me 😉 I'll read about that.. TY

[davidrapan]

Guys @jmccrohan and @githubDante, I really don't like the new "MW3_SSL_5408_1.0B"...

RECD: a5 10 00 10 15 9a a3 be eb 42 fa 02 01 e6 4e 0c 00 7b 05 00 00 09 52 ca 66 05 00 aa 15

Doesn't look like modbus though...

Posts about the firmware and the issues with it (in German):

• https://dy-support.org/community/deye-micro-inverter/port-48899-nach-ota-firmwareupdate-gesperrt/
• https://www.photovoltaikforum.com/thread/233881-deye-firmware-mw3-ssl-5408-1-0b-kein-logging-mehr-m%C3%B6glich/
• https://www.solaranzeige.de/phpBB3/viewtopic.php?t=5023

[davidrapan]

@PV-Joe, could you also start new discussion with those firmware links and all the info you have about it? Thanks in advance. 😉

[PV-Joe]

@PV-Joe, could you also start new discussion with those firmware links and all the info you have about it? Thanks in advance. 😉

Go here:
#135

[davidrapan]

It's an exception.

Maybe a dumb question, but does that mean that we do know what these exceptions look like then? So maybe we can do log them better than just saying the frame is not a modbus frame?

[githubDante]

It's an exception.

Maybe a dumb question, but does that mean that we do know what these exceptions look like then? So maybe we can do log them better than just saying the frame is not a modbus frame?

The frame is invalid, that's for sure, as it does not follow the MODBUS protocol specification. It's a plain exception code without slave address and CRC and as such the frame is shorter. Even the exception code which they use is incorrect

0x05 - ACKNOWLEDGE - The server (or slave) has accepted the request and is processing it, but a long duration of time will be required to do so. This response is returned to prevent a timeout error from occurring in the client (or master).

It should be 0x02 for illegal data address.

Probably we can enrich the exception message a little bit in PySolarman by adding extra info in it as the exception can be checked easily with umodbus

from umodbus.exceptions import error_code_to_exception_map
error_code_to_exception_map.get(v5_frame[25]).__name__
'AcknowledgeError'

[davidrapan]

Even the exception code which they use is incorrect

I'm not surprised at all... lol.

So something like this? (pysolarmanv5.py at 258):

if len(modbus_frame) < 5:
    # Check to some min length or maybe there is some better way to check if even contains any data at all?
    # If it's needed at all though...
    if len(modbus_frame) > 0:
        modbus_exception = error_code_to_exception_map.get(modbus_frame[0]).__name__
        raise V5FrameError(f"V5 frame contains Modbus exception: {modbus_exception}")
    raise V5FrameError("V5 frame does not contain a valid Modbus RTU frame")

[davidrapan]

@mario37359, use this profile: deye_2mppt.yaml during the configuration. 😉

[mario37359]

Oh..that really works ... 👌 Thank you so much guys!

[PV-Joe]

Congratulations!
Now you can start creating spicy dashboards 😄

If you like you can share them here and give some inspiration for others:

https://github.com/davidrapan/ha-solarman/discussions/new?category=show-and-tell