Not Pylon. SMA made the first version of the protocol as far as I know. And this isn’t even a dig at them specifically, we all know how sometimes something you threw together quickly (hence me saying slapdash… there is a time and place for slapdash) can outlive it’s original purpose significantly. This is one of them
It wasn’t done badly because the people who made it were stupid. It was done badly, probably, because nobody expected it to proliferate as much as it did.
I mean, if it was designed “properly”, we’d have the capability to address individual batteries and inverters on a single can-bus, but as it is, it is essentially point to point.
Yeah, there is nothing more permanent than a short term solution.
I was asked to create a quality control capture and reporting platform for a packhouse that needed something asap to replace the spreadsheets that were giving them headaches.
I slapped something to together on AWS and decided to drop all the QC records as json in S3 because I could use S3 as a datasource in AWS Quicksight, great, works.
Then I discovered S3 has a limit on the number of objects you can have in a bucket…
The interim solution? Achieve some of the data then delete it.
I told myself I will come up with a more permanent solution at some point
Man all you clever people makes me feel real stupid… can I create a section where these type of discussions can be hidden from normal people like me, it gives me a headache just trying to read this, let alone trying to understand it…
Part of this development is building support to aggregate information from multiple batteries, and send one set of information to the inverter which gives the total capacity/capability of the combined banks, as well as any charge restrictions required by a single bank.
If I get sufficiently bored, it may extend to a more-or-less universal battery translator, where it can communicate with virtually any collection of batteries, and spit out something that any inverter can understand.
I discovered how device addressing works on the Daly BMS protocol, and
I managed to emulate Eskom.
It seems that device addresses are not just addresses - they are priorities. So, if I use address 0x80 over Bluetooth with my new software, my existing translator running on address 0x40 does not get serviced.
So my existing translator decides the battery is fubar and sends an alarm to the inverter, which promptly shuts down, and creates a perfect Eskom simulation…
On the plus side, I have confirmed that BT comms are identical to RS485 and RS232 on the Daly BMS. Should have these last modules done shortly.
I hacked together some code to read my daly BMS from another project if you are maybe interested. If my phone connects via bluetooth I have noticed that my python code values are not coming through. Seem to recall that 0x40 is RS485 and 0x80 is bluetooth
Yep, thanks. Also already have code for reading it on Arduino.
As I have just discovered, the address is actually a priority - it responds to the highest priority request first. It seems to accept any ‘address’/priority from any channel.
Took a long weekend off to hike Blouberg, but back at the grindstone…
Can now reliably read 5 bluetooth BMSs in parallel, stitch the 4 12V batteries into a 48V bank, and then derate the 2 48V banks (based on maximum and minimum cell voltages) and finally combine them into 1 big 48V bank.
Still lots of testing to do, but looking good so far (the batteries aren’t actually connected in parallel yet, which is why the strange values):
(The nominal values are the expected ones, while the others may be derated. For parallel banks, whenever any bank has an operational value different from the nominal value, it shifts to derate mode, where it only reports the lowest parameters - hopefully making it possible for individual batteries to properly derate when in a parallel bank.)