Jump to content

The dreaded Revov's on Sale!


shanghailoz

Recommended Posts

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 

 

Link to comment
Share on other sites

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 :(

 


image.png.cc24b206e50d498baf394d7be1f6dcb6.png
 

and with some draw - 

179911031_Screenshot2020-09-02at16_35_28.png.58e181947e0b55f25cda912a4372d20a.png

Definitely bare minimum - as none of the other data is populated eg 

 

image.png.b08f37db057281ebfbe66ac00bbbf7f2.png

Edited by shanghailoz
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 year later...

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

Link to comment
Share on other sites

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. 

image.thumb.png.4e3ecf4f732cf5b4e1dddcfdd37b379f.png

Edited by shanghailoz
Link to comment
Share on other sites

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 by shanghailoz
Link to comment
Share on other sites

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 by shanghailoz
Link to comment
Share on other sites

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 by shanghailoz
Link to comment
Share on other sites

Some more work to get the driver loaded (fake hard coded data!), but its appearing now in the Victron side.

 

 

 

image.thumb.png.6437c909b225ad457b951f7e70623ef6.png

 

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 :)

image.thumb.png.0d9a9ef3fda1a62d54241a93f467eeb8.png

 

 

 

Edited by shanghailoz
Link to comment
Share on other sites

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:

image.thumb.png.e0bc8252e74533ee833b1ee7983d6121.png

image.thumb.png.b91f67c3a4fe28601600f08c70e1682c.png

Edited by shanghailoz
Link to comment
Share on other sites

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 by shanghailoz
Link to comment
Share on other sites

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]

image.thumb.png.3c2401b04e4ca16d398a25b063f62bb2.png

Edited by shanghailoz
Link to comment
Share on other sites

Comparison time

Have some different data this morning.

image.thumb.png.2e184ae8b10c25dd5890379451092c2d.png

image.thumb.png.230b0d89af1fe51ada63a8d0f1d3be1b.png

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 by shanghailoz
Link to comment
Share on other sites

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.

image.thumb.png.e80fa3291ef75db3d7461abed7abf9fd.png

Example from packet logging

image.thumb.png.cca64f37f1d36a267ae393c1f6bbb425.png

 

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.

Link to comment
Share on other sites

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.

image.thumb.png.c0be9d5cdc3c64be18b78adfcc51648a.png

Cell Voltages are correct (I assume, as I still need to check C7).

image.thumb.png.9d4352392407e7e610a2b3350096446b.png

Will post my updated driver code shortly.

 

Edited by shanghailoz
Link to comment
Share on other sites

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 by shanghailoz
Link to comment
Share on other sites

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!

 

image.thumb.png.87d792297ffc2e4298a5d570de9f8484.png

 

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

image.thumb.png.b4cfb9b8d7082539ce0e3740f9ef8843.png

Data from close to that time

image.thumb.png.f70fa6f1f3589e42d18cf54adfa45921.png

 

Link to comment
Share on other sites

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 by shanghailoz
Link to comment
Share on other sites

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

 

image.thumb.png.84d8c3d1877447e6ba8c21966742436a.png

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 by shanghailoz
Link to comment
Share on other sites

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).

Link to comment
Share on other sites

  • 3 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...