Added Solix 3 with Sensors & setting Output Power

[MrChurch]

Title: Solarbank 3 E2700 Pro BLE protocol findings and working implementation

## Solarbank 3 E2700 Pro BLE support and protocol findings

My AI Lumi and I reverse-engineered and tested an Anker Solarbank 3 E2700 Pro (A17C5, firmware 1.0.7.1) locally over Bluetooth. The work is based on the BLE implementation in this project and is intended for the upstream community.

### Authentication and session

The following sequence is working reliably:

- 4001 → 4801
- 4003 → 4803
- 4029 → 4829
- Dynamic ECDH key exchange
- Session key derivation
- AES-GCM decryption and MAC verification
- Dynamic cloud-account/user ID generation
- 4021 → 4821
- 4022 → 4822 (decrypted payload `04`)
- 4027 → 4827
- SESSION_READY
- 4040 telemetry activation

### Solarbank 3 telemetry

For the Solarbank 3 c405 telemetry response we identified and validated:

- `ad`: live inverter/output power (Total Power Out)
- `b9`: active scheduled output power
- `d5`: PV maximum
- `ab`, `ac`: energy counters
- `c7`–`ca`: individual PV input ports

### Controls

The following local BLE controls work with the Solarbank 3 Pro:

- `405e`: seven-day schedule/output target
- Schedule values in 50 W steps (tested with 100, 150, 400 and 750 W)
- `4080`: AC maximum-load selection
- Tested maximum-load values: 350, 600, 800 and 1200 W

The device applies the output target correctly over BLE. Cloud/app schedule metadata is not always updated, so the app may still display an older plan value while the Solarbank follows the new local target.

### Scope and status

Most of the changes were developed with AI. We will now freeze our firmware version and use this implementation to automate our Solarbank 3 Pro over Bluetooth.

The device currently works only as a standalone unit. It has not been tested as part of an integrated system.

Using the Anker app and this integration at the same time will not work.

Maybe you will find our work useful. Feel free to use it.

We are happy with the current result, and at the moment no further changes are planned on our side.

Regards,

MrChurch & Lumi

you can find our changes here: https://github.com/MrChurch/HaSolixBLE feel free to use them :)

[flip-dots]

This is really cool, while I don't have any immediate plans to add this new protocol for the solarbank 3 myself at the moment (though I am open to PRs to add it to SolixBLE) its really great to have something to build on in future (especially with the tests).

On first glance this looks fairly similar to the protocol used by the solarbank 2 for control discovered in #36 by @jul1an-s, I would be interested in knowing if the same protocol/implementation in #36 works for the solarbank 3 as well since that would be super convenient.

[MrChurch]

Hi
The Solarbank 3 appears to share the same post-handshake control payload layout as the Solarbank 2 from PR #36, especially for commands 405e and 4080. However, the SB3 cannot use the SB2 implementation unchanged: it requires its own authenticated Prime-style handshake and AES-GCM session transport. We have verified the SB3 command payloads and control behavior locally; only the transport/session layer differs.

I will let Lumi (the AI) create a PR for you with all relevant Data and better commented :) I added this integration in my Homeassistant and there where now hundrets of plan / Power changes without Issues. We fixed also some issues with the PV Sensors today and think we will now hopefully never touch the running system again :) (our Boxes are now without internet and will stay on this Version, without forced updates)
Regards and thank you so much for the foundation work :)

[jul1an-s]

@MrChurch Did I get this right: The SB3 prime-style handshake differs from the SB2 prime-style handshake?

[MrChurch]

@jul1an-s Yes, that is correct. Both devices use a similar Prime-style outer protocol with 40xx/48xx packets, AES-GCM and ECDH, but the actual handshake differs.
The SB3 uses its own captured flow: dynamic ECDH, account authentication via 4022, authenticated 4822, session-encrypted 4027/4827, and then 4040 for telemetry.
The SB2 handshake from PR #36 uses different stage payloads and authentication semantics. Therefore, the common part is mainly the packet framing and cryptographic building blocks; the handshake implementation itself cannot be shared unchanged. The post-handshake control payloads such as 405e and 4080 are very similar.

[jul1an-s]

Crazy 😲... Thank you for clarifying

[kb1ibt]

That looks like it is the same or at least very similar to the auth I proposed in #49 -- specifically prime_device.py around line 370

[MrChurch]

Hi,

I was not aware of commit 1031460 when we implemented our A17C5 support.

Looking at the timestamps, your commit was authored on 21 July 2026
(04:54 CEST). Our initial Solarbank 3 commits were made on 18 and
19 July 2026.

From a first comparison, the implementations also target different
protocol paths. Your commit uses owner_user_id handling and dynamic
frames for the Prime negotiation path.

Our implementation uses the Solarbank 3 A17C5 protocol:

