Interfacing with Valence built in monitoring

compostbrain said:

Would it be hard to adapt this to work with a 24v series attached battery bank?

Click to expand...

With series arrays you need to find a way to balance each part of the series string. The Valence batteries can do this internally, but it's hard to reverse engineer the serial comms to do this - would need access to the official Valance U-BMS hardware and a serial monitor/interceptor. As far as I know, no-one has done this yet.

Another option is to add some simple balancing hardware across each pair of 12V. This will keep the parts in balance, and then my basic BMS will take care of the rest (intra-cell balancing, voltage/temp monitoring, etc.)

Can you elaborate on what the "simple
balancing hardware" would be? What about something like this: https://www.amazon.com/7Series-Prot...y+balancer&qid=1607436582&s=industrial&sr=1-4 ?

compostbrain said:

Can you elaborate on what the "simple
balancing hardware" would be? What about something like this: https://www.amazon.com/7Series-Prot...y+balancer&qid=1607436582&s=industrial&sr=1-4 ?

Click to expand...

See point #13 here:
Where it talks about 2/4-channel balancers

compostbrain said:

Would it be hard to adapt this to work with a 24v series attached battery bank?

Click to expand...

No it wouldn't be hard but it won't balance one battery to another so you'll need an aftermarket balancer for that.
One downside about the aftermarket balancer is it does have a residual draw after balancing is complete. I know this because I had 30 batteries in series with a valance brand BMS which was doing a fine job keeping it balanced. I simultaneously put on the aftermarket balancer just across two of the batteries and it brought those two batteries down so fast that the valence BMS couldn't keep up any longer and they started to become lower voltage than the rest after only two days. for somebody who's using their system often that won't be a problem but if you plan on leaving them unattended for long periods while disconnected like, not charging or discharging at all then the balancers should also be disconnected.

One balencer should be used for every string. Do not teather the center of the strings together to try and use one balancer for the whole bank. so if you have several series strings paralleled together and you have to buy several balancers the car starts adding up and could be more expensive than a valence BMS. But maybe it's worth it for you in order to keep the open source design spoke of here in this thread?

Hello,

Here is a very basic code (nothing nice, just works) of the OpenBMS with MQTT to home assistant. I am still working on making the sensors auto-discover but no luck so far (if someone can help on this would be awesome!). Once I have that implemented, I will add all data available to MQTT. Also, I am planning to add MQTT controls to be able to discharge the batteries on a schedule (ex.: charge during the day and discharge during the night)

Hope this helps somebody

skaggetse said:

I have been building upon the foundation that t3chN0Mad started, and have built my own Raspberry Pi-based monitor for Valence XP U-charge batteries.
It's not perfect, but it works with my 11 modules in series, and probably works with more modules.
I receive SOC, Current, Module voltage, PCB temp, High Temp, Low Temp, High Cell V, Low Cell V of each battery.
I have also constructed a simple UI for visual monitoring of the data.

I'm using it to control the charge of Valence batteries in my Th!nk City -99 EV, so it's not with Solar panels in mind...
It's a much grittier project than t3chN0Mad's, with an USB-FTDI RS485 dongle and a separate Solid State Relay to end charge when first cell reach my specified voltage.

In the far horizon, I would probably build a complete EV BMS upon this foundation with contactor controls for charge and discharge, to also open contactors when voltage is low, but for now this suits my imminent need.

I leave no guarantees, and have not tested it more than briefly, but feel free to use and continue to build upon it.
I have not documented as pretty as t3chN0Mad's project either, but I think it's quite straight forward.

Included is a printscreen of the UI in action (Ran it on macOS over SSH to my Pi. The script does not work on macOS. It works in Windows if you remove GPIO-functions).
Do not run the software over SSH other than for testing, when the SSH session is terminated, the software is interrupted and stops reading, but the relay remains on.
View attachment 8423

Here's my repository (the folder RaspbPi contains my script);

GitHub - skaggetse/OpenXPBMS: Open Source BMS(Battery Management System) for Valence XP Batteries

Open Source BMS(Battery Management System) for Valence XP Batteries - skaggetse/OpenXPBMS

github.com

Click to expand...

Hey, thanks for your work on this. I have it running on a pi in my camper monitored via VNC Connect. Much better that having a Surface Pro with the Valance software.

bagmanmike said:

Hey, thanks for your work on this. I have it running on a pi in my camper monitored via VNC Connect. Much better that having a Surface Pro with the Valance software.

Click to expand...

I read the rest of the thread and wanted to acknowledge other contributions including t3chN0Mad for decoding the data.

And want to ask one question if anyone has noted - I know the internal BMS won't balance while "sleeping". But do the stats continue to update i.e. if I draw down x current/time is the internal BMS aware of that while external comms are not active? Maybe a different way of asking is will the internal BMS get out of sync with the battery under these conditions?

