APK v3.18.0 field name extraction — reference for mqtt_monitor decoding

[moag1000]

Hi,

I ran a Blutter decompilation (Dart AOT reverse engineering) against libapp.so from Anker App v3.18.0 and extracted JSON field names from the Dart model classes. Sharing this as a potential reference for mqtt_monitor sessions — not as verified data.

Important caveats

• This is static analysis of one APK version. Field names are extracted from toJson/fromJson methods in compiled Dart classes. They reflect what the app internally calls these fields, not necessarily what the MQTT binary protocol uses.
• None of this replaces mqtt_monitor verification. The hex-to-field mapping for binary MQTT data (0405, 0408 etc.) is compiled into native ARM64 code and not directly extractable. The JSON field names apply to the JSON "trans" payloads (X1/HES) and to the app's internal models.
• AI-assisted analysis was used. While the Blutter tool itself is deterministic, the interpretation and grouping was partially AI-assisted. Errors are possible. Treat everything as unverified hints, not facts.
• Anker can change field names between app versions.

What was extracted

• Dart SDK: 3.4.4 (stable), snapshot hash d20a1be77c3d3c41b2a5accaee1ce549
• Tool: Blutter against ARM64 ELF
• Method: grep for string constants in decompiled toJson/fromJson methods

---

A17b1 (Solarbank E1600) — MQTT short-form keys

These map to the abbreviated JSON keys used in the A17b1 MQTT payload:

Key	Likely meaning
soc	State of charge
bp / bpu	Battery power / unit
pp / ppu	PV power / unit
gp / gpu	Grid power / unit
lp / lpu	Load power / unit
op / opu	Output power / unit
ws / bs / gs / ps	WiFi/battery/grid/PV state
m	Mode
mps	Master/parallel state
bds	Battery devices list
dataFlow	Energy flow sub-object

DataFlow sub-fields: p2bp, p2lp, p2gp, b2lp, b2gp, g2bp, g2lp, mpp (micro-inverter power — only relevant for systems with external micro-inverter e.g. MI80/A17X7)

---

🆕 A5101 DataCodeType — MQTT binary data codes (not in upstream)

Extracted from the A5101DataCodeType enum. These are the internal MQTT data code names used by the X1/HES for structured binary data. None of these are currently mapped in mqttmap.py:

Power flow: pvPower, pvBatteryPower, pvGridPower, pvLoadPower, pvToChargerPower, batteryPower, batteryLoadPower, batteryGridPower, batToChargerPower, gridPower, gridLoadPower, gridBatteryPower, gridToChargerPower, loadPower, dieselBatterPower, dieselLoadPower, evChargerAllPower, evChargerOnlineNum

EMS/Control: controlMode, workMode, shiftMode, backupMode, peakShaving, peakShavingValue, gridCharging, manualBackupPower, manualBackupEnable, x1AllowCharge

Grid: gridStandardCode, gridSensitivity, gridSensitivityEnable, realGridState, dredRcrState, rsdState, fastStopState

Heat pump: heatPumpMode, heatPumpSGEnable, secondHeatPumpSGEnable, heatPumpActiveRatePower, heatPumpActiveTime, heatPumpWork, heatPumpStartingProtectionDelay

Diesel/Generator: dieselMode, dieselNormalStartSOC, dieselNormalStopSOC, dieselQuietEnable, dieselQuietStartHour/Min/SOC, dieselQuietStopHour/Min/SOC, dieselMaintenanceCycle/Duration/Enable, dieselNextMaintenanceTime, generatorRatedPower

---

🆕 AI EMS Profit model (not in upstream)

From AiEmsProfitModel.fromJson:

aiems_profit, aiems_profit_total, aiems_self_use_diff, aiems_lifetime_profit, price_unit, running_time, schedule_day, self_use_diff_percent, show_percentage, type

---

🆕 Disaster Preparedness / Storm Guard (not in upstream)

From DeviceDisasterModel and related:

auto_disaster_switch, auto_disaster_status, manual_disaster_switch, manual_disaster_status, disaster_type, disaster_details, current_disaster_detail, start_time, end_time, charging_time, soc, code, event, google_code, uuid

MQTT handlers in APK: _handleMqttAutoDisasterState, _handleMqttManualBackupDisasterState

---

🆕 EV Charger A5190 fields (not in upstream)

Load balancing: dynamicLoadBalancing, loadBalancingSwitch, loadBalancingConnectedId/Type/ConnectionMode/ErrorCode, loadBalancingMainBreakerCurrent, maximumCurrentLimit

Green energy priority: greenEnergyPrioritySwitch, greenEnergyPriorityChargingMode, greenEnergyPriorityMinOutputCurrent, greenEnergyPriorityThreePhaseSwitch

Smart features: smartChargingSwitch, plugAndChargeSwitch, rfidCardSwitch/MaxNum, rainTouchPreventionStatus, boostMode, rechargingPowerOutage

OCPP/Modbus: modbusTcpSwitch, tcpModbusIp/Port/MaxCurrent/PhaseLimit/Timeout

---

🆕 A7320 Generator / Range Extender fields (not in upstream)

