TSOL-MP3000 (Y47) – client mode connects successfully but no sensor data

[Riposte82]

Hi Stefan,

I am trying to integrate a TSUN TSOL-MP3000 with tsun-gen3-proxy 0.16.0-rel and Home Assistant.

Inverter details:

Model: TSOL-MP3000
Inverter SN: Y47E8501060F0xxx
Monitoring SN: 2093984xxx
Proxy version: 0.16.0-rel
Client mode: 192.168.178.85:8899

Client mode works successfully and the proxy identifies the inverter. MQTT discovery also works and Home Assistant automatically creates the inverter and its entities.

However, all sensor values in Home Assistant remain Unknown.

The proxy continuously tries the following sensor lists:

0x2b0 – Modbus registers at 0x3000
0x1097 – Modbus registers at 0x1000
0x3026 – Modbus registers at 0x00

Each attempt results in:

CRC error: 0005 != ffff for msg: 0500

The important point is that the inverter itself is working correctly. The TSUN Smart App receives current live data. For example, while testing, it showed 389.6 W current power as well as daily, monthly and total generation data.

The proxy also successfully maintains the client-mode connection to the inverter and forwards the connection to the TSUN cloud. The TSUN Smart App continues to receive live data while the proxy is running.

Therefore, it seems that communication and cloud forwarding are working, but tsun-gen3-proxy is unable to detect or decode the correct sensor/register layout for this TSOL-MP3000.

Is this TSOL-MP3000 / Y47 variant currently supported? If not, I would be happy to provide logs or traces to help add compatibility. Please let me know which logging/trace settings or files you need.

[s-allius]

Hi @Riposte82 ,

the MP3000 inverter properly uses a different sensor list. You may run a modus register scan to find addresses where the inverter send responses. I will write a short description how to do this and add here a link soon.

[Riposte82]

TSOL-MP3000 (TITAN): successful local read over Solarman V5

Hi @s-allius,

I would like to share some findings regarding the TSOL-MP3000 (TITAN).

We now have a reproducible proof of concept for local communication with the inverter.

Environment

• Device: TSOL-MP3000 (TITAN)
• TCP port: 8899
• Transport: Solarman V5

The current proxy can establish the TCP connection, but the MP3000 does not appear to use the same Modbus requests as the currently supported TSUN models.

Instead, the MP3000 expects a proprietary native protocol transported inside the Solarman V5 payload.

Confirmed communication

We captured the UART communication of a working TSOL-MP3000 installation and replayed the exact observed native read requests inside a Solarman V5 command frame.

Example native request for the register block starting at address 3000:

A1 01 00 0B B8 00 02 00 20 D3 3F

This request was transported inside a Solarman frame using:

• Control: 0x4510
• Command type: 0x02
• Sensor list: 0x02B0

The inverter returned a valid Solarman response with:

• Control: 0x1510
• Valid Solarman checksum
• Valid stop byte

The embedded native response starts with:

7E A1 81 01 0B B8 00 40 ...

The native MP3000 CRC is also valid.

This confirms that the existing Solarman V5 transport can be used for the MP3000. The main missing part appears to be the MP3000-specific native request and response handling.

Function code and block selection

An important observation is that the register address alone is not sufficient to select a data block.

For example:

A1 01

is used for the block starting at register 3000.

However:

A1 21

is required for the block starting at register 2000.

Using A1 01 with address 2000 does not return the expected data block and instead produces a short error response.

The second byte therefore appears to be part of the MP3000 block or command selection and should not be treated as a generic Modbus-style read function.

Observed read requests

The following recurring requests were extracted from the UART capture:

Purpose	Native request
Block 3000	A1 01 00 0B B8 00 02 00 20 D3 3F
Block 2000	A1 21 00 07 D0 00 02 00 31 C2 9C
Block 2058	A1 21 00 08 0A 00 02 00 05 39 C4
Register 2060	A1 21 00 08 0C 00 02 00 01 FA 4D

Additional cyclic requests were also observed:

A2 02 00 0C E4 00 02 00 10 98 BA
A3 03 00 0E 10 00 02 00 20 E7 C6
A4 04 00 0E D8 00 02 00 20 E1 40

These have not yet been replayed. Their semantics are currently unknown, so no assumption has been made that they are read or write commands.

Two rare commands were also captured:

A2 12 00 08 FC 00 02 0A 07 BC DC
A2 22 00 08 FC 00 02 00 02 0B 19

These have intentionally not been tested because their purpose is unknown.

Block 3000

The request for block 3000 returns 32 little-endian 16-bit values covering registers 3000 to 3031.

The following mappings are currently supported by measurements with varying inverter output:

Register	Possible meaning	Scaling	Confidence
3012	AC grid voltage	0.1 V	High
3013	AC output current	0.01 A	High
3015	Grid frequency	0.01 Hz	High
3020	Rated inverter power	1 W	Confirmed
3022	Internal inverter temperature	0.1 °C	High
3024 / 3025	32-bit total energy counter	Probably 0.01 kWh	High

