Combination of Solarbank S1 (twice) and S2 Pro - does not provide correct Data #181
Comments
|
Now the app is also halfening everything, seems to be a Problem @ Anker |
|
View above |
|
@RamsukKockoi |
thomluther
added
bug
|
Hi, it really seems to be an Anker Problem. I have opened a ticket there. With sun, the S1 (both) provide 50Watts to the S2. So it seems that the S2 Calculates "50 + Sun + Sun + 50 " (they are connected, as in the Anker Scheme). If now the S1 (both) are loading and providing the 100Watts, Anker forgetts to calculate the Charging to the Solar Power. Let us wait what Anker says to that issue. |
So it means, you cannot set any S1 schedule anymore in the App? Does that mean, they have a fixed setting of 50W each for the output? If so, would a single S1 in the system default to 100 W output fixed?
It depends how the S1 power is considered in relation to what is shown in the coupled system homepage and the charts. Lets hope Anker will improve this, but this would be a complex change since additional fields must be added to the cloud services as well as to the App I guess. So far, all energy stats (App charts) are based on a system only, and this does not distinguish energy types on a device level. Also the S2 PV data (power and energy) do not distinguish whether it comes from a solar panel or from a cascaded S1... It seems that Anker implemented just a quick and dirty support for S1 in S2 systems by sacrificing individual S1 PV and battery data. |
|
Hi, the problem with S1 energy not showed on solarpower is cleared. If S2 ist going empty, S1 starts charging, if it does, this is counted as solarpower. Not nice, but OK. So I now count the charging Power to the total solarpower, and substract the dischargingpower. So my energydashboard is clean. I hope now all three batteries in E-Dashboard give correct values and my solarpower calculation too. |
|
I will soon post more, i think i am on it. Anker makes weird calculations. But i need more sun and after more night to fully find out what they are calculating. One Question: What ist intervallmultiplication in the Configuration of the Integration. Have a look at my screenshot. |
This is all described here |
|
Sorry, did not see it. |
|
Hi @RamsukKockoi |
|
Hi, In userdefined mode (manual) the settings of the S2 take the lead and sets the same setting to my both S1. Means if I set 100 Watts for output, all devices go to 100 Watt. Down to 13% the S2 seems to deliver the energy from itself. From then on it starts to take energy out of the both S1 (50Watts each). The values may not be exact, until now I did not have enough sun to test. If the setting for S2 ist "AI", I am free to set the output for the S1 (one setting for both). What happens, is that if I set 500 Watts, both S1 support the S2 with 250 Watts each, if the S2 means that it needs support. Before that they do nothing oder charge themselves. Without a Zero Watts switch, the S1 always deliver their first 50 Watts to the S2, to charge. Even if I have set 0. That disappears first if you use a 0-Watts switch. One weird thing ist, that since I connected the both S1 to the S2 and made a new system, the sensor "battery Power" in german "Akkuleistung" ist alwaya just half the Value of the app. How do I prduce a System Report? Hope I could help a little. |
|
According to the screenshots, it seems both still have separate schedules, but they are not longer used independently. |
|
According to the screenshots, it seems both still have separate schedules, but they are not longer used independently. SB1 schedule seems to be used only when SB2 is in AI mode. When it is in manual mode, the SB2 schedule seems to be used by the SB1 as well according to description, but not sure how this is done. Maybe the SB1 then utilizes the SB2 schedule object, which is a different one than the SB1 schedule. Therefore it will be helpful only if you also provide an export of the Api responses using the owner account in order to be able and correlate such information with the API responses and field values. Also the problem with wrong battery power....I cannot help fixing this when nobody can correlate the App data to the Api response fields.... |
|
Markus Kociok_2025-01-17_1312.zip I am so fu***** blind .... sensor.system_fluxkompensator_ertrag_gesamt: |
|
Hey, did it help a little? |
I'm puzzeled with the number of different randomized site IDs and device serials in your export zip. Much more than you have in your system... So actually, your export is somehow questionable since I don't know which files belong together to the same export run. Can you please run the export again, but pressing the Run Action button just ONCE. You get no feedback until the action is completed and turns the button green. |
|
Some observations I made already:
|
|
Tomrrow, we should have some sun here. What can I do to help. |
That would help so I can monitor the system values over longer periods for correlation with the App. See here for my account you can use. |
|
1 |
|
Invitation is out. If it would help, and you can promise to not make a toaster of it, I am willing to give you administrative credentials. Otherwise, I can export as much as you want, as soon as I read it. |
Thanks, for now the shared access is sufficient. That will allow me to correlate the values. The schedule is something that I can work later on... From what I see, Anker made a very lazy implementation for those coupled systems. The whole System totals for Solarbanks are ONLY reflecting SB2 data, which is pretty useless if you want to track various energies over time. Having Solar Power/Energy reported at night doesn't make sense and also the SB1 charge and discharge energy is not reflected anywhere to make any monitoring of the overall system efficiency. So you can basically forget now the energy stats collected by the Anker cloud since they are wrong for your system, at least PV, Charge and Discharge energies... Maybe I'll recalculate those SB totals for the system so they make more sense from a system perspective. But that would require to have a reliable indicator, which SB2 PV entry is used by a SB1 and I have not found yet a valid indicator by the existing values that works at any point in time... |
|
Another weird SB totals constellation which puzzles me from your export: I goes this is another inconsistency how the cloud responds to Api queries... |
|
Hey, it is not allowed to connect 2 SB1 into one port of SB2. In Ankers scheme, they only show one per port ... Please do forget the one Microinverter, that looks in direction "West" and is only active if "Flux" ist under 500. To stay in German laws. |
I am wondering what it means, as you. That is one of the miracles .... As I have a Shelly Plug to monitor the Solarpower, I am sure the output is both, means "185", if output is set to on "AI" |
|
Hey, I think i will not make too much sense, to start calculating the values in the integration. I am sure Anker will correct it more or less soon. Here and there, I have my own calculations and the battery state and charging rates, for me come from the SOC ... |
|
Hey, Sun ist comming Up. As now you can see the different values. The API shows more ore less half the Values of the App. Markus Kociok_2025-01-21_0951.zip |
|
Here ist another weird behaviour! SB2 is full now and bypasses solar energy now to the grid. Since it is doing that, I do not see Batterypower for the SB1.
|
|
Yes, the charging power always had to be calculated by the library since the inconsistencies in the Api responses and what is reported as SB totals and individual device power.... |
|
So I think we have to wait for Anker. Until then, the calculations are more or less good. By the way, if you set 450 W for discharging the SB1, the SB2, if it is fully loaded wil not regulate the ammount of energy down. I will just pass the energy through, disregarding, what mit Shelly 3 pro EM says .... |
So looking at the screenshot, only the Akkuleistung should be wrong. The other marked yellow values should all be correct since they are not calculated.
No, I can monitor that with my shared account over time.
Can you confirm, that original saved SB1 schedule is maintained, when toggling between AI and manual mode? Or is it lost, because SB2 manual mode overwrites SB1 schedule? I suspect another inefficiency that you may check and eventually escalate to Anker. The same may apply when it is cold and PV is trottled. The SB2 may do that equally for all MPPTs, not considering that SB1 connected MPPTs may not have to be throttled, especially not if the SB1 is set to 0W output as well and all possible PV could be charged if not limited by SB1. But SB1 does its own PV throttling if necessary. |
|
Hi, early in the morning, here is the first one. System is in AI Mode. SB2 is discharging, SB1 is in scheduled mode. I will give charging SB2 with activated Schedule for SB1 (100Watt, 50 each) a try and see, if SB2 has a negative effect to SB1. When SB2 goes to 90% and over, the both SB1 continue charging with the Power, that the PV modules deliver, with 0-Watt switch from Anker. It does not seem, that SB2 has an impact on charging the SB1. I can not make any statements to when it is cold, as my batteries are stored in the basement of my house, they always have 13-18 degrees. One side Information: If I change a seeting from the integration like excluded qeuries to the api or username and password, I always have to restart homeassistant, oherwise Values like "sensor.solar_system_flux_kompensator_gesamtleistung" are missing. |
|
I have set 250 Watt in manual mode for SB2. PV ist not sufficient to deliver all 250 watts. Is that what you need? |
|
Negative Charge of SB2 can not be correct here. |
Can you go below 100 W min for SB1 output setting in the schedule? Or are the original SB1 min limits remain for the schedule settings, even if connected to known SB2 MPPTs and inverter? I think for the value calculations I have sufficient examples for now and implemented work around for proper total power calculations. The device battery power should also be fixed. I may need more exports or admin access when I start working on support for the SB1 schedule changes in Combi systems, which is probably broken as well in the integration. |
|
Hi, I did not test schedule Actions in the Integration. But I will test. At the Moment we are going to not have Sun here. For your testin I can grant some admin access to you. As I said, just do not make a toaster of it. In Manual mode you can not change SB1, but SB2 then you can set values down to 10, see screenshots.
What exports do you need. Actually there is still some Energy in the batteries, that I can contain for testing. There is another thing I found: the battery states, like "charge" "discharge" "bypass discharge" and so on, are not alway correctly taken specially from the SB2. Leads to some weird calculations of charge and discharge in energydahboard, as I use to see if my calculations need to calculate dis- oder charge ... |
|
In Manual Mode, I can change Values for the SB2 to deliver Power. They are taken by the device, as they were set. After setting SB2 in manual Mode to 170 W: After setting SB2 to SmartMeter (AI) and Battery Value to 260: After staying in AI, but input Value is now 50: Markus Kociok_after having SB2 still on AI Input 50.zip |
|
Hey, if you go back to the app, after the integration had owner access, there is an error message for me. Have a look at the screenshot, please.
|
|
Yes, that might be because the Api sent a schedule that may not be acceptable by the device at that point in time. For the examples, you don't have to paste here the sysinfo part. This is contained in the export anyway and here they just take space and the hirarchy is lost because the HA Action prints the json in YAML format that shows hirarchy only by indents, which are completly missing here in the repo. Regarding admin access for schedule testing will be an issue anyway, because each time I will use it will kick off your token and vice versa. So if you use it in HA at same time, we will both quickly end up in banned IPs because HA will try to re-authenticate on each refresh cycle. I believe more than 10 authentication requests per IP per 24h will cause a 24h IP ban... |
|
OK. So you could test for a few hours, if needed. I should be much easier, then asking me all the time. |
Yes, but that might be the challenge since I never know when I find time to do some work on it... |
|
Hey, do you actually need anything? |
Not at this point. I need to monitor the values for a couple of days and work on other fixes for the next release. I'll let you know when I may have time and need owner access for doing work on the schedules for combined systems.
|
|
Do you need a beta tester? I would give it a try. |
You can test it with the Api library and the solarbank monitor. The HA integration is not ready yet |
|
Here is an example. To me the calculated system totals make more sense and seem to match expected numbers based on cascaded systems. Also the total SOC is now weighted across all battery packs. What I noticed is that upon changes, the devices still report their data at different intervals (SB1 every 1 minute, SB2 every 5 min?) |
|
Hi, the SB2 does not see Solarpower from SB1, if they are set to 0 output. So if SB1 is charging with 100W and there is a 0-W Switch, SB2 will not report PV-Input from SB1. If SB1 is set to 100W, gets 200W from PV-Input, it reports 100W charging and 100W output to home. That output ist what SB2 ist now seeing as PV-Input. The actually different calcutlatable outputs and totals, lead to weird EnergyDashboard effects. As the battery charging in ED reduces the home use of Solarpower. So now you have 2kWh Solarpower, but 1 went into SB1 with 0-Switch set to 0 you will not see any Solar Energy in the dashboard. 1 kWh went into SB1 and was never seen in the actual totals. And the one, that was seen in the actual totals, is "eaten" by the 1kWh SB1 has charged. Actually I really think about, to disconnect the SB1 from SB2 and make SB2 to a night energy system with 2 own PV-modules. But not before you say, you could now solve all the riddles Anker gives us with that. Btw. I am noticing, that SB2 seems to actuatlize PV-Inputs regularly every Minute, but not things as the states. F.e. "charging" to "bypass charging" and so on. |
I know, therefore all Anker 'System totals' and Energy statistics for combined systems are wrong.
The only thing that was calculated so far for a device is the battery power, to have a consistent and valid value for charging or discharging power (there was nothing from the cloud for this, meanwhile Anker provides a discharge field per device that seems reliable, but still nothing reliable for charge power). I changed that completely due to wrong totals. In the new version, totals will be accumulated from individual device level values as they are meaningfull and correct in a cascaded setup, where output of cascaded device = solar input of SB 2 device. Since Anker Cloud does not do that accumulation correctly (and maybe never will do), I had to implement that in the Api library. HOWEVER:
Are you sure about the interval? You can only verify SB2 update frequency if you watch how often the SB2 power device entities will change (not the totals or SB1 values). |
|
Hey, I am sure about the refreshing frequencies, both, the Power Values seem to come every Minute and the states often come later after a few minutes. For the states I am sure it mostly hits the SB2. In the app I already see "bypass discharging", the integration shows a plausible value, but the state does not change to "bypass discharge" for a period of a couple of minutes. |
|
Do you already have an Idea of the new Release ? I had the chance zu buy extension batteries. So I am planning a new System contelkation.Do you need more Information? |
Maybe end of next week. I'm in the middle of adding some stuff for AC model which needs more testing before the new release. |
System Health details
Does not seem to be a System Problem
Integration version
2.3.0
Checklist
Describe the issue
The Solarpower Sensor does not show or calculate the charging Power of my both S1 to the total Solar power Sensor. These datas are missing.
Also the Charging power is not shown correctly, it shows just the charging Power of one panel, also at high charging Power, the from S1 (at standard) delivered 50W (twice => means 100) are missing in the charging Power of the S2.
Compared with the Anker App, the charging Power of the S2 (sensor.solarbank_2_e1600_pro_akkuleistung) is halfened. And
Reproduction steps
It is always like above described ...
Debug logs
Diagnostics dump
.
The text was updated successfully, but these errors were encountered: