thomluther / anker-solix-api

Python library for Anker Solix API
MIT License
74 stars 15 forks source link

Add F3800/BP3800 Equipment when connected to Home Power Panel - Config Example #117

Open doublehelix46 opened 3 months ago

doublehelix46 commented 3 months ago

Hello -

Attached is a system export of two F3800's (with two attached BP3800 expansion batteries) connected to an Anker Home Power Panel in the USA. I ran several exports with the API tools (with the owner account) and each time I received minimal output. I don't believe the existing API work to date accounts for this equipment - but figured I'd shared the output if it may aid in future development. I am more than happy to provide further logs in the future.

F3800 System Export.zip

thomluther commented 3 months ago

Hi @doublehelix46 your output is not even showing any sites listed for your account. Since you are the first one with US country code, I assume the server assignment of the Api library may be incorrect. US is being assumed for account location on the *.com api server. You may try the export again but using an EU country code, e.g. DE. This should assign your login to the EU server and show if your account is located there as well (like all the others so far) From what I have seen in the App code, there are only 2 Cloud servers ww in use. If you access any kind of Beta Server (Beta App), that will be also different and not accessible via the Api library since its an unknown server...

doublehelix46 commented 3 months ago

Hi @thomluther - I believe that issue was on me. I originally had trouble using the "US" code and tried "USA" and started receiving some outputs. I cleared the auth cache and went back to "US" and received much more detail. FYI the DE server did not work for me - not sure if my account is bound or, similarly, would have required an authcache clearing to correct itself.

I ran this a few times but I'm still getting "data_valid": false, in api_sites - as such, all my energy values are 0'd out. I will say this has been my experience with the HACS integration in a 24 hour period as well, so I'm making the assumption these devices are not yet supported.

More than happy to run additional outputs. If I get a sample that is set to true, I will upload.

US2.zip

thomluther commented 3 months ago

USA is no valid country code. Any invalid or unknown should default to the EU server, hence no data for your authentication. While the username is not changed, the cached login response will be used and the entered password and ccountry code will be ignored. So to enforce re-authentication you have to clean the Api auth-cache file for your username.

I ran this a few times but I'm still getting "data_valid": false, in api_sites - as such, all my energy values are 0'd out. I will say this has been my experience with the HACS integration in a 24 hour period as well, so I'm making the assumption these devices are not yet supported.

I have to double check that, its a new field I had to introduce shortly for Solarbank 2 responses. However, this does nothing with the returned data from the cloud. They are all saved in the Api cache as is, just marked as invalid eventually. So if you get 0 values, that is what the cloud responds on your request. May be a common new issue as introduced with Solarbank 2, see #114

If you have a send account to share with your system, test the 2nd account in the App. If that should the same 0 values (or empty) and only shows valid numbers about every 5 minutes, you need to address this to Anker support, that shared accounts cannot longer see valid data on the system home page.

thomluther commented 3 months ago

Actually there are no power data fields in your power panel structures when you look at scene info, and the common power fields of the system are not showing real data:

    "retain_load": "0W",
    "scene_mode": 0,
    "home_load_power": "0",
    "updated_time": "01-01-0001 00:00:00",
    "power_site_type": 4,
    "site_id": "d9db3ea0-d48c-ecf8-57df-9ad78ec60ebf",
    "powerpanel_list": [
      {
        "device_pn": "A17B1",
        "device_sn": "PM6T2AS3Z62D3GEG",
        "device_name": "SOLIX Home Power Panel",
        "device_img": "https://public-aiot-ohi-prod.s3.dualstack.us-east-2.amazonaws.com/anker-power/public/product/2024/01/23/iot-admin/Qcjo9ALaRqFzFNeF/picl_A17B1_normal.png",
        "create_time": 1719792264,
        "bind_site_status": "",
        "status": "1",
        "wireless_type": "1",
        "initial_process": 0
      }
    ],

Also your home_page data looks the same So I wonder where the App gets the power values from, but it does not seem to get them from the cloud Api. Since the cloud does not receive power values, it would explain why all your energy statisitcs are also empty. Do you see statistics data in the App? Have you connected all your devices to Wifi? Otherwise they cannot send data to the cloud.

doublehelix46 commented 3 months ago

@thomluther Thanks for the quick responses. Here's some insight on my setup and my own observations.

