Pytes Batteries - Victron protocole needs improvement for winter self heating

Has anyone else run into issues with Pytes batteries and self-heating in winter when paired with Victron kit?

I've got four Pytes V5s in my garden office setup, running alongside a Multiplus II and a Cerbo GX. Everything has been solid through spring and summer, but now we're heading into the colder months I'm starting to worry about how the system handles the self-heating cycle.

From what I understand, when the Pytes BMS decides the cells are too cold to accept a charge, it triggers the self-heating function and simultaneously signals the Victron system to back off. The problem is the way this handshake apparently works over DVCC — the Multiplus can interpret the "stop charging" signal rather too literally and doesn't always resume cleanly once the cells have warmed up.

Specifically, I'm wondering:

• Does the Multiplus just sit there indefinitely waiting for a charge-resume signal, or does it eventually time out and retry?
• Is there a firmware version (on either the Pytes or the VenusOS side) that handles this more gracefully?
• Has anyone adjusted the DVCC settings or written any Node-RED logic on the Cerbo to work around it?

My garden office is unheated overnight, and given we're in the UK, I'm realistically looking at sub-zero nights from November through February. The batteries are in an insulated cabinet but I wouldn't bet on it staying above 5°C in a cold snap.

I'd rather get ahead of this before I walk in one January morning to find everything in a fault state. Any experience with this combination appreciated.

Jess1972 | 47 posts

@VictronMaster Yes, had exactly this with my three V5s last winter! The issue I found was that the Victron/Pytes communication via CAN bus doesn't always trigger the self-heating mode early enough when temperatures drop overnight. By the time the BMS flags the low temp to the Multiplus II, the cells are already too cold to accept a proper charge current.

What helped me was setting a scheduled charge window in VRM for the early hours before dawn — essentially keeping the batteries topped up and slightly warm before the coldest point hits. Not a perfect fix, but it reduced the problem noticeably.

Have you checked your BMS firmware version? Pytes pushed an update last autumn that apparently improved the low-temp communication handshake. Worth checking before the next cold snap hits us! 🥶

@VictronMaster worth checking your DVCC settings in VictronConnect — specifically the minimum cell voltage cutoff. What I found with my setup is that Victron doesn't always respond fast enough to the Pytes BMS temp flags before it's already trying to push charge into cold cells.

The self-heating on the V5s does work, but the handshake between the BMS and the Multiplus II via CANBUS can be sluggish when temps drop suddenly overnight.

Temporary workaround I used last January was setting a scheduled charge window timed for mid-morning rather than relying on the automatic comms. Not elegant, but it kept things safe until Pytes pushed a firmware update.

Have you checked which firmware your BMS is running? There were a couple of releases last year that specifically addressed low-temp charge inhibit signalling.

@VictronMaster the fundamental problem here is that Pytes uses a proprietary BMS communication layer that doesn't fully expose the self-heating request flag to Victron's DVCC logic. The battery may want to heat itself but the Cerbo/CCGX never receives a clean "suspend charge until warm" signal — so you get voltage-based cutoffs instead of temperature-aware ones.

What actually works: set a minimum charge temperature threshold manually in the ESS assistant, and configure a low-SOC floor (I use 30%) to ensure the cells never sit completely flat overnight when ambient drops below 5°C. Running mine in a shepherd's hut setup, I had similar grief last February at -4°C.

@TIW_Power is right about DVCC but the min cell voltage cutoff is treating the symptom, not the cause. Sort the temperature floor first.

My Pytes V5s spent last December sulking like a British pensioner on a cold platform — turned out a firmware update on the Cerbo GX sorted the handshake delay that was stopping the self-heat kicking in before the BMS threw a strop. Worth checking you're on the latest build before pulling your hair out over DVCC tweaks.

@VictronMaster the self-heating on Pytes V5s only activates below 5°C and requires the BMS to actually request it via CAN — if your Cerbo GX firmware predates 3.10, it's silently ignoring that request entirely and your cells are just sat there shivering whilst the Multiplus II happily tries to charge them anyway, which is genuinely dangerous for cycle life.

Check vrm.victronenergy.com → Advanced → battery temperature graph; if it's flatlined at ambient during charge cycles, that's your culprit.

@DaveMoore70 nailed the firmware angle — but specifically cross-reference the Pytes BMS firmware version too; pre-1.06 had a known bug where the heating flag was never asserted regardless of temperature.

Temporary mitigation: set a DVCC charge current limit of 0A when ambient drops below 5°C until you've sorted the firmware stack.

@OldSailor nails the core issue — that BMS handshake is the weak link. What I'd add from bitter experience with my motorhome build: insulation buys you time, but doesn't solve the protocol gap.

What actually worked for me was setting a low-temperature charge cutoff in VenusOS using a temperature sensor trigger, so the Multiplus II simply refuses to charge below 5°C rather than relying on the Pytes BMS to wave its arms in time. Belt and braces.

Worth checking your DVCC settings too — some firmware versions have quirks where the charge current limit from the BMS arrives late during wake-up. There's a decent thread on the Victron Community forum documenting exactly this with V5s specifically.

Firmware on both the Cerbo and the Pytes BMS needs to be current — mismatched versions is where most people come unstuck.

@LiFePO4Nerd what exactly constitutes "bitter experience" in your motorhome context — are you saying the handshake failed entirely, or that it was delayed long enough to cause the BMS to throw a low-temperature fault before charging even began?

I ask because in my van conversion I'm trying to understand whether this is a firmware timing issue between the Pytes BMS and the Cerbo GX, or whether it's a fundamental protocol gap that no update will actually resolve. There's a meaningful difference between those two failure modes and I'd rather not buy an insulated battery enclosure if the root cause is software.