Testing on Solarbank 2 E1600 Pro

[jul1an-s]

Hi,

first off: Amazing project, thank you so much for your work! 🎉

I'm trying to get the Solarbank 2 E1600 Pro working with this project. Ultimate goal would be to control the output power through the schedule like @smariacher did with the Solarbank 1 #21

I got some first telemetry dumps, but apparently it can't decrypt the telemetry data properly.

DEBUG:bleak_retry_connector:F4:9D:8A:13:CE:82 - F4:9D:8A:13:CE:82: Connected after 1 attempts
DEBUG:SolixBLE.device:Established initial connection to 'Solarbank 2 E1600 Pro' on attempt 1!
DEBUG:SolixBLE.device:Subscribing to notifications from device 'Solarbank 2 E1600 Pro'!
DEBUG:bleak.backends.bluezdbus.client:using "AcquireNotify" for notifications on characteristic 17
DEBUG:bleak.backends.bluezdbus.manager:received D-Bus signal: org.freedesktop.DBus.Properties.PropertiesChanged (/org/bluez/hci0/dev_F4_9D_8A_13_CE_82/service000e/char0011): ['org.bluez.GattCharacteristic1', {'NotifyAcquired': <dbus_fast.signature.Variant ('b', True)>}, []]
DEBUG:SolixBLE.device:Sending negotiation initiation request to 'Solarbank 2 E1600 Pro'...
DEBUG:SolixBLE.device:The client the notification is from is: BleakClient, F4:9D:8A:13:CE:82
DEBUG:SolixBLE.device:Received notification from 'Solarbank 2 E1600 Pro'. length: 14, packet: 'ff090e00030001080100a1010152'
DEBUG:SolixBLE.device:Pattern: 030001
DEBUG:SolixBLE.device:CMD: 0801
DEBUG:SolixBLE.device:Payload: 00a10101
DEBUG:SolixBLE.device:Payload length: 4
DEBUG:SolixBLE.device:Received encryption negotiation message!
DEBUG:SolixBLE.device:Entered negotiation stage 1 due to response from device!
DEBUG:SolixBLE.device:Parameters: {'a1': '01'}
DEBUG:SolixBLE.device:Sending stage 1 response message...
DEBUG:bleak.backends.bluezdbus.client:Write Characteristic 8c850002-0302-41c5-b46e-cf057c562025 | /org/bluez/hci0/dev_F4_9D_8A_13_CE_82/service000e/char000f: b'\xff\t6\x00\x03\x00\x01\x00\x01\xa1\x04B\xad\x8ci\xa2$b2dc0b17-b75d-4abf-ba6e-ec7c997c23e7\xb9'
DEBUG:bleak.backends.bluezdbus.client:Write Characteristic 8c850002-0302-41c5-b46e-cf057c562025 | /org/bluez/hci0/dev_F4_9D_8A_13_CE_82/service000e/char000f: b'\xff\t=\x00\x03\x00\x01\x00\x03\xa1\x04B\xad\x8ci\xa2$b2dc0b17-b75d-4abf-ba6e-ec7c997c23e7\xa3\x01 \xa4\x02\x00\xf0d'
DEBUG:SolixBLE.device:The client the notification is from is: BleakClient, F4:9D:8A:13:CE:82
DEBUG:SolixBLE.device:Received notification from 'Solarbank 2 E1600 Pro'. length: 27, packet: 'ff091b00030001080300a10102a202fd00a30144a40101a50102ff'
DEBUG:SolixBLE.device:Pattern: 030001
DEBUG:SolixBLE.device:CMD: 0803
DEBUG:SolixBLE.device:Payload: 00a10102a202fd00a30144a40101a50102
DEBUG:SolixBLE.device:Payload length: 17
DEBUG:SolixBLE.device:Received encryption negotiation message!
DEBUG:SolixBLE.device:Entered negotiation stage 2 due to response from device!
DEBUG:SolixBLE.device:Parameters: {'a1': '02', 'a2': 'fd00', 'a3': '44', 'a4': '01', 'a5': '02'}
DEBUG:SolixBLE.device:Sending stage 2 response message...
DEBUG:bleak.backends.bluezdbus.client:Write Characteristic 8c850002-0302-41c5-b46e-cf057c562025 | /org/bluez/hci0/dev_F4_9D_8A_13_CE_82/service000e/char000f: b'\xff\t6\x00\x03\x00\x01\x00)\xa1\x04B\xad\x8ci\xa2$b2dc0b17-b75d-4abf-ba6e-ec7c997c23e7\x91'
DEBUG:SolixBLE.device:The client the notification is from is: BleakClient, F4:9D:8A:13:CE:82
DEBUG:SolixBLE.device:Received notification from 'Solarbank 2 E1600 Pro'. length: 56, packet: 'ff093800030001082900a10103a2054553503332a307302e302e302e33a41041504347513830453233373030343134a506f49d8a13ce8282'
DEBUG:SolixBLE.device:Pattern: 030001
DEBUG:SolixBLE.device:CMD: 0829
DEBUG:SolixBLE.device:Payload: 00a10103a2054553503332a307302e302e302e33a41041504347513830453233373030343134a506f49d8a13ce82
DEBUG:SolixBLE.device:Payload length: 46
DEBUG:SolixBLE.device:Received encryption negotiation message!
DEBUG:SolixBLE.device:Entered negotiation stage 3 due to response from device!
DEBUG:SolixBLE.device:Parameters: {'a1': '03', 'a2': '4553503332', 'a3': '302e302e302e33', 'a4': '41504347513830453233373030343134', 'a5': 'f49d8a13ce82'}
DEBUG:SolixBLE.device:Sending stage 3 response message...
DEBUG:SolixBLE.device:The client the notification is from is: BleakClient, F4:9D:8A:13:CE:82
DEBUG:SolixBLE.device:Received notification from 'Solarbank 2 E1600 Pro'. length: 11, packet: 'ff090b00030001080500f2'
DEBUG:SolixBLE.device:Pattern: 030001
DEBUG:SolixBLE.device:CMD: 0805
DEBUG:SolixBLE.device:Payload: 00
DEBUG:SolixBLE.device:Payload length: 1
DEBUG:SolixBLE.device:Received encryption negotiation message!
DEBUG:SolixBLE.device:Entered negotiation stage 4 due to response from device!
DEBUG:SolixBLE.device:Parameters: {}
DEBUG:SolixBLE.device:Sending stage 4 response message...
DEBUG:bleak.backends.bluezdbus.client:Write Characteristic 8c850002-0302-41c5-b46e-cf057c562025 | /org/bluez/hci0/dev_F4_9D_8A_13_CE_82/service000e/char000f: b'\xff\t@\x00\x03\x00\x01\x00\x05\xa1\x04C\xad\x8ci\xa2$b2dc0b17-b75d-4abf-ba6e-ec7c997c23e7\xa3\x01 \xa4\x02\x00\xf0\xa5\x01@\xfa'
DEBUG:bleak.backends.bluezdbus.client:Write Characteristic 8c850002-0302-41c5-b46e-cf057c562025 | /org/bluez/hci0/dev_F4_9D_8A_13_CE_82/service000e/char000f: b'\xff\tL\x00\x03\x00\x01\x00!\xa1@\x06\x0e\xa1h\xf22\xae\xdb7\xfb-\x12\x0cI\x18\x03)\xacr\xab^\xc3\xeb\x8f\xd3\n/%-\xc5\xe1Q\xda\xbc\xcd\x9b\x1d\xc1\xe2\x88pL\xa7`\xa0\xd8\xc9\x18\xe5\xc9H#\xa1\xf6\t\xa4\xbf\x07\xfbL3\xee!\x90\x85'
DEBUG:SolixBLE.device:The client the notification is from is: BleakClient, F4:9D:8A:13:CE:82
DEBUG:SolixBLE.device:Received notification from 'Solarbank 2 E1600 Pro'. length: 77, packet: 'ff094d00030001082100a1401e8d3088e84e1e902688aea10302f93fe637c26003a82aeff639cfbebaf5c604fc11508c6874e2101ba07b339ad393eef8c1c9935148c8141a18cd0e8f7dfa6d20'
DEBUG:SolixBLE.device:Pattern: 030001
DEBUG:SolixBLE.device:CMD: 0821
DEBUG:SolixBLE.device:Payload: 00a1401e8d3088e84e1e902688aea10302f93fe637c26003a82aeff639cfbebaf5c604fc11508c6874e2101ba07b339ad393eef8c1c9935148c8141a18cd0e8f7dfa6d
DEBUG:SolixBLE.device:Payload length: 67
DEBUG:SolixBLE.device:Received encryption negotiation message!
DEBUG:SolixBLE.device:Entered negotiation stage 5 due to response from device!
DEBUG:SolixBLE.device:Parameters: {'a1': '1e8d3088e84e1e902688aea10302f93fe637c26003a82aeff639cfbebaf5c604fc11508c6874e2101ba07b339ad393eef8c1c9935148c8141a18cd0e8f7dfa6d'}
DEBUG:SolixBLE.device:Public key of device: 041e8d3088e84e1e902688aea10302f93fe637c26003a82aeff639cfbebaf5c604fc11508c6874e2101ba07b339ad393eef8c1c9935148c8141a18cd0e8f7dfa6d
DEBUG:SolixBLE.device:Shared secret: 4a30f523082b0a652869fa7e89202f78fe7581d7e5502009a7c343f8a2e82008
DEBUG:SolixBLE.device:AES key: 4a30f523082b0a652869fa7e89202f78
DEBUG:SolixBLE.device:AES IV: fe7581d7e5502009a7c343f8a2e82008
DEBUG:SolixBLE.device:Sending stage 5 response message...
DEBUG:bleak.backends.bluezdbus.client:Write Characteristic 8c850002-0302-41c5-b46e-cf057c562025 | /org/bluez/hci0/dev_F4_9D_8A_13_CE_82/service000e/char000f: b'\xff\tZ\x00\x03\x00\x01@"X\x0b\xc0S*S\xc79\xad\xf3\xda{\x99J{_"\x1b\xcc\x16\xba\xb69,!\\\xb4\xfa\xafA\xd9\xd5\x8e,\x81\xc0\x16\xe4t\xc7\x8e\xedUi\x14|\xb7J\x1f"\xca+?\xad. \x9d\xbb\xcf\xbd\xac\xa3R\x03JlG\x9f\x05_hX\x1b_\x1e"4\x88\t\xf5&'
DEBUG:SolixBLE.device:Negotiations with 'Solarbank 2 E1600 Pro' succeeded!
DEBUG:SolixBLE.device:Automatic reconnect task ready and waiting for disconnect event from 'Solarbank 2 E1600 Pro'!
DEBUG:SolixBLE.device:The client the notification is from is: BleakClient, F4:9D:8A:13:CE:82
DEBUG:SolixBLE.device:Received notification from 'Solarbank 2 E1600 Pro'. length: 253, packet: 'ff09fd0003010fc40513c854310cabf9a3aa16623be7bb2d51a0beb5d64ab8e6cd1f04958220e0af32c8b223f78215e4bd45feeac9c6af62b3ae1a6e36b1a9d6a60c6936525ca0fc322f12caf31db71dc75f46e95093150b4f67a37b97c55678eccc6ab2ed99546e2a00f80956e4d516234eb9e990212bec91e1939eb785c4fa3bb759f743b741dd899d4e137e7394a76eb9c7e2223ecebfc8d65fdad14ecbd1d3684d5b6a9159ce682622f41a58036aa633c2b0513314fddd524bd119739075f26cc7a79e70cb2a4bf9a19e145d23259ec53882aa2487496c198fef089339e241818281c69538a8b33ffa8e49864f5e028fd11ce5c1af6aeef0631bae'
DEBUG:SolixBLE.device:Pattern: 03010f
DEBUG:SolixBLE.device:CMD: c405
DEBUG:SolixBLE.device:Payload: 13c854310cabf9a3aa16623be7bb2d51a0beb5d64ab8e6cd1f04958220e0af32c8b223f78215e4bd45feeac9c6af62b3ae1a6e36b1a9d6a60c6936525ca0fc322f12caf31db71dc75f46e95093150b4f67a37b97c55678eccc6ab2ed99546e2a00f80956e4d516234eb9e990212bec91e1939eb785c4fa3bb759f743b741dd899d4e137e7394a76eb9c7e2223ecebfc8d65fdad14ecbd1d3684d5b6a9159ce682622f41a58036aa633c2b0513314fddd524bd119739075f26cc7a79e70cb2a4bf9a19e145d23259ec53882aa2487496c198fef089339e241818281c69538a8b33ffa8e49864f5e028fd11ce5c1af6aeef0631b
DEBUG:SolixBLE.device:Payload length: 243
DEBUG:SolixBLE.device:Received unknown message of type: c405
ERROR:SolixBLE.device:Exception decrypting unknown message type
Traceback (most recent call last):
  File "/home/julian/projects/SolixBLE/SolixBLE/device.py", line 586, in _process_notification
    decrypted_payload = self._decrypt_payload(payload)
  File "/home/julian/projects/SolixBLE/SolixBLE/device.py", line 448, in _decrypt_payload
    return cipher.decrypt(payload)
           ~~~~~~~~~~~~~~^^^^^^^^^
  File "/home/julian/projects/SolixBLE/.venv/lib64/python3.13/site-packages/Crypto/Cipher/_mode_cbc.py", line 246, in decrypt
    raise ValueError("Data must be padded to %d byte boundary in CBC mode" % self.block_size)