Engine: engineIsOpen, engineNumber, engineOilTime, engineStatus, oilEngineSn, faultCodeA/B

Fuel: currentFuelType, gasolineMargin, remainingGasolineUsageTime, lPGMargin, lPGGasolineUsageTime

E1 Battery (connected PPS): e1BatterySOC, e1BatteryChargingPower, e1BatteryControlMode, eOneSn

Range Extender PPS: oilEngineStartCondition, oilEngineStartSoc, oilEngineTargetSoc, oilEngineStrategyStatus, oilUnableExecuteStrategyReason

---

🆕 Grid Config model (not in upstream mqttmap.py)

From A5101StationGridConfigModel: afci, config, dred, faststop, rcr, rsd, status

EMS Mode model

mode_type, sub_mode, battery_reserve, is_off_grid, price, unit, use_time, weekday, weekend, start_time, end_time, start_month, end_month, sea

---

A5101 (HES/X1) — MQTT device info fields (58)

siteId, sn, onlineState, emsMode, emsStatus, pvPower, pvState, pvToBatPower, pvToLoadPower, pvToGridPower, pvToEvChargerPower, batPower, batState, batElectricQuantity, batTotalCount, batToGridPower, batToLoadPower, batToEvChargerPower, gridPower, gridState, gridToBatPower, gridToLoadPower, gridToEvChargerPower, loadPower, dieselPower, dieselToBatPower, dieselToLoadPower, evChargerAllPower, evChargerOnlineNums, packNumber, packDatas, ppsName, ppsPower, ppsState, ppsElectricQuantity, ppsTotalCount, ppsTotalPower, ppsInfos, ppsRealTimeData, dataFlow, pcsName, pcsData, pcsOnlineNum, pcsTotal, atsName, atsData, deviceCard, ...

---

Devices covered

Field names were extracted for: A17B1, A17C0-C5 (Solarbank), A1782 (PPS), A17E1 (E10), A5101 (X1/HES), A5190 (EV Charger), A7320 (Generator), AX170 (ATS), AE100 (Balcony), AS200 (Car Charger), A2687 (Prime Charger). Full lists available on request.

How this might help

When using mqtt_monitor to decode unknown fields, this list can serve as a vocabulary of candidate field names. It does not tell you which hex byte maps to which field — that still requires the controlled testing approach from Discussion #222. But knowing the field names that exist in the app's data model may speed up identification.

Full Blutter output and raw decompiled Dart files available on request.

---

Update (2026-03-27): The repo linked above has been significantly expanded since this post:

• ~243 endpoints (up from 111), including 95 device-specific ones with community priority tags
• Nesting corrections from 460 toJson() class analysis and upstream cross-reference
• Confidence language reworked — claims now distinguish between device-tested, upstream-confirmed, and structurally inferred findings
• New service prefixes discovered: Storm Guard, Dynamic Pricing, Anka AI, EV fault messaging

Details in the CHANGELOG.

[thomluther]

Thanks for the analysis.
Can you use the AI on the decompiled *.so package to identify possible json field names for payloads per Api endpoint?
The Api endpoints are all contained as string in the package and should all be documented in apitypes.py.
However, the endpoint parameters as usable are unknown and only mandatory parameters can be found eventually by trial and error if you have (owner) access to the specific device.

[moag1000]

I am working on that part already in a fork but it's up to this point 94 Response models, 111 endpoints and in addition to that the mapping to the functions. Those are not in the Dart part of the app from which the above mentioned came, but in fromJSON part of the decompiled app itself. First part is extracting the info, second part will be making it usable for you. I'm still in the extraction step :)

Forgot to mention: the DART part should have the UI (including validation) but in sequential order (disassembled) so it "should" be possible to find field validation, mandatory fields etc.
edit again: nevermind... validation is not hard coded at all. validation as used by the app ui is based on i.e. get_power_limit, get_device_attributes and get_device_home_load (home_load_chart in your energy.py)

[moag1000]

I dropped the work on the fork with apk reverse engineering since just checking the PRs resulting from it would be a nightmare and honestly, AI work isn't reliable enough for that amount of data. Instead I restructured what was found and made a new Repo with appropriate disclaimers and information about confidence level.

https://github.com/moag1000/anker-solix-api-exploration

I genuinely hope that this will be of use. The tokens that went into this (due to the sheer amount of data) were ... a lot.

In order to better suit the information for this repo, what can I do?

[thomluther]

Thanks for this repo.
While the documentation has to be used with care and might be partially wrong or misleading, it may give hints for Api exploration that otherwise would not be available.
Eg. the site_device_parm queries:
The get method supports only following types currently [1 2 3 4 5 6 7 12 13 16 18 20 23 26]
However, the set method seems to support other types if the AI findings are correct, e.g. 19 to set the power limit.
Since there are no examples which parameters may be required for such a request, the AI may have provided some hints here as weill, but this would all have to be tested by device owners to see which parameters work and do the actual work.
Some controls may also require a hybrid approach of Api query for App display and MQTT control for real device change...

[moag1000]

