Youda's off-grid LAB

[martynw]

9 hours ago, Youda said:

To be honest, if I would be skilled enough to code a perfect Pylontech HEX protocol parser

Yeah  I only did enough to get me the pack data (described in that example packet at the end of the documents).

At the moment my Inverter communicates over the RS485 port so I'm using the console and CAN ports for my own logging / reporting.  But I'm going to be switching the Inverter to the CAN port soon because their RS485 implementation isn't very good and I should get better results from the CAN port.

I just need to figure out how I can retain my own CAN port connection simultaneously, it's not something I've looked into yet but I'm hoping I can just split / parallel the cable and connect both the Inverter and my USB CAN on the RPi.

 

[___]

10 hours ago, martynw said:

I just need to figure out how I can retain my own CAN port connection simultaneously, it's not something I've looked into yet but I'm hoping I can just split / parallel the cable and connect both the Inverter and my USB CAN on the RPi.

Yup. CAN-bus is a BUS. It's two wires running from the one end to the other, with 120Ω terminators at the ends, and many modules can connect to the CAN-H and CAN-L of this bus. There is a whole arbitration and collision avoidance protocol, and everything essentially waits for a gap and then they send their data.

It's a bit like those old 10base2 Co-ax network cable setups (anyone remember those, or is it just me who is getting old?). Or perhaps another analogy, it's like your television RF cable... you can throw a splitter on it and add another tv at te end.

The only thing you have to ensure is that the bus is terminated at both ends. Often there is already a terminator built into the ends (sometimes there is a DIP switch to enable/disable it), and on a short run one missing terminator usually doesn't break the bus... but it's a good idea to ensure you don't break the termination.

[Coulomb]

On 2020/06/04 at 6:35 PM, plonkster said:

It's a bit like those old 10base2 Co-ax network cable setups (anyone remember those, or is it just me who is getting old?).

(Raises hand)

To both: remembering 10base2 and getting old  

Edit:

Quote

television RF cable...

And 300Ω ribbon and splitters for analogue TV, and the valve tuners that they connected to, usually with a 6BL8 valve (and one other).

Edited June 20, 2020 by Coulomb

[Nitheido]

On 2020/03/22 at 9:57 PM, plonkster said:

It will be changed in Venus 2.60.

Dear Plonkster,

I do hope you are staying safe during this world wide COVID 19 outbreak?

I have waited so long for the Venus 2.60 update but as of now, Victron are still at v2.54

Please can you point me to the specific script/place to update on the Venus GX where I can change the hardcoded 52v to 52.5v please? I already have root on my Venus GX and have even enabled MQTT and can harvest DBUS values to a RaspBerry Pi (wrote a Python script myself using the Paho MQTT library) which then publishes to emoncms.org

I say this to demonstrate that I am fairly confident that I can safely perform the change if only I knew where it is coming from.

Appreciate your help.

[___]

3 hours ago, Nitheido said:

Please can you point me to the specific script/place to update on the Venus GX where I can change the hardcoded 52v to 52.5v please? I already have root on my Venus GX and have even enabled MQTT and can harvest DBUS values to a RaspBerry Pi (wrote a Python script myself using the Paho MQTT library) which then publishes to emoncms.org

Look in /opt/victronenergy/dbus-systemcalc-py/delegates/dvcc.py. Look for the _pylontech_quirk routine. Inside you will clearly see the 52 value. Change it with your favourite editor. Then reload systemcalc with: svc -t /service/dbus-systemcalc-py

Or just reboot...

 

[Nitheido]

On 2020/06/27 at 7:53 PM, plonkster said:

Look in /opt/victronenergy/dbus-systemcalc-py/delegates/dvcc.py. Look for the _pylontech_quirk routine. Inside you will clearly see the 52 value. Change it with your favourite editor. Then reload systemcalc with: svc -t /service/dbus-systemcalc-py

Or just reboot...

 

Thank you very much.

I navigated to the directory ran >

cp dvcc.py dvcc.bak ----- to backup the original file...

Then > nano dvcc.py and saw the Pylon quirk and made the change.

I must say whoever wrote those scripts has a great sense of humor :):):)

I owe you a beer!

[___]

38 minutes ago, Nitheido said:

I must say whoever wrote those scripts has a great sense of humor :):):)

Thanks

 

[PierreJ]

On 2019/11/18 at 3:06 PM, plonkster said:

A DVCC system running ESS will set the solar chargers to 0.4V above the charge voltage requested by the battery (or the voltage we replace it with in the cases where we have a workaround implemented, eg 52V for pylontech). This means that at worst your batteries will rise to 52.4V. There is no regulation, ie if the Multi cannot feed all the power into the grid, it does not remove the 0.4V offset. The battery voltage simply rises that small amount.

Referencing a very old post here, but in the Venus OS 2.60 beta the Pylontech charge voltage was raised to 52.4V (we've discussed this privately), and a new feature was added to allow the limiting of the grid export. Using the latter with a low export limit (e.g. 100W) causes the charge voltage to rise to 52.8V, and sometimes briefly 52.9V. I'm regularly seeing "high voltage" alarms from the BMS at 52.8V. If I disable feed-in or allow the Multi to feed in the full excess then the voltage drops back to 52.4V and everything is fine. Perhaps 52.8V is pushing the envelope a bit, or I could just have dud batteries...

I did mention this on the Victron beta feedback forum, but since this is your department I figured I'd prod you here as well .

Edited July 16, 2020 by PierreJ

[___]

21 minutes ago, PierreJ said:

I did mention this on the Victron beta feedback forum, but since this is your department I figured I'd prod you here as well .

Yeah, I'm the guy you've been corresponding with, I thought the issue was resolved after you set it to "Keep Batteries Charged"

Pylontech batteries normally (when we use their published charge voltage and not our own) charge to 53.2V, so even at 52.8V it should be perfectly fine. It is still below 53.2V, and even if you go over 53.2V the battery should allow you to go to 54V before it freaks out (3.6V per cell). If it freaks out below 53V, you have a cell imbalance that simply has to resolve itself. Raising the charge voltage by 0.4V not only allows the battery to reach an indicated 100% SOC, but it also gives the balancers more to work with, so in the long run this change must be beneficial.

Of course this is why battery manufacturers should implement dynamic voltage control. A battery that supports this would lower the charge voltage to accommodate an imbalance, and then slowly raise the voltage as the low cell is pulled up. Sadly the more popular battery makers don't do that...

[PierreJ]

14 minutes ago, plonkster said:

I thought the issue was resolved after you set it to "Keep Batteries Charged"

I thought so too, but after a couple of cycles down to the region of 60% and back up to 100% it started throwing the warnings again.

 

15 minutes ago, plonkster said:

If it freaks out below 53V, you have a cell imbalance that simply has to resolve itself

Perhaps a recurring cell imbalance? I've been coaxing it for more than a week now, so if it was only an initial imbalance it should have been sorted by now.

Judging by the rate at which the voltage drops from 52V when discharging, and the rate at which the voltage rises above 52V when charging it's very clear that the Pylontechs store a minuscule amount of energy above that range. Presumably that means that even the tiniest of imbalances will manifest in a disproportionately large voltage differential between the cells when the battery is charged to 52V+.

It's a pity the Pylontechs don't report the individual cell states over the CAN bus. It would have been very insightful to be able to see the individual cell voltages, and whether it is always the same battery cell that is causing the warnings. If it's a dud battery I could have it replaced under warranty.

 

38 minutes ago, plonkster said:

Of course this is why battery manufacturers should implement dynamic voltage control. A battery that supports this would lower the charge voltage to accommodate an imbalance, and then slowly raise the voltage as the low cell is pulled up. Sadly the more popular battery makers don't do that...

Is it a misguided lead acid backward compatibility thing perhaps? What you're saying certainly makes a lot more sense.

I've been looking at the charge current limit that the Pylontechs report to the Cerbo, and it seems ridiculously high even when already highly charged. It's not giving itself any time to do any kind of balancing when it is approaching a fully charged state.

Thanks for the feedback.

[Youda]

4 hours ago, PierreJ said:

It's a pity the Pylontechs don't report the individual cell states over the CAN bus. It would have been very insightful to be able to see the individual cell voltages, and whether it is always the same battery cell that is causing the warnings. If it's a dud battery I could have it replaced under warranty.

For a shame, that kind of detailed info is available only via RS-485 or serial console

Anyway - how about to monitor the battery with the BatteryView diagnostic SW? Did you tried it?

[PierreJ]

25 minutes ago, Youda said:

Anyway - how about to monitor the battery with the BatteryView diagnostic SW? Did you tried it?

Not yet. I'm going to give it a few more days, and if I'm still getting high voltage warnings after that I'm going to make up the cable and dig deeper. Thanks for making it available.

Should I be worried about these high voltage warnings, or is it safe to ignore them? Presumably the BMS will shut the battery down before the cells get damaged, right?

Edited July 16, 2020 by PierreJ

[___]

6 hours ago, PierreJ said:

It's a pity the Pylontechs don't report the individual cell states over the CAN bus. It would have been very insightful to be able to see the individual cell voltages, and whether it is always the same battery cell that is causing the warnings. If it's a dud battery I could have it replaced under warranty.

New firmware is on its way that can do that. It cannot report individual levels, but it can report the lowest and the highest cell, which actually tells you everything you need to know.

24V batteries already support the low/high diagnostic info.

You're right that the battery stores very little extra above 3.45V per cell. But as Youda determined here earlier in this thread, you need 3.48V per cell to really light up the balancer... plus a little extra. The Pylontech documentation actually says 52.5V to 53.2V.

2 hours ago, Youda said:

Anyway - how about to monitor the battery with the BatteryView diagnostic SW? Did you tried it?

That's my next suggestion. That might even tell you where the high cell is. You could then also check the temperature of that cell, chances are it runs a little higher than the rest.

[Calvin]

On 2019/11/17 at 1:03 PM, Youda said:

Recommend chg voltage : 53250 mV

Hi @Youda,

I have a stack of 8 US3000s, but pwrsys command produces  "Unknown command 'pwrsys' - try 'help'".  All the other commands work as expected.  Do you have any idea as to what might cause this?

On another topic, @ThatGuyhas found that the charging voltage that the King uses when in BMS mode (in his case not Pylon) actually comes from the BMS and is not hard-coded in the inverter firmware.  Now your pwrsys command returned  recommended 53250mV which is essentially the same 53.2V and the King uses when in PYL mode.  

With the amount of overshoot that the King's SCC produces 53.2V is simply too high as has been much discussed.  So. my question is: do you know of any way to change that value in the Pylon BMS?  (I am a bit nervous to start playing with config commands - these batteries are expensive...)

If that is possible, and the King reads it to get it's target voltage, then finally we can get rid of the 53.2V problem.

[Youda]

Hi @Calvin

that makes sense, as the same values as reported by "pwrsys" command are being periodically communicated by the BMS to the inverter. For example, there are two variables for charging and discharging current that BMS is adjusting according to the actual SOC. A smart inverter should take these values into account for sure. AFAIK GoodWe does, but I'm not sure about Axpert King.

In my case, when the SOC is 60%, it says:

• Recommend chg current    : 296000   mA
• Recommend dsg current    : -296000  mA
• Recommend chg voltage    : 53250    mV
• Recommend dsg voltage    : 47000    mV

When the SOC is 95%, it says:

• Recommend chg current    : 118400   mA
• Recommend dsg current    : -296000  mA
• Recommend chg voltage    : 53250    mV
• Recommend dsg voltage    : 47000    mV

Speaking of the two Voltage values, it would be cool to have a safe way for an user to adjust these two, just like you've said. For a shame, I did not tested "config" nor "bmic" family of commands. Don't you wanna try them yourself?

 

BTW: Yes, "pwrsys" command works okay for me. Therefore, only advice I can give you is, to check whether you have the same prompt like I do: "pylon_debug>". If not, you might be using CLI in some other mode:

                                                                                                                          

 

Edited July 29, 2020 by Youda

[Calvin]

20 hours ago, Youda said:

For a shame, I did not tested "config" nor "bmic" family of commands. Don't you wanna try them yourself?

I am a bit wary, in the absence of documentation.

 

20 hours ago, Youda said:

es, "pwrsys" command works okay for me. Therefore, only advice I can give you is, to check whether you have the same prompt like I do: "pylon_debug>". If not, you might be using CLI in some other mode:

I am using RS232 into the console port - nothing fancy.  Mainly use 'pwr' command, every 2 seconds.  Have not logged in as I don't know credentials.

[Youda]

5 minutes ago, Calvin said:

I am using RS232 into the console port - nothing fancy.  Mainly use 'pwr' command, every 2 seconds.  Have not logged in as I don't know credentials.

@Calvin

•  log into the BMS console with Putty.exe (or any other terminal emulation app)
• try pwrsys command
• upload the screenshot of the result here

I believe that we can sort it out

[Calvin]

34 minutes ago, Youda said:

upload the screenshot of the result here

What I get is below:

pylon>pwrsys
Unknown command 'pwrsys' - try 'help'
pylon>

Obvious difference: my prompt is "Pylon>"  Yours is "pylon_debug>"

Perhaps the byte sequence that I use to enter console mode is different? I use "~20014682C0048520FCC3"

 

 

[Youda]

Write down "login debug"

 

[Calvin]

7 minutes ago, Youda said:

Write down "login debug"

That worked, thanks!

pwrsys now performs as expected

Thank you!

[Luminous]

Every time I see there is a new update on this thread I open it with the hope that there is a few new pics to check out the lab.

But each time I am left with disappointment...

 

[Youda]

I'm really sorry @Luminous , but there's not much interesting to share. Just everyday's boring stuff.

For example, I had to clearly label the bays in my space-shuttle landing dock, as some (female) family members were not able to clearly understand where they should (NOT) park:

 

Based on the current situation in the world, I upgraded to the AirLock. You know, just in case something goes wrong:

 

And yes, I bought another rack cabinet, so if I will accidentally become a billionaire one day, I will not have a problem with storing some additional lithium for my LAB:

 

Edited July 30, 2020 by Youda

[Luminous]

Haha.

 

That is a nice and clean cabinet installation. Just in case there is a sale on only batteries and not cabinets, then you are prepared.

[PierreJ]

On 2020/07/16 at 2:39 PM, PierreJ said:

Referencing a very old post here, but in the Venus OS 2.60 beta the Pylontech charge voltage was raised to 52.4V (we've discussed this privately), and a new feature was added to allow the limiting of the grid export. Using the latter with a low export limit (e.g. 100W) causes the charge voltage to rise to 52.8V, and sometimes briefly 52.9V. I'm regularly seeing "high voltage" alarms from the BMS at 52.8V. If I disable feed-in or allow the Multi to feed in the full excess then the voltage drops back to 52.4V and everything is fine. Perhaps 52.8V is pushing the envelope a bit, or I could just have dud batteries...

Just an update on this: Turns out it was a problematic cell in one of the batteries. Once the battery was exchanged the warnings went away and haven't come back. Thank you @Youda and @plonkster.

Oddly the firmware of the newer battery is almost a year older than the older batteries, even though the new battery was manufactured in May 2020 and the older batteries in November 2019. They seem to be working together just fine though.

For anyone considering buying Pylontech batteries, but worried about warranty and support issues: My experience has been very positive. I dealt directly with Pylontech and the process of swapping out the faulty battery for a new one was quick and painless.

[Youda]

3 hours ago, PierreJ said:

For anyone considering buying Pylontech batteries, but worried about warranty and support issues: My experience has been very positive. I dealt directly with Pylontech and the process of swapping out the faulty battery for a new one was quick and painless.

Good to know, thanks for the info!