ValueError: Data must be padded to 16 byte boundary in CBC mode
DEBUG:SolixBLE.device:The client the notification is from is: BleakClient, F4:9D:8A:13:CE:82
DEBUG:SolixBLE.device:Received notification from 'Solarbank 2 E1600 Pro'. length: 253, packet: 'ff09fd0003010fc40523ec71b88dfe159cc39a620c8c910b449efb09d5601b0c0fb7f1681b0a422f57a3880a35ad488277280f10c28bc4b419413513dcc3c53b972f5a22e3697d289a811d5119936dbc6a462bca208c9e17253e714a6ae0b4945acb4d2412f7ade88f993178d0c9fe1ce93f05074012e7aa6d39b9e53d9c35e7e5aaf5d06457bff3fb842b99af5ac9d596f2133d0b71d6cd9ae5d6cbe7cc555c34e6569e3aacd9cbdd20b2bc29e40ffa5d40849389d033e4138dc6815591d804fd5d5b3b00f48d149c2dc1c83ce01acc580fe2b1df261785efd1ba04ce34a7afd9df2cecb9d717d7c9ee245955dc80215d771bc0de8def84e4d8aa350a'
DEBUG:SolixBLE.device:Pattern: 03010f
DEBUG:SolixBLE.device:CMD: c405
DEBUG:SolixBLE.device:Payload: 23ec71b88dfe159cc39a620c8c910b449efb09d5601b0c0fb7f1681b0a422f57a3880a35ad488277280f10c28bc4b419413513dcc3c53b972f5a22e3697d289a811d5119936dbc6a462bca208c9e17253e714a6ae0b4945acb4d2412f7ade88f993178d0c9fe1ce93f05074012e7aa6d39b9e53d9c35e7e5aaf5d06457bff3fb842b99af5ac9d596f2133d0b71d6cd9ae5d6cbe7cc555c34e6569e3aacd9cbdd20b2bc29e40ffa5d40849389d033e4138dc6815591d804fd5d5b3b00f48d149c2dc1c83ce01acc580fe2b1df261785efd1ba04ce34a7afd9df2cecb9d717d7c9ee245955dc80215d771bc0de8def84e4d8aa35
DEBUG:SolixBLE.device:Payload length: 243
DEBUG:SolixBLE.device:Received unknown message of type: c405
ERROR:SolixBLE.device:Exception decrypting unknown message type
Traceback (most recent call last):
  File "/home/julian/projects/SolixBLE/SolixBLE/device.py", line 586, in _process_notification
    decrypted_payload = self._decrypt_payload(payload)
  File "/home/julian/projects/SolixBLE/SolixBLE/device.py", line 448, in _decrypt_payload
    return cipher.decrypt(payload)
           ~~~~~~~~~~~~~~^^^^^^^^^
  File "/home/julian/projects/SolixBLE/.venv/lib64/python3.13/site-packages/Crypto/Cipher/_mode_cbc.py", line 246, in decrypt
    raise ValueError("Data must be padded to %d byte boundary in CBC mode" % self.block_size)
