I am trying to use a battery from an EV, maybe BMW i3 or even the tesla battery. i3 would be nice since the voltage is in a good range. With a Tesla battery I would need to use the whole pack with 60 to 100 kWh to have a good voltage, which might be a bit oversized.@huntworker, what is the final goal of this project? You want to build some monitoring system or connect some other battery to your inverter using this protocol.
I didn't know Goodwe when I installed my setup.OK. I got it. So, we are running on the same track here That is pretty similar to what I've done with a Goodwe inverter in my project.
BTW, I'm curious what do you think about this brand of inverters? They are well priced, and for about 1700-1800 euro, you can get a 10kW 3 phase HV hybrid inverter with UPS functionality.
It is exactly what i intend to install for our home location as well.I am trying to use a battery from an EV, maybe BMW i3 or even the tesla battery. i3 would be nice since the voltage is in a good range. With a Tesla battery I would need to use the whole pack with 60 to 100 kWh to have a good voltage, which might be a bit oversized.
So am trying to simulate the BYD battery for the existing Kostal inverter.
I also thought about using another inverter. I like the Victron pars for its uninterruptible power supply and fast transfer switches. But they are using only single phase concepts. So I would need 3x the MultiPlus || and the SmartSolar RS to have a tree phase system which lead to additional cost for the inverter of around 7 k€. With this system I would have the UPS but thats not worth it.
I am working as electrical engineer for a german company which builds cell management controller, battery management controller and battery junction boxes for different OEMs so I know what I am doing.
Only unusual thing for me is to not having a description of the protocols and buses.
Current: -1.775 SOC: 63.000% SysTemp: 20.300 MaxCellVolt: 3.264 MinCellVolt: 3.260 MaxCellTemp: 19.600 MinCellTemp: 17.600 MaxVolPos: 3 MinVolPos: 4 MaxTempPos: 1 MinTempPos: 4 0A E2 FF 02 FF 29 CF 77 82 43 -> 0x438277cf = 260.936004639 Cur Voltage 01 0F 8D 43 -> 0x438d0f01 = 282.117218018 Max Allowed Voltage 66 66 A2 41 -> 0x41a26666 = 20.2999992371 SysTemp 66 66 E6 BF -> 0xbfe66666 = -1.79999995232 Current 46 E1 DA BF -> 0xbfdae146 = -1.70999979973 Current 01 03 48 42 -> 0x42480301 = 50.0029335022 Peak discharge current 01 03 C8 41 -> 0x41c80301 = 25.0014667511 Nominal discharge current 01 14 A0 41 -> 0x410a1401 = 8.62988376617 CD CC 9C 41 -> 0x419ccccd = 19.6000003815 MaxCellTemp CD CC 8C 41 -> 0x418ccccd = 17.6000003815 MinCellTemp FE D4 50 40 -> 0x4050d4fe = 3.26300001144 MaxCellVolt 75 93 50 40 -> 0x40509375 = 3.25900006294 MinCellVolt FC -> 0xFC = 252 Cycle count 02 01 02 3F -> 0x3f = 63 SoC 01 01 02 B4 -> checksum
You mean the last block, in this case 75 93 50 40? I am pretty sure that this is the voltage of the lowest cell since this matches well with the SOC.It could be possible that last byte floating point is used to code other thing like max-min voltage position and temperature position.
If I have a closer look, the Header of the messages is always the sameIf I looked your first log, the second byte from each frame have "E2" or "62", it remain me to webasto protocol that use 4bit for sender address and destination address.
Sure, please find the file attached.@huntworker could you share your log on power on and power off?
09 62 FF 02 FF 29 4A 08 23 00 -> device check/starting 09 62 FF 02 FF 29 4A 04 27 00 -> device ok/run 06 E2 FF 02 FF 29 ... -> some or one value could not be read like missing charging voltage from the inverter or measurement not avaliable yet
07 63FF02FF295E02 16 -> checksum8=14 ??? 07 E3FF02FF29 F4 -> checksum8=F4 09 62FF02FF294A08 23 -> checksum8=23 08 E2FF02FF2906 EF -> checksum8=EF
totally agree with you.So, on long frame, the data just look simple like my last post and the short frame could be some status info like:
I don't have the adding of 0xC0 in mind, but yes, this is sum of all bytes inverted. But we already found that out.About checksum for long frame, I tought it was a special crc-8 but I tried all possibility that could be done with crc calculation with no result then I did 8-bit checksum and founded that it just sum of all bytes added with 0xC0 then inverted.
With checksum it is solved already. What the data in the short frame are standing for is still not known. But as you said, it needs to be some short status or request frames.I am currious with short frame now.
I already done this. SOC is byte 58.@huntworker Could you share some logs with charging 99% to full and also 1% before DoD until DoD.
Since the inverter act as charger/decharger, I expected some data like "ready to charge", "full charged", "charger (inverter) (detected) error", "discharge ready"
This is byte 54 and 55. i did not reached 511 cycles, but I know that they are using zwo bytes because the already use the one bit for 256 to 350 (current cycle count).Discarge cycle is also still a mystery, some logs along 255-257 and 511-513 could be also helpfull
There is 07 frame on start sequence that has not right checksum (07 63FF02FF295E02 16. It has 16 instead of 14)With checksum it is solved already. What the data in the short frame are standing for is still not known. But as you said, it needs to be some short status or request frames.
Yes it is, but I am interested with 3 short frame around it, near SoC 100% until stop charging and nead DoD until stop discharging. Maybe there are some status changing short frame.I already done this. SOC is byte 58.
Byte 57 is a status byte which is 0x00 when the battery is allowerd to charge and 0x40 whe it is fully charged. other values than that have not been seen yet.
I just have one long frame from your post that stating cycle 259:This is byte 54 and 55. i did not reached 511 cycles, but I know that they are using zwo bytes because the already use the one bit for 256 to 350 (current cycle count).
Do you need to do the checksum before doing the replacements of the 00 bytes?There is 07 frame on start sequence that has not right checksum (07 63FF02FF295E02 16. It has 16 instead of 14)
Hm, I will have a look for that. As I wrote, all the logs are done by hand.Yes it is, but I am interested with 3 short frame around it, near SoC 100% until stop charging and nead DoD until stop discharging. Maybe there are some status changing short frame.
Thats on my todo list als well for a long time.I wrote a simple python script to pharse the long frame, just give long frame data included 00 ending as input. Reading cycle count is still not right. Is it not allowed to attach python file?
00 byte is illegal data and use only to marking end of frame. Inside the frame 01 could be "00" or "01" so the receiver could not guess what it was but checksum must always be correct calculated, that's way checksum must always be calculated after replacing "00" to "01".Do you need to do the checksum before doing the replacements of the 00 bytes?
01 0F 8D 43 -> 0x438d(0f01) = 282 Max Allowed Voltage 01 03 48 42 -> 0x4248(0301) = 50 Peak discharge current 01 03 C8 41 -> 0x41c8(0301) = 25 Nominal discharge current
Data-Send: 0A E2FF02FF292FCD804301078D4333338B410101010101010101010348420103C8410116A041CDCC8C41CDCC84413F354E40B6F34D40630101020E010102 5100 Data-Clean: -- e2ff02ff292fcd804300008d4333338b410000000000000000000048420000c8410000a041cdcc8c41cdcc84413f354e40b6f34d40630101000e000000 -> sum=0xAF -sum=0x51 Data-Dirty: -- E2FF02FF292FCD804301078D4333338B410101010101010101010348420103C8410116A041CDCC8C41CDCC84413F354E40B6F34D40630101020E010102+C1 -> sum=0xA5 First byte = 0xAF - 0xA5 = 0x0A