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