A1761, SOLIX C1000(X) #221
Replies: 29 comments 25 replies
|
Hi, You cannot with the power Api, since the PPS do not provide data to the power cloud. |
|
Hi, here are my first mqtt decoding try for Solix C1000/B1000 , please test it SOLIXMQTTMAP = {
# Solarbank C1000(X)
"A1761": {
"0405": {
"topic": "param_info",
"a5": {"name": "ac_in_?"},
"a6": {"name": "ac_out_?"},
"a7": {"name": "usbc1_out_?"},
"a8": {"name": "usbc2_out_?"},
"a9": {"name": "usba1_out_?"},
"a10": {"name": "usba2_out_?"},
"ae": {"name": "dc_in_?"},
"af": {"name": "power_in_?"},
"c1": {"name": "soc_1_?"},
"c2": {"name": "soc_2_?"},
"b0": {"name": "ac_out_total_?"},
"b3": {"name": "sw_version_c1000_?", "values": 1},
"b9": {"name": "sw_version_b1000_?", "values": 1},
"d0": {"name": "device_sn_?"},
},
},
# Solarbank 1 E1600
"A17C0": {
"0405": { |
|
Hi @khfiebig In general, documented descriptions should be done with messages examples, so basically a screenshot from the monitor where you can also add the real value conversion and unit if necessary. Any power is expected to be in W and Energy to be in kWh, if the byte value is different a proper factor must be specified for the field. In general for the field names we need to consider:
At the end I must implement a wrapper method in the library, which filters/wraps mqtt field names into data fields that can be added to the Api cache. This method will of course only consider 'known' names since they will be hard coded and any fields with ? will be ignored as they are not validated yet for its final purpose. The same will be true if descriptions are added that have very unique names... I never had a PPS, so I'm pretty unfamiliar with all the fields and data that could be extracted. Regarding your descriptions, I would question:
|
|
Hi,
new map, feel free to change it, you have much more experience SOLIXMQTTMAP = {
# Solarbank C1000(X) + B1000 Extension
"A1761": {
"0405": {
"topic": "param_info",
"a5": {"name": "ac_in_?"},
"a6": {"name": "ac_out_?"},
"a7": {"name": "usbc_1_out_?"},
"a8": {"name": "usbc_2_out_?"},
"a9": {"name": "usba_1_out_?"},
"aa": {"name": "usba_2_out_?"},
"ae": {"name": "dc_in_?"},
"c1": {"name": "battery_soc_1_?"},
"c2": {"name": "battery_soc_2_?"},
"b0": {"name": "ac_out_total_?"},
"b3": {"name": "sw_version_1_?", "values": 1},
"b9": {"name": "sw_version_2_?", "values": 1},
"bd": {"name": "temperature_1_?"},
"be": {"name": "temperature_2_?"},
"d0": {"name": "device_sn_?"},
"d1": {"name": "ac_load_max_?"},
"d2": {"name": "device_sleeptime_?"},
},
},
# Solarbank 1 E1600
"A17C0": {
"0405": {
....
a dump from the monitor tool
```shell
10:37:37 INFO:
----------------------------------------------------------------------------------------------------
MQTT Monitor key menu:
----------------------------------------------------------------------------------------------------
10:37:37 INFO: [M]enu to show this key list
10:37:37 INFO: [U]nsubscribe all topics. This will stop receiving MQTT messages
10:37:37 INFO: [S]ubscribe root topic. This will subscribe root only
10:37:37 INFO: [T]oggle subscribed topic. If only one topic identified from root topic, toggling is not possible
10:37:37 INFO: [R]eal time data trigger toggle ON (Default) or OFF
10:37:37 INFO: [V]iew value extraction refresh screen or MQTT message decoding
10:37:37 INFO: [Q]uit, [ESC] or [CTRL-C] to stop MQTT monitor
10:37:41 INFO: Starting MQTT message listener, real time data trigger is: OFF
10:37:41 INFO: MQTT session added new topic to subscriptions: dt/anker_power/A1761/APCXXXXXXXXXX/#
10:37:41 INFO: MQTT client subscribing to topic: dt/anker_power/A1761/APCXXXXXXXXXX/#
10:37:42 INFO:
Received message on topic: dt/anker_power/A1761/APCXXXXXXXXXX/param_info
{'head': {'version': '1.0.0.1', 'client_id': 'APCXXXXXXXXXX', 'sess_id': '5887-5862', 'msg_seq': 196, 'cmd': 16, 'cmd_status': 1, 'sign_code': 0, 'seed': 'null', 'timestamp': 1758875862}, 'payload': '{"data":"/wlrAQMBDwQFoQE0ogUDAAAAAKMFAwAAAACkAwJNAaUDAgAApgMCAACnAwIAAKgDAgAAqQMCAACqAwIAAKsDAgAArAMCAACtAwIAAK4DAgsArwMCCwCwAwIAALEDAgAAsgMCAACzAwKfALQDAgAAtQMCAAC2AwL/AbcDAgAAuAMCkwC5AwJyALoDAp8AuwMCAAC8AgEBvQIBF74CARW/AgEAwAIBAsECAWHCAgE9wwIBYcQCAWPFAgEBxgIBAMcCAQDIAgEAyQIBAMoCAQDLAgEAzAIBAM0CAQDOAgEAzwIBANARAEFQQzZOWDBEMzgzMDAwMjDRAwIsAdIDAtAC0wMCHgDUAwI8ANUDAgAA1gMCAADXAgEA2AIBANkCAQLaAgEy2wIBANwCAQDdAgEA3gIBAOMCAQDlAgEA+BUEAQEBAQAAAAAAAAAAAAAAAAAAAAD5AgEC/QsAQTE3NjFfMzBBaP4FA8NQ1mgm","sn":"APCXXXXXXXXXX","pn":"A1761"}'}
10:37:42 INFO: 2025-37-26 10:37:42 Device hex data:
ff:09:6b:01:03:01:0f:04:05:a1:01:34:a2:05:03:00:00:00:00:a3:05:03:00:00:00:00:a4:03:02:4d:01:a5:03:02:00:00:a6:03:02:00:00:a7:03:02:00:00:a8:03:02:00:00:a9:03:02:00:00:aa:03:02:00:00:ab:03:02:00:00:ac:03:02:00:00:ad:03:02:00:00:ae:03:02:0b:00:af:03:02:0b:00:b0:03:02:00:00:b1:03:02:00:00:b2:03:02:00:00:b3:03:02:9f:00:b4:03:02:00:00:b5:03:02:00:00:b6:03:02:ff:01:b7:03:02:00:00:b8:03:02:93:00:b9:03:02:72:00:ba:03:02:9f:00:bb:03:02:00:00:bc:02:01:01:bd:02:01:17:be:02:01:15:bf:02:01:00:c0:02:01:02:c1:02:01:61:c2:02:01:3d:c3:02:01:61:c4:02:01:63:c5:02:01:01:c6:02:01:00:c7:02:01:00:c8:02:01:00:c9:02:01:00:ca:02:01:00:cb:02:01:00:cc:02:01:00:cd:02:01:00:ce:02:01:00:cf:02:01:00:d0:11:00:41:50:43:36:4e:58:30:44:33:38:33:30:30:30:32:30:d1:03:02:2c:01:d2:03:02:d0:02:d3:03:02:1e:00:d4:03:02:3c:00:d5:03:02:00:00:d6:03:02:00:00:d7:02:01:00:d8:02:01:00:d9:02:01:02:da:02:01:32:db:02:01:00:dc:02:01:00:dd:02:01:00:de:02:01:00:e3:02:01:00:e5:02:01:00:f8:15:04:01:01:01:01:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:f9:02:01:02:fd:0b:00:41:31:37:36:31:5f:33:30:41:68:fe:05:03:c3:50:d6:68:26
10:37:42 INFO: ---------------- Pps / A1761 / 0405 / Header -----------------
ff 09 : 2 Byte Anker Solix message marker (supposed 'ff 09')
6b 01 : 2 Byte total message length (363) in Bytes (Little Endian format)
03 01 0f: 3 Byte fixed message pattern (supposed `03 00/01 0f` for send/receive)
04 05 : 2 Byte message type pattern (varies per device model and message type)
: 1 Byte optional message increment ( 0)
-- Fields --|- Value (Hex/Decode Options)---------------------------------------
Fld Len Typ uIntLe/var sIntLe floatLe dblLe/4int
a1 01 -- 34
└-> 1 unk 52 52
a2 05 03 00:00:00:00
└-> 5 var 0;0 0 0.000 0;0;0;0
a3 05 03 00:00:00:00
└-> 5 var 0;0 0 0.000 0;0;0;0
a4 03 02 4d:01
└-> 3 sile 333 333 77;1
a5 03 02 00:00
└-> 3 sile 0 0 0;0 --> ac_in_?
a6 03 02 00:00
└-> 3 sile 0 0 0;0 --> ac_out_?
a7 03 02 00:00
└-> 3 sile 0 0 0;0 --> usbc_1_out_?
a8 03 02 00:00
└-> 3 sile 0 0 0;0 --> usbc_2_out_?
a9 03 02 00:00
└-> 3 sile 0 0 0;0 --> usba_1_out_?
aa 03 02 00:00
└-> 3 sile 0 0 0;0 --> usba_2_out_?
ab 03 02 00:00
└-> 3 sile 0 0 0;0
ac 03 02 00:00
└-> 3 sile 0 0 0;0
ad 03 02 00:00
└-> 3 sile 0 0 0;0
ae 03 02 0b:00
└-> 3 sile 11 11 11;0 --> dc_in_?
af 03 02 0b:00
└-> 3 sile 11 11 11;0
b0 03 02 00:00
└-> 3 sile 0 0 0;0 --> ac_out_total_?
b1 03 02 00:00
└-> 3 sile 0 0 0;0
b2 03 02 00:00
└-> 3 sile 0 0 0;0
b3 03 02 9f:00
└-> 3 sile 159 159 159;0 --> sw_version_1_?
b4 03 02 00:00
└-> 3 sile 0 0 0;0
b5 03 02 00:00
└-> 3 sile 0 0 0;0
b6 03 02 ff:01
└-> 3 sile 511 511 255;1
b7 03 02 00:00
└-> 3 sile 0 0 0;0
b8 03 02 93:00
└-> 3 sile 147 147 147;0
b9 03 02 72:00
└-> 3 sile 114 114 114;0 --> sw_version_2_?
ba 03 02 9f:00
└-> 3 sile 159 159 159;0
bb 03 02 00:00
└-> 3 sile 0 0 0;0
bc 02 01 01
└-> 2 ui 1 1
bd 02 01 17
└-> 2 ui 23 23 --> temperature_1_?
be 02 01 15
└-> 2 ui 21 21 --> temperature_2_?
bf 02 01 00
└-> 2 ui 0 0
c0 02 01 02
└-> 2 ui 2 2
c1 02 01 61
└-> 2 ui 97 97 --> battery_soc_1_?
c2 02 01 3d
└-> 2 ui 61 61 --> battery_soc_2_?
c3 02 01 61
└-> 2 ui 97 97
c4 02 01 63
└-> 2 ui 99 99
c5 02 01 01
└-> 2 ui 1 1
c6 02 01 00
└-> 2 ui 0 0
c7 02 01 00
└-> 2 ui 0 0
c8 02 01 00
└-> 2 ui 0 0
c9 02 01 00
└-> 2 ui 0 0
ca 02 01 00
└-> 2 ui 0 0
cb 02 01 00
└-> 2 ui 0 0
cc 02 01 00
└-> 2 ui 0 0
cd 02 01 00
└-> 2 ui 0 0
ce 02 01 00
└-> 2 ui 0 0
cf 02 01 00
└-> 2 ui 0 0
d0 11 00 41:50:43:36:4e:58:30:44:33:38:33:30:30:30:32:30
└-> 17 str b'APCXXXXXXXXXX' --> device_sn_?
d1 03 02 2c:01
└-> 3 sile 300 300 44;1 --> ac_load_max_?
d2 03 02 d0:02
└-> 3 sile 720 720 208;2 --> device_sleeptime_?
d3 03 02 1e:00
└-> 3 sile 30 30 30;0
d4 03 02 3c:00
└-> 3 sile 60 60 60;0
d5 03 02 00:00
└-> 3 sile 0 0 0;0
d6 03 02 00:00
└-> 3 sile 0 0 0;0
d7 02 01 00
└-> 2 ui 0 0
d8 02 01 00
└-> 2 ui 0 0
d9 02 01 02
└-> 2 ui 2 2
da 02 01 32
└-> 2 ui 50 50
db 02 01 00
└-> 2 ui 0 0
dc 02 01 00
└-> 2 ui 0 0
dd 02 01 00
└-> 2 ui 0 0
de 02 01 00
└-> 2 ui 0 0
e3 02 01 00
└-> 2 ui 0 0
e5 02 01 00
└-> 2 ui 0 0
f8 15 04 01:01:01:01:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
└-> 21 bin b'\x01\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
f9 02 01 02
└-> 2 ui 2 2
fd 0b 00 41:31:37:36:31:5f:33:30:41:68
└-> 11 str b'A1761_30Ah'
fe 05 03 c3:50:d6:68
└-> 5 var 20675;26838 1758875843 8096609744726705886461952.000 195;80;214;104
-------------------------------------------------------------------------------- |
|
ok thanks.
|
|
good morning, some answers, I hope it help's
# Solarbank C1000(X) + B1000 Extension
"A1761": {
"0405": {
"topic": "param_info",
"a5": {"name": "ac_power_in"},
"a6": {"name": "ac_power_out"},
"a7": {"name": "usbc_1_power"},
"a8": {"name": "usbc_2_power"},
"a9": {"name": "usba_1_power"},
"aa": {"name": "usba_2_power"},
"ae": {"name": "dc_power_in"},
"c1": {"name": "battery_soc"},
"c2": {"name": "exp_1_battery_soc"},
"b0": {"name": "ac_power_out_total"},
"b3": {"name": "sw_version", "values": 1},
"b9": {"name": "sw_exp_1", "values": 1},
"ba": {"name": "sw_controller?", "values": 1},
"bd": {"name": "temperature"},
"be": {"name": "exp_1_temperature"},
"d0": {"name": "device_sn"},
"d1": {"name": "ac_power_out_limit"},
"d2": {"name": "device_sleeptime"},
"fd": {"name": "exp_1_type"},
"fe": {"name": "msg_timestamp"},
},
},
08:44:59 INFO:
Received message on topic: dt/anker_power/A1761/APC6NXXXXXX/param_info
{'head': {'version': '1.0.0.1', 'client_id': 'APC6NXXXXXX', 'sess_id': '5921-4699', 'msg_seq': 1477, 'cmd': 16, 'cmd_status': 1, 'sign_code': 0, 'seed': 'null', 'timestamp': 1759214698}, 'payload': '{
08:44:59 INFO: 2025-44-30 08:44:58 Device hex data:
ff:09:1d:00:03:00:0f:08:30:00:a1:08:76:30:2e:32:2e:33:2e:31:a2:06:76:31:2e:35:2e:39:c1
08:44:59 INFO: ---------------- Pps / A1761 / 0830 / Header -----------------
ff 09 : 2 Byte Anker Solix message marker (supposed 'ff 09')
1d 00 : 2 Byte total message length (29) in Bytes (Little Endian format)
03 00 0f: 3 Byte fixed message pattern (supposed `03 00/01 0f` for send/receive)
08 30 : 2 Byte message type pattern (varies per device model and message type)
00 : 1 Byte optional message increment ( 0)
-- Fields --|- Value (Hex/Decode Options)---------------------------------------
Fld Len Typ uIntLe/var sIntLe floatLe dblLe/4int
a1 08 76 30:2e:32:2e:33:2e:31
...-> 8 unk 13843071212072496 13843071212072496
a2 06 76 31:2e:35:2e:39
...-> 6 unk 245588373041 245588373041
{
"code": 0,
"msg": "success!",
"data": {
"update_infos": [
{
"device_sn": "0S5K1SECD7TJP7JZ",
"need_update": false,
"upgrade_type": 1,
"lastPackage": {
"product_code": "A1761",
"product_component": "A1761_high",
"version": "v1.5.9",
"is_forced": false,
"md5": "ce53b545926bf5ce88e886e5da1b12dc",
"url": "https://public-aiot-fra-prod.s3.dualstack.eu-central-1.amazonaws.com/anker-power/public/ota/2025/07/22/iot-admin/NMvH3hGsgGHRWgg5/A1761_AllPackets_V1.5.9_20250617_HighVoltage.bin",
"size": 417860
},
"change_log": "",
"current_version": "v1.5.9",
"children": [
{
"needUpdate": false,
"device_type": "A1761_mcu_high",
"rom_version_name": "v1.5.9",
"force_upgrade": false,
"full_package": {
"file_path": "https://public-aiot-fra-prod.s3.dualstack.eu-central-1.amazonaws.com/anker-power/public/ota/2025/07/22/iot-admin/NMvH3hGsgGHRWgg5/A1761_AllPackets_V1.5.9_20250617_HighVoltage.bi
"file_size": 417860,
"file_md5": "ce53b545926bf5ce88e886e5da1b12dc"
},
"change_log": "",
"sub_current_version": "",
"upgrade_level": 0
},
{
"needUpdate": false,
"device_type": "A1761_30Ah",
"rom_version_name": "v1.1.4",
"force_upgrade": false,
"full_package": {
"file_path": "https://public-aiot-fra-prod.s3.dualstack.eu-central-1.amazonaws.com/anker-power/public/ota/2025/07/22/iot-admin/uFoYXrDnhUhTtXLN/A1761_AllPackets_V1.1.4_20250617_LowVoltage.bin
"file_size": 417860,
"file_md5": "bc0bc44fc69b3cbdb085caa158214a0e"
}, |
|
Thanks. I updated the mapping accordingly in main branch. There is also a new version for the decoder to work with 0830 type messages. model:A1761, header:{prefix:ff09, msglength:29, pattern:03000f, msgtype:0830, increment:00}, hexbytes:ff091d0003000f083000a10876302e322e332e31a20676312e352e39c1
---------------- Pps / A1761 / 0830 / Header -----------------
ff 09 : 2 Byte Anker Solix message marker (supposed 'ff 09')
1d 00 : 2 Byte total message length (29) in Bytes (Little Endian format)
03 00 0f: 3 Byte fixed message pattern (supposed `03 00/01 0f` for send/receive)
08 30 : 2 Byte message type pattern (varies per device model and message type)
00 : 1 Byte optional message increment ( 0)
-- Fields --|- Value (Hex/Decode Options)---------------------------------------
Fld Len Typ uIntLe/var sIntLe floatLe dblLe/4int
a1 08 -- 76:30:2e:32:2e:33:2e:31
└-> 8 unk b'v0.2.3.1' --> sw_unknown_2?
a2 06 -- 76:31:2e:35:2e:39
└-> 6 unk b'v1.5.9' --> sw_version
--------------------------------------------------------------------------------
{
"sw_unknown_2?": "v0.2.3.1",
"sw_version": "v1.5.9"
}Now, your responses show some interesting behavior:
That means to provide an MQTT monitoring capability for such devices, the RT trigger would have to be refreshed permanently. However, that is nothing I would ever do automatically in an HA integration. So a possible implementation could use a RT Trigger Button, which users could use either manually for device data for 5 minutes, or trigger it with an automation according their needs. Triggering it when the device is in standby probably does not make much sense, and the App may not do that either (depending on the device type and status). Further questions to complete the mapping for your device:
|
|
Hi, some news for the interval, the realtime interval ist ca 2-5 Seconds, the msg_timestamp ist every second ??? realtime interval msg_timestamp
11:14:05 INFO: |
Interesting, so you also get json payload from mqtt server, not only hex data? So does that mean you also receive regular messages where payload contains only json fields without data field? This is currently not considered in the framework, but could. All payload fields could be extracted as is from such a payload, which would be similar to Api responses. Only if a data field is contained, the decoding would be required. But that could cause quite a mix between payload field names and decoded field names... |
|
Hi, I atached a dumpfile, so you can discover it (for json, payload and all the other miracle) |
|
Hi, the dump file has only payload with data fields. But I also had one device with Solarbank 2 AC, which publishes normal payload including a sw version, battery always 100 and some network related fields. BTW, I also found that the temp value is always Celcius. If you switch the App to Fahrenheit, it shows just a different bit somewhere, indicating Fahrenheit is enabled. Based on this, I guess it is just the App that converts the celcius value to Fahrenheit. Examples for how this may have to be described depending on the field type where it shows up: "ba": {
"bytes": {
"00": [
{"name": "light_mode", "mask": 0x40},
{"name": "light_off", "mask": 0x20},
{"name": "ac_socket_enabled", "mask": 0x08},
{"name": "temp_unit_fahrenheit", "mask": 0x01},
],
}
},
# or
"a9": {"name": "temp_unit_fahrenheit"},
"aa": {"name": "temperature"}, |
|
Hi, some news |
|
Great. I changed the names for consistency with other devices names already. "bb": {"name": "switch_output_power"}, # value 0 or 1
"d8": {"name": "switch_dc_input_power"}, # car 12 V input value 0 or 1
"dc": {"name": "switch_sos_mode"}, # sos blinking value 0 or 4
"dd": {"name": "temp_unit_fahrenheit"}, # switch between C of F value 0 of 1For the sos blinking...could we name that also generally 'light_mode'? Light mode settings are also used on other devices and there may be more than 2 values to change how device lights should behave..... |
|
Servus, "dc": {"name": "light_mode"}, # value 0: off missunderstanding from mysite, |
|
OK, so updated mapping as following: "bb": {"name": "switch_output_power"}, # Disabled (0) or enabled (1)
"d8": {"name": "switch_12v_dc_output_power"}, # Car 12 V output disabled (0) or enabled (1)
"dc": {"name": "light_mode"}, # Off (0), low (1), medium (2), high (3), blinking (4)
"dd": {"name": "temp_unit_fahrenheit"}, # Toggle °C (0) or F (1) unit, this does not change temperature value itself |
|
I think I have to update the export tool as well to include MQTT file dumps as option. This would have to run for 5 minutes with an initial real time trigger for owned devices. Within 5 minutes, most message types are hopefully received, so the last one of each type can be kept in an export file. This however cannot be anonymized, but at the end it will be required for testing the decoding of mapping descriptions initially, but also later for testing HA integration with such standalone device MQTT data. |
|
good evening, smart_mode_12V_out and smart_mode_ac_out off smart_mode_12V_out on smart_mode_ac_out on "e5": {"name": "ultrafast_load"}, # values: 0 | 1
"d9": {"name": "display_lightness"}, # values: low:1 middle:2 high:3
"d3": {"name": "display_timeout_seconds"}, # values: 20, 30, 60, 300, 1800
"de": {"name": "display"}, # values: 0 | 1 (off/on) |
|
Ok, some questions
|
|
Here is an actual decoding and extracted value example with one of your hex strings and latest descriptions. I assume c3 and c4 could be state of health percentage, which is not externalized?: ------------------------- Pps / A1761 / 0405 / Header --------------------------
ff 09 : 2 Byte Anker Solix message marker (supposed 'ff 09')
6b 01 : 2 Byte total message length (363) in Bytes (Little Endian format)
03 01 0f: 3 Byte fixed message pattern (supposed `03 00/01 0f` for send/receive)
04 05 : 2 Byte message type pattern (varies per device model and message type)
: 1 Byte optional message increment ( 0)
-- Fields --|- Value (Hex/Decode Options)---------------------------------------
Fld Len Typ uIntLe/var sIntLe floatLe dblLe/4int
a1 01 -- 34
└-> 1 unk b'4'
a2 05 03 00:00:00:00
└-> 5 var 0;0 0 0.000 0;0;0;0
a3 05 03 00:00:00:00
└-> 5 var 0;0 0 0.000 0;0;0;0
a4 03 02 b9:00
└-> 3 sile 185 185 185;0
a5 03 02 00:00
└-> 3 sile 0 0 0;0 --> grid_to_battery_power
a6 03 02 48:00
└-> 3 sile 72 72 72;0 --> ac_output_power
a7 03 02 00:00
└-> 3 sile 0 0 0;0 --> usbc_1_power
a8 03 02 00:00
└-> 3 sile 0 0 0;0 --> usbc_2_power
a9 03 02 00:00
└-> 3 sile 0 0 0;0 --> usba_1_power
aa 03 02 00:00
└-> 3 sile 0 0 0;0 --> usba_2_power
ab 03 02 00:00
└-> 3 sile 0 0 0;0
ac 03 02 00:00
└-> 3 sile 0 0 0;0
ad 03 02 00:00
└-> 3 sile 0 0 0;0
ae 03 02 10:00
└-> 3 sile 16 16 16;0 --> dc_input_power
af 03 02 10:00
└-> 3 sile 16 16 16;0
b0 03 02 48:00
└-> 3 sile 72 72 72;0 --> ac_output_power_total
b1 03 02 00:00
└-> 3 sile 0 0 0;0
b2 03 02 00:00
└-> 3 sile 0 0 0;0
b3 03 02 9f:00
└-> 3 sile 159 159 159;0 --> sw_version
b4 03 02 00:00
└-> 3 sile 0 0 0;0
b5 03 02 ff:01
└-> 3 sile 511 511 255;1
b6 03 02 ff:01
└-> 3 sile 511 511 255;1
b7 03 02 00:00
└-> 3 sile 0 0 0;0
b8 03 02 93:00
└-> 3 sile 147 147 147;0
b9 03 02 72:00
└-> 3 sile 114 114 114;0 --> sw_expansion
ba 03 02 9f:00
└-> 3 sile 159 159 159;0 --> sw_controller
bb 03 02 01:00
└-> 3 sile 1 1 1;0 --> switch_ac_output_power
bc 02 01 01
└-> 2 ui 1 1
bd 02 01 17
└-> 2 ui 23 23 --> temperature
be 02 01 16
└-> 2 ui 22 22 --> exp_1_temperature
bf 02 01 00
└-> 2 ui 0 0
c0 02 01 01
└-> 2 ui 1 1
c1 02 01 64
└-> 2 ui 100 100 --> battery_soc
c2 02 01 4b
└-> 2 ui 75 75 --> exp_1_soc
c3 02 01 61
└-> 2 ui 97 97 --> battery_soh?
c4 02 01 63
└-> 2 ui 99 99 --> exp_1_soh?
c5 02 01 01
└-> 2 ui 1 1
c6 02 01 00
└-> 2 ui 0 0
c7 02 01 00
└-> 2 ui 0 0
c8 02 01 00
└-> 2 ui 0 0
c9 02 01 00
└-> 2 ui 0 0
ca 02 01 00
└-> 2 ui 0 0
cb 02 01 00
└-> 2 ui 0 0
cc 02 01 00
└-> 2 ui 0 0
cd 02 01 00
└-> 2 ui 0 0
ce 02 01 00
└-> 2 ui 0 0
cf 02 01 00
└-> 2 ui 0 0
d0 11 00 5f:5f:5f:5f:5f:5f:5f:5f:5f:5f:5f:5f:5f:5f:5f:5f
└-> 17 str b'________________' --> device_sn
d1 03 02 2c:01
└-> 3 sile 300 300 44;1 --> max_load
d2 03 02 d0:02
└-> 3 sile 720 720 208;2 --> device_timeout_minutes
d3 03 02 1e:00
└-> 3 sile 30 30 30;0 --> display_timeout_seconds
d4 03 02 3c:00
└-> 3 sile 60 60 60;0
d5 03 02 00:00
└-> 3 sile 0 0 0;0
d6 03 02 00:00
└-> 3 sile 0 0 0;0
d7 02 01 01
└-> 2 ui 1 1
d8 02 01 00
└-> 2 ui 0 0 --> switch_12v_dc_output_power
d9 02 01 02
└-> 2 ui 2 2 --> display_mode
da 02 01 32
└-> 2 ui 50 50
db 02 01 00
└-> 2 ui 0 0
dc 02 01 00
└-> 2 ui 0 0 --> light_mode
dd 02 01 00
└-> 2 ui 0 0 --> temp_unit_fahrenheit
de 02 01 00
└-> 2 ui 0 0 --> switch_display
e3 02 01 00
└-> 2 ui 0 0
e5 02 01 00
└-> 2 ui 0 0 --> backup_charge
f8 15 04 01:01:01:01:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
└-> 21 bin b'\x01\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' --> {'00': {'name': '12v_dc_output_mode', 'type': b'\x01'}, '01': {'name': 'ac_output_mode', 'type': b'\x01'}}
f9 02 01 02
└-> 2 ui 2 2
fd 0b 00 41:31:37:36:31:5f:33:30:41:68
└-> 11 str b'A1761_30Ah' --> exp_1_type
fe 05 03 c1:64:de:68
└-> 5 var 25793;26846 1759405249 8401791525760652101550080.000 193;100;222;104 --> msg_timestamp (2025-10-02 11:40:49)
--------------------------------------------------------------------------------
{
"grid_to_battery_power": 0,
"ac_output_power": 72,
"usbc_1_power": 0,
"usbc_2_power": 0,
"usba_1_power": 0,
"usba_2_power": 0,
"dc_input_power": 16,
"battery_soc": 100,
"exp_1_soc": 75,
"battery_soh?": 97,
"exp_1_soh?": 99,
"ac_output_power_total": 72,
"sw_version": "1.5.9",
"sw_expansion": "1.1.4",
"sw_controller": "1.5.9",
"switch_ac_output_power": 1,
"temperature": 23,
"exp_1_temperature": 22,
"device_sn": "________________",
"max_load": 300,
"device_timeout_minutes": 720,
"display_timeout_seconds": 30,
"switch_12v_dc_output_power": 0,
"display_mode": 2,
"light_mode": 0,
"switch_display": 0,
"temp_unit_fahrenheit": 0,
"backup_charge": 0,
"12v_dc_output_mode": 1,
"ac_output_mode": 1,
"exp_1_type": "A1761_30Ah",
"msg_timestamp": 1759405249
} |
|
Hi, I try to answer
|
|
Hi
So if Ultrafast is on, will it directly start charging as fast as possible, or just increase the charging power limit, whenever you enable Charge or connect AC input?
I cannot tell you, because I did not manage it. The App does not run on most of the Android emulators (maybe because no BT emulation) and the App is based on flutter framework which may also recognize TLS certificate pinning, which makes it difficult to decrypt the TLS traffic with root certificates. |
|
Hi, yes, if the ultrafast switch turned on, the charging begins immediatly with 1300 W |
|
jumping on the thread, I'm trying to fetch my c1000 data without any success, e.g. a regular execution of the mqtt_monitor doesnt show anything: I've noticed my device uses the anker EU mqtt server, but I'm not seeing any traffic generated by the mqtt browser, makes me wonder if this is a account/region issue ? or is the c1000 not listed as a device, so we cant continue the process, in that case, any pointers on how to move forward will be appreciated :) |
|
Hi |
|
thanks! added #234 |
|
I've created a PR to include support for C1000X at #235 @fumee-neti and @khfiebig would be great if you could test it |
|
Thanks for your PR, I merged it with my recent changes and also refactured some of the code to avoid Ruff and Linting warnings on my end. |
|
The system export module can now export 5 minutes of MQTT data, that should mostly be randomized. It will be useful to provide such an export together with possible descriptions of the decoded fields for your devices. With the Api and MQTT export, at least some base description mapping could be implemented for various Solix devices. |
|
God morning, it seems, there is a small problem, can you help, the git clone is from today anker-solix-api $ pythpon3 ./monitor.py
-bash: pythpon3: command not found
anker-solix-api $ python3 ./monitor.py
Traceback (most recent call last):
File "/home/khfiebig/20251011/anker-solix-api/./monitor.py", line 20, in <module>
from api.api import AnkerSolixApi # pylint: disable=no-name-in-module
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/khfiebig/20251011/anker-solix-api/api/api.py", line 50, in <module>
class AnkerSolixApi(AnkerSolixBaseApi):
File "/home/khfiebig/20251011/anker-solix-api/api/api.py", line 54, in AnkerSolixApi
from .energy import ( # pylint: disable=import-outside-toplevel # noqa: PLC0415
File "/home/khfiebig/20251011/anker-solix-api/api/energy.py", line 20, in <module>
self: AnkerSolixApi,
^^^^^^^^^^^^^
NameError: name 'AnkerSolixApi' is not defined
anker-solix-api $ python3 ./export_system.py
Traceback (most recent call last):
File "/home/khfiebig/20251011/anker-solix-api/./export_system.py", line 26, in <module>
from api.api import AnkerSolixApi # pylint: disable=no-name-in-module
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/khfiebig/20251011/anker-solix-api/api/api.py", line 50, in <module>
class AnkerSolixApi(AnkerSolixBaseApi):
File "/home/khfiebig/20251011/anker-solix-api/api/api.py", line 54, in AnkerSolixApi
from .energy import ( # pylint: disable=import-outside-toplevel # noqa: PLC0415
File "/home/khfiebig/20251011/anker-solix-api/api/energy.py", line 20, in <module>
self: AnkerSolixApi,
^^^^^^^^^^^^^
NameError: name 'AnkerSolixApi' is not defined
anker-solix-api $ python3 ./example_c1000x_mqtt_integration.py
Traceback (most recent call last):
File "/home/khfiebig/20251011/anker-solix-api/./example_c1000x_mqtt_integration.py", line 8, in <module>
from api import api # pylint: disable=no-name-in-module
^^^^^^^^^^^^^^^^^^^
File "/home/khfiebig/20251011/anker-solix-api/api/api.py", line 50, in <module>
class AnkerSolixApi(AnkerSolixBaseApi):
File "/home/khfiebig/20251011/anker-solix-api/api/api.py", line 54, in AnkerSolixApi
from .energy import ( # pylint: disable=import-outside-toplevel # noqa: PLC0415
File "/home/khfiebig/20251011/anker-solix-api/api/energy.py", line 20, in <module>
self: AnkerSolixApi,
^^^^^^^^^^^^^
NameError: name 'AnkerSolixApi' is not defined
anker-solix-api $ python3 ./mqtt_monitor.py
Traceback (most recent call last):
File "/home/khfiebig/20251011/anker-solix-api/./mqtt_monitor.py", line 24, in <module>
from api.api import AnkerSolixApi # pylint: disable=no-name-in-module
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/khfiebig/20251011/anker-solix-api/api/api.py", line 50, in <module>
class AnkerSolixApi(AnkerSolixBaseApi):
File "/home/khfiebig/20251011/anker-solix-api/api/api.py", line 54, in AnkerSolixApi
from .energy import ( # pylint: disable=import-outside-toplevel # noqa: PLC0415
File "/home/khfiebig/20251011/anker-solix-api/api/energy.py", line 20, in <module>
self: AnkerSolixApi,
^^^^^^^^^^^^^
NameError: name 'AnkerSolixApi' is not defined |
|
this seems to broke at bc76e1e |
|
I've created #237, which hopefully resolves this |
|
Thanks. I found a different solution to prevent the error and uploaded the new version. |
|
To avoid that there will be more and more methods that have to be imported into the AnkerSolixApi class, we definitely should restructure the control methods for MQTT. If there are more devices following, each may need its own controls, so it will be better to have a separate class for each. Devices from a family can maybe be combined with the same class. |
|
Hi all @ohadlevy Please verify all your test modules again if they still run, eventually I broke them but cannot verify. I would also be happy to get a system export from anyone including the MQTT messages for the C1000X in order to have a base to develop and test file based poller mode for that device. |
|
@ohadlevy, I did more class restructuring:
Please verify all your test modules with this latest change if they still run, eventually I broke them but cannot verify. |
|
thanks @thomluther, added #239 for a few fixes and rebase on your recent work. |
|
OK Folks, I have now included proper MQTT message export as option to system export tool. It will dump messages in grouped files including message timestamp and topic. Actually I need a system_export from one of you that includes the MQTT message dump, so I can simulate and enhance the monitor for MQTT devices in general. The monitor and its debug capabilities is the foundational tool, in order to resolve data and library issues before those finalized changes can be picked up by the HA integration. Although the monitor tool has no capabilities to test/mock setting changes, it allows to validate the data base and proper export. The HA integration can then be enhanced and used to validate mock setting changes against the dumped folders, including behavior validation with simulated MQTT messages arriving at runtime... Edit: I also added the Fahrenheit conversion to the monitor tool. Since the value in the mqtt is always °C, it is up to the 'display tool' to convert this value based on the Fahrenheit unit setting (if that is available/described) for the device data. |
|
Hi, I hope, the dump is useful for you |
|
Hm, it does not contain the C1000 mqtt messages. This seems to be caused by the fact that standalone devices are not flagged as admin device. I need to debug the reason with your export and let you know once an update is available. |
|
Hi @khfiebig , I uploaded a fix, good that the admin flagging was found now :-) BTW: In the export tool, you can hit enter for type of export and use the defaults. If you enforce all api types it will just cause errors on unused system type queries, but mqtt option still has to be allowed on top (not included in all api types). If you specify api type mqtt only allows to export only the mqtt messages without all the api queries. At the end however, since your system has solarbank and C1000, I would need the default Api types plus MQTT data additionally. This allows to bring the MQTT data into system context. I will make the MQTT data export also a new option for the HA system export with the next release. |
|
Hi, ok, I download the last git version and create a dump with mqtt_only flag, hope thats ok, |
|
I uploaded the latest version of the mapping and monitor. The monitor now also support realtime and file mode for C1000x devices.
MQTT values may be mixed in and overlay Api data upon message related updates, otherwise normal Api refresh cycle will only show Api data (without MQTT overlay) or MQTT data that are only provided via MQTT interface. I also added following calculated values to device MQTT cache if data is available. This is only available for SB1 currently :
I also try to calculate the overall soc and remaining battery energy. I had to change the whole algorithm for considering optional MQTT data that may have to trigger an update on the battery capacity calculations. I hope this change did not break anything in the existing behavior, including the customization of battery capacity.... This change made me wonder, whether there are C1000 values that correspond to following:
|
|
Can someone confirm if A4 is 'remaining_hours' with factor 0.1 as it is for other devices? |
|
Hi @ohadlevy elif command == "c1000x_backup_charge":
# Backup charge mode: field e5 (PARTIALLY VALIDATED ⚠️ - field-based protocol)
value = 1 if parameters.get("enabled", False) else 0
hexdata = DeviceHexData(
model="A1761", msg_header=DeviceHexDataHeader(cmd_msg="0057")
)
hexdata.update_field(DeviceHexDataField(hexbytes="a10122"))
hexdata.update_field(
DeviceHexDataField(
f_name=bytes.fromhex("e5"),
f_type=DeviceHexDataTypes.ui.value,
f_value=value.to_bytes(length=1, byteorder="little"),
)
) |
|
… On Mon, Nov 10, 2025 at 6:59 PM Thomas Luther ***@***.***> wrote:
Hi @ohadlevy <https://github.com/ohadlevy>
Can you please validate following command, I think the message 0057 as
well as the field name e5 is wrong:
elif command == "c1000x_backup_charge":
# Backup charge mode: field e5 (PARTIALLY VALIDATED
|
|
@ohadlevy I think the Max Load command that you deleted should work if correct parameters and hex message is applied, or did you delete it because it does not work? Since your code used incorrect byte order for the multi byte values, that may be the reason for it not working!! A general thing I noticed is that the Anker message length in the msg header is +1 compared to the total bytes of the message. Not sure if that is on purpose, but it does not really seem to matter for the command messages that are being generated...I don't want to increase that value in the header since it is used for other routines and may break something. As long as it does not matter for the MQTT server, I will add the correct number of bytes into message headers. |
|
@ohadlevy "0076": CMD_DC_12V_OUTPUT_MODE, # Normal (1), Smart (0)
"0077": CMD_AC_OUTPUT_MODE, # Normal (1), Smart (0)
"f8": {
"bytes": {
"00": {
"name": "dc_12v_output_mode", # Normal (1), Smart (2) - auto-off below 3W
"type": DeviceHexDataTypes.ui.value,
},
"01": {
"name": "ac_output_mode", # Normal (1), Smart (2) - auto-off when not charging and low power
"type": DeviceHexDataTypes.ui.value,
},
}
},This is weird, can you confirm? |
|
… On Wed, Nov 12, 2025 at 3:55 PM Thomas Luther ***@***.***> wrote:
@ohadlevy <https://github.com/ohadlevy>
Another weird thing I noticed. The AD/DC output modes controls [0,1] do
not correspond to their state values [1,2].
"0076": CMD_DC_12V_OUTPUT_MODE, # Normal (1), Smart (0)
"0077": CMD_AC_OUTPUT_MODE, # Normal (1), Smart (0)
"f8": {
"bytes": {
"00": {
"name": "dc_12v_output_mode", # Normal (1), Smart (2) - auto-off below 3W
"type": DeviceHexDataTypes.ui.value,
},
"01": {
"name": "ac_output_mode", # Normal (1), Smart (2) - auto-off when not charging and low power
"type": DeviceHexDataTypes.ui.value,
},
}
},
This is weird, can you confirm?
Not sure how I should cover that properly for HA and whether the values
are the same for other devices supporting the smart modes for output
controls.
Eventually different options have to be defined for the control
(string/value) and for the state (string/value) in order to map the names
for correct values...
—
Reply to this email directly, view it on GitHub
<#221 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAE5RZN4YNC3543FEI7D5L34M35DAVCNFSM6AAAAACGBLHBJOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOJUHAYDENQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
|
This is to track the missing parts for C1000 in the MQTTMAP descriptions:
"c0": {"name": "expansion_packs_a?"},
"c5": {"name": "expansion_packs_b?"},
"d7": {"name": "expansion_packs_c?"},Output seen in a recent log with expansion installed, however I'm not sure where the first entry comes from, since that is not in the actual mqttmap description: |
|
tried to address it in #248 |
|
Thanks for the update on the MQTT mapping @ohadlevy |
|
I implemented a work around for the mqtt device cache regarding the expansion packs, since that is needed to calculate the overall battery capacity and remaining energy. |
|
Is it possible they've updated mappings to be similar to the c2000 and allowing power in/out entities? 
###This is only a C1000X (1st gen- hw_version 0.2.3.1, wifi blocks excluded from image) i notice the output_power_total and ac_output_power in my capture is accurate - but i only have capacity as a value/entity in HA for both my C1000's- Edit: most likely doesnt warrant a reply as it's likely just the pps vs home system difference. |
To get PPS values in HA, you need to enable the MQTT connection and eventually also push the RT trigger and/or Status request buttons, or open the App in parallel which does the same. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hello, thank you very much for your work here with the API.
It would be nice if the manufacturer also released this officially :)
I have one question: I have an A1761, SOLIX C1000(X), which is also displayed to me, but I only get these values — not AC output, solar input, or similar data.
How can I best access these values?
If you need more data, I’d be happy to provide it.
All reactions