shanghailoz

Greenrich and Kynee - 15S or 16S?

Yes, as mine is running on a PI, with a small touch screen.

I don't get dealer pricing at Revov though 😀 The Fox aren't badly priced, maybe I just upgrade to 2 stacks for the upstairs house. Works out at 92k for 40KWh. HV though, but I can rejig my system to support.

Just checked Segen, I see the Revovs are around 12k ex vat for the 5KWh units. so 24k ex vat per 10KWh I'll be finishing off my house end of 2025, and plan to add another 40KWh of battery, so that's nice Current wholesaler pricing below - I assume you'll get similar pricing that I will.

Be aware., I've had them swap out batteries on both units under warranty already. That said, fairly painless as they came out and swapped and gave a replacement unit while they confirmed that it was a bad cell in the pack. I could see it as the per cell values on my monitoring made it obvious, but they still took 2-3 months to check /replace at the time. The price differential at the moment doesn't seem worthwhile to go for 2nd hand cells, it's cheap enough now to go new, and the BMS's are better. I paid 35k for 10KW for my first set with BMS, which at the time was a great deal, nowadays that's pretty average I think for new.

I'm overseas again working, so don't have an on the ground view of things. Going to assume they're working, as I don't have CoCT or Eskom, and the tenant in place hasn't complained. I did add another 10KWh, so it's 20KWh of storage now, so should be plenty for the tenant to abuse, even in winter. The extra 10KW is sitting on a Sunsynk, which does have native support for the BMS. Also connected to +-9KW of panels.

Sold.

Sunsynk 8KW updated 25th Oct 2023 MAIN 6024-0717. HMI E435

I have 3 x Victron 24v 3kw multiplus for sale. Was for a 3 phase setup, but I was out of the country for a decade, then eventually moved house which made them redundant (and unused) *Long* out of warranty, but virtually unused, still have boxes. Make offers! -------------- Item: Victron 3kw 24v Multiplus Age: 2014, but need to check. Price: Make offers Payment Method Accepted: EFT or cash on collection. Warranty: None Packaging: Yes Condition: As new Location: Cape Town (Deep South) Reason: Been Sitting in the garage for a few years now Shipping: Too heavy I think Collection: Yes. Link:

done

Been a while, but I have revisited this, as the current driver that replaced mine didn't actually work on my Revov BMS My updated driver is here - https://github.com/csloz/dbus-serialbattery Will probably be merged back with main at some point, but this will work on the older Tianpower BMS that Revov used. I also fixed a few of the missing bits like temp sensor etc. Works fine on v3 of PI Venus.

Having run my own forums before, it is a tireless thankless task. Get some moderators and hand it over to them also Many hands make light work! Happy holidays to you and family!

Good to see more options in the market. Hopefully the BMS in this is documented, so that I don't need to write my own drivers for it TianPower /Revov looking at you...hahah

Nicely done. I should revisit some of the values on mine, see if i can map more fields to actual values.

Ok, I see that he finally updated the repo with my changes, so its "live" if you pull the current version. Fork and modify from the current repo then.

To be honest my notes in the thread, and the current code should be enough to continue working on things. Fork it, and continue. Unfortunately I just haven't had time to continue, and it works well enough for me for now. Did Louis finally update his repo with my additions? If not, you need to pull the current version from my fork here - Not that complicated You send the device a command over serial, it sends data back, thats basically it, and you parse the reply into something meaningful. Here are 2 commands I know about - 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 I sniffed what I could of the protocol from watching the BMS app itself, and some detective work. Current code - https://github.com/csloz/dbus-serialbattery/blob/revov/etc/dbus-serialbattery/revov.py Now we sort of know the packet format, the code needs to be reorganized, as we can parse the entire thing in one go. I put enough logging into the driver so that its useful. eg

Just be aware that battery voltage will be incorrect if a cell is in error state. I do need to look at the bit values to work out what bits they use for this still, its ok when not in error state. (a data sheet from Tianpower of the packet format would be nice, but no, its reverse engineer, bleh). I've had the current version running on mine for a month and a half, seems reliable, and is a good indicator for me of values. I do need to get the SoC state calc done and added in, as well as the other things i don't know from the data... When I have time haha.

Do read the caveats above i.e. - some values aren't correct. I will get around to sorting that out, but right now busy with work stuff, which takes priority. Feel free to delve in and fix yourself though (especially since I noted the packet format) Send me a push request if you do, so i can merge. Cheers.

Read the instructions for the repo. https://github.com/Louisvdw/dbus-serialbattery/wiki/How-to-install Once installed, overwrite with the updated files from here from the REVOV branch - https://github.com/csloz/dbus-serialbattery You'll need ssh access to your PI or CCGX Files to update / add from his release are mostly in these 2 files https://github.com/csloz/dbus-serialbattery/blob/revov/etc/dbus-serialbattery/revov.py (the partially completed driver) https://github.com/csloz/dbus-serialbattery/blob/revov/etc/dbus-serialbattery/dbus-serialbattery.py (some mild updates to add a link to load the revov.py code). Bit busy on work atm, if you get stuck shout.

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

Some screen shots of this in action on my Venus PI Now with per cell monitoring (added the qml file on the current repo)

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!

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.

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

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.