Collection of Solarbank 2 system exports #115
Comments
thomluther
added
help wanted
|
I just packaged two exports and a system description Something I wonder about. Is it possible that the extension battery is not yet visible? The app shows both but in the api there is only 1600 Wh. |
|
Here's my export, I have the same setup as @stephan-l (meaning, one Solarbank 2 E1600Pro, one battery expansion and one smart meter). Let me know if you need more. |
|
I made another export especially for reference in the status thread: |
Thanks for the data. The export looks like being done with the shared account, since many responses have no data. In general, when providing exports to get a full picture of what is possible with the devices, you need to run the export tool with the main account. |
Indeed, I thought it was already useful that way, but for science™, I can do another export using my main Anker account. |
It was visible, but not properly considered for the cap and energy calculation of the battery. This is fixed now, also update the solarbank monitor and export tool based on recent data. |
|
I made a full dump with the owner account. |
|
@stephan-l thanks for the new dump. That looks much more useful. First observations:
|
|
Here is an actual extract of owner data from export in the monitor after I implemented another workaround for a missing field value in scene_info for the smartmeter wireless_type. I assume now this to be 1 if there is only 1 network in the list for the site and smartmeter reports an online wifi state. In that case it must be using the same network (don't want to make assumptions for anything else, since there could also be smartmeters without solarbank in a site). Since both Grid values were 0W, it is difficult to relate them to the new |
|
Grid status for a power outage will be difficult to obtain. the smart meter is powered by the voltage sensing ports. so it will go offline on power loss. any idea what I shall test next week when I am onsite next time? I gave it a new try (full dump: ste202407022222303.zip ) My grid meter was at approx 140W. So input is right. Also the Capacity is broken again. Before todays git pull it was 3200Wh for my setup: Somehow the battery is charged but now output to the home. I need to understand when it is charged by solar power. Today there wasn't any output only charging. |
|
After another try I got the correct capacity again. Kind of confusing. |
|
Over the last ~23 hours I have collected some data every 15min via cron, see attachment. Unfortunately most of them are with "is_display_data"="false". I have attached my interpretation of the values in a screenshot of the Anker app. |
@stephan-l thanks for the many extracts, they help to get a better picture on various situations after sorting out the invalid data extracts. One situation puzzles me however to correlate the values properly: Generated Solar power is 3 W from all, but this is not reflected somehow in any of the other fields. How is the display in the App in the morning with little solar power and empty battery when this full bypass mode is used without charge and discharge? Is the solar power reflected somewhere else in the figures going to home? |
|
@stephan-l Following is another weird situation making it difficult to correlate the values accurately. It appears the individual fields are not used consistently (same as with Solarbank 1), which makes it pretty difficult to extract them properly for correct monitoring. I built some work arounds for such fields, where e.g. the SB totals do not match the usage of individual solarbank device fields, or the wrong device charging power field. But I'm reluctant to break anything with those workarounds for anything that does not match with Solarbank 2 reporting. For example the Api reports for devices in scene_info response: |
This might be related to the capacity and energy calculation. If the initial response is invalid, the battery packs are 0 too, Maybe the calculations are not refreshed properly afterwards. The code also needs to make sure, that re-calculation is not done when the response contains invalid data, so it must cover both special cases:
|
|
I think I will do some measurements onsite next week to verify the theses. I can monitore questionable values and test different scenarios then. |
|
Can someone explain this situation? |
|
Here is another interesting example, showing kind of charge_priority in the morning even if in detection mode, since SOC is just at 7%. I don't think this should get a different pseudo state since it is charging code 0, and all kind of charging states typically have 3. Still thinking about it. Maybe it might be useful to have historical visibility when and how long home demand was partially ignored due to enforced charging. But this pseudo state for code 0 (detection_charge ? or enforced_charge ?) will be used only for code 0 under specific conditions: Charge > 0 and output < demand, because typically when output < demand, there should never be charge unless enforced by BMS |
T2 is my system. That was a situation I couldn’t explain either. It got deflated to 10% the night before and there was low solar power during day. So it charged until next day when solar power was bigger than house demand. |
|
OK, so just a firmware flaw, nothing to be considered for the field interpretation. |
|
I updated the api with new charging states and the monitor accordingly. #104 However, someone needs to confirm with the monitor whether the smartmeter values are valid when the SB data is invalid. Right now I consider them invalid too, but they are 0W most of the time also with valid SB data, so it is difficult to recognise that in a snapshot. |
|
Some notes to make here to the new SB2 related power fields:
|
Please provide your solarbank 2 system export examples here.
You can extract all data with the system_export tool and zip the output files.
You can add a text file to the zip containing info about some specifics when the export was taken, for example the components of your setup.
Before you provide an export, make sure that the solarbank_info structure in api_sites.json does show:
"is_display_data": true,and not
"is_display_data": false,The power values in the site scene_info response are wrong when is_display_data is false. This field seems to be an indicator to the app to skip the display of the response and delay home screen update until next refresh.
The reason and work around for this problem is not understood yet and is to be documented in issue #114
The text was updated successfully, but these errors were encountered: