Then I checked the power supply that's integrated into OpenEVSE's main board. And surprise #2 occurred, as the power supply had more than 80°C.

OpenEVSE's main board with the power supply (MINMAX) on the bench:

Thermal image of the OpenEVSE's power supply during operation:

For a shame, the thermal measurement sensor in the OpenEVSE is a part of LCD display board, that sits just in front of the aforementioned MINMAX ABF-04D125 power supply. Given there's high ambient air temperature, plus heat from the relay, plus heat from the power supply, it's no surprise that the wallbox feels too hot sometimes.

Since I cannot do much with the relay, I searched info on the MINMAX ABF-04D125 and found that it's has efficiency of just 75% and it's output power is quite low too (0,25A@12V and 0,12A@5V). That would explain why it gets so hot when under a load.

So I removed the supply from the board and bolted on two separate power supplies, one for 12V and one for 5V. With their power rating (0,45A@12V and 0,7A@5V) I believe that they will run much coller.

Original dual-voltage PSU vs two new PSUs (before the actual lobotomy):

OpenEVSE's main board with the new power supplies bolted on:

Luckily my lobotomy skills were good enough for the wallbox to survive and it works again

 

Edited August 17, 20241 yr by Youda
more pictures

Since I have no EV myself, I tested the wallbox with my home-made EV emulator:

Now I am waiting for some real EV to come and try it. Anyway, to me it looks like the thermal design of OpenEVSE is not the best one. The enclosure is small and water-tight sealed, location of thermal sensor in the LCD bring some issues too. I cannot speak for the relay, but to me it's strange that relay's armature is hotter than the actual contacts.

BTW, I have two such wallboxes and they behave identically. There's a new version of OpenEVSE already available, with large display (touchscreen?) where the temperature sensor is not on the LCD board, but has it's own separate board connected via I2C cable. Therefore, one can place the sensor near to the relay, far from the power supply.

 

 

Edited August 15, 20241 yr by Youda

Hi Guys, I'm new to this forum.

Does anyone know if the battery view software works with the new Pylontech Pelio batteries?
Also noticed that the Pelio's have a USB interface. Would the RS232 -> RJ45 cable still be necessary, or could
one just connect to the USB port?

Hi @Graniet,

Technically, Pylontech Pelio has all the necessary interfaces to be monitored via BatteryView. But, as fas as I know, the compatible version of the BW is not available for download yet. Even the version 3.0.29 is not designed to work with Pelio.

Anyway, the correct way to monitor and fiddle with the Pylontech Pelio is to use the WIFI module that has been packed in the wall-mount kit (or ground-standing kit). Just plug the WIFI module to the master battery of the stack, then turn the battery on and follow this manual.

https://powerforum.co.za/applications/core/interface/file/attachment.php?id=47487&key=1237ec54d25eb41c15f29481409317b0

At the end, you will be able to see the detailed info about the cells directly on your mobile phone.

 

WI-FI Set-up Guidance Pelio.pdf

Edited October 13, 20241 yr by Youda

Thanks for the reply. I have the Wifi-kit installed on the Pelio's. It is connected to my network. But the Pylontech Home app shows no battery information whatsoever. The first 2 days it showed me the SoC of the batteries, and at this moment it does not even show me that anymore.
In the app, under "Plant" and "Collector" it should show 4 connected batteries. (I have 4 batteries).
I my case, it shows "There is no sub devices".
I have opened a ticket for that in the app, about a week ago. Still waiting for a reply :-).

That's why I was looking for another tool to get more information out of the batteries.

Edited October 13, 20241 yr by Graniet
Typo's

On 2023/02/02 at 10:26 PM, Youda said:

Model: US5000 (original chip)
FW: V1.3
FLASH: US5000 ST+NT 1.3.zip

Model: US5000 (new chip)
FW: V1.3
FLASH: US5000 ST+NT 1.3.zip

 

 

hi Youda ! This post is from february 2023, have you seen anyhing more recent for the US5000 ? Especially, I know there is a version that solves a lot of bugs when used with a Victron inverter, is it 1.3 ?

AFAIK, for US5000 the latest is 1.3.

Hi,

I have a new US2000C battery (with a new chip) and the firmware installed is v2.2.

I knew the latest was v1.8 but probably Pylontech has released a new firmware.

Since I want to align all my batteries, does anyone have more information and where I can download this firmware?

Thanks

 

Edited October 28, 20241 yr by Matteo_Mantovani

Hi guys, I've just uploaded BatteryView 3.0.37 in the Files section:

Use at your own risk. And do not forget to read the instructions first.

 

On 2024/10/28 at 6:52 PM, Matteo_Mantovani said:

Hi,

I have a new US2000C battery (with a new chip) and the firmware installed is v2.2.

I knew the latest was v1.8 but probably Pylontech has released a new firmware.

Since I want to align all my batteries, does anyone have more information and where I can download this firmware?

Thanks

 

I don't understand the situation, to be honest.