1) I had a delay in having the Home Power Panel installed - so I had setup both of the F3800's on wifi as two individual devices. However, they have since (and are currently) been connected to a Power Panel and I was able to create a home in the Anker App.

IMG_4077

2) Once connected to the Power Panel, the F3800s no longer connect to wifi (or make any standalone calls via the internet from what I can see in my network monitoring.) Additionally the solar bank monitor suggests they are offline as well. Solarbank Monitor

The Power Panel is really only connecting to the MQTT and API servers IMG_4076

3) I can see what appears to be live stats in the app (even remotely away from my home network.) I've attached a screen recording as well to step through the various tabs on the Home Screen. Just a quick note - I switched my app to a shared account so I could monitor while generating the previous outputs. (sorry for the low res I needed to adjust for file size.)

https://github.com/thomluther/anker-solix-api/assets/69429590/e52c0401-5142-4ee7-bce9-479ee26463cd

thomluther commented 3 months ago

Hm, seems weird from what I have seen so far for Solarbank systems. There all power values are provided in the Solarbank structure of the scene_info or homepage response. For Power Panels that doesn't seem to be the case, rathermore the home page is already triggering device updates via MQTT servers and maybe the usage values are merged from that api into the home screen? In other words the cloud api only knows the system structure and devices, but no consumption values, therefore the energy_statistic queries are also empty.

I can try to add as much as possible from the provided Api fields, but that will be pretty much useless in HA in the long term if we do not get power values via the cloud Api... You can check the scene Info output and the device_bind output showing most of the data. Other common data might be usable via HA (Site price and unit, Reserved power setting, etc). So not too much and nothing useful to monitor closely or keep as history

doublehelix46 commented 3 months ago

Understood - and I appreciate your willingness to work with what you have. I'm going to spend some time this afternoon seeing if I can snoop on some api calls from an android device to see if I notice new endpoints or differing structures from the Solarbank with respect to the Power Panel. If I find anything that appears to be remotely useful, I'll update the issue.

thomluther commented 3 months ago

When I look at your homepage structure, it seems your PPS (F3800) devices are not really added / joined to the system since the pps list is empty. That means the cloud does not consider them belonging to the site

  "data": {
    "site_list": [
      {
        "site_id": "d9db3ea0-d48c-ecf8-57df-9ad78ec60ebf",
        "site_name": "My Home",
        "site_img": "",
        "device_type_list": [
          5
        ],
        "ms_type": 0,
        "power_site_type": 0,
        "is_allow_delete": false,
        "support_device_models": null,
        "current_site_device_models": null
      }
    ],
    "solar_list": [],
    "pps_list": [],
    "solarbank_list": [],
    "powerpanel_list": [
      {
        "device_pn": "",
        "device_sn": "PM6T2AS3Z62D3GEG",
        "device_name": "SOLIX Home Power Panel",
        "device_img": "https://public-aiot-ohi-prod.s3.dualstack.us-east-2.amazonaws.com/anker-power/public/product/2024/01/23/iot-admin/Qcjo9ALaRqFzFNeF/picl_A17B1_normal.png",
        "create_time": 0,
        "bind_site_status": "",
        "status": "",
        "wireless_type": "",
        "initial_process": 0
      }
    ]
  },

Furthermore the bind_devices show that only the Power panel is online to Wifi, but both F3800 are not. On top, the wifi list output does not show any Wifi network, which is weird since the power panel is online to wifi. Then the wifi list output typically shows at least one wifi network with signal strength.

I guess there is something weird in your system setup. Maybe you have to delete that completely in the app, make sure that all then standalone devices are connected to Wifi and then recreate a new system and add all device again.

But that typically will scratch all your energy history data that is recorded with the system. However in your case that was empty as well, so maybe it does not hurt to recreate the system from scratch and see if it gets better

doublehelix46 commented 2 months ago

Hi @thomluther - I apologize for the delay (I was away for the US Holiday.)

I completely erased my Home; created a new Anker Account; first setup each F3800 on wifi as individual devices (and bound them to the new account); added the Home Power Panel to the new account/wifi > created the new home with the existing F3800.

However, based on the export, looks like there's no difference in the system export.

You'll notice in the below screenshot, that Anker's App disable's the wifi in F3800 devices when linked to a Power Panel.

image

But the Power Panel remains enabled with WiFi... F3800 Wifi Disabled

I can see all the devices listed in the Site_Detail.json, but you're right... the remaining scripts don't return the connected devices. It appears they're routing all data and management through the Home Power Panel.

