WIP: add support for EASUN iBattery-EA-51.2V-200AH

[f3nix]

Hi. I'm trying to connect to an EASUN battery.

Link to battery: https://www.easun-energy.com/products/easun-5kwh-10kwh-powerwall-48v-lifepo4-battery-bms-communication?srsltid=AfmBOo

Sticker on BMS.

Pbms tools view.

Battery sticker

It seems the analog info answer has a few more bytes:

7e (SOI)
32 35 (VER)
30 31 (ADDR)
34 36 (CID1)
30 30 (RTN)
31 30 39 36 (LENGTH)
30 30 (INFOFLAG)
30 31 (PACK NUMBER)
31 30 (battery cell number M)

30 44 30 46 3343 (first cell voltage) 
30 44 30 46 3343
30 44 30 46 3343
30 44 30 46 3343
30 44 30 46 3343
30 44 31 30 3344
30 44 30 46 3343
30 44 31 30 3344
30 44 31 30 3344
30 44 30 46 3343
30 44 30 46 3343
30 44 30 46 3343
30 44 30 46 3343
30 44 30 46 3343
30 44 30 46 3343
30 44 30 45 3342 (sixteenth cell voltage)

30 36 (temperature number)
30 42 33 43 2876 14,6st(first temperature)
30 42 33 46 2879 14,9st
30 42 33 43 2876 14,6st
30 42 33 45 2878 14,8st
30 42 35 37 2903 (t_mos temp) 17,3st
30 42 34 45 2894 (sixth temperature) (ENV_T) 16,4st

46 46 35 43 (pack current) -164 0 mA Decimal from signed 2's complement (3 digits)
44 30 46 32 (pack total voltage) D0F2 53,490
33 39 31 44 pack remain capacity) 14621 0 mAh
30 39 (user define number)

35 31 34 33 (pack full capacity)    20 803 0 mAh
30 30 30 35 (cycle times)                5
34 45 32 30 (pack design capacity)  20 000 9 mAh
34 36 34 45 17 998 (???)
32 30 34 45  8 270 (???)
32 30 34 45  8 270 (???)
32 30 34 45  8 270 (???)
32 30 36 34  8 292 (???)
44 30 36 38 53 352 (???)
30 30 30 30

44 43 42 46 (CHKSUM)
0d (EOI)

I thought that user define number would mean the count of additional info but here it says 9 and I get 10 values. esphome-pace-bms states there are 28 bytes which shouldn't be there.

30 39 (user define number)

35 31 34 33 (pack full capacity) 20 803 0 mAh 30 30 30 35 (cycle times) 5 34 45 32 30 (pack design capacity) 20 000 9 mAh 34 36 34 45 17 998 (???) 32 30 34 45 8 270 (???) 32 30 34 45 8 270 (???) 32 30 34 45 8 270 (???) 32 30 36 34 8 292 (???) 44 30 36 38 53 352 (???) 30 30 30 30 0000

Ignoring those bytes works as expected :)

Now I'm moving to the status query. It is 2 bytes off. Work in progress.

7e 32 35 30 31 34 36 30 30 45 30 34 45 30 30 30  ~25014600E04E000
31 31 30 30 30 30 30 30 30 30 30 30 30 30 30 30  1100000000000000
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  0000000000000000
30 30 30 30 36 30 30 30 30 30 30 30 30 30 30 30  0000600000000000
30 30 30 30 30 30 30 30 30 30 30 30 45 30 30 30  000000000000E000
30 30 30 30 30 30 30 30 30 30 30 45 45 43 33 0d  00000000000EEC3.

Cheers, Mateusz

[nkinnan]

Hey, thanks for sharing! The User Defined Value is a special constant which identifies the specific protocol variant being used. The Jakiper battery pack I have sends the value 0x03 for that. It doesn't have anything to do with how many additional values might be present (well, indirectly it specifies that the protocol variant may have a different number of values, but it's not a count.)

Interesting that you're seeing 0x09, but that accounts for the extra bytes at the end. I'm not sure what those extra bytes are since I don't have any protocol documentation for your variant. If you can find any, or are able to decode those values, I'd love to extend the support for this variant!

Lining up the status response you shared with the one I see from my Jakiper, it's off by 2 bytes, but those bytes appear to be at the end of the response (the cell count, temperature count, and system status values line up) so it's probably compatible with the pace_bms implementation of protocol 0x25.