FW V2.2 for US2000C/3000C (new chip) is pretty new and there's no need to upgrade it.

Do you have some other US2000C's in your stack that you want to combine together with that new one and they are running older FW version? So you're looking for V2.2 for those other batteries?

If that's the case, the V2.1 is available here on the forum in the "Pylontech Firmware Bundle". But the V2.2 is not there. Should you need V2.2, just write directly to Pylontech support, include serial numbers and ask for the FW image. The address is: [email protected]

 

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

 

On 2024/10/28 at 7:52 PM, Matteo_Mantovani said:

Hi,

I have a new US2000C battery (with a new chip) and the firmware installed is v2.2.

I knew the latest was v1.8 but probably Pylontech has released a new firmware.

Since I want to align all my batteries, does anyone have more information and where I can download this firmware?

Thanks

 

Here you are... the latest I managed to find for both old and new chip. 

From the bin file for the new chip(v2.2), it just seems they refactored some code, so no major changes from v2.1.

 

I noticed there is also support for UP5000 as well on these versions. 

 

US_C_stV2.9_NTV2.2Crc.zip

 

Edited November 1, 20241 yr by PurePower

8 hours ago, Tinbum said:

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

 

For US3000C the highest/lowest voltage cell and highest/lowest temperature cell functions were implemented in 2.1ST firmware (see the table below). For a shame, with that bad sample bug.  Fix is in the 1.7NT and 2.8ST firmware.

So, your firmware is definitely able to report these.

AFAIK the reason why you are not seeing those CAN IDs is that you must "feed" the BMS with a proper "unlock" CAN message first, in order to start broadcasting them. Normally, Pylontech is broadcasting standard IDs only, but those details are considered diagnostic IDs.

Since I am not using this feature personally, I don't know what's the actual "unlock" message, but I would try plain 0x305 : 00-00-00-00-00-00-00-00 first. If that won't work, then you can sniff the CAN comm between Pylontech and Victron Venus OS (you can put Venus on a RPi with CAN HAT).

Anyway, if you discover a proper unlock message, let me know for sure, as I'd like to store it in my knowledgebase

 

 

LINK: https://www.victronenergy.com/live/battery_compatibility:pylontech_phantom

 

 

3 hours ago, PurePower said:

I noticed there is also support for UP5000 as well on these versions. 

 

US_C_stV2.9_NTV2.2Crc.zip 235.27 kB · 5 downloads

 

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

6 minutes ago, Tinbum said:

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

Certainly not. My Pylons US2000B, US2000C & US3000C's are hooked up on my old Axpert 5KVA inverters without any comms cables. 

Edited November 1, 20241 yr by PurePower

1 hour ago, Youda said:

For US3000C the highest/lowest voltage cell and highest/lowest temperature cell functions were implemented in 2.1ST firmware (see the table below). For a shame, with that bad sample bug.  Fix is in the 1.7NT and 2.8ST firmware.

So, your firmware is definitely able to report these.

AFAIK the reason why you are not seeing those CAN IDs is that you must "feed" the BMS with a proper "unlock" CAN message first, in order to start broadcasting them. Normally, Pylontech is broadcasting standard IDs only, but those details are considered diagnostic IDs.

Since I am not using this feature personally, I don't know what's the actual "unlock" message, but I would try plain 0x305 : 00-00-00-00-00-00-00-00 first. If that won't work, then you can sniff the CAN comm between Pylontech and Victron Venus OS (you can put Venus on a RPi with CAN HAT).

Anyway, if you discover a proper unlock message, let me know for sure, as I'd like to store it in my knowledgebase

 

 

LINK: https://www.victronenergy.com/live/battery_compatibility:pylontech_phantom

 

 

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.

2 minutes ago, PurePower said:

Certainly not. My Pylons US2000B, US2000C & US3000C's are hooked up on my old Axpert 5KVA inverters without any comms cables. 

 

3 minutes ago, PurePower said:

Certainly not. My Pylons US2000B, US2000C & US3000C's are hooked up on my old Axpert 5KVA inverters without any comms cables. 

This gets more puzzling. 🙄

Puzzling it is, but there's still a pattern going on. If you open all the historical BIN files, you can see this:

• firmware line X = US3000 only
• firmware line Y = US3000C + US2000C + UP5000
• firmware line Z = US5000

BTW: Support for UP5000 was included in the US3000C firmware line for years. Contrary, US5000 has it's own firmware line, incompatible with everything else.

So, even if US5000 at FW1.9 needs a heartbeat to stay alive (as we are being told now) this has no effect on US2000C and US3000C. At least, until Pylontech will decide to implement it specifically for these.

 

Makes sense?

7 hours ago, Tinbum said:

Now to set up a pi.

If it's still time you may have a look at this page : https://github-wiki-see.page/m/victronenergy/venus/wiki/RaspberryPi-CAN-Interfaces

 

Right now this one works fine for me : https://www.waveshare.com/wiki/2-CH_CAN_HAT

 

But there seems to be something with risk of losses, so you may consider this : https://github.com/SebKuzminsky/mks-canable-2.0-pro/blob/main/README.md

39 minutes ago, Shortcut said:

If it's still time you may have a look at this page : https://github-wiki-see.page/m/victronenergy/venus/wiki/RaspberryPi-CAN-Interfaces

 

Right now this one works fine for me : https://www.waveshare.com/wiki/2-CH_CAN_HAT

 

But there seems to be something with risk of losses, so you may consider this : https://github.com/SebKuzminsky/mks-canable-2.0-pro/blob/main/README.md

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.

Edited November 1, 20241 yr by Tinbum

On 2024/11/01 at 8:35 AM, Youda said:

For US3000C the highest/lowest voltage cell and highest/lowest temperature cell functions were implemented in 2.1ST firmware (see the table below). For a shame, with that bad sample bug.  Fix is in the 1.7NT and 2.8ST firmware.

So, your firmware is definitely able to report these.

AFAIK the reason why you are not seeing those CAN IDs is that you must "feed" the BMS with a proper "unlock" CAN message first, in order to start broadcasting them. Normally, Pylontech is broadcasting standard IDs only, but those details are considered diagnostic IDs.

Since I am not using this feature personally, I don't know what's the actual "unlock" message, but I would try plain 0x305 : 00-00-00-00-00-00-00-00 first. If that won't work, then you can sniff the CAN comm between Pylontech and Victron Venus OS (you can put Venus on a RPi with CAN HAT).

Anyway, if you discover a proper unlock message, let me know for sure, as I'd like to store it in my knowledgebase

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.

Edited November 2, 20241 yr by Tinbum

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:

1. battery announces itself as Pylontech
2. Venus will see it, announces itself as Victron, sending "unlock"
3. 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

Edited November 2, 20241 yr by Youda

1 hour ago, Tinbum said:

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.

Hmm, this is interesting:

0x12 0x34 0x56 0x78 0x56 0x49 0x43 0x00

12345678VIC

 

Edited November 2, 20241 yr by Youda

Pylontech High Voltage Battery UnBalancing Problem

 

Greetings! A new forum member here,

Respected forum members Youda and other worthy members who have the experience of using Pylontech High Voltage Battery system may kindly provide the possible solutions to the following Problem.

System Information:
We have a Residential 10kW Hybrid Inverter attached to Pylontech High Voltage Battery Pack with a total capacity of 14.4kWh.
BMS is Pylontech SC0500-40 (37Amps), it communicates with the inverter via CAN BUS protocol,
Battery Modules are Pylontech H48050, 2.4kWh (50Amps) each,
6 Battery modules are connected to the BMS (initially 4 modules, with addition of 2 more modules).

Problem:

·        To keep it simple we will take the example of 3 Batt. modules connected to the BMS.

·        Initially when batteries are charged, 2 batt. modules have Balanced Cell Voltages i-e difference of 20milli Volts between the cells and this is maintained all the way to 100% charging.

·        3^rd batt. module has UnBalanced cells with Voltage Delta of more than >100milliVolts(0.150Volts) between minimum and maximum cell voltage.

·        The BMS first charges all the modules to 100% State of Charge (SOC) and then balances the cell voltages to around 3.4Và3.3Volts with SOC at 100%.

·        During Discharge cycle when the SOC reaches 45% the Batt. module which was initially having UnBalanced cell voltages (but later it was balanced by BMS) just drops the SOC from 45% à35% à20% which is the Cut off for the BMS. At this stage its cells voltage also become UnBalanced Again.

·        While the remaining 2 Batt.modules which had initially balanced cell voltages remain at 45% SOC.

Queries:

1.      If the BMS balances all the 45 cells in 3 batt. modules at a specific voltage repeatedly, then why one module drops State of Charge (the one with the initial ImBalanced Cells)?
and it does Not seem to be a problem with one particular module, by hit and trial the UnBalanced module can become balanced and Another module may start to have Unbalanced Cell Voltages.

2.      The basic issue seems to be cell UnBalancing.
 

3.      During every charging cycle, the cells of one of the Batt module become UnBalanced, but the Pylontech BMS  Balances the cells on daily basis after SOC reaches 100% , however at the next discharge/charging cycle the cells are UnBalanced again? And again the BMS balances all. Why is this so? This has continued for 2 months now.
 

4.      During Discharge cycle, why the cells become UnBalanced below 45% (SOC) and the battery charge rate drops suddenly if the BMS has balanced the cell during charging cycle?
 

The overall effect is that the Backup Time of the Battery is Cut by Half.
 

Solution to the above problem will be highly appreciated.
 

Have attached a few pictures from Battery View Software here:

Edited November 13, 20241 yr by PylonHV

16 hours ago, Youda said:

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:

1. battery announces itself as Pylontech
2. Venus will see it, announces itself as Victron, sending "unlock"
3. 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?

 

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.