US Server Refreshed.zip

thomluther commented 2 months ago

Hi It seems that's the way it is implemented. Your site_list shows type 4 and the 'known' model types, which is only the Power panel

        "device_type_list": [
          5
        ],
        "ms_type": 1,
        "power_site_type": 4,
        "is_allow_delete": true,
        "support_device_models": [
          "A17B1"
        ],
        "current_site_device_models": [
          "A17B1"
        ]

The site_rules show all supported power site types and supported model types. For type 4 you see:

      {
        "power_site_type": 4,
        "main_device_models": [
          "A17B1"
        ],
        "device_models": [
          "A17B1"
        ],
        "can_empty_site": true,
        "quantity_min_limit_map": null,
        "quantity_max_limit_map": {
          "A17B1": 1
        }
      },

Type 4 seems to be the only site type supporting the power panel and there is not listed any other device model. This is differently for other site types. So I'm afraid there is no support for getting the PPS device infos in a power panel site type. Furthermore the power panel iteself does not provide any usage values in the scene_info response, so there is nothing that can be usefully extracted for HA. All data what you see in the app home screen must be merged it with the data pulled in realtime from the MQTT server, which just receives data when the App is open and triggers the devices to send their data to the MQTT server in realtime. Eventually there are default sporadic data updates every 5 minutes or so like it is done now for Solarbank 2 systems. But key is that frequent data transmission is triggered only by main account watching the system. Nothing that the cloud Api can do in general.

Edit: The F3800 model type A1790 does not seem to be supported in any power site type (like other PPS models are not supported in a power system). So it won't be possible to have them providing usage data to the api cloud I guess. I just wonder why the scene info structure seem to support PPS details, but are not used...

doublehelix46 commented 2 months ago

Ahh that is unfortunate news, but I realize that's not your doing. I greatly appreciate you reviewing the issue as in-depth as you could. I hope this isn't the direction Anker takes moving forward.

Some additional notes that may be helpful in the future...

1) Yes, it seems the MQTT server is where the Power Panel is getting the bulk of the data via downloads (very minimal uploads).

image

2) What is interesting though, and I don't want to say exactly counter to your theory above, is that it is regularly transmitting data to the MQTT server without the App. It's making calls for the server on a schedule which looks like every 30 minutes (and that's without the app open.) Each out reach looks the same, about 770kb uploaded... until the morning hours (once solar starts generating.) Now I'm seeing uploads greater than 1.5MB, which alludes that there are more energy stats in the upload as all of the overnight stats were very consistent. (Just a note, at this point, I haven't opened the app for the day - so this change was not prompted by app usage.)

image

3) I had been logged in with a sub account on my phone opposed to the owner account to avoid any issues while running the APIs, the sub account in the app gets all details, except for the PPS temp and system settings. This is true, even when I'm away from home not on my network. I was showing some friends and family the system and could show the real time stats in the sub account while not on the same network.

4) I just opened my app at 7:38am to see if it would make a call, and it did despite having just recently uploaded data in its cycle. It was slightly larger than the last upload, but nothing dramatically different.

I wish you luck in your further developments - if you happen to stumble across anything PPS or Powerwall related, feel free to reach out any time. I'll do the same... off to explore MQTT now, haha (though I saw it wasn't fruitful in your past experience.)

thomluther commented 2 months ago

Thx for the update. Yeah, MQTT is nothing I start with. The problem is that you will have to do reverse engineering how the data inside the requests are encryted with the EDHC mechanism. The api supports this data encryption too and its used via the app, the the api library does not use it currently for request data, only for the authentiation requests. Its not clear how the request data header fields must be created to use enable encryption for requests. I assume same way it may be used for the MQTT api and you will have to find a way how to decrypt the data. See #71 and #70 if you want to start with that journey. If you get behind the required header fields for encryption and their content creation just let me know.

doublehelix46 commented 2 months ago

@thomluther - I might be delusional at this point, but I think I found the endpoint the PPS/Powerwall is using for energy statistics (and I don't think you're currently leveraging it) - at least for the US Server

https://ankerpower-api.anker.com/charging_energy_service/energy_statistics

request.txt response.txt

Likewise there's a few others, but I haven't seen anything useful with them yet...