Example measurement while the app displayed approximately 789 W:

3012 = 2365  -> 236.5 V
3013 = 326   -> 3.26 A
3015 = 4996  -> 49.96 Hz
3020 = 3000  -> 3000 W
3022 = 409   -> 40.9 °C
3024 = 59516
3025 = 0

The apparent power calculated from voltage and current was:

236.5 V × 3.26 A = 771 VA

The app and local register values are apparently not updated at exactly the same time, so this calculated value should not yet be treated as confirmed active power.

Total energy counter

Registers 3024 and 3025 appear to form a little-endian 32-bit increasing energy counter:

raw_energy = (register_3025 << 16) | register_3024

The likely conversion is:

total_energy_kwh = raw_energy × 0.01

Observed values:

13:31  59490
15:52  59505
15:53  59506
later  59516

The increments are consistent with an energy resolution of 10 Wh per unit.

This would be especially useful for Home Assistant because it could be exposed as:

• device_class: energy
• state_class: total_increasing
• unit_of_measurement: kWh

Other observations from block 3000

Registers 3010 and 3019 remain close to approximately 412 V over a wide power range.

They may represent an internal high-voltage DC bus rather than the individual PV input voltage.

The individual PV input values do not appear to be present in the currently decoded block 3000 and may be located in one of the other observed blocks.

Registers 3017, 3021 and 3028 are dynamic but remain unidentified.

Register 3021 is not proportional to AC output power and is not monotonic, so it is unlikely to be an energy counter or a direct power value.

Block 2000

The block requested with A1 21 appears to contain grid protection or configuration values rather than live telemetry.

Observed values include numbers corresponding to approximately:

252.7 V
197.2 V
50.10 Hz
49.00 Hz
52.02 Hz
53.02 Hz

These values resemble voltage and frequency protection thresholds.

The rated power value 3000 also appears in this block, which supports the interpretation of register 3020 as rated inverter power rather than an address echo.

Current proof-of-concept

A Python proof-of-concept currently performs the following steps:

1. Creates the native MP3000 request.
2. Wraps it in a Solarman V5 frame.
3. Sends it to TCP port 8899.
4. Validates the Solarman checksum and stop byte.
5. Locates the embedded native frame starting with 0x7E.
6. Validates the native MP3000 CRC.
7. Decodes the returned registers as little-endian values.

Possible implementation approach

From the current findings, the existing Solarman transport layer could probably remain unchanged.

MP3000 support would mainly require:

• An MP3000-specific native request generator
• Support for the different MP3000 command or block selectors
• A parser for the native 0x7E response frames
• Native CRC validation
• An MP3000-specific register mapping

No protocol changes appear to be required in the outer Solarman V5 layer.

Available material

I can provide the following material if it is useful:

• UART Saleae captures
• The Python proof-of-concept
• Raw Solarman and native response frames
• Decoded register dumps
• Time-series measurements at different inverter power levels
• Additional testing on a real TSOL-MP3000

I would also be willing to help test or contribute a clean MP3000 protocol implementation if support is added to the project.

[s-allius]

Hi @Riposte82 ,
this is really excellent work. I once had remote access to an MP3000, but I didn't see the connection to the UART. To better understand how the Solarman packets are encoded, it would be great if you could send logs containing the complete packets. I can then build unit tests for them, and we can certainly add the protocol to the proxy. You can send me traces per eMail to DataType76@allius.de

With the other TSUN inverters, however, the addresses are in hexadecimal—namely, 0x2000 and 0x3000. With the MP3000, on the other hand, the addresses are in decimal. Otherwise, the temperature register has an offset of -40 on the TSUN. But we'll figure that out...

[TheSmartGerman]

Well, i kown the Inverter talks to the WiFi Module due to a UART. I did some sniffing there too...

[Riposte82]

We nearly figured it out, but we could need a second SALEAE record with 6 panels connected to the 6 MPPTs to identify the remaining 8 registers.

So far we got only 4 from a record who was uploaded here, but had only 2 panels connected.

[TheSmartGerman]

@Riposte82 You talk about the UART connection. I didn't got it so far, where you sniffing. I did some UART captures a while ago: #316 (reply in thread)

But this was some bench testing with a DC supply at the mppt. Now the MP3000 is on my garage roof, 6 panles installed. But if I kown where to make the UART recording. I can do it... It's just not that easy to reach anymore...

[s-allius]

I build a test version of the Home Assistant App: 0.17.0-dev-2608142353

This version should detect the MP3000 and register 6 modules and the inverter in HA. Maybe someone can validate the values.

[s-allius]

With today's version tsun-gen3-addon:0.17.0-dev-2608161444
I added a temperature sensor (there are at least two) and the inverter status.

With this version comes also a fix for the total energy values. Thanks to @Riposte82 who figured this out in his own project