Thanks for this repo. While the documentation has to be used with care and might be partially wrong or misleading, it may give hints for Api exploration that otherwise would not be available. Eg. the site_device_parm queries: The get method supports only following types currently [1 2 3 4 5 6 7 12 13 16 18 20 23 26] However, the set method seems to support other types if the AI findings are correct, e.g. 19 to set the power limit. Since there are no examples which parameters may be required for such a request, the AI may have provided some hints here as weill, but this would all have to be tested by device owners to see which parameters work and do the actual work. Some controls may also require a hybrid approach of Api query for App display and MQTT control for real device change...

Thank you very much for your feedback here and in # 423 of the integration.

The endpoint mapping had a systematic extraction error that shifted parameters between adjacent functions — in decompiled ARM64, string constants are loaded sequentially, so one misattribution cascades through all following entries. Your mention on Issue #423 helped find this: the "not accurate" feedback triggered a deeper upstream cross-reference that revealed the shift across 150+ functions.

A separate finding from the depth scan: feed-in_power_limit uses a hyphen, not an underscore — that's a first for me and easy to miss in any extraction method.
Both could have happened manually too, but not as quickly.

Fun fact: many of the newly mined endpoints turned out to be app-UI features (marketing popups, screen savers, AI chat) rather than device controls — not useful for the HA community. The AI should have classified it based on requests.

[thomluther]

Yeah, I could not filter anything else useful from the repo, a lot of stuff was wrong, shifted etc.
The endpoints themselve are documented in the apitypes already, I don't know if anything was missing, I believe I have not seen one that was found and was missing. But not all endpoints have been found by AI. And yes, any UI related functions are useless.
I can imagine that other param types are used for settings only, e.g. 14, 15, 17, 21, 22, 24, 25
What does not work are the 1,2,3,5 types in relation to any time_of_use or time_slot settings. Also settings for dynamic tarif tax and fee I could not find yet, neither do I know how to adjust.
Any information about dynamic tarif and time_slot mode are completely missing.

[moag1000]

Yeah, I could not filter anything else useful from the repo, a lot of stuff was wrong, shifted etc. The endpoints themselve are documented in the apitypes already, I don't know if anything was missing, I believe I have not seen one that was found and was missing. But not all endpoints have been found by AI. And yes, any UI related functions are useless. I can imagine that other param types are used for settings only, e.g. 14, 15, 17, 21, 22, 24, 25 What does not work are the 1,2,3,5 types in relation to any time_of_use or time_slot settings. Also settings for dynamic tarif tax and fee I could not find yet, neither do I know how to adjust. Any information about dynamic tarif and time_slot mode are completely missing.

So I've used a different approach now using the decompiled code and trying do analyze the set and get paths. Theres many new things now but I am not sure if i can trust the results. I've added a changelog to show what changed when so no-one has to read the entire thing or trace commits :)

If the AI is right, the knowledge should help more now, since it tried to analyze the get and set in the BLE communication as well.

edit: it still gets things wrong i.e. where the write happens (api, mqtt) because it's hard to track, but it appears to deliver at least a bit more useful stuff

[moag1000]

Yeah, I could not filter anything else useful from the repo, a lot of stuff was wrong, shifted etc. The endpoints themselves are documented in the apitypes already, I don't know if anything was missing, I believe I have not seen one that was found and was missing. But not all endpoints have been found by AI. And yes, any UI related functions are useless. I can imagine that other param types are used for settings only, e.g. 14, 15, 17, 21, 22, 24, 25. What does not work are the 1,2,3,5 types in relation to any time_of_use or time_slot settings. Also settings for dynamic tarif tax and fee I could not find yet, neither do I know how to adjust. Any information about dynamic tarif and time_slot mode are completely missing.

So I've used a different approach now using the decompiled code and trying to analyze the set and get paths. There's many new things now but I am not sure if I can trust the results. I've added a changelog to show what changed when so no-one has to read the entire thing or trace commits :)

If the AI is right, the knowledge should help more now, since it tried to analyze the get and set in the BLE communication as well.

What's new (2026-03-28):

• BUSINESS_RULES.md — SET command guards, validation logic, error codes. This is stuff that mqtt_monitor can't show: when the app blocks a command (OTA in progress, charge priority active, device offline), what error codes mean (e.g. error 8 exits self-consumption mode), and safety rules (EV charger 6A fallback on communication loss).
• FLOWS.md — 14 step-by-step traces from UI button to wire bytes. Includes the dual API+BLE pattern for schedules and the finding that encoding_type 2 for EV charger is below the Flutter layer.
• BLE_COMMAND_MAP.md — Wire protocol reference (~2400 lines) with TLV format, data types, scaling factors.

Device-tested corrections (on my own SB2 Pro + Smart Plug):

• 0W mode is simply c7 (home_load_preset) set to 0, no special flag
• fc is static capability array (136 msgs, no change on toggle)
• Schedule CRUD confirmed: a2=action(0/1/2) matches your naming exactly
• isEffective inversion from APK assembly was WRONG — device shows a4=1=enabled (normal)

edit: it still gets things wrong i.e. where the write happens (api, mqtt) because it's hard to track, but it appears to deliver at least a bit more useful stuff