https://ankerpower-api.anker.com/charging_energy_service/report_device_data https://ankerpower-api.anker.com/charging_energy_service/get_system_running_info https://ankerpower-api.anker.com/charging_energy_service/get_installation_inspection https://ankerpower-api.anker.com/charging_energy_service/get_rom_versions

doublehelix46 commented 2 months ago

Seems to be slightly different logic implemented in this endpoint compared to the Solarbanks... I believe our theory that everything is running through the Power Wall is correct.

/charging_energy_service/energy_statistics = building the "Home Page" in the app. IMG_0EF5F4600614-1

POST request always contains the following:

"siteID": "end": (notes within dateType on when/how used) "start": (notes within dateType on when used) "global": false (so far I've only seen this set to false - not sure how it's used.) "productCode": (so far I've only seen this null - not sure how it's used.)

Numbers below correspond with the attached picture/UI elements "dateType":

  1. day (end: ""; start "yyyy-mm-dd")
  2. week (end: "yyyy-mm-dd"; start: "yyyy-mm-dd") - runs Monday thru Sunday (not sure if that's required yet)
  3. month (end: ""; start "yyyy-mm")
  4. year (end: ""; start: "yyyy")

"sourceType":

  1. solar
  2. home
  3. hes (this is the "home energy system")
  4. grid

The "cumulative stats" (item 5 below) are sitting in the /charging_energy_service/get_system_running_info endpoint

IMG_4112

The POST request only sends "siteId"

I will try and get some samples tomorrow of Request/Response for each page. I'd like to capture as much Solar/Battery/Grid behavior as possible in the responses.

I hope this helps!

thomluther commented 2 months ago

@thomluther - I might be delusional at this point, but I think I found the endpoint the PPS/Powerwall is using for energy statistics (and I don't think you're currently leveraging it) - at least for the US Server

https://ankerpower-api.anker.com/charging_energy_service/energy_statistics

request.txt response.txt

Likewise there's a few others, but I haven't seen anything useful with them yet...

https://ankerpower-api.anker.com/charging_energy_service/report_device_data https://ankerpower-api.anker.com/charging_energy_service/get_system_running_info https://ankerpower-api.anker.com/charging_energy_service/get_installation_inspection https://ankerpower-api.anker.com/charging_energy_service/get_rom_versions

That is interesting indeed. Most of the endpoints I found start with power_service, your endpoints I never had on the radar. Yes, the more examples you can provide, the easier an implementation can be. Maybe those are used in general for any PPS related device and the PPS structure in the power_service requests are just artifacts but never filled there...

In a first step it will be good to know all these endpoints and with which parameters they can be used. Then I can integrate them into the system_export tool in a first step to get a full snapshot of actual system data. From that point on, the meaning of the fields must be understood and described to use the properly for enhancing the Api cache structures and avoid clashes with existing fields.

Basically the power stats from the home screen should be different endpoint than the energy stats. Energy stats are more difficult to implement, since you need to run multiple queries to get all type of stats. Furthermore some data are only returned in the total of the queries time span, so to have those values on a daily base as used by HA, I need to query some types twice for today and yesterday to get all values for actual and past day.

doublehelix46 commented 2 months ago

Well, from what I can tell (and I think you mentioned this in another issue,) the real-time energy stats/display within the app are on the mqtt server and are merged into the daily energy stats every 5 mins to the cloud api.

I attempted a MitM to monitor the data flows. When I included the MQTT port, not only did I fail to capture the data, but the real-time stats were effectively frozen until I removed the port from monitoring. Instantly the real-time stats loaded.

I think I found one or two more endpoints but need to double check your working list to be sure. I will update with examples as soon as possible.

thomluther commented 2 months ago

I found following endpoints for the charging_service:

PPS and Power Panel related:
    "charging_energy_service/energy_statistics",  # Energy stats for PPS and Home Panel
    "charging_energy_service/get_system_running_info",
    "charging_energy_service/get_device_infos",
    "charging_energy_service/get_rom_versions",
    "charging_energy_service/get_error_infos",
    "charging_energy_service/get_wifi_info",
    "charging_energy_service/get_installation_inspection",
    "charging_energy_service/sync_installation_inspection",
    "charging_energy_service/get_utility_rate_plan",
    "charging_energy_service/report_device_data",
    "charging_energy_service/restart_peak_session",
    "charging_energy_service/preprocess_utility_rate_plan",
    "charging_energy_service/ack_utility_rate_plan",
    "charging_energy_service/get_configs",
    "charging_energy_service/adjust_station_price_unit",
    "charging_energy_service/sync_config",
    "charging_energy_service/get_sns",
    "charging_energy_service/get_world_monetary_unit",

They do not work on the EU Api server with my account however: Api Request Error: 503, message='Service Temporarily Unavailable' The power_service endpoints work there...weird. Maybe the servers have different versions of the Api, otherwise I would have expected another type of response error.

You will have to explore them manually and figure out required parameter and response structures. Anything that is meaningful and working could I then add in the system_Export tool for the beginning.

doublehelix46 commented 2 months ago

Hi @thomluther -

I'm still testing calls and compiling the results... but out of curiosity... do you see any additional endpoints within: /charging_hes_svc/ ?

I've found /charging_hes_svc/get_device_product_info - but it appears to just be a list of Anker products (ironically none in the US.

thomluther commented 2 months ago

Indeed, another whole set of endpoints you can explore.

    "charging_hes_svc/ota",
    "charging_hes_svc/check_update",
    "charging_hes_svc/get_installer_info",
    "charging_hes_svc/download_energy_statistics",
    "charging_hes_svc/get_wifi_info",
    "charging_hes_svc/update_wifi_config",
    "charging_hes_svc/get_device_product_info",
    "charging_hes_svc/report_device_data",
    "charging_hes_svc/get_auto_disaster_prepare_status",
    "charging_hes_svc/get_install_info",
    "charging_hes_svc/get_device_pn_info",
    "charging_hes_svc/get_device_card_list",
    "charging_hes_svc/get_device_card_details",
    "charging_hes_svc/get_system_running_time",
    "charging_hes_svc/get_system_profit_detail",
    "charging_hes_svc/get_tou_price_plan_detail",
    "charging_hes_svc/get_electric_utility_and_electric_plan_list",
    "charging_hes_svc/get_station_config_and_status",
    "charging_hes_svc/get_current_disaster_prepare_details",
    "charging_hes_svc/adjust_station_price_unit",
    "charging_hes_svc/update_hes_utility_rate_plan",
    "charging_hes_svc/quit_auto_disaster_prepare",
    "charging_hes_svc/restart_peak_session",
    "charging_hes_svc/check_function",
    "charging_hes_svc/remove_user_fault_info",
    "charging_hes_svc/user_event_alarm",
    "charging_hes_svc/sync_back_up_history",
    "charging_hes_svc/cancel_pop",

At least the 'charging_hes_svc/get_device_product_info' is also working for my account, can start looking at the others

thomluther commented 2 months ago

Examples that work for my account but not with my devices. I also just tried with shared account that has no permission to devices, therefore I may see many permission errors:

await myapi.request("post", "charging_hes_svc/report_device_data",json={"siteIds":[siteId]}))
(200104) Anker Api Error: The installer system does not exist