[nkinnan]

note for myself:

Easun Power Powerwall IBattery-EA-51.2V-200AH P16S100A-32117-1.00 / P16S100A-PX32117-20A-K4-10B https://www.easun-energy.com/products/easun-5kwh-10kwh-powerwall-48v-lifepo4-battery-bms-communication

[f3nix]

All the parameters are read correctly :)

Cheers, Mateusz

[f3nix]

Lining up the status response you shared with the one I see from my Jakiper, it's off by 2 bytes, but those bytes appear to be at the end of the response (the cell count, temperature count, and system status values line up) so it's probably compatible with the pace_bms implementation of protocol 0x25.

Ignoring those two bytes seems to work ok. Will have to investigate further.

Thanks for you great work! :)

Cheers, Mateusz

[nkinnan]

Thanks for validating it against your BMS :) If you find any issues, please let me know. Once you're happy that it's working correctly, I'll update the documentation to include your battery pack as a supported model.

[f3nix]

Hi. I think I've made some progress with decoding the other values:

Previous data:

34 36 34 45    17 998 (???)
32 30 34 45    8 270 (???)
32 30 34 45    8 270 (???)
32 30 34 45    8 270 (???)
32 30 36 34    8 292 (???)
44 30 36 38    53 352 (???)
30 30 30 30    0000

Latest data:

34 44 34 45    19 790 (???)
32 30 34 45    8 270  (???) const
32 30 34 45    8 270  (???) const
32 30 34 45    8 270  (???) const
32 30 36 34    8 292  (???) const
43 46 39 39    53 145 <- Independent voltage
30 30 30 30    0000   <- Independent current

Cheers, Mateusz

[nkinnan]

Interesting, thanks for sharing. If they are just constants / duplicates of other values (which are read correctly) then it doesn't seem that interesting to add any kind of special support for them. Let me know if you find anything else!

[nkinnan]

If the commit I just made to the main pace_bms tree is working for you, I'd like to close this issue report and we can focus on multi-pack support here: https://github.com/nkinnan/esphome-pace-bms/issues/24

[f3nix]

Thanks :)

I'll test tonight and get back to you.

Cheers, Mateusz

[f3nix]

Hi. Everything seems to work good :) Thanks.

Here are the requests/responses for UD 9 if you would like to embed them in code for future tests.

Analog info request:

7e 32 35 30 31 34 36 34 32 45 30 30 32 30        ~25014642E0020
31 46 44 33 30 0d                                1FD30♪

Analog info response:

7e                                               ~
32 35 30 31 34 36 30 30 31 30 39 36 30 30 30 31  2501460010960001
31 30 30 44 30 33 30 44 30 33 30 44 30 33 30 44  100D030D030D030D
30 32 30 44 30 33 30 44 30 33 30 44 30 33 30 44  020D030D030D030D
30 33 30 44 30 34 30 44 30 34 30 44 30 33 30 44  030D040D040D030D
30 33 30 44 30 33 30 44 30 33 30 44 30 33 30 44  030D030D030D030D
30 33 30 36 30 42 34 41 30 42 34 43 30 42 34 42  03060B4A0B4C0B4B
30 42 34 42 30 42 36 30 30 42 35 37 46 46 33 42  0B4B0B600B57FF3B
44 30 33 31 33 45 43 38 30 39 35 31 34 33 30 30  D0313EC809514300
30 35 34 45 32 30 34 44 34 45 32 30 34 45 32 30  054E204D4E204E20
34 45 32 30 34 45 32 30 36 34 43 46 39 39 30 30  4E204E2064CF9900
30 30 44 44 41 34 0d                             00DDA4♪

Status info request:

7e 32 35 30 31 34 36 34 34 45 30 30 32 30 31 46  ~25014644E00201F
44 32 45 0d                                      D2E♪

Status info response:

7e 32 35                                         ~25
30 31 34 36 30 30 45 30 34 45 30 30 30 31 31 30  014600E04E000110
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  0000000000000000
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  0000000000000000
30 36 30 30 30 30 30 30 30 30 30 30 30 30 30 30  0600000000000000
30 30 30 30 30 30 30 30 30 45 30 31 30 30 30 30  000000000E010000
30 30 30 30 30 30 30 30 45 45 43 32 0d           00000000EEC2♪

Cheers, Mateusz

[nkinnan]

Thanks for sharing the strings, I'll add them to the protocol documentation :)