ValueError: Data must be padded to 16 byte boundary in CBC mode
DEBUG:SolixBLE.device:The client the notification is from is: BleakClient, F4:9D:8A:13:CE:82
DEBUG:SolixBLE.device:Received notification from 'Solarbank 2 E1600 Pro'. length: 39, packet: 'ff09270003010fc40533ecea1c09301d956378241b6d6eccbe078a8fcc1322b732e6ab4d75c31c'
DEBUG:SolixBLE.device:Pattern: 03010f
DEBUG:SolixBLE.device:CMD: c405
DEBUG:SolixBLE.device:Payload: 33ecea1c09301d956378241b6d6eccbe078a8fcc1322b732e6ab4d75c3
DEBUG:SolixBLE.device:Payload length: 29
DEBUG:SolixBLE.device:Received unknown message of type: c405
ERROR:SolixBLE.device:Exception decrypting unknown message type
Traceback (most recent call last):
  File "/home/julian/projects/SolixBLE/SolixBLE/device.py", line 586, in _process_notification
    decrypted_payload = self._decrypt_payload(payload)
  File "/home/julian/projects/SolixBLE/SolixBLE/device.py", line 448, in _decrypt_payload
    return cipher.decrypt(payload)
           ~~~~~~~~~~~~~~^^^^^^^^^
  File "/home/julian/projects/SolixBLE/.venv/lib64/python3.13/site-packages/Crypto/Cipher/_mode_cbc.py", line 246, in decrypt
    raise ValueError("Data must be padded to %d byte boundary in CBC mode" % self.block_size)