await myapi.request("post", "charging_hes_svc/get_installer_info",json={"siteIds":[siteId]}))
(160003) Anker Api Error: The device has no access permission.

await myapi.request("post", "charging_hes_svc/get_wifi_info",json={"sn":deviceSn}))
  "data": {
    "ssid": "",
    "rssi": 100
  },

await myapi.request("post", "charging_hes_svc/get_install_info",json={"siteId":siteId}))
  "data": {
    "installLocation": "",
    "installEnv": ""
  },

await myapi.request("post", "charging_hes_svc/get_tou_price_plan_detail",json={"template_id": 1, "template_name": "", "customer_segment_type": 1}))
  "data": {
    "peak_sessions": null
  },

await myapi.request("post", "charging_hes_svc/get_install_info",json={"siteId":siteId}))
  "data": {
    "installLocation": "",
    "installEnv": ""
  },

await myapi.request("post", "charging_hes_svc/get_installer_info",json={"siteIds":[siteId], "siteId": siteId}))
  "data": {
    "companyName": "",
    "address": "",
    "contactEmail": "",
    "contactPhone": ""
  },

So indeed the /charging_service endpoints do not seem to be implemented yet on the EU api cloud server. Maybe just a matter of time, depending on what they are supposed to support? I assume the functional /charging_hes_svc endpoints may be used for the power panels, which are also announced for the European market.

Hints for exploring:

doublehelix46 commented 2 months ago

I found following endpoints for the charging_service:

