Tinbum

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.

No, it think that is the victron venus rebroadcasting it. I can't understand why their is no 0x70 and 0x371.

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

I'm honestly not sure, but balancing starts at lower voltages , 3.360v if I recall correctly on the LV battery. Again I'm not sure on the time it will take, but yes i thinks weeks is possible. It does depend on how far out they are.

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.

The manual was just one I found online using Google. You will have to ask Pylontech. I only have LV batteries so can't test. If the cells are the same as the LV, which I'm sure they will be, then they have a charge voltage 53.2v set by the bms, that would be 3.546v per cell. The LV batteries cell balance at anything over 30ma imbalance, if I remember correctly, but the actual balance current is very small, miliamps. It can therefore take a long time for cell voltages to balance. I doubt very much that the main bms will have anything to do with cell balancing- that will be left to the internal battery bms. I'm pretty certain the HV battery will be pretty well the same as the LV but the BMS will just have the facility to cope with passing a small amount of current through it to enable the other series batteries to charge when its cells are full. I'm also pretty sure that if you leave all your batteries connected and they have an imbalance they will eventually equalize but it could take a very long time. Again, I would ask Pylontech, I can't give you an answer as I don't know it..

I'd refer you back to what @Youda said above. My thinking would be the following but this is just going on educated guesswork; Each battery block will have it's own bms to look after its cells. I would expect this to incorporate safety features to protect the battery from over-voltage, cell over-voltage, temperature, etc and it will manage the balancing of the cells. This bms will also have the facility to allow current to flow through the battery (not the cells) at 100% SOC to enable all the battery packs to equalize their SOC at 100% with each other. This current will probably on be small, could well be something like 1A as shown in that other thread I linked to. I would have thought connecting a charger up to an individual battery at 52.5v would be fine and not result in any cell over-voltage as the bms would cut in. This is the same as the battery being used in service except their is no inter battery /master bms communication. If the battery will accept charge like this then this would seem to point that it was ok as otherwise Pylontech would have set the battery to isolate on lack of an inter battery communication fault. If I had a HV system I would be looking at what info was passed in the messages between the packs and asking Pylontech for the protocol. BUT - I would contact Pylontech and ask them.

Sadly this is big problem in a lot of systems, as can be seen often in this forum.

You need to download the log files from the batteries with BatteryView- that is the only and definitive way to see if the batteries have suffered over voltage.

The HV will have a BMS in each pack.

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

I would think they could be very near 100% when at 50v. My LV ones are at 88% and 49.8v at the moment.

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%..

Here I think it depends if the new ones were at a higher or lower soc when added. Depending on which way round I would either discharge or charge and once they had reached the max or min soc remove the new ones and then charge or discharge the old ones until they also reach the same max or min soc. That's if you can't charge each individually with a separate charger.

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!!

Thanks, I had the protocols except the 1.3 which seems the same except for the LV hub added. (I do have a hub, but not in use, but would need to find newer firmware for it). It's a pity their doesn't seem to be a copy of the CAN protocol showing 0x70 and 0x371 anywhere. Think I may be emailing Pylontech. Re firmware version being sent- I'd wondered if it was a new addition to the Pylontech battery firmware with Victron having the display box for it. I've tried sending 0x307 to my battery set but it hasn't initiated the 0x70 or 0x371.

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.

Thanks, I already have the hardware. The one you link to is one I've set up to try. I have a few different ones. I've got the Pi up and running but haven't connected it to my CAN bus yet. I've found date loss before using arduino but if it's a problem here I could look at swapping the chips on the board, or I could but a delay into the CAN bus.

This gets more puzzling. 🙄

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.

Interesting, does that mean that the US2000C and US3000C are going to have to get a heartbeat signal to let power out, going on the thread of the 5000 not powering up, if that proves to be correct.?

@Youda Do you know which firmware versions started broadcasting 0x371 and 0x70? I've just checked my US3000C on 2.8 and they aren't.

It's amazing how many companies don't even publish an update log. It may be possible to go back to an earlier firmware but they may also have prohibited that as well. I can see why they would introduce it to protect their products. They would probably say it's not that major as it wouldn't change anything that isn't already in their warranty terms.

Oh how they make it complicated. Personally, if pylontech have introduced this, I think its probably a good thing as, for the majority of cases it will ensure the bms is in control. It's not hard to get round though.