ValueError: Data must be padded to 16 byte boundary in CBC mode
DEBUG:SolixBLE.device:The client the notification is from is: BleakClient, F4:9D:8A:13:CE:82
DEBUG:SolixBLE.device:Received notification from 'Solarbank 2 E1600 Pro'. length: 26, packet: 'ff091a0003010f440940b347438cbedb04133c595cd4261d394a'
DEBUG:SolixBLE.device:Pattern: 03010f
DEBUG:SolixBLE.device:CMD: 4409
DEBUG:SolixBLE.device:Payload: 40b347438cbedb04133c595cd4261d39
DEBUG:SolixBLE.device:Payload length: 16
DEBUG:SolixBLE.device:Received unknown message of type: 4409
DEBUG:SolixBLE.device:Decrypted payload: a10131a2020100a302012f0505050505
DEBUG:SolixBLE.device:Parameters: {
    "a1": {
        "bytes": "b'1'",
        "hex": "31",
        "int": "0",
        "uint": "0"
    },
    "a2": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "a3": {
        "bytes": "b'\\x01/'",
        "hex": "012f",
        "int": "47",
        "uint": "47"
    }
}
DEBUG:SolixBLE.device:The client the notification is from is: BleakClient, F4:9D:8A:13:CE:82

Is this really just a padding issue or is it using a different encryption mechanism? I've read GCM might be used by some models.
Sorry I'm not very familiar with the Anker devices and these protocols. I'm willing to help but I need some guidance

Edit: Included encryption secrets

[jul1an-s]

OK I Claude got it working ;-) It was really just padding. Now I just have to implement the parser.

I'll follow up when I can control the Solarbank 2 Pro.

