Sleeper85

0x70 and 0x371 come from the SEPLOS 1.0 document which says to be compatible with PYLON 1.3 and GoodWe 1.5. I had never managed to find the PYLON 1.3 protocol or higher that's why I named this protocol PYLON + in my application YamBMS because I couldn't really put a version number without having had an official document in my hands.
I will now be able to update my code with the PYLON 2.0.5 protocol 😍
As you have discovered you must respond every second with an ID 0x305 what I called the inverter heartbeat in my code.

0x70 and 0x371 come from the SEPLOS 1.0 document which says to be compatible with PYLON 1.3 and GoodWe 1.5. I had never managed to find the PYLON 1.3 protocol or higher that's why I named this protocol PYLON + in my application YamBMS because I couldn't really put a version number without having had an official document in my hands.
I will now be able to update my code with the PYLON 2.0.5 protocol 😍
As you have discovered you must respond every second with an ID 0x305 what I called the inverter heartbeat in my code.

Really interesting, thanks for sharing this document.

@Youda Here's something nice to have a look at.
2.0.1 in 2021/4/2 is interesting note. So you have to send both 0x305 and 0x307.
I've not looked at it properly yet.
Pylon CAN bus protocol V2.0.5 20230327.pdf

I updated the firmware three weeks ago (Deye SUN-6K-SG03LP1).
The situation with the speed of finding a new mppt point, in my opinion, is not good.
Search by the Deye Inverter   for the second mppt point with partial shading of one panel of a string of six panels:
14:06 - the first attempt
14:09 - second attempt
14:12 - the third attempt
14:14 - the fourth attempt

Hi,
I noticed the same thing with my Deye SUN-6K-SG03LP1-EU.
I spoke with the Deye service about this and they advised me to add optimizers 😐
But, since the latest firmware version:
HMI: 0000-C369
MAIN: 0-4385-1515
A new “MPPT multi-point scanning” option has appeared.
I haven't tested it yet but I hope it will help to have better behavior.
 

Are you using CAN or RS485?  CAN only has one output voltage (measured voltage) and one command voltage (requested charge voltage). So there can be no real confusion.
I have played a lot with the Sunsynk CAN link (developing my own BMS comms implementing the Pylon CAN protocol), and have found that it consistently errs on the other side.  I can never get it to charge to more than 0.5V BELOW the requested charge voltage.