4001 → 4003 → 4029 → 4021 → 4022 → 4027 → 4040

with dynamic P-256 ECDH, AES-GCM session-key derivation, and the
A17C5-specific responses. I did not see this A17C5-specific approach
in your commit.

Our implementation is now complete for our use case and works reliably
with our Solarbank 3.

Our work was based on:

• the flip-dots codebase as the general BLE foundation
• reverse-engineering of the Anker SOLIX APK
• BLE protocol captures for individual actions in the Anker app
• Home Assistant telemetry to validate and refine the parser
• thomluther/ha-anker-solix as a cloud-data reference, not as a BLE code source
• AI-assisted implementation and review by Lumi

Regards,
MrChurch & Lumi (ChatGpt SOL)

[kb1ibt]

Not debating that your approach with dynamic P-256 ECDH is a better and more secure approach, just correcting your timestamp understanding. PRs 48-52 were based on the retracted #45 due to Harvey's comment in #22 that the singular #45 was a huge PR with over 3000 lines changed.

[kb1ibt]

I do not have an SB3, but while going through some of the existing docs I've been using for reference, I found something that confirmed some of your findings and expands on them in meaningful ways.

The 2-byte command field decomposes -- msgtype = (byte0 & 0x0f) << 8 | byte1, where byte0's high nibble is transport flags (0x4 = encrypted payload, 0x8 = an extra C-series marker) and a 0x8 bit inside the group nibble marks a response. I've checked that against 62 distinct opcodes across four PacketLogger captures without an exception, which is also why ca00 (C-series) and 4a00 (Prime) decode with the same field map -- both are msgtype 0a00.

So your three control opcodes land as:

your opcode	msgtype	meaning
405e	005e	setBackPower / setTacticsTime
4080	0080	setDevicePowerLimit
4040	0040	status request

Those show up in moag1000/anker-solix-api-exploration, a static map of the decompiled app, in its A17C1/A17C2/A17C3/A17C5 SET-command table -- the same opcodes for the Solarbank family, plus a note that A17C5 reuses A17C1DeviceController, which lines up with what you said about the SB3 sharing SB2's control payloads. It also has field-level detail:

msgtype	function	fields
005e	setBackPower	a2: usage_mode, a3: flag, a4: charge_switch, a6: start_ts (u32), a7: end_ts (u32), fd: timestamp
005e	setTacticsTime	a2-bb: 30 schedule slot tags, fd: timestamp
0080	setDevicePowerLimit	a2-a8: grid export + power limit fields (u16)
0040	(status request)	no payload

The notes say setTacticsTime is the largest function in the codebase at ~14 KB, which fits it carrying 30 slots.

Might be worth cross-checking against your captures. If the field names hold, set_schedule(power_w) and set_max_load() could carry the full slot structure rather than a single target.

On the dynamic ECDH -- worth noting for whoever reviews it that the rest of the library replays a hardcoded private key with its matching public key baked into a frozen 0021/4021 frame, so every user shares the same key material. Yours generating a fresh keypair per connection fixes that, not just for the SB3.

[MrChurch]

Thanks — this is very useful and it lines up well with our captures.

We can confirm the command-family mapping from our A17C5 work:

• 405e / msgtype 005e: schedule write
• 4080 / msgtype 0080: power-limit write
• 4040 / msgtype 0040: status request

For 405e, our capture-derived A17C5 builder writes seven identical
day blocks for a 00:00–24:00 schedule and then sends the command inside
the authenticated AES-GCM session. This is consistent with the
setTacticsTime interpretation and the large multi-slot structure.

One detail we want to keep conservative: the static map is an excellent
cross-reference, but we have only hardware-validated the concrete
subsets observed in our own A17C5 captures. In particular, our current
4080 implementation covers the captured maximum-load fields only; we
would not infer the remaining a2–a8 fields without a dedicated capture.

The same applies to 4040: it is clearly the status-request msgtype,
but on A17C5 we see it wrapped in the already established encrypted
session, so the wire-level framing differs from a logical “no payload”
description.

Your point about ECDH is also useful. Our A17C5 path generates a fresh
P-256 keypair per connection and derives a new AES-GCM session key from
the resulting shared secret. We will document that distinction more
explicitly.

Thanks for the reference — it gives us a much better static cross-check
for the parts we already reconstructed dynamically.

---

Unfortunately, we do not have a BLE capture for switching the test plan from Custom mode to Self-Consumption mode. Unlike the Solarbank 2, this setting is not controllable through the Bluetooth app for the Solarbank 3.

Instead, the Solarbank 3 Custom Plan has two tabs: Charge and Discharge. We have now added support for these features experimentally in our fork, but they are not part of the existing PR yet.

Since this allows us to control both charging and discharging locally, it has been sufficient for our use case. However, the behaviour and user interaction are different from the Solarbank 2.