PPS and Power Panel related:
    "charging_energy_service/energy_statistics",  # Energy stats for PPS and Home Panel
    "charging_energy_service/get_system_running_info",
    "charging_energy_service/get_device_infos",
    "charging_energy_service/get_rom_versions",
    "charging_energy_service/get_error_infos",
    "charging_energy_service/get_wifi_info",
    "charging_energy_service/get_installation_inspection",
    "charging_energy_service/sync_installation_inspection",
    "charging_energy_service/get_utility_rate_plan",
    "charging_energy_service/report_device_data",
    "charging_energy_service/restart_peak_session",
    "charging_energy_service/preprocess_utility_rate_plan",
    "charging_energy_service/ack_utility_rate_plan",
    "charging_energy_service/get_configs",
    "charging_energy_service/adjust_station_price_unit",
    "charging_energy_service/sync_config",
    "charging_energy_service/get_sns",
    "charging_energy_service/get_world_monetary_unit",

They do not work on the EU Api server with my account however: Api Request Error: 503, message='Service Temporarily Unavailable' The power_service endpoints work there...weird. Maybe the servers have different versions of the Api, otherwise I would have expected another type of response error.

You will have to explore them manually and figure out required parameter and response structures. Anything that is meaningful and working could I then add in the system_Export tool for the beginning.

My initial pass at the charging_energy_service endpoints. I think there's a lot of overlap between these and the new ones, but I'll continue exploring and expanding.

PPS and Power Panel related:
    "charging_energy_service/energy_statistics",  # Energy stats for PPS and Home Panel
    "charging_energy_service/get_system_running_info", # Cumulative Home/System Energy Savings since Home creation date
    "charging_energy_service/get_device_infos", # Home Panel Info
    "charging_energy_service/get_rom_versions”, # Check for firmware update and download available packages
    "charging_energy_service/get_error_infos", # Unknown at this time
    "charging_energy_service/get_wifi_info", # Displays WiFi network connected to Home Power Panel
    "charging_energy_service/get_installation_inspection", # Unknown at this time - appears to say which page last viewed on App
    "charging_energy_service/sync_installation_inspection", #Unknown at this time
    "charging_energy_service/get_utility_rate_plan",
    "charging_energy_service/report_device_data",
    "charging_energy_service/restart_peak_session",
    "charging_energy_service/preprocess_utility_rate_plan",
    "charging_energy_service/ack_utility_rate_plan",
    "charging_energy_service/get_configs",
    "charging_energy_service/adjust_station_price_unit",
    "charging_energy_service/sync_config",
    "charging_energy_service/get_sns", # Displays Serial Numbers of attached PPS in Home
    "charging_energy_service/get_world_monetary_unit",

# /charging_energy_service/get_system_running_info Request 

{
    "siteId": "932a71aa-i1b3-4f0c-a232-nj9023c02bab"
}

# /charging_energy_service/get_system_running_info Response

{
    "code": 0,
    "msg": "success!",
    "data": {
        "connect_infos": {
            "PowerPanelSN": true
        },
        "connected": true,
        "total_system_savings": 0,
        "system_savings_price_unit": "$",
        "save_carbon_footprint": 52.18,
        "save_carbon_unit": "kg",
        "save_carbon_c": 0.997,
        "total_system_power_generation": 52.34,
        "system_power_generation_unit": "KWh"
    },
    "trace_id": “redacted”
}

# /charging_energy_service/get_sns Request

{
    "main_sn": "PowerPanelSN",
    "macs": [
        "F38001MAC001",
        "F38002MAC002"
    ]
}

# /charging_energy_service/get_sns Response

{
    "code": 0,
    "msg": "success!",
    "data": {
        "mac_sn_map": {
            "F38002MAC002": "F38002SN",
            "F38001MAC001": "F38001SN"
        }
    },
    "trace_id": “redacted”
}

# /charging_energy_service/get_configs Request

{
    "siteId": "932a71aa-i1b3-4f0c-a232-nj9023c02bab",
    "sn": "PowerPanelSN",
    "param_types": []
}

# /charging_energy_service/get_configs Response

{
    "code": 0,
    "msg": "success!",
    "data": {
        "configs": []
    },
    "trace_id": “redacted”
}

# /charging_energy_service/report_device_data Request

{
    "siteIds": [
        "932a71aa-i1b3-4f0c-a232-nj9023c02bab"
    ],
    "ctrol": 1,
    "duration": 300
}