DEBUG:SolixBLE.device:Parameters: {
    "a1": {
        "bytes": "b'1'",
        "hex": "31",
        "int": "0",
        "uint": "0"
    },
    "a2": {
        "bytes": "b'\\x00APCGQ80E23700414'",
        "hex": "0041504347513830453233373030343134",
        "int": "69375336830057035675862955851906240577",
        "uint": "69375336830057035675862955851906240577"
    },
    "a3": {
        "bytes": "b'\\x016'",
        "hex": "0136",
        "int": "54",
        "uint": "54"
    },
    "a4": {
        "bytes": "b'\\x01\\x02'",
        "hex": "0102",
        "int": "2",
        "uint": "2"
    },
    "a5": {
        "bytes": "b'\\x02\\x00\\x00'",
        "hex": "020000",
        "int": "0",
        "uint": "0"
    },
    "a6": {
        "bytes": "b'\\x03\\x01\\x00\\x06\\n'",
        "hex": "030100060a",
        "int": "168165377",
        "uint": "168165377"
    },
    "a7": {
        "bytes": "b'\\x03\\x00\\x00\\x061'",
        "hex": "0300000631",
        "int": "822476800",
        "uint": "822476800"
    },
    "a8": {
        "bytes": "b'\\x03\\x00\\x03\\x03\\x06'",
        "hex": "0300030306",
        "int": "100860672",
        "uint": "100860672"
    },
    "a9": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "aa": {
        "bytes": "b'\\x01\\x15'",
        "hex": "0115",
        "int": "21",
        "uint": "21"
    },
    "ab": {
        "bytes": "b'\\x03\\xb2\\x0c\\x00\\x00'",
        "hex": "03b20c0000",
        "int": "3250",
        "uint": "3250"
    },
    "ac": {
        "bytes": "b'\\x03\\xea\\x01\\x00\\x00'",
        "hex": "03ea010000",
        "int": "490",
        "uint": "490"
    },
    "ad": {
        "bytes": "b'\\x016'",
        "hex": "0136",
        "int": "54",
        "uint": "54"
    },
    "ae": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "af": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "b0": {
        "bytes": "b'\\x03\\xd0k\\x00\\x00'",
        "hex": "03d06b0000",
        "int": "27600",
        "uint": "27600"
    },
    "b1": {
        "bytes": "b'\\x03\\xbf\\xb9\\x0b\\x00'",
        "hex": "03bfb90b00",
        "int": "768447",
        "uint": "768447"
    },
    "b2": {
        "bytes": "b'\\x03\\xecT>\\x00'",
        "hex": "03ec543e00",
        "int": "4084972",
        "uint": "4084972"
    },
    "b3": {
        "bytes": "b'\\x03\\xd5\\xa0\\t\\x00'",
        "hex": "03d5a00900",
        "int": "630997",
        "uint": "630997"
    },
    "b4": {
        "bytes": "b'\\x01\\n'",
        "hex": "010a",
        "int": "10",
        "uint": "10"
    },
    "b5": {
        "bytes": "b'\\x01\\x05'",
        "hex": "0105",
        "int": "5",
        "uint": "5"
    },
    "b6": {
        "bytes": "b'\\x01\\n'",
        "hex": "010a",
        "int": "10",
        "uint": "10"
    },
    "b7": {
        "bytes": "b'\\x03\\x00\\x00\\x00\\x00'",
        "hex": "0300000000",
        "int": "0",
        "uint": "0"
    },
    "b8": {
        "bytes": "b'\\x01\\x01'",
        "hex": "0101",
        "int": "1",
        "uint": "1"
    },
    "b9": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "ba": {
        "bytes": "b'\\x03\\x1e\\x00\\x00\\x00'",
        "hex": "031e000000",
        "int": "30",
        "uint": "30"
    },
    "bb": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "bc": {
        "bytes": "b'\\x03\\x00\\x00\\x00\\x00'",
        "hex": "0300000000",
        "int": "0",
        "uint": "0"
    },
    "bd": {
        "bytes": "b'\\x03\\x00\\x00\\x00\\x00'",
        "hex": "0300000000",
        "int": "0",
        "uint": "0"
    },
    "be": {
        "bytes": "b'\\x03\\x00\\x00\\x00\\x00'",
        "hex": "0300000000",
        "int": "0",
        "uint": "0"
    },
    "bf": {
        "bytes": "b'\\x03\\x00\\x00\\x00\\x00'",
        "hex": "0300000000",
        "int": "0",
        "uint": "0"
    },
    "c0": {
        "bytes": "b'\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00'",
        "hex": "0000000000000000000000000000000000",
        "int": "0",
        "uint": "0"
    },
    "c1": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "c2": {
        "bytes": "b'\\x02 \\x03'",
        "hex": "022003",
        "int": "800",
        "uint": "800"
    },
    "c4": {
        "bytes": "b'\\x03\\xea\\x01\\x00\\x00'",
        "hex": "03ea010000",
        "int": "490",
        "uint": "490"
    },
    "c5": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "c6": {
        "bytes": "b'\\x01\\x01'",
        "hex": "0101",
        "int": "1",
        "uint": "1"
    },
    "c7": {
        "bytes": "b'\\x022\\x00'",
        "hex": "023200",
        "int": "50",
        "uint": "50"
    },
    "c8": {
        "bytes": "b'\\x03\\x00\\x00\\x00\\x00'",
        "hex": "0300000000",
        "int": "0",
        "uint": "0"
    },
    "c9": {
        "bytes": "b'\\x03\\x04\\x00\\x00\\x00'",
        "hex": "0304000000",
        "int": "4",
        "uint": "4"
    },
    "ca": {
        "bytes": "b'\\x03v\\x02\\x00\\x00'",
        "hex": "0376020000",
        "int": "630",
        "uint": "630"
    },
    "cb": {
        "bytes": "b'\\x03J\\x06\\x00\\x00'",
        "hex": "034a060000",
        "int": "1610",
        "uint": "1610"
    },
    "cc": {
        "bytes": "b'\\x03\\xae\\x01\\x00\\x00'",
        "hex": "03ae010000",
        "int": "430",
        "uint": "430"
    },
    "cd": {
        "bytes": "b'\\x03D\\x02\\x00\\x00'",
        "hex": "0344020000",
        "int": "580",
        "uint": "580"
    },
    "d2": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "d3": {
        "bytes": "b'\\x03\\xea\\x01\\x00\\x00'",
        "hex": "03ea010000",
        "int": "490",
        "uint": "490"
    },
    "d4": {
        "bytes": "b'\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00'",
        "hex": "0000000000000000000000000000000000",
        "int": "0",
        "uint": "0"
    },
    "d5": {
        "bytes": "b'\\x02\\x00\\x00'",
        "hex": "020000",
        "int": "0",
        "uint": "0"
    },
    "d6": {
        "bytes": "b'\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00'",
        "hex": "0000000000000000000000000000000000",
        "int": "0",
        "uint": "0"
    },
    "d7": {
        "bytes": "b'\\x02\\x00\\x00'",
        "hex": "020000",
        "int": "0",
        "uint": "0"
    },
    "d8": {
        "bytes": "b'\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00'",
        "hex": "0000000000000000000000000000000000",
        "int": "0",
        "uint": "0"
    },
    "d9": {
        "bytes": "b'\\x02\\x00\\x00'",
        "hex": "020000",
        "int": "0",
        "uint": "0"
    },
    "da": {
        "bytes": "b'\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00'",
        "hex": "0000000000000000000000000000000000",
        "int": "0",
        "uint": "0"
    },
    "db": {
        "bytes": "b'\\x02\\x00\\x00'",
        "hex": "020000",
        "int": "0",
        "uint": "0"
    },
    "dc": {
        "bytes": "b'\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00'",
        "hex": "0000000000000000000000000000000000",
        "int": "0",
        "uint": "0"
    },
    "dd": {
        "bytes": "b'\\x02\\x00\\x00'",
        "hex": "020000",
        "int": "0",
        "uint": "0"
    },
    "de": {
        "bytes": "b'\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00'",
        "hex": "0000000000000000000000000000000000",
        "int": "0",
        "uint": "0"
    },
    "df": {
        "bytes": "b'\\x02\\x00\\x00'",
        "hex": "020000",
        "int": "0",
        "uint": "0"
    },
    "e0": {
        "bytes": "b'\\x01\\x03'",
        "hex": "0103",
        "int": "3",
        "uint": "3"
    },
    "e1": {
        "bytes": "b'\\x01\\x01'",
        "hex": "0101",
        "int": "1",
        "uint": "1"
    },
    "e2": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "e3": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "e4": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "e5": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "e6": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "e7": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "e8": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "e9": {
        "bytes": "b'\\x01\\x00'",
        "hex": "0100",
        "int": "0",
        "uint": "0"
    },
    "ea": {
        "bytes": "b'\\x01\\x01'",
        "hex": "0101",
        "int": "1",
        "uint": "1"
    },
    "fb": {
        "bytes": "b'\\x03\\x00\\x00\\x00\\x00'",
        "hex": "0300000000",
        "int": "0",
        "uint": "0"
    },
    "fc": {
        "bytes": "b'\\x04\\x01\\x01\\x01\\x01\\x00\\x01\\x01\\x01\\x01\\x01\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00'",
        "hex": "04010101010001010101010100000000000000000000",
        "int": "1213666705181741072580865",
        "uint": "1213666705181741072580865"
    },
    "fe": {
        "bytes": "b'\\x03\\xb5y\\xcai'",
        "hex": "03b579ca69",
        "int": "1774877109",
        "uint": "1774877109"
    }
}