bagmanmike said:

I read the rest of the thread and wanted to acknowledge other contributions including t3chN0Mad for decoding the data.

And want to ask one question if anyone has noted - I know the internal BMS won't balance while "sleeping". But do the stats continue to update i.e. if I draw down x current/time is the internal BMS aware of that while external comms are not active? Maybe a different way of asking is will the internal BMS get out of sync with the battery under these conditions?

Click to expand...

I know for sure that the SOC value does not update unless the battery is kept awake. The batteries are intended to be kept awake whenever they are being used. I also found that my Victron BMV700 does a FAR better job of keeping track of SOC than the internal BMS. The only thing I use the battery BMS for is to monitor if cell voltage or temperature is out of range and balancing the cells.

Here is a teaser for you all..... It does require one of the valence bms which is another long post. I've written a windows service that communicates to the valence bms through canbus. The service then uploads all of the data to an influxdb database for grafana and a mobile android app.

Hi, I recently bought some p40-24, xp27-36 and higher voltage Valence batteries. Has anyone made an attempt to communicate with those?
Thanks.

nickskethisnikske said:

Hi, I recently bought some p40-24, xp27-36 and higher voltage Valence batteries. Has anyone made an attempt to communicate with those?
Thanks.

Click to expand...

I don't expect they would communicate any differently.

The hardware looks very much the same, the software that was written for the 12V version will need to be altered to work for 8 cells. I see the battery is awake by the message but the data is not interpreted right. Anyone knows which changes to be made, my first attempt failed?

Thanks

nickskethisnikske said:

The hardware looks very much the same, the software that was written for the 12V version will need to be altered to work for 8 cells. I see the battery is awake by the message but the data is not interpreted right. Anyone knows which changes to be made, my first attempt failed?

Thanks

Click to expand...

So is it a 24 V battery or a 36 V battery. Or are you saying that you purchased 2 different types of batteries? I think their deserving of their own thread can you start one and post a link here?

Has anyone been about to get this BMS running on a Wemos D1 mini?. This area is completely new to me. Current having a D1 mini set up on a Breadboard with a Max845 and as far as I'm aware wired up Correctly and connected up with the batteries . Loaded the code onto the D1, set the pins but not luck yet getting it work and wake up the batteries.

Alexfrood said:

Has anyone been about to get this BMS running on a Wemos D1 mini?. This area is completely new to me. Current having a D1 mini set up on a Breadboard with a Max845 and as far as I'm aware wired up Correctly and connected up with the batteries . Loaded the code onto the D1, set the pins but not luck yet getting it work and wake up the batteries.

Click to expand...

Swapped a ESP8266 for a ESP32 as I saw User aguerrejoaquin has it working and used there code with a MQTT they posted a few posts back. i haven't yet figured out how to get there MPTT stuff to working. Going to try and get Blynk to run and seeing if I can output some of the information from the BMS to Blynk.

Seems to be mostly working. in Serial monitor I "Invalid readSOC"

using a MAX485 as well.

next job in the Final assembly and mounting

Mounted to a perfboard now, wakes up the battery no issue but now have the problem of "invalid read" in the Serial monitor on seemingly all information coming from the batteries.

I am wondering if anyone has got the Arduino-XP-BMS code to work with a Mega board (I do see the ESPs above). I would like to use the Arduino Mega 2560 so I can merge this code with the code for getting a graphing interface on a LCD like in this project (https://www.nutsvolts.com/magazine/article/build-the-graphing-thermometer). I am running into compiling issues as it would appear the libraries for Teensy that are built in are not built into Arduino. I am especially having problems with the following sections of code:
I get compiling errors for this that transmitterEnable and setTX/setRX are not members of Hardware serial. I assume this is because Teensy has a built in library for this but Arduino does not. I found this library (https://github.com/sauttefk/RS485HwSerial) that appears to have many of the same functions but I am not sure what these Teensy members do and so what that would translate to in the RS485HwSerial library. Even if I do comment out the lines above that contain those I still get the following compiling errors:
HardwareSerial0.cpp.o (symbol from plugin): In function `Serial':
(.text+0x0): multiple definition of `__vector_25'
C:\arduino_build_656498\libraries\RS485HwSerial\RS485HwSerial0.cpp.o (symbol from plugin).text+0x0): first defined here
HardwareSerial0.cpp.o (symbol from plugin): In function `Serial':
(.text+0x0): multiple definition of `__vector_26'
C:\arduino_build_656498\libraries\RS485HwSerial\RS485HwSerial0.cpp.o (symbol from plugin).text+0x0): first defined here
HardwareSerial3.cpp.o (symbol from plugin): In function `Serial3':
(.text+0x0): multiple definition of `__vector_54'
C:\arduino_build_656498\libraries\RS485HwSerial\RS485HwSerial3.cpp.o (symbol from plugin).text+0x0): first defined here
HardwareSerial3.cpp.o (symbol from plugin): In function `Serial3':
(.text+0x0): multiple definition of `__vector_55'
C:\arduino_build_656498\libraries\RS485HwSerial\RS485HwSerial3.cpp.o (symbol from plugin).text+0x0): first defined here
collect2.exe: error: ld returned 1 exit status

