Tinbum

@Youda
Have you seen this thread?
 

They will be fine. The problem is when actually installing the new one as you can get large currents.

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

Batteries are designed to go down to 5%. I wouldn't take them that low though.

The SOC follow the ages nearly perfectly. Pack 2 is very slightly different.

It really isn't a problem.

They will vary. It can be dependent upon a number of factors, eg ages of the batteries, how they are wired, etc.
Your batteries SOC will be a lot more accurate than any voltage values due to the voltage curve of the battery.
I wouldn't worry.

I found the problem with the Teensy setup, I had 4 receive mailboxes set as standard and 4 as extended. The 4 as standard were not enough so I added another 4 standard and can now get all the messages.
I can confirm that if you send 0x305 and 0x307 it opens up the 0x372 > onwards. (Tried it on my Teensy instead of the Venus Pi).
I don't know where the 0x70 and 0x371 come from on that chart but I'm sure it's wrong.

I found the problem with the Teensy setup, I had 4 receive mailboxes set as standard and 4 as extended. The 4 as standard were not enough so I added another 4 standard and can now get all the messages.
I can confirm that if you send 0x305 and 0x307 it opens up the 0x372 > onwards. (Tried it on my Teensy instead of the Venus Pi).
I don't know where the 0x70 and 0x371 come from on that chart but I'm sure it's wrong.

@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

Well, I couldn't wait till tomorrow so turned the pi off and you were right. Oh actually it is tomorrow!!
The messages carried on, so yes, the battery is sending them. It's strange though as the CANalyst II sees them but my Teensy doesn't. Their is still no 0x70 or Ox371 anywhere so I think that table may be wrong.
Next I'm going to put the CANalyst II on another pack of batteries, read the messages and see what that shows. Then I will put the Victron Pi on that CAN bus and see if it opens up the battery to 0x372 and above if they were not already being sent. If it is the pi opening it up I will also be able to see what it has sent from it..
I'm then going to have to investigate why my Teensy isn't seeing these extra messages. It may be it's not fast enough or the buffers need to be bigger. (I initially started off with an Arduino but that missed messages so went I on to the Teensy).
victron_0002_0001.csv
 
Yes that coding makes sense- ties in with the table I posted above. Strange how temps are in K not Degrees C

Yep, will try that tomorrow. pretty certain they will disappear as they don't show on the Teensy that I use to alter the pylontech CAN messages to the inverter.

I'm baffled!! Here is the CAN sniffing file;
victron_0001.csv

I've now connected the pi to the pack and it is showing the cell voltages etc ok.

But I'm really baffled as I can't see the 0x70 and 0x371 in the CAN communication. In a document I have showing the CAN protocols they are shown in a different color so I'm wondering if their is something special about them.

Well, each H48050 is able to work standalone and you can monitor it via it's RS232 console port.
Even now, when you have H48050 in the stack, you can plug a console cable into an individual brick.
 
On the other hand - charging 50Ah pack with a bench power supply running for days at 3Amps is not an easy task. Do you have enough experience with that?
If you do, go on. If not, just ask hire somebody experienced to come onsite and do this for you.
 
You don't want ruin batteries that are almost new...and/or kill yourself in the process.

I know HV and LV are different but the cells are the same and i believe both are 15 cell.
 
to your question

For some reason HV are 100% SOC on delivery according to the manual unless otherwise requested. I find this strange as I would thought transport regs would want less and storage is best at about 30%..

This is very much like another thread in the battery section where someone else added batteries but I suspect didn't ensure they were equal soc when added. He asked the question then hasn't replied despite reading the thread since!!
 

Hi @Tinbum, nice work!
Let's see how it will do once connected to the real Pylontech US battery.🤔
I am just guessing, but maybe that there's a small handshake needed? Something like:
battery announces itself as Pylontech Venus will see it, announces itself as Victron, sending "unlock" battery starts to broadcast diagnostic IDs  
AFAIK, Pylontech is not reporting it's FW version via CAN. But sends "PN" as manufacturer's name in TWO of the CAN IDs.
BTW: Here are the CAN protocol files, including V1.3 addition - will it be any help?
 
 
 
 
PYLON-CAN-Bus-protocol-low-voltage-V1.1-20161103.pdf PYLON-CAN-Bus-protocol-low-voltage-V1.2-20180408.pdf PYLON-CAN-Bus-protocol-low-voltage-V1.3-20190301.pdf

Hmm, this is interesting:
0x12 0x34 0x56 0x78 0x56 0x49 0x43 0x00
12345678VIC
 

I've been having a look at this and got the Pi set up with Venus and the CAN Hat. For testing I set up a battery emulator and watched the messages.

From the Pi their are 2;
CAN 1   MB: 0  OVERRUN: 1  ID: 0x305  EXT: 0  LEN: 8  DATA:  0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
CAN 1   MB: 0  OVERRUN: 1  ID: 0x307  EXT: 0  LEN: 8  DATA:  0x12 0x34 0x56 0x78 0x56 0x49 0x43 0x00
I then tried including the 0x307 data in my actual battery setup but it made no difference.
In my battery emulator I then added 0x70 and 0x371 data to send to the Pi, (little bit of educated guesswork here) ;
    txmsg7.id = 0x371;
    txmsg7.len = 4;
    txmsg7.buf[0] = 0x20;
    txmsg7.buf[1] = 0x0F;
    txmsg7.buf[2] = 0x0E;
    txmsg7.buf[3] = 0x1F;
    can2.write( txmsg7);
    txmsg8.id = 0x70;
    txmsg8.len = 8;
    txmsg8.buf[0] = 0xB4;
    txmsg8.buf[1] = 0x00;
    txmsg8.buf[2] = 0xAA;
    txmsg8.buf[3] = 0x00;
    txmsg8.buf[4] = 0x59;
    txmsg8.buf[5] = 0x01;
    txmsg8.buf[6] = 0x54;
    txmsg8.buf[7] = 0x01;
    can2.write( txmsg8);
I thought it may then activate the following

but no, so I suspect their must be something else. I notice in venus, on the battery details page, their is a place for firmware version and mine is unpopulated.

I'd say it doesn't really matter, both will work fine, but it would more depend on how you wish to fuse and if you want the ability to isolate if you have a problem.
 

Thanks, I've just had a quick look at my CAN and I'm already broadcasting 
10:19:32.850 -> SMA     MB: 1  OVERRUN: 1  ID: 0x305  EXT: 0  LEN: 8  DATA:  0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Now to set up a pi.