Solarbank 2 status code descriptions

thomluther commented 1 week ago

An open topic to verify for Solarbank 2 support is how the Solarbank 2 will use the status codes. Do they have the same coding as for Solarbank 1? What you currently see for the status code description is translated only by the library based on what the Solarbank 1 was doing when reporting a certain code. We need a translation table for the Solarbank 2 status codes as well. Ignore 0 when false values are returned by the Api, but watch status code and actual description for other conditions:

charge (Solix 1 has only code 3 for any charging mode, but library translates it to more detailed charging mode like charge priority or charge bypass, depending on other values at reported point in time.
discharge only
bypass only
standby
discharge-bypass (new mode only supported by Solix 2), does that have a new status code?
other codes not translated yet
codes that are translated incorrectly for Solix 2

The solarbank monitor will show both, the status code and its translation. In HA you can also see the history of both, but the code is only an attribute and you need to create a template helper entity first for status code history tracking and comparison to the description: {{state_attr('sensor.sb_e1600_betriebszustand','charging_status')}}

stephan-l commented 6 days ago

I just got my Setup ready and try to support as much as possible to get the API completed. Right not I can provide: 3 -> Überschussladung

thomluther commented 5 days ago

Just as a reminder: Do not trust the description provided by the Api. This is what I coded for Solarbank 1 behavior. Also code 3 means charging. Solarbank 1 does not distibuish between charging, surplus charing or charge priority. This is what I coded into the desciption too, based on the other power values when code 3 is active. So you need to carefully watch the solarbank state code, and what is really happening at that time to make a validated translation of the status code. For example, if code 3 is still used when any battery charge applies, it could be used in charge-bypass situations (Surplus-charging) or charge-priority situations (no output to house even if needed), or maybe other constellations that we may differentiate. For reference only, here is defined solarbank 1 charge status:

class SolarbankStatus(Enum):
    """Enumuration for Anker Solix Solarbank status."""

    # TODO(#SB2): Eventually introduce dedicated type for solarbank 2 if it has different states
    detection = "0"
    bypass = "1"
    discharge = "2"
    charge = "3"
    charge_bypass = "35"  # pseudo state, the solarbank does not distinguish this
    charge_priority = "37"  # pseudo state, the solarbank does not distinguish this but reports 3 as seen so far
    wakeup = "4"  # Not clear what happens during this state, but observed short intervals during night as well
    # TODO(3): Add descriptions once status code usage is observed/known
    # code 5 was not observed yet
    full_bypass = "6"  # seen at cold temperature, when battery must not be charged and the Solarbank bypasses all directly to inverter, also solar power < 25 W
    standby = "7"
    unknown = "unknown"

stephan-l commented 5 days ago

Sorry my fault. That was kind of obvious... I'll try to collect the states I experience. Code 6: Bypass at empty battery. Example: Solarbank 10% (discharge limit); Solar input 85W; Solarbank output 85W; Home 160W, Grid 75W

My setup: two panels at 415W each, Solarbank 2 E1600 Pro, 1x extension battery, Smart meter

stephan-l commented 4 days ago

Even with "is_display_data": true there are code 0 responses. During night there is a dedicated message in the app: device is sleeping. Data is currently not available.

stephan-l commented 4 days ago

Additionally also charging in the app translates to "charging_status": "0" in the api. I guess we miss something here.

thomluther commented 4 days ago

Additionally also charging in the app translates to "charging_status": "0" in the api. I guess we miss something here.

Can you confirm that was an Api response that showed valid Power values? Otherwise for invalid responses the status is also 0 instead if the real value, so we cannot trust it.

stephan-l commented 4 days ago

Additionally also charging in the app translates to "charging_status": "0" in the api. I guess we miss something here.

Can you confirm that was an Api response that showed valid Power values? Otherwise for invalid responses the status is also 0 instead if the real value, so we cannot trust it.

Yes according to my knowledge it was a valid response. I made a new dump here: https://github.com/thomluther/anker-solix-api/issues/115#issuecomment-2199932163 You can see power values for solar, totals, home load, charging power etc. Everything comparable to the app display. But status is 0. According to home assistant it sometimes switches to Ladepriorität (sorry no state code available).

May you got a prometheus/Victoria metrics compatible export somewhere? I could dump it in my storage on a regular base. But I didn't got enough time yet to build one on my own.

thomluther commented 4 days ago

Maybe 0 is really kind of detection mode (Solarbank 1 used it very seldom at morning when starting to discover what mode to use). It may refer to the AI mode auto-regulation maybe once sufficient SOC and solar is available. The charge prio means it was code 3, but that can also be valid since it is charge_priority in the morning when SOC is empty to bring is to a min level (or when less than 50W Solar are available)

thomluther commented 1 day ago

"charging_status": "1", => This is Bypass for Solarbank 1 (neither charge nor discharge), looks to be the similar for SB2, but here code 1 (bypass) was also seen while adding discharge power to the solar bypass, a mode that is not supported by Solarbank 1. This should be distinguished with a pseudo code and dedicated description for bypass_discharge

thomluther commented 1 day ago

"charging_status": "7" => Confirmed to be Standby "charging_status": "6" => Seems to be Full Bypass as well, seen in the morning but without valid solar power. To be confirmed That all solar power is bypassed without BMS or battery to be involved "charging_status": "3" => Confirmed that charging is involved. SB1 Pseudo states for charge_bypass does match. Pseudo state for charge_priority may have to be adopted since home demand value may be different for SB2 (Smart meter) "charging_status": "2" => Confirmed to be Discharge only, Bypass + discharge has "charging_status": "1"

thomluther commented 1 day ago

Here is what I implemented now:

    detection = "0"  # Rare for SB1, frequent for SB2 especially in combination with Smartmeter in the morning
    protection_charge = "03"  # For SB2 only when there is charge while output below demand in detection mode
    bypass = "1" # Bypass solar without charge
    bypass_discharge = "12"  # preudo state for SB2 if discharging in bypass mode, not possible for SB1
    discharge = "2"  # only seen if no solar available
    charge = "3"  # normal charge for battery
    charge_bypass = "31"  # pseudo state, the solarbank does not distinguish this
    charge_priority = "37"  # pseudo state, the solarbank does not distinguish this, when no output power exists while preset is ignored
    wakeup = "4"  # Not clear what happens during this state, but observed short intervals during night, probably hourly? resync with the cloud
    # TODO(3): Add descriptions once status code usage is observed/known
    # code 5 was not observed yet
    full_bypass = "6"  # seen at cold temperature, when battery must not be charged and the Solarbank bypasses all directly to inverter, also solar power < 25 W. More often with SB2
    standby = "7"
    unknown = "unknown"

The solarbank_monitor was also updated, allowing now easier working with multiple files to review various export scenarios easily.

thomluther / anker-solix-api

Solarbank 2 status code descriptions #104