Add F3800/BP3800 Equipment when connected to Home Power Panel - Config Example #117
Comments
doublehelix46
changed the title
|
Hi @doublehelix46 |
|
Hi @thomluther - 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. |
|
USA is no valid country code. Any invalid or unknown should default to the EU server, hence no data for your authentication.
I have to double check that, its a new field I had to introduce shortly for Solarbank 2 responses. If you have a send account to share with your system, test the 2nd account in the App. |
|
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: Also your home_page data looks the same |
|
@thomluther Thanks for the quick responses. Here's some insight on my setup and my own observations.
The Power Panel is really only connecting to the MQTT and API servers
AnkerApp.Screen.Record.mov |
|
Hm, seems weird from what I have seen so far for Solarbank systems. 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... |
|
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. |
|
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 Furthermore the bind_devices show that only the Power panel is online to Wifi, but both F3800 are not. 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 |
|
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.
But the Power Panel remains enabled with WiFi... 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. |
|
Hi The site_rules show all supported power site types and supported model types. For type 4 you see: Type 4 seems to be the only site type supporting the power panel and there is not listed any other device model. 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. |
|
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...
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.) |
|
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. |
|
@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 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 |
|
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. POST request always contains the following: "siteID": Numbers below correspond with the attached picture/UI elements "sourceType":
The "cumulative stats" (item 5 below) are sitting in the /charging_energy_service/get_system_running_info endpoint
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! |
That is interesting indeed. Most of the endpoints I found start with power_service, your endpoints I never had on the radar. 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. |
|
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. |
|
I found following endpoints for the charging_service: They do not work on the EU Api server with my account however: 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. |
|
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. |
|
Indeed, another whole set of endpoints you can explore. At least the 'charging_hes_svc/get_device_product_info' is also working for my account, can start looking at the others |
|
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: 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? Hints for exploring:
|
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. |
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
Response provides a link to a file:
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. |
|
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. I believe that will be the endpoints used for the X1 home energy storage system (hes) that was announced for July in Europe: |
|
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 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? |
|
This request and response encryption is done by the app, but can also be used without encryption. |
|
Hi @doublehelix46 , did you still look further into the Api capabilities? In a first step, I would like to enhance the export class with the charging_energy* endpoints as well as the the new hes_svc endpoints. However, the charging_energy endpoints still do not work on EU server, and I assume they are just used for powerpanel systems, which are not supporeted in the EU market. In order to test various queries and see which ones are working as shared account, I would need shared access to a powerpanel system on the COM server. Would it be possible to give me member access to your system, so I can work on system export queries and proper anonymization of the reported data? |
|
Hi @thomluther - |
I registered a new alias with Anker which you can use for the invite: lollygames2@gmail.com |
|
@thomluther - Great, an invite has been sent. I would wait about 2 hours for my solar to activate for the day. |
Great, I accepted and that works, can see the home page of your system in read only mode as usual for shared accounts. But this is sufficient for the time being to start testing some queries against it and see if the power values are somewhere in the cloud and how to extract the energy values that are accessible for shared accounts as well. |
|
Hi @doublehelix46 , some updates on this:
Edit Note:
|
|
Hi @doublehelix46 Here is what I implemented so far which is also visible in the solarbank monitor tool. That is from the live query as member account with anonymized IDs. However, the shared account has limited capabilities and only subset of information that might be possible. I enhanced the daily energy stats in the cached api object to be common with the fields and units as used already for solarbank systems. Additional fields have been added. The app is showing more percentages, however I limit the percentage share only for the home consumption view. The percentages Last but not least, I noticed in the App that there is a diagram for SOC over time and I wonder where this data is coming from. Interestingly there is also power field and I wonder whether there may be a combination of paramters to get the actual power or charge level of the F3800s... |
|
@doublehelix46 The energy stats when used with the "dateType": "day" parameter will provide large lists for the power and chargeLevel fields. |
|
I did nore testing on it and usability is limited for power values. Some caveats:
As a summary, it would be possible to extract some data from the energy stats, but you have to consider it as the last valid data point that you see in the App diagrams. It is delayed by 2-3 minutes, its rounded to kW with 2 decimals and it is averaged by 5 minute intervals. So I'm not sure whether it makes sense to report them as power values, since that could raise more questions than necessary. |
|
Hi @thomluther - I apologize for the delay I've been traveling, but I will absolutely run the extracts and tests with the Owner account. I recall most things being very similar between the Master/Sub accounts... only exception seemed to be more in the setup/device calls. I agree, I had not personally found a way to get the real time stats - I'm fairly confident (and to your earlier comment) that the MQTT server handles the energy stats for the Power Panel. I did a lot of testing with the energy stats. I'll go back to my statements and see if I was able to get down to a specific time interval to reduce the response load. I'll think through the solution further, but for me personally, even having the daily totals of Solar generated, Energy Used (and where - Load vs. Charging Battery) and then the depletion of the battery to plug into the Energy Monitor Dashboard is a huge plus. I happen to have a Sense energy monitor but I lose insight when leveraging the Home Panel to power the load when solar is not being generated. I recognize that's my specific use case - but I will do my best to figure out if there's broader value. Thank you for testing! |
|
I added some code to extract the last 5 min avg values from todays energy stats. It was not as simple as I thought, because I want to limit the queries to once every 5 minutes max (more often does not make sense). On the other hand, I want to query the last average stat once it becomes available in the cloud to avoid the delay is too big. Here is what I get from your system in the monitor: So you see, including energy stats, there will be lots of initial queries, but that should go down to 3-4 per normal refresh after a while. |
|
Hi @thomluther - I'm so sorry for the long delay. Attached is the export from the System Admin as requested. I still need to play around with the energy stats and the payloads to try to limit the data pull. I will do my best to get another update out to you next week. Thank you again for your patience. Best, |
|
Hi @doublehelix46 |
|
Hi @thomluther - I reran the export after your updates. Providing a copy for reference. Thank you again for your support! |
|
Hi @doublehelix46 I think following endpoints may be worth further exploration:
I don't think the charging_hes_svc endpoints are relevant for your power panel system. since many of them fail too in your setup. |
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
The text was updated successfully, but these errors were encountered: