The Hubble AM-4 without a Cloudlink identifies as a Pylontech.
As a result of the, the Pylontech quirk is applied and the CVL is hardcoded to 27.8V.
The AM-4 is a 7S NMC battery and should charge to 29V.
The SoC does not rise above 93%.
The use case here is a simple, small backup. An 800VA inverter with an AM-4 and a Cerbo-S.
I want to SSH into the Cerbo and disable DVCC so the quirk does not apply anymore.
Possible?
Oh of courseâŚ
After logging in via ssh, run dbus-spy, scroll down com.victronenergy.settings, and then to /Settings/Services/Bol and set it to 0.
Alternatively, talk to Hubble support. I believe they have new firmware that fixes the problem by not pretending to be a Pylontech battery.
Also note that in future Venus versions, we will force DVCC=on for Hubble⌠by their request.
Thank you Sir!
Yup, but then it will be per Hubble voltage and not overridden by the quirk.
Regarding their new firmware per Nelius:
"Not at this stage. We will release a firmware update for the BMS ie 4.51 that will possibly allow this. But only next year.
For now we want to make sure that all sites are working correctly with a CL then we can apply our experience to the BMS."
Yes, also this relies on the battery identifying as âHubbleâ (not Hubble-AM4 as some still do), so as long as it doesnât identify as a Pylontech (PN in bytes 4 and 5 of CAN-bus frame 0x359), it should be detected as a generic CAN-bus battery, which will also avoid the quirk.
Cool - I assume you have told them this?
I have made the change you suggested. DVCC was indeed disabled in the Settings menu but the battery was still being held at 27.8V.
I tried a reboot but then DVCC was enabled again. Is there anything else I need to do to sidestep the quirk?
Can I do something equivalent to an entry in /etc/rc.local to make it permanent?
You can edit /opt/victronenergy/dbus-systemcalc-py/delegates/dvcc.py and around like 80 you will see the lookup map with all the quirks. Simply put a # in front of the line that has _pylontech_quirk in it, or completely remove that line, and reboot the GX. That will disable the quirk.
QUIRKS = {
0xB004: _lg_quirk,
# 0xB009: _pylontech_quirk,
0xB00A: _byd_quirk,
0xB015: _byd_quirk,
0xB019: _byd_quirk,
0xA3E5: _lynx_smart_bms_quirk,
0xA3E6: _lynx_smart_bms_quirk,
}
In order to edit the file, you need to remount the rootfs read-write:
mount -o remount,rw /
Use your editor of choice, vi if you know it, but nano is also there.
And of course an update will kill it, so disable automatic updates as well.
You know you are old when your fingers automatically start typing Esc:q! as soon as you get stuck in a terminal 
Way back when I started with Linux, in 1997, it wasnât as kind as it is now. Now, if you hit ctrl+c, it tells you at the bottom of the screen what to type. Back in the 90s, it did no such thing. Emacs was slightly more welcoming, but 20 times bigger to install on your tiny hard drive, and the Unix servers on campus didnât have it.
Of course, the first time I installed Linux, I knew only two commands: ls and vi. The second one usually âlocked upâ the computer and I could only get out with a reboot⌠
I have since learned that ctrl+Z backgrounds it, and that is more useful than you may know. When working in a single terminal, you can quickly background the editor, do something else (such as running make), and then jump back to the same spot in the editor by fg-ing it.
Snap. I installed Slackware (I think?) from a LSL CD and got a mail server up in an afternoon replacing the Novell Netware box that failed / license expired or something. Been hooked since.
Long time vi user 
CTRL + Z is a winner but Iâve been using tmux / byobu a lot these days and used screen a heck of a lot in the past - most of my work was / is on remote servers and screen/tmux/byobu are basically essential for that kind of work.
PS. This seems to work even if not remounting rw
Thatâs weird⌠because the magic is one line of shell codeâŚ
# Change dvcc.py to not detect BMS as pylontech
sed -i 's/0xB009/0xAAAA/' /opt/victronenergy/dbus-systemcalc-py/delegates/dvcc.py
The -i option means âin placeâ, which basically means it changes the file and immediately writes the result over the old file. And that cannot possibly work if the filesystem isnât read-write.
Also, if a battery with productid 0xAAAA ever shows up this will break. Itâs a bit cheeky. Iâd rather delete the line:
sed -i '/0xB009: _pylontech_quirk/d' /opt/victronenergy/dbus-systemcalc-py/delegates/dvcc.py
Aaaanyway. Venus 3.00 has a feature where it will skip the quirk if the battery asks for a 16-cell voltage
What was the reason 55V was chosen?
Iâm missing some context here. Are you asking why 55V is chosen as the âdetectionâ point for a 16 cell battery? Because Iâve never seen a Pylontech battery ask for less than 3.45V per cell, and I have seen 15-cell batteries (that werenât Pylontech but identified as such) ask for 54.5V. So it is a bit of a magic number, but it seems to work. I can imagine that for other brands, eg BSL, it wonât work.
If a battery is not Pylontech but identifies as such, surely it makes sense to do whatever that BMS says?
How would I know? I mean, I know because I have eyes, but the GX doesnât. It sees the letters âPNâ in 0x359 and without any other identifying marks that it knows, it has to assume it is a very old 15-cell Pylontech battery
Edit: What we could probably do, is if the battery sends 0x35E (manufacturer name), and it contains an unknown string, then assume it is a generic CAN-bus battery. That will solve the problem for a lot of these third party batteries that copy the pylontech verbatim. I donât know how much effort it will be. I see it as an example of people making their problems mine. At some point it hurts enough to do something about it, but so far it hasnât happened yet
ctrl+Z is an unfortunate choice of keys for back-grounding. I frequently do ctrl+zz when I wanted to save with shift+zz.
I think it would be good for Victron to work as well as possible on as many batteries as possible out the box.
The current handling of batteries âmasquerading as Pylontechâ results in the âbut it works fine on other invertersâ. Your suggestion above is an excellent one - if it isnât a Pylontech made by Pylontech, then do what the BMS says.
IMHO most of them are 16S batteries, and if they had a CVL that dropped below 55V, then they would get an even lower one as a result of the quirk.
In principle I agree, that sells more inverters But it also increases the support load. But then, at least we can say ânot on the supported list, call your battery supplierâ.
Another option, which a few battery makers have implemented, is to detect that they are in a Victron system (we send 0x307 with the content 0x12 0x34 0x56 0x78 "V" "I" "C" 0x00), and modify their protocol. Or make it a configurable option. They then switch to using 0x35A for alarm messaging, and voila⌠no more incorrect detection. Not the weirdest change in the world either, SMA also uses 0x35A as does most of the BMSes that is not from China.