Support for Solix C1000 Gen 2?

[crowedavid]

i have been following the incredible progress here in adding support for additional models and decided to see if my Solix C1000 Gen 2 would be recognized and how well it would show up - unfortunately not very much (used SolixBLE v3.4.0 along with the example monitoring script).

intent is to use the Home Assistant HaSolixBLE integration but wanted to gather data direct w/o disrupting my HA instance too much. i have had this same C1000G2 setup using the Anker Solix HA integration with data updates working well on wifi. hopefully the data format/fields will come over easily as it appears they did for other devices.

C1000G2 is using the latest firmware for it: v1.1.4.1

here is the plain state output from the monitor.py script: (full debug output attached)

==== REMOTE STATE CHANGE DETECTED ====
C1000G2(
AC_OUTPUT: PortStatus.UNKNOWN,
AC_POWER_IN: -1,
AC_POWER_OUT: -1,
ADDRESS: 7C:E9:13:4E:C8:62,
AVAILABLE: False,
BATTERY_HEALTH: -1,
BATTERY_PERCENTAGE: -1,
CONNECTED: True,
DC_OUTPUT: PortStatus.UNKNOWN,
DC_POWER_OUT: -1,
LAST_UPDATE: None,
MAX_BATTERY_PERCENTAGE: -1,
MIN_BATTERY_PERCENTAGE: -1,
NAME: SOLIX C1000 Gen 2,
NEGOTIATED: True,
PART_NUMBER: Unknown,
POWER_OUT: -1,
SERIAL_NUMBER: Unknown,
SOLAR_PORT: PortStatus.UNKNOWN,
SOLAR_POWER_IN: -1,
TEMPERATURE: -1,
USB_A1_POWER: -1,
USB_C1_POWER: -1,
USB_C2_POWER: -1,
USB_C3_POWER: -1,
USB_PORT_A1: PortStatus.UNKNOWN,
USB_PORT_C1: PortStatus.UNKNOWN,
USB_PORT_C2: PortStatus.UNKNOWN,
USB_PORT_C3: PortStatus.UNKNOWN,
)

solix.txt

does this help in getting the information needed? if not, i'm happy to gather more data and try out updates on my device.

[flip-dots]

@crowedavid Is anything plugged into your device? Anker devices only send telemetry updates when something is happening so if there is nothing plugged in to your device you won't get any telemetry updates.

[crowedavid]

i turned off/on the AC input to trigger a change and had a lamp plugged in just for some AC output. just tried again with one of the USB-C ports and i don't see any changes when selecting Print state on the script. not many new DEBUG messages come in between times when i select Print state on the script either but i have seen some in the past.

i'll do some more this evening and see if i can gather more data over time - i may have stopped too quickly last night when it show much.

is that monitor script a good one to gather data for you?

[flip-dots]

@crowedavid Sure, just make sure to change the class to C1000G2. If that does not work, try using the C1000 class and call the get_status_update() method to see if you get any response. Its possible that the C1000G2 does not send telemetry by itself and needs to be polled or there might be some special message needed to enable it that is different from all the other devices.

[thomluther]

Gen 2 PPS and newer PPS have completely different telemetry data structures.
Instead of individual values in a field, in most cases each field is binary data that contains multiple 1-4 byte chunks of values of different format, much more difficult to decode and identify.
They definitely need a different class for proper handling of value extraction, although the properties themselves may be the largely the same between both generations.

[flip-dots]