[smariacher]

FYI: You actually don't have to worry about GCM/CBC as far as I can tell. The app uses GCM and this github CBC, and both encryption methods work for some reason. So don't let claude implement a whole new encryption method, just use the already available send command functions. Good luck!

[flip-dots]

@jul1an-s This sped up my work under #16 which reworked a bunch of things to make it easier to override methods like decryption, parsing, and padding, on a per-device basis (needed for adding support for Anker Prime devices which use different encryption methods), so you might want to base your work off that.

So Solix devices tend to split the payloads across multiple packets which can cause that error if the split packet is not combined/handled correctly, your device might need special logic for that. The general approach I encourage is overriding the methods you need to on a per-class basis rather than modify the base class and then add tests for the overridden methods.

[jul1an-s]

Thank you both for your inputs :-)

Yes the fragmentation of the telemetry was the issue. The Solarbank 2 Pro uses 3 fragments to transmit its entire telemetry. Current code only supported 2 fragments.

Yes I like the approach to apply overrides per class whenever needed and will structure my code accordingly.

But shouldn't we handle the fragmentation inside device.py?
The first byte of a decrypted payload contains the fragment information:

async def _process_notification(

   ...
                            # Check if the first byte encodes fragment
                            # info (high nibble = index, low nibble =
                            # total). Multi-part messages need to be
                            # reassembled before decryption.
                            fragment_index = (payload[0] >> 4) & 0x0F
                            fragment_total = payload[0] & 0x0F

   ...

This applies at least to c405 CMDs.

But maybe it is also present in c402 CMDs, because maybe you strip it in:

    def _parse_payload(self, payload: bytearray) -> dict[str, bytes]:
        """Parse payload bytes into parameters."""

        parsed_data: dict[str, bytes] = {}
        remaining_data = bytearray(payload)

        # Packets sometimes start with 00 and we must strip that
        if remaining_data.startswith(bytes.fromhex("00")):
            remaining_data.pop(0)

What do you think? If this applies to all telemetry CMDs, multiple devices could benefit from it.

[jul1an-s]

Btw the existing properties are now populated properly:

Solarbank2(
    AC_POWER_OUT: 48.0,
    AC_POWER_OUT_SOCKETS: 0.0,
    ADDRESS: F4:9D:8A:13:CE:82,
    AVAILABLE: True,
    BATTERY_CHARGE_POWER: 0.0,
    BATTERY_DISCHARGE_POWER: 48.0,
    BATTERY_PERCENTAGE: 44,
    BATTERY_PERCENTAGE_AGGREGATE: 44,
    CHARGED_ENERGY: 412.2206,
    CONNECTED: True,
    CONSUMED_ENERGY: 0.0004,
    GRID_EXPORT_ENERGY: 0.0,
    GRID_IMPORT_ENERGY: 0.0,
    GRID_TO_HOME_POWER: 0.0,
    HOUSE_DEMAND: 48.0,
    LAST_UPDATE: 2026-03-31 01:28:16.322064,
    NAME: Solarbank 2 E1600 Pro,
    NEGOTIATED: True,
    OUTPUT_ENERGY: 63.5728,
    POWER_OUT: 48.0,
    PV_TO_GRID_POWER: 0.0,
    PV_YIELD: 77.3481,
    SERIAL_NUMBER: XXXREDACTEDXXX,
    SOFTWARE_VERSION: 1.6.8.1.6.5.3.7.7,
    SOFTWARE_VERSION_CONTROLLER: 8.2.2.4.7.6.8.0.0,
    SOFTWARE_VERSION_EXPANSION: 1.0.0.8.6.0.6.7.2,
    SOLAR_POWER_IN: 0.0,
    SOLAR_PV_1_POWER_IN: 0.0,
    SOLAR_PV_2_POWER_IN: 0.0,
    SOLAR_PV_3_POWER_IN: 0.0,
    SOLAR_PV_4_POWER_IN: 0.0,
    TEMPERATURE: 7,
)

I'll include the missing ones from https://github.com/thomluther/anker-solix-api/blob/35e5c3664862d1f3f4d01e2717a7d6e0b1b2fce2/api/mqttmap.py#L1306

[flip-dots]

Thank you both for your inputs :-)

