New DIYish battery build

Batteries
21

I was referring to working with DateTime values in programming logic.
Its easy when you are working with dates formatted in ISO 8601, but when you start working with a value that is going between ISO 8601 (2023-02-10T07:44:48.582Z) and Unix Time (ms since 1 January 1970 in UTC)
You need to standardize otherwise it can lead to weird results.

Some DBMS’s also don’t support DateTime fields like Sqlite (Sqlite also doesn’t support Boolean) so sometimes you will end up storing a DateTime value as Unix Time.

22

Amazing that these ‘standards’ are not cast in stone.
Next thing is they’ll forget how they did that…

23

Time is always stored in UTC. Always. It is converted to the right timezone at the time it is displayed to the end user.

Even on the Victron Venus devices. Everything runs UTC. The few items that need local time make sure to set it when they start up, or when it changes.

Everything logged to VRM is in UTC too. When drawing the charts or downloading the data, it is converted to the right time zone.

Something that used to break my brain (not quite as hard as how unicode relates to its various codings, but close), is the unix timestamp. This is the number of seconds since 1 January 1970, as the day started, but the part people forget is that it is always in UTC. Always.

A unix timestamp of zero, is 10PM on 31 December 1969… if your context is South Africa. If you ever wonder how I know… just imagine that some time in the recent past I had to deal with a weird date in a customer complaint, and I was probably wondering how in the world we ended up in 1969 without a negative timestamp… :slight_smile:

Now what gets even more tricky, is when DST comes in, and you cannot necessarily assume that remains the same. For example, you may think that you can do some of your time math by simply using seconds since the start of the day, on 1 January 1970… easy easy… except, if you are in Europe/London Time Zone, then you need to know that London was 1 hour ahead of UTC in January 1970. Your math works perfectly until someone from England uses it…

Again… no need to ask why I know that :slight_smile:

2 Likes
24

Yup, its something I learnt the hard way (In my defense it was a legacy system that worked on localtime and no one thought it would ever need to support more than one timezone) so all times were saved in GMT+2

Time to get our signatures in!

25

Instead of using an EP32board, please start investing time in Cerbogx listening/talking straigth to BT connected batteries
Ah this fell out of context as I was reacting on early plans and not reading the rest of the messages yet.
What I mean to say is how wonderful would it be if JKBMS for example is read throught BT straigth into the CerboGX and tunnels into Louis serial battery script. So many BT connected batteries and BMS’s on the market now.

26

I do not have a Victron system - so that would need to be someone else’s game.

But there is a simple python script:

that emulates a serial port for Bluetooth connected devices, so it should be possible to use Louis stuff with this as an intermediary.

27

Very interesting info. My challenge is I manage many Victron systems with more and more self build recycled automotive batteries with often BMS including Bluetooth option. But I’m a very weak programmer. Can only read and make minor changes to someones code. (preferable Python) Which is exactly what your link gives. I’ll give it a good read. But the real difficulty will be that the serial protocol out of JKBMS that works with Louis code is most likely very different than the info streaming out of the BT connection. Hopefully someone else is interested to help. Bounty can be discussed

28

BTW Are you sure that these have a 10 year warranty. Was at GC solar this weekend and they told me it has a 3 year warranty.

There sure does mention 10 year under the specs but I suspect that was a mistake.

29

Interestingly enough the warranty certificate on the GC Solar website from the manufacturer also specifies the warranty as 3 years for UPS use and only 2 years in Solar use.

Here is the warranty certificate if anyone is interested.

30

From what I have seen, the BT connection seems to be a UART module plugged into the stadard UART port on the BMS, so comms should be identical. Just fire up ble-serial, and point your battery driver to the fake tty it creates.

31

I see they have vhanged their website w.r.t. the warranty, but I did print a copy showing the 10 year warranty when I bought it. If there are issues later, then they can either honour it, or fight it with the NCC.

32

Whee! Blinkenlights!

IMG_20230216_185919
IMG_20230216_1859191920×2560 350 KB

Using 12v bulbs as dummy loads for now, as they are the cheapest 20W resistors available :wink: .

Reliably reading all 4 batteries in a nice modular system.

It is approaching usable, so I have made the repo visible:

Next steps:

  1. finish watchdog code
  2. add Daly BMS support
  3. add parallel and series drivers
  4. add derate code
  5. add pylon CAN output…

Still lots to do, but hopefully all the tough nuts are cracked.

3 Likes
33

Pleast don’t copy the 0x359 frame exactly… :slight_smile:

34

I will build 0x359 exactly as per their protocol document:

image

:wink:

35

Its crazy to think that a certain popular battery manufacturer did exactly that…

36

Fully noting that wink and all… this is the part that makes life hard for others :slight_smile:

pn

If you do copy 359, just put zeroes in there or something.

37

No man… “B” and “G” = Bak Gat Battery!

38

I will try again, but older versions of Deye firmware did not recognise the battery without those tags.

But seeing as those are fixed values in the documented protocol, I don’t see how they can complain about anything.

39

Right… so some history here :slight_smile:

There is another frame, 0x35E, which has the manufacturer name, but this frame wasn’t always there. Early Pylontech batteries didn’t have it. The only way to detect those, is to look for the PN in 0x359.

What is more, there are two other battery makers that use 359 as well, without the PN (Muratta and LG).

Then others copied the “pylontech protocol” exactly, and that means inverters that had support for those older Pylontech batteries started incorrectly detecting those batteries as Pylontech batteries. And sadly cannot stop doing so, otherwise support for older installations is lost.

That is why I ask people not to do it. If you’re not a Pylontech battery, don’t claim to be one (unless, as in your case, it’s a personal project and it is the only way to get it to work at all).

Further to that, I dislike the 0x359 for other reasons too. The Warnings (Protection) and Alarms are on that frame, but it is limited to an on/off bit. Some other batteries use 0x35A for this, and allocates two bits to each alarm/warning, which allows the battery to also communicate which warnings or alarms are supported. Much better.

I have other issues with the protocol as well, but that is not specific to any particular manufacturer. For example, they original protocol specified the maximum charge/discharge currents as a 16-bit SIGNED integer. Why, when the number will never be negative?

What is more, they provided for one decimal place, which allows you to specify charge current to the nearest 100mA, a feature absolutely nobody uses, and which limits the maximum charge/discharge current to 3276.7A. Sounds like a lot, but in the same manner that 640kb of RAM was a lot, this is no longer true.

Then we get to the SOC on 0x355, where a decimal place WOULD have been nice, and there is ample space for it in the data type… but none was provided. Also, if a decimal place was not envisioned, why would you allocate 16-bits for the SOC, if the maximum number is 100 (which fits in 8 bits)?

A perfect example of a slapdash protocol that is now the defacto standard :slight_smile:

40

As a whole, the solar industry is rather pathetic.

In the ideal world, there would be an industry body creating standards, which everybody needs to adhere to if they want to be usable.

Imagine if all batteries had a standard protocol (rather than bodged extensions on top of Pylon’s dodgy one). All MPPTs spoke the same language. All chargers. Etc.

Would be able to parallel any equipment, or extend any system with any mix of components from any manufacturer.

Almost all hardware is capable of this on a hardware level, but all software follows Crapples walled garden model to try and lock people in.