Not a clue what these errors are. Any help would be much appreciated.

Maybe I am better going with a Teensy 3.6 and adapting the code from the graphing thermometer Mega to the Teensy? I have one laying around that I was using for another project and was able to get the code to compile for both using Teensy 3.6 so that is further than I got with the Mega.

Thanks.

redscott said:

I am wondering if anyone has got the Arduino-XP-BMS code to work with a non-teensy board. I would like to use the Arduino Mega 2560 so I can merge this code with the code for getting a graphing interface on a LCD like in this project (https://www.nutsvolts.com/magazine/article/build-the-graphing-thermometer). I am running into compiling issues as it would appear the libraries for Teensy that are built in are not built into Arduino. I am especially having problems with the following sections of code:

Code:

    #ifdef hasAutoTxEnable
        RS485.transmitterEnable(enableRS485Tx);
    #else
        pinMode(enableRS485Tx, OUTPUT);
    #endif
    RS485.setTX(RS485Tx);
    RS485.setRX(RS485Rx);

I get compiling errors for this that transmitterEnable and setTX/setRX are not members of Hardware serial. I assume this is because Teensy has a built in library for this but Arduino does not. I found this library (https://github.com/sauttefk/RS485HwSerial) that appears to have many of the same functions but I am not sure what these Teensy members do and so what that would translate to in the RS485HwSerial library. Even if I do comment out the lines above that contain those I still get the following compiling errors:
HardwareSerial0.cpp.o (symbol from plugin): In function `Serial':
(.text+0x0): multiple definition of `__vector_25'
C:\arduino_build_656498\libraries\RS485HwSerial\RS485HwSerial0.cpp.o (symbol from plugin).text+0x0): first defined here
HardwareSerial0.cpp.o (symbol from plugin): In function `Serial':
(.text+0x0): multiple definition of `__vector_26'
C:\arduino_build_656498\libraries\RS485HwSerial\RS485HwSerial0.cpp.o (symbol from plugin).text+0x0): first defined here
HardwareSerial3.cpp.o (symbol from plugin): In function `Serial3':
(.text+0x0): multiple definition of `__vector_54'
C:\arduino_build_656498\libraries\RS485HwSerial\RS485HwSerial3.cpp.o (symbol from plugin).text+0x0): first defined here
HardwareSerial3.cpp.o (symbol from plugin): In function `Serial3':
(.text+0x0): multiple definition of `__vector_55'
C:\arduino_build_656498\libraries\RS485HwSerial\RS485HwSerial3.cpp.o (symbol from plugin).text+0x0): first defined here
collect2.exe: error: ld returned 1 exit status

Not a clue what these errors are. Any help would be much appreciated. Thanks.

Click to expand...

Mine in running on a ESP32 board, I couldn't get it running my Wemos D1 Mini / ESP8266. Arguably I did just copy the code a user posted here for there version with a mqtt but mainly has as they was also running it on a ESP32 based. unfortunately this area is just way above my knowledge and skillset to actually offer any support.

But in the version, I'm using the lines
RS485.setTX(RS485Tx);
RS485.setRX(RS485Rx);

have been commented out

I can post/sent you my code tomorrow. I'm using a mega2560 uC. I even did some testing with a 2004 I2C LCD.

nickskethisnikske said:

I can post/sent you my code tomorrow. I'm using a mega2560 uC. I even did some testing with a 2004 I2C LCD.

Click to expand...

Thanks Nick! That would be amazing! I am really challenging these batteries in our rv using them to run the ac and have a solar array (not to mention in Minnesota). So I would really like to be able to get some graphical feedback as to where the voltage, temperature and SOC are at.

Ive run into an issue when is anyone can help, seems after a while my ESP32 just stops Communicating or the Comms shutdown maybe with the batteries and the batteries go back to sleep. but if I close the Serial monitor and then reopen it again it starts communicating again or if I just power the device off and on again.

I wonder if it related to the invalid read. on my breadboard version, I only had an invalid read on SOC but volts and temp were fine. on my perfboard final version, I'm no getting an invalid read from everything, the batteries are still waking up but then after a while the comms seem to stop.

any ideas?

