Are BYD LVS BatteryBox Premium batteries also supported?
dfch opened this issue · comments
Though the repo clearly states that the code is intended for HVS batteries, I would like to know whether it is known if LVS batteries are also supported?
Also onto which version of the BYD CAN protocol this information is based? Is there a reference to an "official" or publicly available BYD CAN protocol information?
Thanks for the reply!
We reverse engineered the protocol with a BYD Battery-Box Premium HVS and an Sungrow sh10rt inverter.
That's why we used a 2-channel can controller. It would be nice to have some protocol information.
Maybe someone can test it with an low voltage inverter or log the can communication of a real BYD LVS Battery-Box.
Some other tried to reverse engineer it too, but it looked mostly like Modbus RTU instead of CAN: https://secondlifestorage.com/index.php?threads/communication-between-byd-battery-and-kostal-plenticore-inverter.10513/
I have a spare BYD LVS Battery-Box where I could do some investigation (but actually hoped that someone would have already done this already ...).
The reason why I am asking this anyway is, because I am trying to implement an RS-485 to CAN converter for our battery system. Originally, I thought to emulate the target CAN protocol as "Pylontech", but they are not too well documented either. That is why I thought, BYD might be easier. But that seems not to be the case.
I will have to make up my mind on which road to go (BYD, Pylontech or something completely different).
Would have been nice, I would love to have an alternative protocol as backup or if switching to another inverter would cause problems.
Pretty difficult task to simulate 2 protocols at the same time, hope you will find a solution.
agrred - supporting two protocols would be really a benefit. I would have thought to find the BYD and other CAN protocol impementations in Venus OS (either I was not looking correctly or that part is not open source). Do you know more about this or where Victron could have that code on GitHub (or elsewhere)?
From a CAN bus perspective one should be able to run both protocols at the same time. So the question would be how "stateless" the emulation / translation from RS485 to CAN would be. If both emulators inside the driver would base on the same data model it should be possible to switch from one protocol to the other (or as I wrote before even have both protocols running at the same time). It probably also depends on the back communication from the inverter to the "battery" (if any). But if the driver could model the state of the batteries it could be updated at the same time.
There is one downside or uncertainty to reverse engineering the BYD protocol. When I set up the BMU from BYD I had to choose an inverter type. That indicates that the protocol/ communication might differ between different inverters. So, it is not clear how portable such an implementation across different vendors would be anyway.
As this is not really an issue with your driver/repo at all we can close this GitHub issue. I can still report progress if you are interested when I have some.
It appears that the BMS CAN protocol is not officially published. Tom's repository might be helpful for VE.can https://github.com/Tom-evnut/VEcan.
Should be no problem to let them running at the same time. The way we have implemented our project, we would implement a RS485 and a CAN client communicating over MQTT. So both could run on one device or separately.
I think there is no way around reverse engineering a protocol, but there will be more projects in the future and maybe some manufacturers will publish their protocols.
Happy to be interested in your progress as we won't be with BYD and Sungrow forever. Feel free to start a new discussion if there is an update. https://github.com/orgs/SunshadeCorp/discussions
I take the liberty to add my findings to this issue (and it can be kept closed). I just did not see it fit to start a new discussion just to add the info. I had a quick look at the BYD LVS CAN protocol and think, I identified most of the required messages. I created a table here: https://github.com/dfch/BydCanProtocol/blob/main/README.md
Maybe this is useful to someone else as well ...