@thomluther I am aware of that (its why there is a C1000G2 class, which is also based off your work so big thanks for that), but I only implemented get_status_update() for the C300, C800, and C1000 since I decided to only add commands (including the one to request a single telemetry update) for devices I could actually test with out of an abundance of caution (it's probably a bit overly cautious). So if the command results in the device responding with a telemetry update, even if the values are a bit jumbled, I can add the get_status_update() function to the C1000G2 class to get it working. If that does not work then someone who has a C1000G2 will need to go through the app decoding process to help me figure out what special command is needed to get this particular device talking.

[thomluther]

@flip-dots Sure, I understand the cautious about it. I allow the 'standard' RT trigger '0057' and status request '0040' commands for every device since I believe they should not harm and in worst case the device does not react on them at all.
The C200/300 family does not use them however, they use different command messages for the status request and the realtime trigger command has no values, like timeout typically. Their realtime trigger seems to be fix to 8-10 messages, one per second. But that message content is also contained in the status request response message, so RT trigger command is not really beneficial for those devices.

I just discovered that the newer 'Gen 2' PPS may also have a different status request message, '0100' which contains a binary value pattern that I have not understood. So they may not respond anyway on '0040' commands and the App doesn't seem to use them either, only the '0057' RT trigger and the '0100' command. That may be valid for all newer PPS devices that mostly use the binary fields format in their telemetry messages, making it more difficult to identify the value byte chunks.

[flip-dots]

@thomluther good to know, I appreciate your help with this. I have been able to get away without status requests for most devices because with Bluetooth they seem to send telemetry packets regularly unprompted as long as the negotiation succeeds and things are changing on device (though the C1000G2 might be the exception). I get the same unprompted (unless the request is in the handshake somewhere) telemetry behavior with the Anker Prime 160w charger in my experimental branch and I think that device is fairly new, though it's also quite different from Solix devices.

It might be a good idea to make it request an initial update first by default and just silently fail if it can't, it is probably safe. I did notice that the commands for Bluetooth seem slightly different, like the first byte of the command will be different but the second will be the same as the MQTT API (i.e requesting a status update is 4040 rather than 0040 for the C300 and C1000). Maybe if I am lucky the Bluetooth protocol will be the same as the old one, at least that's what I am hoping.

If that's not the case and it is different from the MQTT API, I wrote a bash script to automate it and some docs on how to build and use a patched version of the Anker app which dumps the keys, decrypted payloads, and packets into a console for analysis, and that should probably reveal the correct sequence of commands to get telemetry data for the Bluetooth API. I do hope Anker would stop ruining their protocol though, it started out so well.

[flip-dots]

@crowedavid it seems likely that these devices need a special command sent to them in order for them to start sending telemetry data, someone else has raised an issue in the Home Assistant library experiencing the same thing.

Finding out what that command is meant to be is kind of a pain. It requires patching the Anker app so it dumps all the sent/received data to/from the device to a log file so it can be analysed. If you are willing to go through the process there is a script which automates the patching process and a guide in the docs which explains how to do it and get the data.

[pilonull]

Man, I'm having this same issue (home assistant integration) and would really love to help but I don't have an available android device with dev mode enabled :(

[flip-dots]

@EugeneDrpc that does look very helpful, thanks. I don't currently have the time to implement it as I have my dissertation and exams due imminently which will keep me busy for the next two months but after that I think I should be able to get it working using this.

[flip-dots]

@EugeneDrpc damn thats awesome. Its interesting that you make use of pairing button thing, this library does not make use of that (and devices when used with this library seem to not require it even though when you use the app it does). Having a working example (like you have provided) and ideally some test data (like packet captures) is super useful for me as they give me something to compare my library to and allow me to add tests to see if my changes work.

If you are interested in figuring it out for yourself you do not need Home Assistant to use this library, you just need a computer with Bluetooth (I use a mac mini), there are some demo scripts in the examples folder which can be used to play around with devices.

[EugeneDrpc]

Security Notice: Anker C1000 v2 Bluetooth Vulnerability

I'd like to bring an issue to your attention regarding the Anker C1000 v2 power station: control commands can be sent without going through the pairing process.
This means anyone within Bluetooth range can connect to your station and — without physically pressing the power button — turn the inverter on or off, or modify settings (for example, restricting the battery operating range to 15–20%, which effectively renders the station unusable, or repeatedly toggling the inverter on and off). Personally, I would recommend disabling Bluetooth until Anker fixes this bug, though you may not consider it critical for your use case.
I spent three weeks trying to reach Anker, sending them a detailed description and a video demonstrating the issue, but I never received a meaningful response. For that reason, I'm publishing the protocol source code here.
Telemetry, on the other hand, is properly protected by the pairing mechanism. For that, I'm sharing the C++ protocol I used on the ESP32-S3 — with the help of Claude Code, I think you should be able to adapt it into a Home Assistant integration within a couple of hours.

Press AC button + 4 times power btn to disable bluetooth.

BleController.cpp
SolixProtocol.cpp

[flip-dots]

@EugeneDrpc Yea its obviously not perfect security but I do kind of understand where Anker are coming from, i.e an attacker needs to be physically nearby, needs to use a custom implementation (so not their App), and the impact is an unauthorised person turning stuff on or off, or worst case scenario maybe bricking the device. It's part of the reason why I decided to make a HACS integration for Home Assistant rather than building in support directly like I did with HueBLE, since people accidentally connecting to someone else's power station might actually happen if it used the auto discovery mechanism in Home Assistant.

In a strange way I almost don't want Anker to fix it since they will probably fix it by making the protocol even more strange and hard to reverse engineer which makes the efforts of myselves and others harder, who just want to control and automate the devices they paid for, in a perfect world Anker would make the protocol open source or develop their own BLE integration, but I don't think that's likely to happen.

I already mentioned this but I am surprised you need to go through the pairing button process for telemetry, this is not needed at least for the devices I tested, either to control them or get telemetry. I appreciate the code, I am stuck dealing with final year exams at the moment but it should be useful to get more devices working when I have the time to look at it properly.