# /charging_energy_service/report_device_data Response
{
    "code": 0,
    "msg": "success!",
    "data": null,
    "trace_id": “redacted”
}

# /charging_energy_service/get_installation_inspection Request

{
    "sn": "PowerPanelSN"
}

# /charging_energy_service/get_installation_inspection Response
{
    "code": 0,
    "msg": "success!",
    "data": {
        "latest_result": true,
        "latest_time": 1720387249,
        "latest_page": "/electricityScene",
        "need_self_inspection": false
    },
    "trace_id": “redacted”
}

# /charging_energy_service/get_wifi_info Request

{
    "siteId": "932a71aa-i1b3-4f0c-a232-nj9023c02bab",
    "sn": "PowerPanelSN"
}

# /charging_energy_service/get_wifi_info Response

{
    "code": 0,
    "msg": "success!",
    "data": {
        "ssid": “My WiFi Network Name”,
        "rssi": 100
    },
    "trace_id": “redacted”
}

# /charging_energy_service/get_device_infos Request

{
    "siteId": "932a71aa-i1b3-4f0c-a232-nj9023c02bab",
    "sns": [
        "PowerPanelSN",
        "F38001SN",
        "F38002SN"
    ]
}

# /charging_energy_service/get_device_infos Response

{
    "code": 0,
    "msg": "success!",
    "data": {
        "device_infos": [
            {
                "sn": "PowerPanelSN",
                "device_type": "A17B1",
                "ble_bind_type": 2,
                "ble_mac": “POWERPANELMA”,
                "wifi_bind_type": 2,
                "connect": false
            },
            {
                "sn": "F38001SN",
                "device_type": "A1790",
                "ble_bind_type": 2,
                "ble_mac": "F38001MAC001",
                "wifi_bind_type": 2,
                "connect": false
            },
            {
                "sn": "F38002SN",
                "device_type": "A1790",
                "ble_bind_type": 2,
                "ble_mac": "F38002MAC002",
                "wifi_bind_type": 2,
                "connect": false
            }
        ]
    },
    "trace_id": “redacted”
}

# /charging_energy_service/get_device_infos Request

{
    "main_sn": "PowerPanelSN",
    "device_rom_versions": [
        {
            "sn": "PowerPanelSN",
            "sub_version_infos": [],
            "type": "A17B1",
            "device_mac": "POWERPANELMA",
            "version": "v1.2.9"
        },
        {
            "sn": "F38002SN",
            "sub_version_infos": [
                {
                    "sn": “BP3800-2SN”,
                    "type": "A1790_15Ah",
                    "version": "v3.6.0"
                }
            ],
            "type": "A1790",
            "device_mac": "F38002MAC002",
            "version": "v2.0.9"
        },
        {
            "sn": "F38001SN",
            "sub_version_infos": [
                {
                    "sn": "BP3800-1SN",
                    "type": "A1790_15Ah",
                    "version": "v3.6.0"
                }
            ],
            "type": "A1790",
            "device_mac": "F38001MAC001",
            "version": "v2.0.9"
        }
    ]
}

# /charging_energy_service/get_device_infos Response