It has been a while since I have messed with an ESP board but my guess is some kind of serial conflict. It looks like you are hooked up to serial 0 on the ESP through pins 13 and 15? If this is the case you have to very careful the Serial.swap command is used after Serial.begin. You might even need to use that with other serial commands if you are using those two pins. You could try using pins 1 and 3 which should be the same serial on the ESP (but does not need the Serial.swap commands). Does the ESP use one of the hardware serials for the WiFi? If so you would have to disable it when you are using two serial connections (one for the batteries and one for the computer). I also have a question about your battery cable hookup. I assume the silver USB cable heads to your batteries? If so what do you have on the other end? I am just making sure you don't have another rs485 converter and that it is just strait through connections.

redscott said:

It has been a while since I have messed with an ESP board but my guess is some kind of serial conflict. It looks like you are hooked up to serial 0 on the ESP through pins 13 and 15? You could try using pins 1 and 3 which should be the same serial on the ESP. Does the ESP use one of the hardware serials for the WiFi? If so you would have to disable it when you are using two serial connections (one for the batteries and one for the computer). I also have a question about your battery cable hookup. I assume the silver USB cable heads to your batteries? If so what do you have on the other end? I am just making sure you don't have another rs485 converter and that it is just strait through connections.

Click to expand...

Using Pin 16 ( TX ) & 17 ( RX ) on the ESP32 board which is Serial2, Using a ESP32 wroon 32 Dev kit C, which does have a different pinout to some of the Esp32 boards. This Arduino based BMS is the first time I've ever attempted anything like this so forgive me for missing anything obvious.

Something I need to experiment with and is probably is an issue I realised today Is I'm using a MAX485 which is 5V, Whilst the pin tolerance on ESP32 is only 3.3v So the Esp32 is Receiving 5V logic from the MAX485. Which might explain why transmitting is fine but receiving is not, Or at least why not all information is being received. Ordered a different board which can put out 3.3v logic to the ESP32

Ah yes I thought my USB port in there might raise some eyebrows. USB port wise Im just a through connector as I had some usb terminal block. no conversion going on or anything.

I made temporary naughty fix as Im only really after the Internal slave BMS to be kept awake for the Active cell Balancing to be able to function when appropriate. Things like low temperature charge cut off and low voltage cut up are managed elsewhere in my system.

but getting it working fully and being able to see the cell voltages and so on would be nice. but primarily I'm after the BMS wake-up Command being sent. so my fix currently is probably abusing the deep-sleep mode and awake timer on the ESP32. on boot my Temporary fix is to wait five seconds after the ESP32 sends the Battery BMS wake up Command batteries, then enter deep sleep mode for 1 minute ( Which shutdowns almost everything on the ESP32 ) then wake up after that minute via a 1 minute timer. Waking up for Deep sleep mode the EPS32, Basically, restarts it and Void Setup runs again which then send the Battery BMS wake up Command, waits 5 seconds and then returns to deep sleep. Basically a one minute loop. Since the BMS inside the batteries goes to sleep 120 seconds after the last BMS wake up Command / last Contact from the master BMS. since the ESP32 Wakes up every minute and resend the command the batteries stay awake permanently. ( Side-effect it's super low power consumption )

I like your workaround... very smart. I was trying to figure out what exact ESP board you have (must be the ESP32)...I misunderstood your previous post. That one does have 3 serial ports. Some of the ESP boards have a serial that is transmit only and cannot receive. That may be the case with your serial2 but I don't think so. I think the bigger issue is the 5v tolerance. It is very likely you fried that serial sending 5 volts into it. You need a logic level converter to change the 5v logic from the MAX485 to 3.3v. You might be able to get one and then just use a different serial port. This might also explain the batteries not responding as 3.3v may not be enough to trigger 5v logic in some cases.

redscott said:

I like your workaround... very smart. I was trying to figure out what exact ESP board you have (must be the ESP32)...I misunderstood your previous post. That one does have 3 serial ports. Some of the ESP boards have a serial that is transmit only and cannot receive. That may be the case with your serial2 but I don't think so. I think the bigger issue is the 5v tolerance. It is very likely you fried that serial sending 5 volts into it. You need a logic level converter to change the 5v logic from the MAX485 to 3.3v. You might be able to get one and then just use a different serial port. This might also explain the batteries not responding as 3.3v may not be enough to trigger 5v logic in some cases.

Click to expand...

Much appreciated I'm quite happy the workaround worked what I needed to in the end, Fun learning process. I think that was part of my issue when trying to get it ESP8266 D1 mini to work. that one only had 2 Serial ports. on that I think Serial is the USB and Serial1 was Transmit only, I tried to figure out the Software serial swap. Couldn't get my head around it and switch to ESP32 board I another member here I saw had it working on one.

Yeah that I may have fried the pin was in the back of my mind. All a learning process for me and at least it only a £7 board. I was originally using a Wemos D1 mini / ESP8266 which are 5v Tolerant, but switched to the ESP32 But in my ignorance didn't realise those pins only 3.3V. I got a board coming tomorrow would should work for 3.3v