Louisvdw Posted September 2, 2020 Share Posted September 2, 2020 23 minutes ago, shanghailoz said: Canbus over RS485<-> to a Ve.direct usb adaptor Nice. If you know where to get the communications protocol specs from the supplier then my software driver should be able to do this as well. At the moment it is only working with 1 BMS brand, but if there are people with other batteries that we can get the commands for it would be great to add to the driver. What information does the Canbus over RS485 cable give you. What values are coming through from the BMS? If you go to the details of your battery in your Remote Console for your VenusPi what values does it give you compared to the first 3 pictures in my post here Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted September 2, 2020 Author Share Posted September 2, 2020 (edited) I won't lie, I've been watching your post with interest already The "RCU" BMC doesn't push much data over to the Victron - looks like a bare minimum. i.e. Voltage, Amps / Watts / SoC. The PC based BMS software can drill down to battery state, and see other details. I'll need to organize a cable then do some digging to see whats available from the BMS itself. I don't have a copy of their data sheet, but worst case can sniff. I have a ton of RS232 -> USB but no 485's! here. I also don't have any tools this side - all my goodies are back in China, so will need to buy some bits n bobs and with some draw - Definitely bare minimum - as none of the other data is populated eg Edited September 2, 2020 by shanghailoz Quote Link to comment Share on other sites More sharing options...
Louisvdw Posted September 2, 2020 Share Posted September 2, 2020 1 hour ago, shanghailoz said: The PC based BMS software can drill down to battery state, and see other details This means the data is available. That cable just does not publish it. The basics is all that is required, but the rest is very nice to have. 1 hour ago, shanghailoz said: but no 485's! here I can confirm that this one does work with the VenusOS Pi. The drivers are already available and loaded. 1 hour ago, shanghailoz said: I don't have a copy of their data sheet Most suppliers will send this if you ask them. Just try sending a few mails. It much easier that trying to sniff commands if you have the spec. Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted September 2, 2020 Author Share Posted September 2, 2020 Yes, I was pointing out the same thing That cable is out of stock, I did look already. I haven't bothered asking yet, given the few data points I don't think will be too hard to plumb the depths of the protocol! Quote Link to comment Share on other sites More sharing options...
Louisvdw Posted September 2, 2020 Share Posted September 2, 2020 1 hour ago, shanghailoz said: That cable is out of stock This one use the same chip and should work as well.This HAT is also confirmed to work by one of the forum users. You do need to edit the config file for the Pi to load it though and I don't know if the HAT will work with the serial-starter that the VenusOS use. Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted September 8, 2020 Author Share Posted September 8, 2020 Have ordered the waveshare rs485 adaptor, will play when i get it in a few days. Ideally I can adapt your python script once I have an idea of what the modbus fields are likely to be for the various parameters. Louisvdw 1 Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 2, 2022 Author Share Posted May 2, 2022 Revisiting this a few years later! Have downloaded your script, need to see how to get it to work. I have 3 devices connected to my PI. 2 x Victron cables + an RS485 cable. The modbus adaptor seems to be on usbtty0 (after grepping dmesg to see where it got populated) lsusb Bus 001 Device 006: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO) Bus 001 Device 005: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO) Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC Unplugging/plugging in confirms thats correct. udevadm info --query=property --name=/dev/ttyUSB0 DEVLINKS=/dev/serial-starter/ttyUSB0 /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AC00XXY2-if00-port0 /dev/serial/by-path/platform-3f980000.usb-usb-0:1.2:1.0-port0 DEVNAME=/dev/ttyUSB0 DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0/tty/ttyUSB0 ID_BUS=usb ID_MODEL=FT232R_USB_UART ID_MODEL_ENC=FT232R\x20USB\x20UART ID_MODEL_FROM_DATABASE=FT232 Serial (UART) IC ID_MODEL_ID=6001 ID_PATH=platform-3f980000.usb-usb-0:1.2:1.0 ID_PATH_TAG=platform-3f980000_usb-usb-0_1_2_1_0 ID_REVISION=0600 ID_SERIAL=FTDI_FT232R_USB_UART_AC00XXY2 ID_SERIAL_SHORT=AC00XXY2 ID_TYPE=generic ID_USB_DRIVER=ftdi_sio ID_USB_INTERFACES=:ffffff: ID_USB_INTERFACE_NUM=00 ID_VENDOR=FTDI ID_VENDOR_ENC=FTDI ID_VENDOR_FROM_DATABASE=Future Technology Devices International, Ltd ID_VENDOR_ID=0403 MAJOR=188 MINOR=0 SUBSYSTEM=tty USEC_INITIALIZED=3679573 If I tail the serial logs I can see that its trying to assign a driver repeatedly. tail -F /data/log/serial-starter/current | tai64nlocal 2022-05-02 09:38:00.441561500 INFO: Start service dbus-serialbattery.ttyUSB0 once 2022-05-02 09:38:09.701031500 INFO: Start service gps-dbus.ttyUSB0 once 2022-05-02 09:38:18.973991500 INFO: Start service vedirect-interface.ttyUSB0 once 2022-05-02 09:38:24.202539500 INFO: Start service dbus-cgwacs.ttyUSB0 once 2022-05-02 09:38:29.425260500 INFO: Start service dbus-fzsonick-48tl.ttyUSB0 once 2022-05-02 09:38:32.627069500 INFO: Start service dbus-imt-si-rs485tc.ttyUSB0 once 2022-05-02 09:38:35.840616500 INFO: Start service dbus-modbus-client.serial.ttyUSB0 once 2022-05-02 09:38:39.047054500 INFO: Start service dbus-serialbattery.ttyUSB0 once 2022-05-02 09:38:48.313591500 INFO: Start service gps-dbus.ttyUSB0 once 2022-05-02 09:38:57.578868500 INFO: Start service vedirect-interface.ttyUSB0 once 2022-05-02 09:39:02.803860500 INFO: Start service dbus-cgwacs.ttyUSB0 once If I check the serial-starter.conf cat /etc/venus/serial-starter.conf service cgwacs dbus-cgwacs service gps gps-dbus service modbus dbus-modbus-client.serial service modem dbus-modem service mkx mk2-dbus service vedirect vedirect-interface service fzsonick dbus-fzsonick-48tl service imt dbus-imt-si-rs485tc alias rs485 cgwacs:fzsonick:imt:modbus alias default gps:vedirect include /data/conf/serial-starter.d I see that there is already a rs485 set of drivers? Should I disable those? cat /data/conf/serial-starter.d service sbattery dbus-serialbattery Does show sbattery added (i assume this is what you've called the service) Looking at the logs root@raspberrypi2:/opt/victronenergy/dbus-serialbattery# tail /var/log/dbus-modbus-client.ttyUSB0/current -F | tai64nlocal 2022-05-02 09:44:23.410207500 /opt/victronenergy/serial-starter/run-service.sh: line 5: shift: 2: shift count out of range 2022-05-02 09:44:24.661635500 INFO Waiting for localsettings 2022-05-02 09:44:24.686419500 INFO Starting background scan 2022-05-02 09:44:24.688038500 INFO Scanning ttyUSB0 @ 38400 bps (quick) 2022-05-02 09:44:26.005016500 INFO Scan complete 2022-05-02 09:45:02.054384500 /opt/victronenergy/serial-starter/run-service.sh: line 5: shift: 2: shift count out of range 2022-05-02 09:45:03.259235500 INFO Waiting for localsettings 2022-05-02 09:45:03.283734500 INFO Starting background scan 2022-05-02 09:45:03.285313500 INFO Scanning ttyUSB0 @ 38400 bps (quick) 2022-05-02 09:45:04.602015500 INFO Scan complete I see an error with the run-service.sh script. normal? You think the best way will be to take one of the existing BMS in your script and modify for the relevant modbus addresses? I have the data sheet for the BMS attached. REVOV.Modbus.communication.protocol.v1.pdf Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 2, 2022 Author Share Posted May 2, 2022 (edited) The modbus docs appear to be utterly incorrect. Had a bit of a play using the manual modbus registers, and no luck, so opened up the BMS software and did some serial sniffing instead. Of course the address is not at 01 that would be too easy, seems to be using 0x7C (124). Having fun though, hopefully I can hack together a revov "tianpower" driver. Edited May 2, 2022 by shanghailoz Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 2, 2022 Author Share Posted May 2, 2022 (edited) Either I'm doing something wrong (or its just not modbus). [Narrator: It wasn't modbus, its modbus"ish", gah! ] Some command data samples ------ 7C 01 33 00 FE 0D -> Get name. Returns 7C 01 33 Length + [data] + checksum? + endline (0xd) eg 7c 01 33 16 54 50 2d 42 x x x x T P - B 44 31 36 53 34 38 56 31 D 1 6 S 4 8 V 1 35 30 2d 56 33 2e 31 2e 5 0 - V 3 . 1 . 32 39 e2 0d 2 9 [crc?] [newline] TP-BD15S48V150-V3.1.29 ----- 7C 01 42 00 80 0D -> Get Model Number. Returns 7C 01 42 0F 54 42 4D 31 x x x [length] T B M 1 39 30 34 31 33 30 30 32 9 0 4 1 3 0 0 2 36 33 20 8C 0d 6 3 [crc?] [newline] Edited May 3, 2022 by shanghailoz Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 2, 2022 Author Share Posted May 2, 2022 (edited) Quote 2022-05-02 16:28:57.625069500 ERROR:SerialBattery:Revov::False 2022-05-02 16:28:57.625493500 ERROR:SerialBattery:Data is False 2022-05-02 16:28:58.126764500 WARNING:SerialBattery:Testing Revov 2022-05-02 16:28:58.167072500 ERROR:SerialBattery:serial data length 22 2022-05-02 16:28:58.167507500 ERROR:SerialBattery:lc-1 2022-05-02 16:29:14.089183500 ERROR:SerialBattery:bytearray(b'|\x01B\x0fTBM19041300263 \x8c\r') 2022-05-02 16:29:14.089602500 ERROR:SerialBattery:>>> ERROR: No reply - returning (count>150) 2022-05-02 16:29:14.090844500 ERROR:SerialBattery:b'|\x01B\x00\x80\r' Starting to take shape. Have some debugging up to see the passed result within the serial driver code although the python read_serial_data that @Louisvdw has isn't commented that well. Need to work out what LENGTH_POS, LENGTH_CHECK are as its not that obvious in utils.py code LENGTH_POS should be the start offset - at least looking at the code, although if i change it, I don't see my data changing. LENGTH_POS is the offset starting from 0 bytes for packet length. PACKET_LENGTH might be a bit more obvious imho. LENGTH_CHECK not quite sure yet. At least its talking and giving back a response, even though I need to get the returned values to work correctly with the read_serial_data(command, port, baud, length_pos, length_check, length_fixed=None, length_size=None) function. Edited May 2, 2022 by shanghailoz Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 2, 2022 Author Share Posted May 2, 2022 (edited) Quote 2022-05-02 18:11:13.686966500 WARNING:SerialBattery:dbus-serialbattery v0.1 2022-05-02 18:11:13.687686500 WARNING:SerialBattery:Testing Revov 2022-05-02 18:11:13.827072500 ERROR:SerialBattery:Revov TP-BD16S48V150-V3.1.29 2022-05-02 18:11:14.004604500 ERROR:SerialBattery:Revov ver ( TBM19041300263 ) 2022-05-02 18:11:14.005181500 WARNING:SerialBattery:Connection established to Revov Getting further. Have worked out what it was trying to do. LENGTH_CHECK = 0 LENGTH_POS = 3 #offset starting from 0 byte for packet length LENGTH_FIXED = -1 Works out. I can now call and read 2 settings. command_get_version = b"\x7C\x01\x42\x00\x80\x0D" #Get version number command_get_model = b"\x7C\x01\x33\x00\xFE\x0D" #Get model number Will work a bit further tomorrow. I need to sniff some more serial to see what it needs to query cells and other values. Happy with todays progress though. I'm using logger.error for my current output (hence the "error serial" above, as logger.info doesn't display in the logs). Edited May 2, 2022 by shanghailoz Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 2, 2022 Author Share Posted May 2, 2022 (edited) Some more work to get the driver loaded (fake hard coded data!), but its appearing now in the Victron side. My logs looking good too 2022-05-02 19:16:58.577040500 WARNING:SerialBattery:dbus-serialbattery v0.1 2022-05-02 19:16:58.577708500 WARNING:SerialBattery:Testing Revov 2022-05-02 19:16:58.638016500 WARNING:SerialBattery:Modbus Address: 124 2022-05-02 19:16:58.638502500 WARNING:SerialBattery:Modbus Type : 1 2022-05-02 19:16:58.638950500 WARNING:SerialBattery:Modbus Command: 51 2022-05-02 19:16:58.639399500 WARNING:SerialBattery:Modbus PackLen: 22 2022-05-02 19:16:58.639836500 WARNING:SerialBattery:== Modbus packet good == 2022-05-02 19:16:58.640329500 ERROR:SerialBattery:Revov TP-BD16S48V150-V3.1.29 2022-05-02 19:16:58.787653500 WARNING:SerialBattery:Modbus Address: 124 2022-05-02 19:16:58.788143500 WARNING:SerialBattery:Modbus Type : 1 2022-05-02 19:16:58.788595500 WARNING:SerialBattery:Modbus Command: 66 2022-05-02 19:16:58.789043500 WARNING:SerialBattery:Modbus PackLen: 15 2022-05-02 19:16:58.789478500 WARNING:SerialBattery:== Modbus packet good == 2022-05-02 19:16:58.789910500 ERROR:SerialBattery:Revov ver ( TBM19041300263 ) 2022-05-02 19:16:58.790313500 WARNING:SerialBattery:Connection established to Revov 2022-05-02 19:16:58.837810500 WARNING:SerialBattery:Battery connected to dbus from /dev/ttyUSB0 Slowly slowly! This one is actual data pulled from the hardware (not hard coded) Hardware version is being populated correctly Edited May 2, 2022 by shanghailoz Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 2, 2022 Author Share Posted May 2, 2022 (edited) revov.py Code so far In order to test, will also need to be added into dbus-serialbattery.py by adding (under import logging line ) from revov import Revov and in the battery_types array add another line for Revov(port=_port, baud=9600), ---- This is a work in progress This only loads the driver so far, and shows the Hardware revision and Hardware version data. Some data is hard coded so that the driver loads successfully. These vars - self.soc =70 self.voltage = 52.7 self.current = 6 self.cell_min_voltage = None self.cell_max_voltage = None self.cell_min_no = None self.cell_max_no = None self.cell_count = 16 Victron Side will display: Edited May 2, 2022 by shanghailoz Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 2, 2022 Author Share Posted May 2, 2022 (edited) Two more commands command_one = b"\x7C\x01\x06\x00\xF8\x0D" #returns 4 bytes 2022-05-02 20:08:48.202980500 WARNING:SerialBattery:bytearray(b'|\x01\x06\x04\x00\x00\x0e\xa6') [ 0x7c 0x01 0x06 ] [ 0x04 ] [0x00 0x00 0x0e 0xA6] [ 0xec] [0x0d] [Modbus addr/reg/cmd] [length] [ data 0x0 0x0 0xe 0xA6] [Checksum?] [LF] 2022-05-02 20:08:48.202980500 WARNING:SerialBattery:bytearray(b'|\x01\x06\x04\x00\x00\x0e\xa6') 2022-05-02 20:08:48.204063500 WARNING:SerialBattery:Modbus Address: 124 2022-05-02 20:08:48.205698500 WARNING:SerialBattery:Modbus Type : 1 2022-05-02 20:08:48.205704500 WARNING:SerialBattery:Modbus Command: 6 2022-05-02 20:08:48.206214500 WARNING:SerialBattery:Modbus PackLen: 4 2022-05-02 20:08:48.206727500 WARNING:SerialBattery:== Modbus packet good == ----- command_two = b"\x7C\x01\x01\x00\x02\x0D" #returns a ton of data (118 bytes) eg 2022-05-02 20:08:48.532293500 WARNING:SerialBattery:bytearray(b"|\x01\x01v\x01\x10\x0c\xf1\x0c\xf5\x0c\xf5\x8c\xf4\x0c\xf2\x8c\xf2\x0c\xf4\x8c\xf5\x0c\xf2\x0c\xf2\x0c\xf6\x0c\xfa\x0c\xf4\x0c\xf4\x0c\xf6\x0c\xf7\x02\x01w\xc1\x03\x01!^\x04\x01FP\x05\x03\x00H\x00H I\x06\x05\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00\x07\x01\x00\x85\x08\x01\x14\xba\t\x01\'\x10\n\x01\x00\x00\x0b\x01\x00\x00\x82\xc0\x0c\x01\x00\x007\xae\r\x01\x00@\x00\x00\x0e\x01\x00@\x00\x00\x0f\x01\x00\x1a\'\xe5\x10\x01\x00\tW\xad\x0e\r") 2022-05-02 20:08:48.532318500 WARNING:SerialBattery:Modbus Address: 124 2022-05-02 20:08:48.532426500 WARNING:SerialBattery:Modbus Type : 1 2022-05-02 20:08:48.532430500 WARNING:SerialBattery:Modbus Command: 1 2022-05-02 20:08:48.532433500 WARNING:SerialBattery:Modbus PackLen: 118 I've put more detail in the next post below Edited May 2, 2022 by shanghailoz Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 2, 2022 Author Share Posted May 2, 2022 (edited) For the larger packet I can identify that AlarmCode seems to be at position 57 - 67 (10 bytes) as that matches AlarmCode: 00 00 10 10 00 00 00 00 00 01 Cycles possibly at 70, 71 as I see 00 85 in there, and I'd think that would be a 2 byte number, and that matches 133 Will need to watch the values tomorrow see if I can identify some other variables. Late and I'm tired [7c 01 01] [76] [01 10 8d 1c 0d 17 ed 1c 0d 32 8d 33 [modbus addr/reg/command] [length] 0d 36 cd c5 0d b9 8d 20 0d 0c 8d 20 0d 20 0d 01 0d 1c 0d 16 0d 1d 02 01 75 30 03 01 27 10 04 01 46 50 05 03 00 48 00 48 20 4b 06 05 00 00 10 10 [alarm] 00 00 00 00 00 01 07 01 00 85 08 01 15 1e 09 01 [cycles?] 27 10 0a 01 00 01 0b 01 00 00 82 c0 0c 01 00 00 37 ae 0d 01 00 40 00 00 de 01 00 40 00 00 0f 01 00 1a 27 ac 10 01 00 09 57 ad 28 0d [lf] Edited May 2, 2022 by shanghailoz Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 3, 2022 Author Share Posted May 3, 2022 (edited) Comparison time Have some different data this morning. Today: [7c 01 01] [76] [01 10] [0c c5 0c c7 0c c7 0c c8 0c c5 [Battery# cell count?] 0c c7 0c c8 0c c8 0c c6 0c c6 0c cb 0c ce 0c c7 [Per Cell Data ? in 2 byte pairs] 0c c8 0c cb 0c cd ] 02 01 77 84 03 01 15 87 04 01 46 50 05 03 00 46 00 46 20 48 06 05 [00 00 00 02 Alarm 00 00 00 00 00 00 ] 07 01 00 85 08 01 14 73 09 01 [cycles?] 27 10 0a 01 00 00 0b 01 00 00 82 c0 0c 01 00 00 37 AE 0d 01 00 40 00 00 0e 01 00 40 00 00 01 01 00 1A 27 e5 10 01 00 09 57 ad 12 [0d] Yesterday: [7c 01 01] [76] [01 10 8d 1c 0d 17 8d 1c 0d 32 8d 33 [modbus addr/reg/command] [length] 0d 36 cd c5 0d b9 8d 20 0d 0c 8d 20 0d 20 0d 01 0d 1c 0d 16 0d 1d 02 01 75 30 03 01 27 10 04 01 46 50 05 03 00 48 00 48 20 4b 06 05 00 00 10 10 [alarm] 00 00 00 00 00 01 07 01 00 85 08 01 15 1e 09 01 [cycles?] 27 10 0a 01 00 01 0b 01 00 00 82 c0 0c 01 00 00 37 ae 0d 01 00 40 00 00 de 01 00 40 00 00 0f 01 00 1a 27 ac 10 01 00 09 57 ad 28 0d [lf] Let's look at the byte data. [0c c5] 0c c7 0c c7 0c c8 0c C5 = 3269. This does match our 32.69 nice! 0c c5 0c c7 0c c8 0c c8 0c c6 0c c6 0c cb 0c ce 0c c7 0c c8 0c cb [0c cd] 3277 Looks correct. Compare yesterdays first cell reading - 8d 1c = 36124. hmm not quite, so possibly some bits not used. Although 3.6124 is possible. Will try parse out todays data using what I can see and see what the values look like through the day. Will implement shortly. Edited May 3, 2022 by shanghailoz Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 3, 2022 Author Share Posted May 3, 2022 After a bit of fighting with endianness got some Cell data out from my inverter. Values are looking correct(ish). I just need to add a trailing zero (if missing) then divide by 1000 for voltage. Also tidied up the serial logging a bit so I can see hex data and packet size etc Example from the cell logging. Example from packet logging Now that I can see data I can see some cells are looking a little unhappy - Cell 7 looks low. Going to plug in directly with the software in a bit see if it's valid or not. Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 3, 2022 Author Share Posted May 3, 2022 (edited) Nice, after a bit of crap code I haz some values. [Note - Battery, SoC, Consumed are not populated correctly yet] -- Top Section / Bottom Section are pulled correctly from data sources. Cell Voltages are correct (I assume, as I still need to check C7). Will post my updated driver code shortly. Edited May 3, 2022 by shanghailoz Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 3, 2022 Author Share Posted May 3, 2022 (edited) Current version attached (v 0.1.2 / May 3 2022) Allows reading of Per Cell Voltage, Hardware Name, Hardware Revision from BMS Note: Battery Voltage/ Amps/ SoC are not implemented yet. revov.py This is also very verbose in the logs, as its a work in progress. Edited May 3, 2022 by shanghailoz Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 3, 2022 Author Share Posted May 3, 2022 Time for some more data analysis.. Since the voltage is 2 bytes, in big endian order, its likely other data will be also. So far I've identified a few area's in the data that map to data. Lets see if we can find more! Revisiting a data packet from the same time period, lets see if any values are close. (TBC...) [7c 01 01] [76] [01 10] [0c c5 0c c7 0c c7 0c c8 0c c5 [Battery# cell count?] 0c c7 0c c8 0c c8 0c c6 0c c6 0c cb 0c ce 0c c7 [Per Cell Data ? in 2 byte pairs] 0c c8 0c cb 0c cd ] 02 01 77 84 03 01 15 87 04 01 46 50 05 03 00 46 00 46 20 48 06 05 [00 00 00 02 Alarm 00 00 00 00 00 00 ] 07 01 00 85 08 01 14 73 09 01 [cycles?] 27 10 0a 01 00 00 0b 01 00 00 82 c0 0c 01 00 00 37 AE 0d 01 00 40 00 00 0e 01 00 40 00 00 01 01 00 1A 27 e5 10 01 00 09 57 ad 12 [0d] As I was about to do some more investigating, my inverter tripped with a battery ripple warning. Which its been doing occasionally. (Hence my trying to get some logs so I can troubleshoot it!) Plugged in my cable in the interim, and looked at the value for Cell 7 - value looks ok in their software, although with a stateful parameter in red. I suspect that they might use one of the bits in the first byte to note the Voltage is over, as the value looks valid in the BMS side, but not in my raw data. BMS is showing 3.625 (with a red Voltage warning). Raw value is showing Cell [7] 2.0018 [0x4E32 | 20018] Will add some bitwise logging next to show what bits are set, and see if that is the case. Also took some more stats from the inverter so i can compare more values Data from close to that time Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 3, 2022 Author Share Posted May 3, 2022 (edited) Modbus Packet : [7C:01:01:76:01:10:0D:28:8D:20:0D:29:8D:37:0D:45:8D:3A:4E:0B:8D:CC:0D:2C:8D:10:0D:2B:0D:28:8D:16:0D:2A:8D:1D:0D:27:02:01:75:30:03:01:27:10:04:01:46:50:05:03:00:49:00:49:20:4B:06:05:00:00:10:10:00:00:00:00:00:01:07:01:00:85:08:01:15:34:09:01:27:10:0A:01:00:01:0B:01:00:00:83:00:0C:01:00:00:37:AE:0D:01:00:40:00:00:0E:01:00:40:00:00:0F:01:00:1A:3A:04:10:01:00:09:57:AD:2E:0D] (118 Bytes)+6 bytes head/foot = [7c:01:01:76] + [data] + 2 bytes [2E 0D] Checksum / LF [HEADER] 7C:01:01:76 Modbus bits (Cut when passed) [0..1] 01:10 BatteryModule? | Cell Count [2..33] [0D:28:8D:20:0D:29:8D:37:0D:45:8D:3A:4E:0B:8D:CC:0D:2C:8D:10:0D:2B:0D:28:8D:16:0D:2A:8D:1D:0D:27 [ Per Cell Data ] [34..55] 02:01 75:30 03:01 27:10 04:01 [46:50] 05:03 00:49 00:49 20:4B 06:05 11 doubles [18000 = Full Bat Cap?] [56..65] [00:00:10:10:00:00:00:00:00:01] Alarm [66..81] 07:01 [00:85] 08:01 [15:34] 09:01 [27:10] 0A:01 00:01 [133=Cycles?] [5428 = 54.28 V_SUM?] [10000 = 100.00] [82..97] 0B:01 00:00 83:00 [0C:01] 00:00 37:AE [0D:01] 00:40 [3073 = 3.073] [3329= 3.329? V_AVG/MIN etc?] [98..113] 00:00 0E:01 00:40 00:00 0F:01 00:1A 3A:04 10:01 [114..117] [00:09 57:AD] [118..119] [2E] 0D Checksum? , LF Some more guesswork above. Will implement as noted, then see if the inferred values are guessed wrong or not. Another modbus packet to compare [7C:01:01:76:01:10:8D:20:0D:17:8D:21:0D:2F:8D:3B:0D:32:CD:E3:0D:B3:8D:23:0D:0D:8D:24:0D:24:0D:11:8D:21:0D:18:8D:21:02:01:75:30:03:01:27:10:04:01:46:50:05:03:00:49:00:48:20:4B:06:05:00:00:10:10:00:00:00:00:00:01:07:01:00:85:08:01:15:24:09:01:27:10:0A:01:00:01:0B:01:00:00:83:00:0C:01:00:00:37:AE:0D:01:00:40:00:00:0E:01:00:40:00:00:0F:01:00:1A:3A:04:10:01:00:09:57:AD:BA:0D] 02:01 75:30 03:01 27:10 04:01 46:50 05:03 00:49 00:48 20:4B 06:05 [00:00:10:10:00:00:00:00:00:01] Alarm 07:01 [00:85] 08:01 [15:24] 09:01 27:10 0A:01 00:01 [Cycles] 54.48 Bat Voltage?] [soc state?] 0B:01 00:00 83:00 0C:01 00:00 37:AE 0D:01 00:40 [these haven't changed, so probably not V_min/avg] 00:00 0E:01 00:40 00:00 0F:01 00:1A 3A:04 10:01 00:09 57:AD I think cycles and Battery voltage look correct. Will need to check in morning or later if soc state is correct as batteries should be full until after sunset. Edited May 3, 2022 by shanghailoz Nicholas 1 Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 3, 2022 Author Share Posted May 3, 2022 (edited) New version 0.1.3 /* Cell Voltage Implemented Hardware Name Implemented Hardware Revision Implemented Battery Voltage added (but not correct!) Added additional binary logging so I can try spot what bits are used for RED cell errors (not the Alarm error, which I'll get to later) Added return false for the read_cell_data in case of bad packet. To do: SOC, Error Codes, Other variables */ Example Logging revov.py I think this is good enough as a beta to ask Louisvdw to pull to github. I'd like testers if anyone else has a revov, so I can check whats different between units/revisions You'll need an RS485 cable, and a PI (or CCGX) Also available at https://github.com/csloz/dbus-serialbattery/tree/revov I have asked for a merge to the main repo. Further code updates will be published at the repo. Enjoy! Edited May 3, 2022 by shanghailoz Nicholas 1 Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 3, 2022 Author Share Posted May 3, 2022 Some screen shots of this in action on my Venus PI Now with per cell monitoring (added the qml file on the current repo) Nicholas 1 Quote Link to comment Share on other sites More sharing options...
shanghailoz Posted May 4, 2022 Author Share Posted May 4, 2022 I just spotted something blindingly obvious. So obvious in fact that I missed it! I've re-ordered the data. See if you can spot it - 7C:01:01:76 01:10 0D:35:8D:2E:0D:36:8D:43:0D:4A:8D:45:4D:D9:8D:D0:0D:37:8D:13:0D:36:0D:2A:8D:20:0D:35:8D:20:0D:2A: 02:01 75:30 03:01 27:10 04:01 46:50 05:03 00:49 00:49 20:4A 06:05 00:00 10:10 00:00 00:00 00:01 Alarm 07:01 00:85 08:01 15:3C 09:01 27:10 0A:01 00:01 0B:01 00:00 83:66 0C:01 00:00 37:AE 0D:01 00:40 00:00 0E:01 00:40 00:00 0F:01 00:1A 4A:3F 10:01 00:09 57:AD DE:0D Thats right - the packet structure is actually quite nicely laid out. We have the header bits and footer bits (in bold). Then each message has a ID byte, and a Length (although some values are longs, some not) eg ID: Length. Value 01:10 with length 16 (10 in HEX) is our battery cell info 02:01 75:30 = 3000 -> 30 03:01 27:10 = 10000 ->100 04:01 46:50 = 18000 ->180 05:03 00:49 00:49 20:4A = 3 pairs? 73/73/8266 ?? 06:05 00:00 10:10 00:00 00:00 00:01 Alarm bits 07:01 00:85 = 133 -> Cycles 08:01 15:3C = 5436 -> Volts (54.36) 09:01 27:10 = 10000 -> 100 0A:01 00:01 = 1 0B:01 00:00 83:66 = 0, 33670 (3.367?) 0C:01 00:00 37:AE = 0, 14254 (0.14254?) 0D:01 00:40 00:00 = 64, 0 0E:01 00:40 00:00 = 64, 0 0F:01 00:1A 4A:3F = 26, 190007 (19.000) 10:01 00:09 57:AD = 9, 22445 (22.445?) A lot less info to work out. I think I should be able to map the rest later! (Bit busy today, so can't touch right now). Quote Link to comment Share on other sites More sharing options...
Nicholas Posted May 20, 2022 Share Posted May 20, 2022 @shanghailozwould you mind advising upon the preferred method to install? I'd like to start testing as soon as possible. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.