{
    "code": 0,
    "msg": "success!",
    "data": {
        "packages": [
            {
                "sn": "F38002SN",
                "pn": "A1790_low",
                "version": "v2.0.9",
                "is_forced": false,
                "md5": "666abf2e78252965058ba51ed4e9dea0",
                "url": "https://public-aiot-ohi-prod.s3.dualstack.us-east-2.amazonaws.com/anker-power/public/ota/2024/06/03/iot-admin/gS4zfLxxnqeiko5v/A1790_AllPackets_V2.0.9_LowVoltage_20240530.bin",
                "size": 783360,
                "need_Update": false,
                "introduction": "1. New supported devices: Double Power Hub\n2. Functions Optimized."
            },
            {
                "sn": "F38001SN",
                "pn": "A1790_low",
                "version": "v2.0.9",
                "is_forced": false,
                "md5": "666abf2e78252965058ba51ed4e9dea0",
                "url": "https://public-aiot-ohi-prod.s3.dualstack.us-east-2.amazonaws.com/anker-power/public/ota/2024/06/03/iot-admin/gS4zfLxxnqeiko5v/A1790_AllPackets_V2.0.9_LowVoltage_20240530.bin",
                "size": 783360,
                "need_Update": false,
                "introduction": "1. New supported devices: Double Power Hub\n2. Functions Optimized."
            }
        ],
        "sub_packages": [
            {
                "parent_sn": "F38002SN",
                "needUpdate": false,
                "device_type": "A1790_15Ah",
                "rom_version_name": "v3.6.0",
                "force_upgrade": false,
                "file_path": "https://public-aiot-ohi-prod.s3.dualstack.us-east-2.amazonaws.com/anker-power/public/ota/2024/06/03/iot-admin/hlLNpKZpkAwmFOlP/A1790_AllPackets_V3.6.0_LowVoltage_20240530.bin",
                "file_size": 783360,
                "file_md5": "666abf2e78252965058ba51ed4e9dea0",
                "change_log": "1. Fixed a bug. \n2. Optimized some functions.",
                "introduction": "1. Fixed a bug. \n2. Optimized some functions."
            },
            {
                "parent_sn": "F38001SN",
                "needUpdate": false,
                "device_type": "A1790_15Ah",
                "rom_version_name": "v3.6.0",
                "force_upgrade": false,
                "file_path": "https://public-aiot-ohi-prod.s3.dualstack.us-east-2.amazonaws.com/anker-power/public/ota/2024/06/03/iot-admin/hlLNpKZpkAwmFOlP/A1790_AllPackets_V3.6.0_LowVoltage_20240530.bin",
                "file_size": 783360,
                "file_md5": "666abf2e78252965058ba51ed4e9dea0",
                "change_log": "1. Fixed a bug. \n2. Optimized some functions.",
                "introduction": "1. Fixed a bug. \n2. Optimized some functions."
            }
        ]
    },
    "trace_id": “redacted”
}

# /charging_energy_service/get_error_infos Request

{

}

# /charging_energy_service/get_error_infos Response

{
    "code": 0,
    "msg": "success!",
    "data": {
        "error_infos": []
    },
    "trace_id": “redacted”
}
doublehelix46 commented 2 months ago

charging_hes_svc/get_device_card_details

This service appears to be used for the X1 series. The bulk of these APIs I don't have access to or return empty responses as you experienced.

Few exceptions:

charging_hes_svc/download_energy_statistics # Creates a CSV file export of all energy stats for selected time period

{ "siteId": "932a71aa-i1b3-4f0c-a232-nj9023c02bab", "end": "", "start": "2024-07-09", "global": false, "productCode": "", "dateType": "day", "sourceType": "solar" }

Response provides a link to a file:

{ "code": 0, "msg": "success!", "data": { "fileUrl": "https://edge-aiot-ohi-prod.s3.dualstack.us-east-2.amazonaws.com/anker_power/edge/station_statistics_data/truncated", "fileName": "Energy Data.csv" }, "trace_id": "redacted" }

charging_hes_svc/get_wifi_info works exactly the same as charging_energy_service/get_wifi_info;

the charging_hes_svc introduces a new key on "station_id" opposed to "siteId" (though I will tell you the formatting has been inconsistent across the endpoints (stationId, station_id, stationID)

I dought I'll find much more in these services, but will loop back to the charging_energy_service and report back anything useful.

thomluther commented 2 months ago

Yes, It appears the hes endpoints are for managed power services (home energy services?), since they can address multiple sites in the siteIds parameter. End consumer probably should use the charging_power endpoints. It might be a way for external services to look end customer site data and modify them if they are listed as installer for the site...

I believe that will be the endpoints used for the X1 home energy storage system (hes) that was announced for July in Europe: https://www.anker.com/eu-de/anker-solix/x1-energy-storage-system-hes

doublehelix46 commented 2 months ago

I've continued to monitor some activity in the app and documenting the params - I'll have some updates in the near future...

However I've noticed the /power_service/v1/site/get_scen_info endpoint is in fact still being used for the PowerPanel setup, but it is an encrypted body request/response.

The only thing I'm able to determine so far is that the requests all start with an epoch timestamp that has been base64encoded. The rest of the request is encrypted using other methods I have yet to determine.

I think you've mentioned this method in your review of the mqtt ... have you seen this in any of your endpoints?

thomluther commented 2 months ago

This request and response encryption is done by the app, but can also be used without encryption. The login response uses ECDH encryption and this method is probably also used for the request data encryption, but there are additional header fields used in that case and I have not clue how they are generated, see #70 Since you don't know the shared secret of the App connection, you can't either decrypt the header fields / contents...so its all guess work.