tgalarneau/bms

BMS Interactivity

Opened this issue · 29 comments

Now that we've got reading data sorted out. I know that the App can interact with the BMS as well. I'm not so sure about changing parameters, but there is one feature that might be useful.
I've noticed a couple of times that the BT connection hangs and the reader code can't connect. Its behaving like there is already something connected to it. The only way around that seems to be to wait for a timeout/disconnect on the BMS side.

On the cellphone app there is a button on the login page that allows you to 'Fix' the bluetooth. Looks like it's just pushing a reset command to the module. That would be a useful feature to have, with a little logic that hits reset after XX service restarts.

that will of course cause hell for the App if someone was actually using it, so maybe not automate it.. but have it available as a -r command appended to the service line. That way every time you start the service and a connect is attempted it will kick over the bluetooth. Or some other non invasive way of checking for BMS availability. though that might cause a race condition between a command line launch and a service launch of the code.

Yep hence the reset. I was doing some heavy code messing-with, a few times my kludgy attempts left a connection hanging. I had to wait some time for a timeout. Your bms code would throw a couldn't connect error. I had to wait till it would accept connection again. It was at that point when I understood why they had the 'fix' button On the app.

no i get that. I'm just relaying my experience. There were several times where the module wouldn't accept a connection when the script or service was stopped. It happened after I attempted to run bad code. I suppose it also could have come from the Pi, too not being able to initiate a connection. shrug

Didn't you say you were using a Zero-W?
This is a pi4 4g booting off of a SSD. Not even a slight performance blip here.

ahh here we go:

pi@Farm-pi:~/bms $ sudo /usr/local/opt/python-3.9.4/bin/python3.9 jbdbms.py -b A4:C1:38:EC:78:4F -i 7 -m bms
Traceback (most recent call last):
File "/home/pi/bms/jbdbms.py", line 137, in
bms = bluepy.btle.Peripheral(args.BLEaddress) # Connect to bms - 2 tries
File "/usr/local/opt/python-3.9.4/lib/python3.9/site-packages/bluepy-1.3.0-py3.9.egg/bluepy/btle.py", line 411, in init
self._connect(deviceAddr, addrType, iface, timeout)
File "/usr/local/opt/python-3.9.4/lib/python3.9/site-packages/bluepy-1.3.0-py3.9.egg/bluepy/btle.py", line 462, in _connect
raise BTLEDisconnectError("Failed to connect to peripheral %s, addr type: %s" % (addr, addrType), rsp)
bluepy.btle.BTLEDisconnectError: Failed to connect to peripheral A4:C1:38:EC:78:4F, addr type: public

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/pi/bms/jbdbms.py", line 139, in
except BTLEException as ex:
NameError: name 'BTLEException' is not defined
pi@Farm-pi:~/bms $ sudo service jbdbms status
● jbdbms.service - bms Service
Loaded: loaded (/etc/systemd/system/jbdbms.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Fri 2021-04-30 21:53:05 PDT; 56s ago
Process: 10015 ExecStartPre=/bin/sleep 10 (code=killed, signal=TERM)

Apr 30 21:52:58 Farm-pi systemd[1]: Starting bms Service...
Apr 30 21:53:05 Farm-pi systemd[1]: jbdbms.service: Control process exited, code=killed, status=15/TERM
Apr 30 21:53:05 Farm-pi systemd[1]: jbdbms.service: Succeeded.
Apr 30 21:53:05 Farm-pi systemd[1]: Stopped bms Service.
pi@Farm-pi:~/bms $ sudo /usr/local/opt/python-3.9.4/bin/python3.9 jbdbms.py -b A4:C1:38:EC:78:4F -i 7 -m bms
Traceback (most recent call last):
File "/home/pi/bms/jbdbms.py", line 137, in
bms = bluepy.btle.Peripheral(args.BLEaddress) # Connect to bms - 2 tries
File "/usr/local/opt/python-3.9.4/lib/python3.9/site-packages/bluepy-1.3.0-py3.9.egg/bluepy/btle.py", line 411, in init
self._connect(deviceAddr, addrType, iface, timeout)
File "/usr/local/opt/python-3.9.4/lib/python3.9/site-packages/bluepy-1.3.0-py3.9.egg/bluepy/btle.py", line 462, in _connect
raise BTLEDisconnectError("Failed to connect to peripheral %s, addr type: %s" % (addr, addrType), rsp)
bluepy.btle.BTLEDisconnectError: Failed to connect to peripheral A4:C1:38:EC:78:4F, addr type: public

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/pi/bms/jbdbms.py", line 139, in
except BTLEException as ex:
NameError: name 'BTLEException' is not defined
pi@Farm-pi:~/bms $

and a scan:

pi@Farm-pi:~ $ sudo hcitool lescan
LE Scan ...
pi@Farm-pi:~ $ sudo hcitool scan
Scanning ...
pi@Farm-pi:~ $

I know its not signal strength. I can App connect 30ft away, and the pi is sitting 3ft away from the battery.
I waited 15 minutes and it came up fine.
k, on the gattool. I've seen it but didn't dive in.

just catching up. Got it..

The bluetooth implementation by JBD comes across as a kludge overlay of their serial interface. Using gatttool sometimes it just won't connect, no matter how many times try. But have found once connected it usually maintains the connection. Waiting usually fixes the problem. On my pi zero it does seem related to cpu, ram and heat. Works better here in morning when a little cooler or if dial back collection intervals.

Yup, that sounds exactly what I'm talking about. The Zero though. You're using a VW Bug, and I'm using a Ferrari pi with this 4g ram and SSD.
this is running Home Assistant with a bunch of other containers.
image

uhhh aparently i grabbed a 2g Pi... Well ok then. I had a bunch laying around. but still.

Trying the new code now.

the 16ell code works on mine, but the 8 doesn't. I'm not able to parse the error though... digging into it now side by side.

16cell BMS code

pi@Farm-pi:~/bms $ sudo /usr/local/opt/python-3.9.4/bin/python3.9 jbdbms.py -b A4:C1:38:EC:78:4F -i 7 -m bms
attempting to connect
connected A4:C1:38:EC:78:4F
Created socket
sending
sending
meter,cell1,cell2,cell3,cell4,cell5,cell6,cell7,cell8
bms,56580,16,3315,3310,3312,3311,3312,3311
sending
meter,cell1,cell2,cell3,cell4,cell5,cell6,cell7,cell8
bms,56580,16,3315,3310,3312,3311,3312,3311

8 cell code

pi@Farm-pi:~/bms $ sudo /usr/local/opt/python-3.9.4/bin/python3.9 jbdbms.py -b A4:C1:38:EC:78:4F -i 7 -m bms
Traceback (most recent call last):
File "/home/pi/bms/jbdbms.py", line 146, in
class MyDelegate(btle.DefaultDelegate): # notification responses
NameError: name 'btle' is not defined

oh you changed a bunch :)

Yep, i got it too. You just need to add

import atexit

sending
meter,cell1,cell2,cell3,cell4,cell5,cell6,cell7,cell8
bms,56580,16,3314,3309,3312,3310,3311,3311
meter,cellmin,cellmax,delta
bms,16,56580,56564
meter,volts,amps,watts,remain,capacity,cycles
bms,26.48,-2.15,-56.93,149,280,0
meter,c01,c02,c03,c04,c05,c06,c07,c08
bms,0,0,0,0,0,0,0,0
meter,ovp,uvp,bov,buv,cot,cut,dot,dut,coc,duc,sc,ic,cnf
bms,0,0,0,0,0,0,0,0,0,0,0,0,0
meter,protect,percent,fet,cells,temp1,temp2
bms,0,53,3,8,14.7,14.8

wait hang on a sec
image

hah! oops. I even looked at that and didn't notice the extra 0 till i compared them.

sending
meter,cell1,cell2,cell3,cell4,cell5,cell6,cell7,cell8
bms,3313,3308,3311,3310,3310,3310,3307,3313
meter,cellmin,cellmax,delta
bms,3307,3313,6
meter,volts,amps,watts,remain,capacity,cycles
bms,26.48,-2.22,-58.79,148,280,0
meter,c01,c02,c03,c04,c05,c06,c07,c08
bms,0,0,0,0,0,0,0,0
meter,ovp,uvp,bov,buv,cot,cut,dot,dut,coc,duc,sc,ic,cnf
bms,0,0,0,0,0,0,0,0,0,0,0,0,0
meter,protect,percent,fet,cells,temp1,temp2
bms,0,53,3,8,14.6,14.7

Do we need:
#sock = socket.socket(*self._socket_type,self._socket_data)
or is that legacy now?

#sock = socket.socket(*self._socket_type,self._socket_data) Is the best one to use. I just used the actual values as I thought there could be a problem. But it is used in meters-socket.py without any problems.

Got it

I have installed victoriametrics db to replace influxdb. Where influx was used 80-90 % cpu victoriametrics uses 7-8% and the ram usage is also way less. It still uses telegraf and grafana just a different port. I'm impressed. Great for a pi zero.

I'm using a monitor for my MPPT that only takes influx. I'd rather just run a single distribution point. that kind of overhead though, seems perfect for lightweight things like this.

I was out all weekend and the script ran flawlessly.
image

ohh, mqqt! nice, i'll give it a go when i'm back in front of my computer.
I was working that out on my own to take action/notifications on alarms and battery states.

running the latest iteration of the code. I haven't switched over to MQTT yet, but otherwise the 8s version is still working fine.

it is possible to monitor multiple BMS at same time ? i have 5 battery packs with 5 JBD BMS