MQTT data for A1790, SOLIX F3800 #241
Replies: 26 comments 45 replies
0410Uncertain what a 'param_info' message is, but this is the first result from the monitor Received message on topic: dt/anker_power/A1790/AZxxxxxxxxxxxx41/param_info
{'head': {'version': '1.0.0.1', 'client_id': 'AZxxxxxxxxxxxx41', 'sess_id': '6131-7549', 'msg_seq': 15165, 'cmd': 16, 'cmd_status': 1, 'sign_code': 0, 'seed': 'null', 'timestamp': 1761317549}, 'payload': '{"data":"/wl3AAMBDwQQoQE0ohkEQVpWRzhQMEU0ODUwMDI3Mh4AAW8AnQAAoxoEQVpWNzQ0MEQ1MjIwMDA0MfAAATIRAAAAAKQaBEFaVjc0NDBENDc2MDAwNTTwAAE0EAAAAAGlBgBBMTc5MKYGAEExNzkw/gUDuVD6aMI=","sn":"AZxxxxxxxxxxxx41","pn":"A1790"}'}
07:52:29 INFO: 2025-10-24 07:52:29 Device hex data:
ff:09:77:00:03:01:0f:04:10:a1:01:34:a2:19:04:41:5a:56:47:38:50:30:45:34:38:35:30:30:32:37:32:1e:00:01:6f:00:9d:00:00:a3:1a:04:41:5a:56:37:34:34:30:44:35:32:32:30:30:30:34:31:f0:00:01:32:11:00:00:00:00:a4:1a:04:41:5a:56:37:34:34:30:44:34:37:36:30:30:30:35:34:f0:00:01:34:10:00:00:00:01:a5:06:00:41:31:37:39:30:a6:06:00:41:31:37:39:30:fe:05:03:b9:50:fa:68:c2
07:52:29 INFO: ------------------------- Pps / A1790 / 0410 / Header --------------------------
ff 09 : 2 Byte Anker Solix message marker (supposed 'ff 09')
77 00 : 2 Byte total message length (119) in Bytes (Little Endian format)
03 01 0f: 3 Byte fixed message pattern (supposed `03 00/01 0f` for send/receive)
04 10 : 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 19 04 41:5a:56:47:38:50:30:45:34:38:35:30:30:32:37:32:1e:00:01:6f:00:9d:00:00
└-> 25 bin b'AZVG8P0E48500272\x1e\x00\x01o\x00\x9d\x00\x00'
a3 1a 04 41:5a:56:37:34:34:30:44:35:32:32:30:30:30:34:31:f0:00:01:32:11:00:00:00:00
└-> 26 bin b'AZxxxxxxxxxxxx41\xf0\x00\x012\x11\x00\x00\x00\x00'
a4 1a 04 41:5a:56:37:34:34:30:44:34:37:36:30:30:30:35:34:f0:00:01:34:10:00:00:00:01
└-> 26 bin b'AZV7440D47600054\xf0\x00\x014\x10\x00\x00\x00\x01'
a5 06 00 41:31:37:39:30
└-> 6 str b'A1790'
a6 06 00 41:31:37:39:30
└-> 6 str b'A1790'
fe 05 03 b9:50:fa:68
└-> 5 var 20665;26874 1761235129 9456645527185640673771520.000 185;80;250;104 |
|
If you start to describe all messages and fields in your version of mqttmap.py, you can see the description in the output as well. |
|
Dual Power Hub is a cable bridging the 2 F3800s. |
|
That is an accessory and probably has a device_sn as well. But it should be listed as accessory for both devices. |
|
For bin type fields you need to describe the start byte and length for the extracted value including its base type. There are examples for bin field descriprionin in existing map. |
|
From monitor.py Device [A1790] : SOLIX F3800 Alias : SOLIX F3800 A
Serialnumber : AZxxxxxxxxxxxx41 Admin : YES
Wireless Type : Bluetooth MAC : E8xxxxxxxxx6
Wifi SSID : Hxxxxxxxs Wifi MAC : E8xxxxxxxxx5
Wifi State : Online Signal : 100 % (-50 dBm)
SW Version : v2.4.0 (Latest) Auto-Upgrade : Enabled (OTA v2.4.0)
-Component : A1790_15Ah (Latest) -Version : v4.7.9
-Component : A1790_A17B2 (Latest) -Version : v0.3.0
-Component : A1790_esp32_low (Latest) -Version : v0.2.3.1
-Component : A1790_mcu_low (Latest) -Version : v2.4.0
Battery Energy : ---- Wh Capacity : 3840 Wh
Device [A1790] : SOLIX F3800 Alias : SOLIX F3800 B
Serialnumber : AZxxxxxxxxxxxx54 Admin : YES
Wireless Type : Bluetooth MAC : E8xxxxxxxxx4
Wifi SSID : Hxxxxxxxs Wifi MAC : E8xxxxxxxxx3
Wifi State : Online Signal : 86 % (-55 dBm)
SW Version : v2.4.0 (Latest) Auto-Upgrade : Enabled (OTA v2.4.0)
-Component : A1790_15Ah (Latest) -Version : v4.7.9
-Component : A1790_A17B2 (Latest) -Version : v0.3.0
-Component : A1790_esp32_low (Latest) -Version : v0.2.3.1
-Component : A1790_mcu_low (Latest) -Version : v2.4.0
Battery Energy : ---- Wh Capacity : 3840 Whredundant image for readability: |
|
from mqtt_monitor.py I took a screenshot of the app just as the mqtt message came through I am most interested in determining battery level. Received message on topic: dt/anker_power/A1790/AZxxxxxxxxxxxxx4/param_info
{'head': {'version': '1.0.0.1', 'client_id': 'AZxxxxxxxxxxxxx4', 'sess_id': '6136-3582', 'msg_seq': 25838, 'cmd': 16, 'cmd_status': 1, 'sign_code': 0, 'seed': 'null', 'timestamp': 1761363532}, 'payload': '{"data":"/wl4AQMBDwQFoQE0ogUDAAAAAKMFAwAAAACkAwIVAaUDAgAApgMCPgCnAwIAAKgDAgAAqQMCAACqAwIAAKsDAgAArAMCAACtAwJWAK4DAgAArwMCAACwAwIAALEDAgAAsgMCPgCzAwIAALQDAkAAtQMC8AC2AwIAALcDAowAuAMCbwC5AwIAALoDAt8BuwMC8AC8AwIAAL0CAQC+AgEcvwIBAcACAVbBAgFkwgIBAMMCAQDEAgEAxQIBAMYCAQDHAgEAyAIBAMkCAQDKAgEAywIBAMwRAEFaVjc0NDBENDc2MDAwNTTNAwKQAc4DAgAAzwMCPADQAwI8ANEDAgAA0gMCAADTAgEA1AIBANUCAQLWAgE81wIBANgCAQHZAgEA2gIBA9sCARTcAgEA3QIEAOQCAQD+BQNJRvxo3gIBAPYDAlVT9wUDAQAAAPgVBAIAAQEAAQEAAAAAAAAAAAAAAAAA+QIBAfoCAQr9CwBBMTc5MF8xNUFo0A==","sn":"AZxxxxxxxxxxxxx4","pn":"A1790"}'}
2025-10-24 20:38:52 Device hex data:
ff:09:78: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:15:01:a5:03:02:00:00:a6:03:02:3e: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:56:00:ae:03:02:00:00:af:03:02:00:00:b0:03:02:00:00:b1:03:02:00:00:b2:03:02:3e:00:b3:03:02:00:00:b4:03:02:40:00:b5:03:02:f0:00:b6:03:02:00:00:b7:03:02:8c:00:b8:03:02:6f:00:b9:03:02:00:00:ba:03:02:df:01:bb:03:02:f0:00:bc:03:02:00:00:bd:02:01:00:be:02:01:1c:bf:02:01:01:c0:02:01:56:c1:02:01:64:c2:02:01:00:c3:02:01:00:c4:02:01:00:c5:02:01:00: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:11:00:41:5a:56:37:34:34:30:44:34:37:36:30:30:30:35:34:cd:03:02:90:01:ce:03:02:00:00:cf:03:02:3c:00:d0:03:02:3c:00:d1:03:02:00:00:d2:03:02:00:00:d3:02:01:00:d4:02:01:00:d5:02:01:02:d6:02:01:3c:d7:02:01:00:d8:02:01:01:d9:02:01:00:da:02:01:03:db:02:01:14:dc:02:01:00:dd:02:04:00:e4:02:01:00:fe:05:03:49:46:fc:68:de:02:01:00:f6:03:02:55:53:f7:05:03:01:00:00:00:f8:15:04:02:00:01:01:00:01:01:00:00:00:00:00:00:00:00:00:00:00:00:00:f9:02:01:01:fa:02:01:0a:fd:0b:00:41:31:37:39:30:5f:31:35:41:68:d0
------------------------- Pps / A1790 / 0405 / Header --------------------------
ff 09 : 2 Byte Anker Solix message marker (supposed 'ff 09')
78 01 : 2 Byte total message length (376) 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 15:01
└-> 3 sile 277 277 21;1
a5 03 02 00:00
└-> 3 sile 0 0 0;0
a6 03 02 3e:00
└-> 3 sile 62 62 62;0
a7 03 02 00:00
└-> 3 sile 0 0 0;0
a8 03 02 00:00
└-> 3 sile 0 0 0;0
a9 03 02 00:00
└-> 3 sile 0 0 0;0
aa 03 02 00:00
└-> 3 sile 0 0 0;0
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 56:00
└-> 3 sile 86 86 86;0 Tempurature (deg F)?
ae 03 02 00:00
└-> 3 sile 0 0 0;0
af 03 02 00:00
└-> 3 sile 0 0 0;0
b0 03 02 00:00
└-> 3 sile 0 0 0;0
b1 03 02 00:00
└-> 3 sile 0 0 0;0
b2 03 02 3e:00
└-> 3 sile 62 62 62;0 A/C Output (W)?
b3 03 02 00:00
└-> 3 sile 0 0 0;0
b4 03 02 40:00
└-> 3 sile 64 64 64;0
b5 03 02 f0:00
└-> 3 sile 240 240 240;0
b6 03 02 00:00
└-> 3 sile 0 0 0;0
b7 03 02 8c:00
└-> 3 sile 140 140 140;0
b8 03 02 6f:00
└-> 3 sile 111 111 111;0
b9 03 02 00:00
└-> 3 sile 0 0 0;0
ba 03 02 df:01
└-> 3 sile 479 479 223;1
bb 03 02 f0:00
└-> 3 sile 240 240 240;0
bc 03 02 00:00
└-> 3 sile 0 0 0;0
bd 02 01 00
└-> 2 ui 0 0
be 02 01 1c
└-> 2 ui 28 28
bf 02 01 01
└-> 2 ui 1 1
c0 02 01 56
└-> 2 ui 86 86
c1 02 01 64
└-> 2 ui 100 100
c2 02 01 00
└-> 2 ui 0 0
c3 02 01 00
└-> 2 ui 0 0
c4 02 01 00
└-> 2 ui 0 0
c5 02 01 00
└-> 2 ui 0 0
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 11 00 41:5a:56:37:34:34:30:44:34:37:36:30:30:30:35:34
└-> 17 str b'AZxxxxxxxxxxxxx4'
cd 03 02 90:01
└-> 3 sile 400 400 144;1
ce 03 02 00:00
└-> 3 sile 0 0 0;0
cf 03 02 3c:00
└-> 3 sile 60 60 60;0
d0 03 02 3c:00
└-> 3 sile 60 60 60;0
d1 03 02 00:00
└-> 3 sile 0 0 0;0
d2 03 02 00:00
└-> 3 sile 0 0 0;0
d3 02 01 00
└-> 2 ui 0 0
d4 02 01 00
└-> 2 ui 0 0
d5 02 01 02
└-> 2 ui 2 2
d6 02 01 3c
└-> 2 ui 60 60
d7 02 01 00
└-> 2 ui 0 0
d8 02 01 01
└-> 2 ui 1 1
d9 02 01 00
└-> 2 ui 0 0
da 02 01 03
└-> 2 ui 3 3
db 02 01 14
└-> 2 ui 20 20
dc 02 01 00
└-> 2 ui 0 0
dd 02 04 00
└-> 2 bin b'\x00'
e4 02 01 00
└-> 2 ui 0 0
fe 05 03 49:46:fc:68
└-> 5 var 17993;26876 1761363529 9530663087781400249630720.000 73;70;252;104
de 02 01 00
└-> 2 ui 0 0
f6 03 02 55:53
└-> 3 sile 21333 21333 85;83
f7 05 03 01:00:00:00
└-> 5 var 1;0 1 0.000 1;0;0;0
f8 15 04 02:00:01:01:00:01:01:00:00:00:00:00:00:00:00:00:00:00:00:00
└-> 21 bin b'\x02\x00\x01\x01\x00\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
f9 02 01 01
└-> 2 ui 1 1
fa 02 01 0a
└-> 2 ui 10 10
fd 0b 00 41:31:37:39:30:5f:31:35:41:68
└-> 11 str b'A1790_15Ah'
|
|
BA and BB could be versions if you compare them with the Api output. |
|
Have a look to C1000 mapping description, all PPS should be somewhat similar despite some unique features. You can probably reuse most of them and just assign correct fields for F3800. Names should be reused or follow existing naming concepts. Use ? at end of name if it still has to be confirmed. |
|
BTW, A4 could be remaining hours with factor 0.1 |
|
ad appears to be your battery %. This also appears to be the same for my A1790P |
Yes, 'ad' may be the App SOC. There may be internal calculated SOC or total Soc if expansion is in use on 'c0' or 'ad'. Its difficult to say without expansion.... |
|
I've had some delays (cloudy days and loss of power) A1790_0405 = {
# F3800 unknown message 405
"topic": "param_info",
"a4": {"name": "remaining_usage_time_?", "factor": 0.1},
"a6": {"name": "total_ac_power_out_?"},
"ad": {"name": "battery_soc_?"},
"ae": {"name": "solar_input_total_power_?"},
"af": {"name": "xt60_frontinput_power_?"},
"b0": {"name": "xt60_rearinput_power_?"},
"b1": {"name": "solar_something_?"},
"b2": {"name": "110ac_power_out_?"},
"be": {"name": "temperature"},
"cd": {"name": "ac_recharging_power"},
"fe": {"name": "msg_timestamp"},
}
A1790_040a = {
# F3800 unknown message 40a
"topic": "param_info",
}
A1790_0410 = {
# F3800 unknown message 410
"topic": "param_info",
}
A1790_0804 = {
# F3800 unknown message 804
"topic": "param_info",
}
A1790_0830 = {
# F3800 Version info
"topic": "param_info",
"a1": {"name": "sw_version?", "values": 4},
"a2": {"name": "fw_version", "values": 4},
} |
|
Potentially some possible tweaks / additions: "A1790P": {
"0057": TRIGGER_0057,
"0405": {
"topic": "param_info",
"a4": {"name": "remaining_usage_time_?", "factor": 0.1},
"a6": {"name": "total_ac_power_out_"},
"ad": {"name": "battery_soc_total"},
"a5": {"name": "ac_power_in?"},
"a7": {"name": "usb_power_out_1"},
"a8": {"name": "usb_power_out_2"},
"a9": {"name": "usb_power_out_3"},
"aa": {"name": "usb_power_out_4?"},
"ab": {"name": "usb_power_out_5?"},
"ae": {"name": "solar_input_total_power_?"},
"af": {"name": "xt60_frontinput_power_?"},
"b0": {"name": "xt60_rearinput_power_?"},
"b1": {"name": "total_power_in?"},
"b2": {"name": "total_power_out_"},
"be": {"name": "temperature"},
"c2": {"name": "usb_status_out_1?"},
"c3": {"name": "usb_status_out_2?"},
"c4": {"name": "usb_status_out_3?"},
"c5": {"name": "usb_status_out_4?"},
"c6": {"name": "usb_status_out_5?"},
"cc": {"name": "device_sn"},
"cd": {"name": "ac_recharging_power"},
"fe": {"name": "msg_timestamp"},
},
}, |
|
@gitTinker, for the naming keep in mind that this should be scalable if other PPS have mor sockets of same type. |
|
In general I think it might be ok to describe only one type for A1790 and A1790P, unless there is a significant shift in fields. Typically newer models may just add fields, that will mot be provided by old models. So descrption of newer model can be reused also for old one. |
|
ac_recharging_power is the setting to control how much power is drawn from the 110v ac when its plugged in (adjustable from 200W to 1800W). Looks like this should change to ac_input_limit (note that the technically the F3800+ has the ability to take 240V ac input which wouldn't utilize this setting... maybe there is another setting for that). We should rename the xt60s as well to pv_1_power and pv_2_power (especially since the F3800+ has a different connector type). Is there an equivalent to remaining_usage_time_ for the other devices? "A1790P": {
"0057": TRIGGER_0057,
"0405": {
"topic": "param_info",
"a4": {"name": "remaining_usage_time", "factor": 0.1},
"a6": {"name": "ac_output_power"},
"ad": {"name": "battery_soc_total"},
"a5": {"name": "ac_power_in?"},
"a7": {"name": "usbc_1_power"},
"a8": {"name": "usbc_2_power"},
"a9": {"name": "usbc_3_power"},
"aa": {"name": "usba_1_power?"},
"ab": {"name": "usba_2_power?"},
"ae": {"name": "photovoltaic_power"},
"af": {"name": "pv_1_power"},
"b0": {"name": "pv_2_power"},
"b1": {"name": "charging_power"},
"b2": {"name": "output_power"},
"be": {"name": "temperature"},
"c2": {"name": "usbc_1_status?"},
"c3": {"name": "usbc_2_status?"},
"c4": {"name": "usbc_3_status?"},
"c5": {"name": "usba_1_status?"},
"c6": {"name": "usba_2_status?"},
"cc": {"name": "device_sn"},
"cd": {"name": "ac_input_limit"},
"fe": {"name": "msg_timestamp"},
},
},I'll hope to identify more as I start to get pv power today. |
I deliberately avoided the numerals - there is no indication/marking that #2 is on the left and #1 is on the right. Other suggested names that unambiguously identify each port? |
|
Numbers are required for scalability and reuse across various device types. Even if you device has just one port, another might have more. |
|
@stockmopar do you happen to have additional batteries? |
|
I don't |
|
here's hoping for an amazing black-friday sale |
|
Should the labels include the units. This would reduce misinterpretation. examples: |
Preferrably not, only for uncommon units. Otherwise W, kWh, °C, % are assumed default and factor should be used to convert the value accordingly. For fields representing a toggle setting, switch should be included. Fields representing non binary mode setting should include mode. Fields representing a status that is not controllable should use status, but need comments which value represents which status. # Display and light settings
"d9": {
"name": "display_mode"
}, # Display brightness: Off (0), Low (1), Medium (2), High (3)
"dc": {
"name": "light_mode"
}, # LED light mode: Off (0), Low (1), Medium (2), High (3), Blinking (4)
# Smart mode configuration (byte field)
"f8": {
"bytes": {
"00": {
"name": "12v_dc_output_mode", # 12V DC mode: Normal (1), Smart (2) - auto-off below 3W
"type": DeviceHexDataTypes.ui.value,
},
"01": {
"name": "ac_output_mode", # AC output mode: Normal (1), Smart (2) - auto-off when not charging and low power
"type": DeviceHexDataTypes.ui.value,
},
}
}, |
|
If you describe command messages, each field need to be described including the type. This must become consumable for code to compose the whole cmd message per device and only vary the adjustable parameter. I think I'm also going to separate cmd messages in their own map, but you may start describing them as you see them when doing changes. |
|
@thomluther It appears that the majority of the most interesting pieces of data requires the realtime trigger. I'm most interested in getting this data in Home Assistant. I guess a few questions, what is the best way to get this there? Should we create the PRs for both here and ha-anker-solix? (assuming yes). Regarding the realtime trigger to get these pieces of data to show. Is that already built in to the home assistant integration to enable that to have this data flow? Or are there any challenges you anticipate for enabling that? |
|
The realtime trigger will be part of next release and requires new config options including configuration migration for better structure of options. This will be a breaking change and no way backward while maintaining hub configuration since old versions cannot migrate backwards. But that is OK since hub can be deleted and recreated if necessary without loosing history. The mqtt trigger option might be available in HA by end Nov. Still need to implement a common, but modular and scalable mqtt device class framework and factory to allow controls via HA. This will also enable a common control testing via the monitor tool, which needs to get clear features and allowed options per device class and PN to provide a selectable controll approach, which is required for HA as well. |
|
I put up #243 to share the progress and make it easier to point out where this needs to be changed to match intent for going forward! @thomluther it looks like most of the commands are almost exactly the same as the C1000x for controlling the F3800P. |
|
Thanks. |
|
@gitTinker , @stockmopar A1790_040a = {
# F3800 param info
"topic": "param_info",
}
A1790_0804 = {
# F3800 param info
"topic": "param_info",
}
A1790_0830 = {
# F3800 param info
"topic": "param_info",
"a1": {"name": "sw_version?", "values": 4},
"a2": {"name": "fw_version", "values": 4},
}Standalone F3800(p) may send less message types than coupled F3800 or even if attached to power panel. |
|
This is to track the missing parts for F3800 (P) in the MQTTMAP descriptions:
|
|
Here is log of walking through all the valid options for display timeout (changes performed from the app): display_timeout_2025-11-22__16_48_06.txt Command example/validation and valid options to control Display Timeout setting
The valid options for device timeout are:
The valid options for max load setting are:
A/C charge limit and max load are the same thing. In the app, the setting is labeled "AC Recharging Power". It controls the amount of power that is used to recharge using the 110V AC cord. |
|
|
|
so jealous. for the original F3800 I do not have this option so my off-grid setup was down for 2 weeks (drained batteries due to cloudy weather) until I could drive out and restart everything. The batteries were fully charged when I got there. A did order the BP3800 extension batteries (black friday sale). So I should have info where those appear in the messages. |
I think we need to distinguish max load = max. AC/DC output typically and max AC charge (power drawn from grid). |
While I am using mqtt_monitor, I tap "r" and within a second, I see the 405 message (app not needed) |
|
Retested it again and that worked as expected. Maybe my order was wrong. But yep works as expected! |
|
The realtime trigger is not enabled by default, because that spams with messages. 'r' will toggle on and off. |
|
@stockmopar , some questions on your log file:
16:48:11 INFO: ------------------------- Pps / A1790P / 0840 / Header -------------------------
ff 09 : 2 Byte Anker Solix message marker (supposed 'ff 09')
a7 01 : 2 Byte total message length (423) in Bytes (Little Endian format)
03 01 0f: 3 Byte fixed message pattern (supposed `03 00/01 0f` for send/receive)
08 40 : 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
...
f9 02 01 01
└-> 2 ui 1 1
fa 02 01 0c
└-> 2 ui 12 12
fd 0c 00 41:31:37:39:30:50:5f:31:35:41:68
└-> 12 str b'A1790P_15Ah' --> exp_1_typeMessage 0840 may show expansion pack num in F9?
cd 03 02 c8:00
└-> 3 sile 200 200 200;0 --> ac_input_limit
...
e6 03 02 08:07
└-> 3 sile 1800 1800 8;7
f6 03 02 55:53
└-> 3 sile 21333 21333 85;83 --> region?
f7 05 03 01:00:00:00The 200 seem to be the charge limit that you can modify.
|
|
|
There are a couple capabilities of the F3800 Plus that I haven't analyzed values for including utilizing the 240V generator input charging / bypass. I think there is a 220VAC input charging limit which depends on the number of expansion batteries that are installed. I believe if none, it allows up to 3300W and if you have at least an expansion battery it allows up to 6000W. Its possible that either that value or other values represent these? I also wonder if another setting becomes visible to manually adjust the rate of charge from the 240V option or if the range increases? I do have the generator input / bypass unit but have not tested it yet. I do have another F3800 Plus with dual power hub coming with an expansion battery too. |
|
Thanks for the update and log. I could now finally code and described the command for the display timeout. This is not working yet however, I still have to create a common command composer framework that can utilize the command descriptions. Once ready, I will add an 'issue command' option to the normal monitor tool, that should then be usable to select from supported commands and options and validate the change directly in the monitor output. What I also found in your log is message 0840. This appears similar to 0405 message which is only sent with the realtime trigger. 07:07:33 INFO: ------------------------- Pps / A1790P / 0840 / Header -------------------------
ff 09 : 2 Byte Anker Solix message marker (supposed 'ff 09')
a7 01 : 2 Byte total message length (423) in Bytes (Little Endian format)
03 01 0f: 3 Byte fixed message pattern (supposed `03 00/01 0f` for send/receive)
08 40 : 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 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 00:00
└-> 3 sile 0 0 0;0
a5 03 02 00:00
└-> 3 sile 0 0 0;0
a6 03 02 00:00
└-> 3 sile 0 0 0;0
a7 03 02 00:00
└-> 3 sile 0 0 0;0
a8 03 02 00:00
└-> 3 sile 0 0 0;0
a9 03 02 00:00
└-> 3 sile 0 0 0;0
aa 03 02 00:00
└-> 3 sile 0 0 0;0
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 4a:00
└-> 3 sile 74 74 74;0
ae 03 02 00:00
└-> 3 sile 0 0 0;0
af 03 02 00:00
└-> 3 sile 0 0 0;0
b0 03 02 00:00
└-> 3 sile 0 0 0;0
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 00:00
└-> 3 sile 0 0 0;0
b4 03 02 37:00
└-> 3 sile 55 55 55;0
b5 03 02 62:01
└-> 3 sile 354 354 98;1
b6 03 02 00:00
└-> 3 sile 0 0 0;0
b7 03 02 df:00
└-> 3 sile 223 223 223;0
b8 03 02 71:00
└-> 3 sile 113 113 113;0
b9 03 02 00:00
└-> 3 sile 0 0 0;0
ba 03 02 e5:01
└-> 3 sile 485 485 229;1
bb 03 02 62:01
└-> 3 sile 354 354 98;1
bc 03 02 00:00
└-> 3 sile 0 0 0;0
bd 02 01 00
└-> 2 ui 0 0
be 02 01 14
└-> 2 ui 20 20
bf 02 01 00
└-> 2 ui 0 0
c0 02 01 4a
└-> 2 ui 74 74
c1 02 01 64
└-> 2 ui 100 100
c2 02 01 00
└-> 2 ui 0 0
c3 02 01 00
└-> 2 ui 0 0
c4 02 01 00
└-> 2 ui 0 0
c5 02 01 00
└-> 2 ui 0 0
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 17 00 *** (REDACTED) ***
cd 03 02 c8:00
└-> 3 sile 200 200 200;0
ce 03 02 a0:05
└-> 3 sile 1440 1440 160;5
cf 03 02 08:07
└-> 3 sile 1800 1800 8;7
d0 03 02 3c:00
└-> 3 sile 60 60 60;0
d1 03 02 00:00
└-> 3 sile 0 0 0;0
d2 03 02 00:00
└-> 3 sile 0 0 0;0
d3 02 01 00
└-> 2 ui 0 0
d4 02 01 00
└-> 2 ui 0 0
d5 02 01 03
└-> 2 ui 3 3
d6 02 01 3c
└-> 2 ui 60 60
d7 02 01 00
└-> 2 ui 0 0
d8 02 01 01
└-> 2 ui 1 1
d9 02 01 01
└-> 2 ui 1 1
de 02 01 00
└-> 2 ui 0 0
df 02 01 00
└-> 2 ui 0 0
e3 0e 04 00:00:00:00:00:00:00:00:00:00:00:00:00
└-> 14 bin b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
e4 0e 04 00:00:00:00:00:08:07:78:05:10:0e:f0:0a
└-> 14 bin b'\x00\x00\x00\x00\x00\x08\x07x\x05\x10\x0e\xf0\n'
e5 16 06 00:00:00:10:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
└-> 22 strb b'\x00\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
e6 03 02 08:07
└-> 3 sile 1800 1800 8;7
f6 03 02 55:53
└-> 3 sile 21333 21333 85;83
f7 05 03 01:00:00:00
└-> 5 var 1;0 1 0.000 1;0;0;0
f8 15 04 01:02:01:01:00:01:01:00:00:00:00:00:00:00:00:00:00:00:00:00
└-> 21 bin b'\x01\x02\x01\x01\x00\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
f9 02 01 01
└-> 2 ui 1 1
fa 02 01 0c
└-> 2 ui 12 12
fd 0c 00 41:31:37:39:30:50:5f:31:35:41:68
└-> 12 str b'A1790P_15Ah'
fe 05 03 96:58:24:69
└-> 5 var 22678;26916 1763989654 12417635604931423116460032.000 150;88;36;105
-------------------------------------------------------------------------------- |
|
Here is a longer running log: Note that it appears to be variable update times. A1790P_mqtt_dump_2025-11-24__10_38_23.txt Here are the times when 0405 were recorded: I started the log with very little happening on the F3800 Plus. The AC Output (ac_output_power_switch) was OFF. Right around 10:40:14 was when I turned the AC Output ON. Updates came frequently. When I turned the AC Output off again the updates slowed again. |
|
The rate of 0405 is pretty clear. The devices send it only if their real time trigger is active and then in 3-5 second intervals typically. |
|
Comparing the C1000, which seem to have both: The C1000 has the max_load command described as message 0044, but has not described it for ac_charge_limit. |
|
Adding @ohadlevy for commenting on the commands, namings and state for the following PPS settings:
In the C1000 descriptions and coded commands, there is only command described as message 0044 and coded in that way. Altough the parameter checks in the device class show "ac_charge_limit": lambda v: 100 <= v <= 800,, this is not coded in any way. So the question is what is the command message and content for those 2 features? We must not intermix max_load and ac_charge_limit in the namings across the devices as this becomes confusing. If both features are not available on every PPS, this must be documented accordingly and excluded from the PPS feature list for each particular PN. Even if the setting may not be available, the fix limit (state) could still be found in the mqtt messages... Each PN that supports both features must also describe them both in their PN mapping for the particular message type they are using for the command. The state names must be descibed accordingly, since each command will need a corresponding state field in the messages, otherwise it cannot be configured as HA control entity. |
|
I also found another weird command in your logs: Since the value is a binary field type, it may be difficult to understand what this is about. Part of it could be your SN string, but you would need to compare... |
|
Its "account_id". Probably another value one that would be good to scrub :) |
|
|
Yeah, first device where I see that in the mqtt data. But should be randomized in the export tool. |
|
Hold on, actually this is a command which is not included in the export. |
|
@stockmopar did you ever get the BP3800 extensions? ------------------------- Pps / A1790 / 0405 / Header --------------------------
ff 09 : 2 Byte Anker Solix message marker (supposed 'ff 09')
78 01 : 2 Byte total message length (376) 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 f0:00
└-> 3 sile 240 240 240;0 --> remaining_time_hours (factor 0.1)
a5 03 02 00:00
└-> 3 sile 0 0 0;0 --> ac_input_power
a6 03 02 3f:00
└-> 3 sile 63 63 63;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 --> usbc_3_power
aa 03 02 00:00
└-> 3 sile 0 0 0;0 --> usba_1_power?
ab 03 02 00:00
└-> 3 sile 0 0 0;0 --> usba_2_power?
ac 03 02 00:00
└-> 3 sile 0 0 0;0 --> dc_12v_output_power_switch?
ad 03 02 49:00
└-> 3 sile 73 73 73;0 --> battery_soc_total
ae 03 02 df:00
└-> 3 sile 223 223 223;0 --> photovoltaic_power
af 03 02 8d:00
└-> 3 sile 141 141 141;0 --> pv_1_power
b0 03 02 52:00
└-> 3 sile 82 82 82;0 --> pv_2_power
b1 03 02 df:00
└-> 3 sile 223 223 223;0 --> bat_charge_power
b2 03 02 3f:00
└-> 3 sile 63 63 63;0 --> output_power
b3 03 02 00:00
└-> 3 sile 0 0 0;0
b4 03 02 67:00
└-> 3 sile 103 103 103;0 --> bat_discharge_power?
b5 03 02 f0:00
└-> 3 sile 240 240 240;0 --> sw_version?
b6 03 02 00:00
└-> 3 sile 0 0 0;0
b7 03 02 8c:00
└-> 3 sile 140 140 140;0
b8 03 02 6f:00
└-> 3 sile 111 111 111;0
b9 03 02 00:00
└-> 3 sile 0 0 0;0
ba 03 02 df:01
└-> 3 sile 479 479 223;1 --> sw_expansion?
bb 03 02 f0:00
└-> 3 sile 240 240 240;0
bc 03 02 00:00
└-> 3 sile 0 0 0;0 --> ac_output_power_switch
bd 02 01 01
└-> 2 ui 1 1 --> charging_status
be 02 01 06
└-> 2 ui 6 6 --> temperature
bf 02 01 02
└-> 2 ui 2 2 --> display_status
c0 02 01 52
└-> 2 ui 82 82 --> battery_soc_total_dup?
c1 02 01 62
└-> 2 ui 98 98 --> max_soc
c2 02 01 00
└-> 2 ui 0 0 --> usbc_1_status
c3 02 01 00
└-> 2 ui 0 0 --> usbc_2_status
c4 02 01 00
└-> 2 ui 0 0 --> usbc_3_status
c5 02 01 00
└-> 2 ui 0 0 --> usba_1_status?
c6 02 01 00
└-> 2 ui 0 0 --> usba_2_status?
c7 02 01 00
└-> 2 ui 0 0 --> dc_output_power_switch
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 11 00 41:5a:56:xxxxxxxxxxxxxx:30:30:30:35:34
└-> 17 str b' xxxxxxxxxxxxx' --> device_sn
cd 03 02 2c:01
└-> 3 sile 300 300 44;1 --> ac_input_limit
ce 03 02 00:00
└-> 3 sile 0 0 0;0
cf 03 02 3c:00
└-> 3 sile 60 60 60;0 --> display_timeout_seconds
d0 03 02 3c:00
└-> 3 sile 60 60 60;0
d1 03 02 00:00
└-> 3 sile 0 0 0;0
d2 03 02 00:00
└-> 3 sile 0 0 0;0
d3 02 01 00
└-> 2 ui 0 0 --> ac_output_power_switch_dup?
d4 02 01 00
└-> 2 ui 0 0 --> dc_output_power_switch_dup?
d5 02 01 02
└-> 2 ui 2 2 --> display_mode
d6 02 01 3c
└-> 2 ui 60 60
d7 02 01 00
└-> 2 ui 0 0
d8 02 01 00
└-> 2 ui 0 0 --> temp_unit_fahrenheit
d9 02 01 00
└-> 2 ui 0 0 --> light_mode
da 02 01 03
└-> 2 ui 3 3
db 02 01 14
└-> 2 ui 20 20
dc 02 01 00
└-> 2 ui 0 0
dd 02 04 00
└-> 2 bin b'\x00'
e4 02 01 00
└-> 2 ui 0 0
fe 05 03 af:f2:3e:69
└-> 5 var -3409;26942 1765733039 14427621662240431031713792.000 175;242;62;105 --> msg_timestamp (2025-12-14 09:23:59)
de 02 01 00
└-> 2 ui 0 0
f6 03 02 55:53
└-> 3 sile 21333 21333 85;83 --> region?
f7 05 03 01:00:00:00
└-> 5 var 1;0 1 0.000 1;0;0;0 --> port_memory_switch
f8 15 04 02:00:01:01:00:01:01:00:00:00:00:00:00:00:00:00:00:00:00:00
└-> 21 bin b'\x02\x00\x01\x01\x00\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
f9 02 01 01
└-> 2 ui 1 1
fa 02 01 0a
└-> 2 ui 10 10
fd 0b 00 41:31:37:39:30:5f:31:35:41:68
└-> 11 str b'A1790_15Ah' --> exp_1_type
--------------------------------------------------------------------------------------------------------- Pps / A1790 / 040a / Header --------------------------
ff 09 : 2 Byte Anker Solix message marker (supposed 'ff 09')
48 00 : 2 Byte total message length (72) in Bytes (Little Endian format)
03 01 0f: 3 Byte fixed message pattern (supposed `03 00/01 0f` for send/receive)
04 0a : 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 02 01 01
└-> 2 ui 1 1
a3 02 01 40
└-> 2 ui 64 64
a4 27 04 31:30:31:41:4d:32:35:30:37:32:35:30:30:33:38:32:6a:01:00:08:02:40:64:00:01:00:01:00:41:31:37:39:30:5f:31:35:41:68
└-> 39 bin b'101AM25072500382j\x01\x00\x08\x02@d\x00\x01\x00\x01\x00A1790_15Ah'
a5 01 -- 01
└-> 1 unk b'\x01'
fe 05 03 af:f2:3e:69
└-> 5 var -3409;26942 1765733039 14427621662240431031713792.000 175;242;62;105
--------------------------------------------------------------------------------
```
<img width="640" height="622" alt="image" src="https://github.com/user-attachments/assets/856b2be5-ee90-4589-a4b2-61750f4955a6" />
|
|
Once you descibe SOC with expansions, you need to distinguish the average soc of the device (battery_soc) and the soc of the main battery, that can be different (main_battery_soc). So in general for F3800, someone needs to dump separate files for each Control that can be toggled with the App. I would like to see an example command message decoded for each control that can be done in the App. |
This is on my to-do list, but low priority. First I need a dashboard of system health. My off-grid system is 20+ minutes from my development environment, so it is 'challenging' to observe results directly and if/when I disable something I have to drive out to restore functionality. |
|
I added description for 040a, it seems similar to the solarbank extensions, but yet different. You need to monitor if the names can be confirmed. |
at the time of the message below: I assume the "1" (called "expansion_packs?" below) indicates this is the 1st attached extension. I assume the second on the chain of cables would be "2". ------------------------- Pps / A1790 / 040a / Header --------------------------
ff 09 : 2 Byte Anker Solix message marker (supposed 'ff 09')
48 00 : 2 Byte total message length (72) in Bytes (Little Endian format)
03 01 0f: 3 Byte fixed message pattern (supposed `03 00/01 0f` for send/receive)
04 0a : 2 Byte message type pattern (varies per device model and message type)
: 1 Byte optional message increment ( 0)
-> 13 <-: XOR Checksum Byte (last message byte), Crosscheck: 00 => OK
-- Fields --|- Value (Hex/Decode Options)---------------------------------------
Fld Len Typ uIntLe/var sIntLe floatLe dblLe/4int
a1 01 -- 34
└-> 1 unk b'4'
a2 02 01 01
└-> 2 ui 1 1 --> expansion_packs?
a3 02 01 42
└-> 2 ui 66 66 --> main_battery_soc?
a4 27 04 31:30:31:41:4d:32:35:30:37:32:35:30:30:33:38:32:6a:01:00:09:02:42:64:00:01:00:01:00:41:31:37:39:30:5f:31:35:41:68
└-> 39 bin b'101AM25072500382j\x01\x00\t\x02Bd\x00\x01\x00\x01\x00A1790_15Ah' --> {'00': {'name': 'exp_1_sn?', 'length': 16, 'type': b'\x00'}, '19': {'name': 'exp_1_temperature?', 'type': b'\x01'}, '21': {'name': 'exp_1_soc?', 'type': b'\x01'}, '22': {'name': 'exp_1_soh?', 'type': b'\x01'}, '28': {'name': 'exp_1_type', 'length': 10, 'type': b'\x00'}}
a5 01 -- 01
└-> 1 unk b'\x01' --> {'00': {'name': 'exp_2_sn?', 'length': 16, 'type': b'\x00'}, '19': {'name': 'exp_2_temperature?', 'type': b'\x01'}, '21': {'name': 'exp_2_soc?', 'type': b'\x01'}, '22': {'name': 'exp_2_soh?', 'type': b'\x01'}, '28': {'name': 'exp_2_type', 'length': 10, 'type': b'\x00'}}
fe 05 03 8c:00:3f:69
└-> 5 var 140;26943 1765736588 14431713380660280731631616.000 140;0;63;105 --> msg_timestamp (2025-12-14 10:23:08)
-------------------------------------------------------------------------------- |
Yes, but 2 in the same field. No expansions installed and this should be 0 |
|
Adding a data point that may help with the Setup: F3800 + 1× BP3800 expansion (15Ah model, type string "A1790_15Ah"), continuous MQTT captures running since early May 2026. Concurrent reading from a single sniff window, 2026-05-05 23:15 UTC:
Anker app at the same moment displayed 91% — the user-facing total. What I think this might meanIf both batteries contribute equally to the user-displayed total (which assumes equal capacity per Interpretation A — ad = whole system, c0 = F3800-only Interpretation B — c0 = whole system, ad = F3800-only Interpretation A is what the math points to, which would mean the two labels are flipped vs reality. The Where I might be wrongA few things I don't fully understand and would value input on:
If the interpretation holds upI could open a small PR to update the labels and remove the Either way, glad to share more captures or test specific hypotheses against ongoing data if it's useful. |
|
Hi @jlchatha |
|
@jlchatha |
|
Hi @thomluther, appreciate you taking the time, and glad if the analysis helps with the ad/c0 update. On 040a.a3 in our capture: the value was 87. With our reading of the 0405 fields (ad as system total = 91, c0 as F3800 unit alone = 95, exp_1_soc = 87 from 040a.a4 offset 22), the 040a.a3 value matches the BP3800 expansion battery, On the system export: attached. Generated via export_system.py with randomization on, ANKERCOUNTRY=US, MQTT data included. Includes the full set of api_* JSON files plus mqtt_msg_*.ndjson capture files for message types 0405, 040a, One small data anomaly I noticed in api_devices.json: expansion_packs reads 0 even though the BP3800 is present and listed in ota_children as A1790_15Ah. Probably an Anker reporting quirk rather than something useful for the mapping On the 0405-with-vs-without-expansion comparison: also possible. Would require physically disconnecting the BP3800 for a separate capture, doable in a controlled test session if it would help isolate the expansion-pack-count field. |
Hm, that is weird if it does not match the total. If no expansion is installed, it shows the main and only battery soc. If 1 expansion installed, it shows the expansion soc...I miss the common use of field 040a.a3
I don't think that needs randomization. The time zone may even be required if the offset of extracted data may be usefull, but right now the library does not use this field and auto determines energy data offset automatically.
expansion_packs is just a helper in the cache to calculate overall capacity. It will be updated once MQTT data is received, but the export creates the randomized Api cache only at the end without MQTT knowledge.
I need to compare the messages with other devices to see if I can find the candidate fields already. |
|
Some observations from the package:
a5 03 02 00:00
└-> 3 sile 0 0 0;0 --> ac_input_power
a6 03 02 87:00
└-> 3 sile 135 135 135;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 --> usbc_3_power
aa 03 02 00:00
└-> 3 sile 0 0 0;0 --> usba_1_power?
ab 03 02 00:00
└-> 3 sile 0 0 0;0 --> usba_2_power?
ac 03 02 00:00
└-> 3 sile 0 0 0;0 --> dc_12v_output_power_switch?
ad 03 02 4c:00
└-> 3 sile 76 76 76;0 --> battery_soc
ae 03 02 4c:01
└-> 3 sile 332 332 76;1 --> photovoltaic_power
af 03 02 00:00
└-> 3 sile 0 0 0;0 --> pv_1_power
b0 03 02 4c:01
└-> 3 sile 332 332 76;1 --> pv_2_power
b1 03 02 4c:01
└-> 3 sile 332 332 76;1 --> bat_charge_power
b2 03 02 87:00
└-> 3 sile 135 135 135;0 --> output_power_total
b3 03 02 00:00
└-> 3 sile 0 0 0;0
b4 03 02 71:00
└-> 3 sile 113 113 113;0 --> bat_discharge_power?
b5 03 02 f3:00
└-> 3 sile 243 243 243;0 --> sw_version
b6 03 02 00:00
└-> 3 sile 0 0 0;0
b7 03 02 8c:00
└-> 3 sile 140 140 140;0
b8 03 02 6f:00
└-> 3 sile 111 111 111;0
b9 03 02 00:00
└-> 3 sile 0 0 0;0All PV 332 W seems to be charged 332 W, while there is also 135 W AC output. So where does this come from? I don't think b4 is correct in this context, there should not be discharge while charging. Where is discharge reflected, and what could be b7 and b8? Also any power values? 140 W could rather reflect some discharge that result in 135 W AC output. But charge and discharge at same time?
------------------------- Pps / A1790 / 0500 / Header --------------------------
ff 09 : 2 Byte Anker Solix message marker (supposed 'ff 09')
7c 00 : 2 Byte total message length (124) in Bytes (Little Endian format)
03 01 0f: 3 Byte fixed message pattern (supposed `03 00/01 0f` for send/receive)
05 00 : 2 Byte message type pattern (varies per device model and message type)
: 1 Byte optional message increment ( 0)
-> 84 <-: XOR Checksum Byte (last message byte), Crosscheck: 00 => OK
-- Fields --|- Value (Hex/Decode Options)---------------------------------------
Fld Len Type uIntLe/var sIntLe floatLe dblLe/4int
a1 01 -- 12
└-> 1 unk b'\x12'
a2 6d 04 04:00:02:00:06:00:01:00:01:00:09:01:1c:00:00:00:00:00:00:00:00:00:0b:00:0e:00:c2:17:00:00:87:06:00:00:88:06:00:00:c3:17:00:00:04:00:00:00:00:00:aa:12:f4:09:00:00:00:00:00:00:01:01:41:03:00:00:41:03:00:00:70:00:00:00:70:00:00:00:4c:00:58:37:00:00:e4:28:01:00:00:00:00:00:5e:ff:01:00:00:00:00:00:00:00:00:00:0c:00:66:05:00:00
└-> 109 bin b'\x04\x00\x02\x00\x06\x00\x01\x00\x01\x00\t\x01\x1c\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0b\x00\x0e\x00\xc2\x17\x00\x00\x87\x06\x00\x00\x88\x06\x00\x00\xc3\x17\x00\x00\x04\x00\x00\x00\x00\x00\xaa\x12\xf4\t\x00\x00\x00\x00\x00\x00\x01\x01A\x03\x00\x00A\x03\x00\x00p\x00\x00\x00p\x00\x00\x00L\x00X7\x00\x00\xe4(\x01\x00\x00\x00\x00\x00^\xff\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0c\x00f\x05\x00\x00'
--------------------------------------------------------------------------------You would need to compare their changes along the command messages, that modify those settings to get an idea. The A1790P contains additional binary fields in 0405 which I have not seen in yours. I don't know if that depends on actual settings, or is model specific: d8 02 01 01
└-> 2 ui 1 1 --> temp_unit_fahrenheit
d9 02 01 00
└-> 2 ui 0 0 --> light_mode
de 02 01 00
└-> 2 ui 0 0
df 02 01 00
└-> 2 ui 0 0
e3 20 04 05:00:00:00:00:00:00:11:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
└-> 32 bin b'\x05\x00\x00\x00\x00\x00\x00\x11\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
e4 0e 04 00:00:00:00:00:08:07:78:05:10:0e:f0:0a
└-> 14 bin b'\x00\x00\x00\x00\x00\x08\x07x\x05\x10\x0e\xf0\n'
e5 16 06 00:00:00:10:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
└-> 22 strb b'\x00\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
e6 03 02 08:07
└-> 3 sile 1800 1800 8;7 --> ac_input_limit_max
e7 2c 04 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
└-> 44 bin b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
f6 03 02 55:53
└-> 3 sile 21333 21333 85;83 --> {'00': {'name': 'region', 'type': b'\x00', 'length': 2}}A1790: d8 02 01 01
└-> 2 ui 1 1 --> temp_unit_fahrenheit
d9 02 01 00
└-> 2 ui 0 0 --> light_mode
da 02 01 03
└-> 2 ui 3 3
db 02 01 14
└-> 2 ui 20 20
dc 02 01 00
└-> 2 ui 0 0
dd 02 04 00
└-> 2 bin b'\x00'
e4 02 01 00
└-> 2 ui 0 0
fe 05 03 f3:bb:04:6a
└-> 5 var -17421;27140 1778695155 40116443320059396534304768.000 243;187;4;106 --> msg_timestamp (2026-05-13 17:59:15)
de 02 01 00
└-> 2 ui 0 0
f6 03 02 55:53
└-> 3 sile 21333 21333 85;83 --> {'00': {'name': 'region', 'type': b'\x00', 'length': 2}}
f7 05 03 01:00:00:00
└-> 5 var 1;0 1 0.000 1;0;0;0 --> port_memory_switch |
|
Is it the F3800 that also supports a usage mode? That may reveal the plan structure, and the set_device_attr can eventually be used to set the same and change the mode... More details here: |
|
Hi @thomluther, sorry for the long gap on my end, and thanks for the 040a work. Picking this back up with a lot more decoded data on our side, so instead of hypothesizing I can answer the power-field questions with a real frame. Here is a representative 0405 frame from our F3800 + 1x BP3800 during midday solar charging (values little-endian decoded, device SN redacted): On the "charge and AC output at the same time" puzzle: in our data the field that resolves it is bd (charging status), not b4. In the frame above bd=1 (solar), b1=832 W charge, and a6/b2=103 W AC output, all at once. That is consistent with normal off-grid behavior: PV can feed the AC load while charging the pack, so this frame does not establish a separate battery-discharge value. A "discharge" field reading around 113 W there is not trustworthy on its own, since this capture cannot confirm the pack is net-discharging. So I would treat bd as the mode selector, and I would not trust b4 as a discharge value. On b4/b7/b8 specifically: your sample had b4=113, b7=140, b8=111, and ours reads b4=84, b7=140, b8=111. b7 and b8 are identical to yours, and across our charging captures they stayed rock stable while solar (and therefore b1 charge power) varied a lot. So this b4..b8 group is not tracking charge power, since b1 already does that. It clusters with b5=bb=243 and ba=487, which looks more like a voltage or current group on some rail than a power channel. My guess is b5/bb is a pack or bus voltage times 10 and ba is a charge current, with b4/b7/b8 as related current or voltage readings, but I have not confirmed those against the app yet. Where discharge actually shows up: I cannot hand you a confirmed discharge-power field yet, because every raw frame we have archived is from a daytime charging session (our decode day was all solar). The clean way to isolate it is a night frame with bd=0, zero PV, and a real AC load, where the pack is the only source. We run overnight on base load every night, so I can capture that on purpose and send the decoded frame. Comparing a bd=1 charging frame against a bd=0 discharging frame side by side should make the discharge channel fall out, and by contrast tell us what b4/b7/b8 really are. That feels like the one capture worth doing next. Two extra fields we mapped that might help elsewhere:
Happy to send the overnight discharge frame plus a matched charging frame, same export and scrub as before, in whatever set is most useful (0405 alone, or 0405 + 040a + 0840 together). Just say which and I will grab them on the next clear night. |
|
Hi @jlchatha "b4": {NAME: "bat_discharge_power?"},
"b5": {NAME: "sw_version"}, # Main firmware version
"ba": {NAME: "sw_expansion"}, # Expansion firmware version
"bb": {NAME: "sw_controller"},The db field is nothing that can be described currently. So I don't see any change necessary at the moment, unless you have validated incorrect or missing field descriptions from the latest main branch. If the F3800 supports usage mode, you will have to trace the MQTT commands that change them and where the actual mode state is reflected. That's the only think I still could add for the device. I have no idea what else is still missing. |
|
Thanks @thomluther, and fair. You're right on all counts. To be straight with you: yes, we're absolutely leaning on AI to accelerate this decode, and your reply is a good reminder that it will hand you a confident, tidy story that's wrong. The Going forward I'll validate any field claim against the latest main map before I write it up, and only bring you things I can back with matched captures rather than interpretation. On that, the one place I might still be able to add real data is your I'll follow up when I have the captures. Thanks for the correction and for the patience, genuinely. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I have two F3800 (the original model, not F3800+) and a Dual Power Hub to connect them. Completely off-grid; charged via solar on the XT60 ports. All 4 ports used (two on each F3800).
This setup may affect the values received from MQTT.
For reference: I am running mqtt_monitor.py on a Raspberry Pi 4B with the trixie version of RPiOS.
I am using the same account, simultaneously, for the app (IOS) and anker-solix-api.
Device awake publish interval: TBD
Device standby publish interval: TBD
Device real time trigger publish: TBD
All reactions