Yes the fragmentation of the telemetry was the issue. The Solarbank 2 Pro uses 3 fragments to transmit its entire telemetry. Current code only supported 2 fragments.

Yes I like the approach to apply overrides per class whenever needed and will structure my code accordingly.

But shouldn't we handle the fragmentation inside device.py? The first byte of a decrypted payload contains the fragment information:

async def _process_notification(

   ...
                            # Check if the first byte encodes fragment
                            # info (high nibble = index, low nibble =
                            # total). Multi-part messages need to be
                            # reassembled before decryption.
                            fragment_index = (payload[0] >> 4) & 0x0F
                            fragment_total = payload[0] & 0x0F

   ...

This applies at least to c405 CMDs.

But maybe it is also present in c402 CMDs, because maybe you strip it in:

    def _parse_payload(self, payload: bytearray) -> dict[str, bytes]:
        """Parse payload bytes into parameters."""

        parsed_data: dict[str, bytes] = {}
        remaining_data = bytearray(payload)

        # Packets sometimes start with 00 and we must strip that
        if remaining_data.startswith(bytes.fromhex("00")):
            remaining_data.pop(0)

What do you think? If this applies to all telemetry CMDs, multiple devices could benefit from it.

@jul1an-s If you can get it to work, go for it. I have tests for Solix devices and Prime devices which test the processing and ordering of telemetry packets, so if those pass (when the override for Prime devices is disabled) then it should work. I must admit it would be very nice to have a universal mechanism for handling it, I just haven't had enough data to figure out the pattern.

[jul1an-s]

I started investigating the set schedule command for the SB2 because the schedule is not included in the regular telemetry ("c405") and I couldn't find a command to trigger its transmission.

First off all it is really incredible how much work you put into these scripts and how easy it is to use them, even for someone with little experience in this field. Great job!

I quickly got the set schedule command c05e. It seems to be split into two fragments:

1/2
ff09 fd00 03000f c05e 12 2b044f39d5593a9a197c8d62c2bc05f20ee6d881feb846ba40b9a80f87095dc683f426010242d402e97fe43d070620c5361e20f4c229079ef84dee7d50338c34dfd36c5a385a9d1b790974959b21f86503b19a0e9fd9a8faf9fb826289df38d1ca33d30142cc83f90459ade3cf0bd4616cb1f1651c186b351a864d55999713873c7b4637273fd749763a9295df22c63aec7dacb4f5fa220f31d8ba9fa160b22f2810df2420c023dba54fa9cd8fd9095fbd1e8aa8c4b292b076437b2bf82e998020c23b3df0e405b09a6860a02d60a8684ed3cdea50e5e97b7674ffb30be20b9d0ca7b4f37c8f31b94b565ee4702f377fc4b1fb

2/2
ff09 4800 03000f c05e 22 12b4e44678a4cb98a2d78131855745f84d041f408d74d40bdf00de6a923f49350aeeb2e91f30d8626c291cb5623a5402092752473d174e8504b9be1c11b9

This contains a very simple schedule (50W around the clock).
Expected payload from the App logs:

{
    "mode_type": 3,
    "default_home_load": 200,
    "max_load": 800,
    "min_load": 0,
    "step": 10,
    "blend_plan": null,
    "custom_rate_plan": [
        {
            "ranges": [
                {
                    "start_time": "00:00",
                    "end_time": "24:00",
                    "power": 50,
                    "exceed_alarm": null
                }
            ],
            "week": [
                0,
                1,
                2,
                3,
                4,
                5,
                6
            ],
            "index": 0
        }
    ],
    "ai_ems": null,
    "data_auth": null,
    "reserved_soc": 0
}

However I'm having a hard time to decrypt the payload. My attempts have failed so far.
Any chance you could take a look @flip-dots and give me a hint? I can share the encryption keys with you via email.

@thomluther is there a command to get the schedule from the SB2 via api that I missed in your repo?

I appreciate any feedback or ideas

[thomluther]

@thomluther is there a command to get the schedule from the SB2 via api that I missed in your repo?

You can use get_device_parm method with paramType = SolixParmType.SOLARBANK_2_SCHEDULE.value or "6"

[flip-dots]

I started investigating the set schedule command for the SB2 because the schedule is not included in the regular telemetry ("c405") and I couldn't find a command to trigger its transmission.

First off all it is really incredible how much work you put into these scripts and how easy it is to use them, even for someone with little experience in this field. Great job!

I quickly got the set schedule command c05e. It seems to be split into two fragments:

1/2
ff09 fd00 03000f c05e 12 2b044f39d5593a9a197c8d62c2bc05f20ee6d881feb846ba40b9a80f87095dc683f426010242d402e97fe43d070620c5361e20f4c229079ef84dee7d50338c34dfd36c5a385a9d1b790974959b21f86503b19a0e9fd9a8faf9fb826289df38d1ca33d30142cc83f90459ade3cf0bd4616cb1f1651c186b351a864d55999713873c7b4637273fd749763a9295df22c63aec7dacb4f5fa220f31d8ba9fa160b22f2810df2420c023dba54fa9cd8fd9095fbd1e8aa8c4b292b076437b2bf82e998020c23b3df0e405b09a6860a02d60a8684ed3cdea50e5e97b7674ffb30be20b9d0ca7b4f37c8f31b94b565ee4702f377fc4b1fb

2/2
ff09 4800 03000f c05e 22 12b4e44678a4cb98a2d78131855745f84d041f408d74d40bdf00de6a923f49350aeeb2e91f30d8626c291cb5623a5402092752473d174e8504b9be1c11b9

This contains a very simple schedule (50W around the clock). Expected payload from the App logs:

{
"mode_type": 3,
"default_home_load": 200,
"max_load": 800,
"min_load": 0,
"step": 10,
"blend_plan": null,
"custom_rate_plan": [
{
"ranges": [
{
"start_time": "00:00",
"end_time": "24:00",
"power": 50,
"exceed_alarm": null
}
],
"week": [
0,
1,
2,
3,
4,
5,
6
],
"index": 0
}
],
"ai_ems": null,
"data_auth": null,
"reserved_soc": 0
}

However I'm having a hard time to decrypt the payload. My attempts have failed so far. Any chance you could take a look @flip-dots and give me a hint? I can share the encryption keys with you via email.

@thomluther is there a command to get the schedule from the SB2 via api that I missed in your repo?

I appreciate any feedback or ideas

@jul1an-s So what I did when I was originally figuring the encryption out was rather crude but quite effective. I basically wrote a Python script which would try every possible substring of a packet and try to decrypt and return the correct indexes when it was able to decrypt it (detected via finding expected values like a1, a2, a3, and the serial number in the decrypted payload) and that worked, the last bit of the packet was always corrupted but I didn't care, it was only when I looked into it more that I realised payloads were being spread across multiple packets and I was then able to get the whole thing. Your device might be using different indexes, the order might be different, or it might be using AES GCM rather than AES CBC. The app logs should specify what encryption is being used. I recommend setting up a test with the encrypted packets, keys, and decrypted payloads captured with the app and then tweaking things until it works.

I got quite a lot of coursework due soon so I am not going to be able to take much of a deeper look into it until at least the weekend (but possibly later than that).

[thomluther]

the last bit of the packet was always corrupted but I didn't care, it

The last bit could be an XOR checksum for the package and may need to be removed, especially for split payloads

[flip-dots]

the last bit of the packet was always corrupted but I didn't care, it

The last bit could be an XOR checksum for the package and may need to be removed, especially for split payloads

So I knew the last byte was a checksum at the time but my earlier approach cut off the two bytes before the checksum to get it to decrypt properly (since AES CBC needs to be aligned to a 16-byte boundary) and it just seemed to work and I ignored whatever was in those 2 bytes since I figured they could not be that important. Its only when I later started trying to decrypt the second packet and noticing that the first few bytes were junk even after decryption even though the rest of the payload was fine and it did this no matter what I tried, that I realised that the lengths of both of the payloads in bytes was divisible by 16 and that those last two bytes from the payload of the first packet are meant to be appended to the start of the payload of the second packet and then it all decrypts properly. Its a very strange protocol.

[thomluther]

Its a very strange protocol.

Haha, Rest assured that this is not the only strange thing.
It appears like each product family is developing from scratch, not caring about what already exists. There is no clear development strategy across the families from my point of view.

[jul1an-s]

Thank you for your help, especially the insights about the different schedule patterns across devices were very interesting.

However I think I'm clearly doing something wrong or my App is super weird. I can't even decrypt the BLE notifications payload using the intercepted Keys from the App (which works fine in the lib, so it's not a code/Algorithm issue). Additionally lot's of the capturing code doesn't work in my app (like the cipher.doFinal). I tried adding more captures to replace the broken ones, but to no avail. And I couldn't figure out how to capture the plaintext data before it is encrypted.
It's hard to believe the problem is in the App, because why would it be different for different countries... But I can't figure out what I'm doing wrong. Maybe my GrapheneOS has some side effects on the frida session, but idk

[flip-dots]

@jul1an-s have you tried using frida_2.js? @smariacher developed it after they ran into a similar issue with the encryption hooks not working.