Add Support for AC model and Usage Mode: Backup Power

[Vehekk]

Checklist

• I have filled out the template to the best of my ability.
• This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
• This issue is not a duplicate feature request of previous feature requests.

Is your feature request related to a problem? Please describe.

I'd like to use my SB2 AC as a addon-battery for my already existing solar plant on my roof. I don't have additional solar panels connected to the SB2 AC, i just want to be able to charge surplus energy coming from my roof to the SB2. Preferably, I'd like it automated, when HA detects that I have surplus energy so it automatically switches the SB2 mode to "backup power" and charges it through the outlet.

Describe the solution you'd like

I'd like to request to add the "backup power" mode to usage modes for the AC model..

Describe alternatives you've considered

manually changing the mode in anker app.

Additional context

Do you need any info or log from the SB2 AC?

[thomluther]

Hi, yes lots of various Api exports are needed to get all the new structures supported by AC model.
You can use the HA service to export the config, but gives just the picture with the current Api library.

Support for new features will require you to use newer versions of Api library for testing against your system and maybe re-run exports or test individual Api methods with the system before they can be added to the HA integration.

Please have a look to the libary and the solarbank fields issue that is tracked there. Any exports can be uploaded there.
HA integration can only be enhanced once the Api library fully supports the new feature.

[thomluther]

Here is another library issue to track your request.

[thomluther]

@Vehekk did you create already an export from your SB2 AC in HA when using your main account?
You should create a complex schedule with peek and off peek first, using various combinations of weekdays and month to get the full possible schedule structure in the export. Also prior exporting, enable the new backup mode in the App to see which code it will use in the Api export.

[Vehekk]

@thomluther not yet, i'm currently not able to access my system while on a work trip. Will report more information and possible a export next week.

[yhammeke]

To my knowledge if you use Anker Smart Meter, then Anker SB2 AC automatically charge the battery with the power which otherwise goes to the grid.
I was very surprised about that.
So no need to do some automations.

[thomluther]

That makes sense of course.
Yet, it will be helpful to get various exports to be able to switch the mode or schedule settings via Api. Especially high and low peek times may fluctuate and Anker App cannot adopt automatically.

[noseshimself]

To my knowledge if you use Anker Smart Meter, then Anker SB2 AC automatically charge the battery with the power which otherwise goes to the grid. I was very surprised about that. So no need to do some automations.

It's not working that well if you have several systems on different phases. A single E1600 "site" will take the entire meter; even if you could share it between devices you would not be able to balance across systems or return 800W per phase. The only thing you could do was adding one Anker power meter per inverter 👏👏👏. I'm happy to have one set of current transformers in the restricted space...

The more flexible solution would be using a Shelly 3EM which is not yet supported by Anker for the E1600 AC.

Right now it would be nice if the "System Einspeisevorgabe" slider was working with the current E1600 AC firmware instead of returning to 0. Unless Anker is adding another API variable to specify a charging rate (right now all you can do is turning on emergency mode which will cause the E1600 AC to suck as much energy as it can get from all bodily openings it has including the grid-directed inverter) this system will be not that useful as energy storage controlled by Home Assistant.

[noseshimself]

That makes sense of course. Yet, it will be helpful to get various exports to be able to switch the mode or schedule settings via Api. Especially high and low peek times may fluctuate and Anker App cannot adopt automatically.

Would full access to a system be useful? Right now mine is sitting in a corner collecting dust, waiting for Anker to integrate Shelly power meters. I'm going to reuse its batteries for an E1600 Pro so it's not that bad but right now it's a brick sitting in my guest room.

[thomluther]

Would full access to a system be useful? Right now mine is sitting in a corner collecting dust, waiting for Anker to integrate Shelly power meters. I'm going to reuse its batteries for an E1600 Pro so it's not that bad but right now it's a brick sitting in my guest room.

If I get full Owner access to a AC System that might help testing against the API. But I cannot do anything before mid Jan.
And even then progress won't be quick, so I would probably need that for a couple of weeks.

[noseshimself]

Would full access to a system be useful? Right now mine is sitting in a corner collecting dust, waiting for Anker to integrate Shelly power meters. I'm going to reuse its batteries for an E1600 Pro so it's not that bad but right now it's a brick sitting in my guest room.

If I get full Owner access to a AC System that might help testing against the API. But I cannot do anything before mid Jan. And even then progress won't be quick, so I would probably need that for a couple of weeks.

Let's return to it then.

There seem to be a few more problems with the way the integration is using the API which is (as far as I have understood the support's replies) going to change with the next firmware release (which might "take a few weeks"). While the Anker app is always correctly reporting the charge level of the whole system the integration is reporting the charge of the inverter's built-in battery most of the time

and I don't see any bug that would cause this in the source. And even the Anker app can't get the additional BP1600s to charge in "emergency mode"; if the built-in batteries are full the inverter is pulling 1.1kW from the grid and sending it into nowhere. 🤦

[thomluther]

The Screenshot you show is a calculated entity by the library, based on battery packs and SOC. If that goes down to main device in between then the response may show no installed battery packs for any reason. You need to double check if battery pack count remains stable. If it does, there may be another bug in the library for new AC device type.
Keep in mind that the shown entity is just a theoretical value. It never can reflect the real Energy in the battery. Use the Soc entities instead to monitor the fill level.

[thomluther]

@noseshimself actually I'm not sure how you can give me Owner access to your system, since you have to use an Anker account with password to create an owning system with your BT connected AC device.
Either you would have to share the account including PW, or I would have to give you an account with PW. Either way, just one person can use it as owner for the time being.

[noseshimself]

actually I'm not sure how you can give me Owner access to your system, since you have to use an Anker account with password to create an owning system with your BT connected AC device.

Relatively easy: I'll change the password and provide you with the credentials to it.. If you blow it up Anker will have to explain that to me. If you burn the house down I'll have an interesting discussion with the insurance.

Right now it's completely useless to me; I can't even get it to return energy from the batteries any more -- it's resetting the output to 0 every time I use the slider. It's still not possible to connect the Shelly meter to the device either.

I'm close to using it as just another PV system and get an SMA Sunny Boy Storage instead. More expensive but the software is doing everything in the manual.

[thomluther]

Hi @noseshimself

Relatively easy: I'll change the password and provide you with the credentials to it.. If you blow it up Anker will have to explain that to me. If you burn the house down I'll have an interesting discussion with the insurance.

You can send me the credentials to [email protected]. If you have another account, you can share the system first with that account, then you can continue monitoring with shared account at least while I may utilizing the main account for Api work.
I'll also share the system with my other Anker account, so I can validate both account types via Api.

Since I have no validation of what is really happening with the device (AC output or AC charge), I can only trust the values in the App/Api. I'm not going to stress it to the upper limit, but maybe testing the lower limits for AC output and AC charging...
My major use case is to correleate the App data with the Api responses in order to enhance the Api library accordingly and understand how the Api system and device caches can be structured in a meaningful way to simplify the various solarbank model cache structures for the HA integration.
To validate if the SB2 is really doing something it will be good if it has AC power connection (will limit output and charge to 150 W max when testing)
Do you have PV connected to validate the Api numbers for PV and internal Inverter?

[noseshimself]

Sorry, no panels and I had to borrow one of the batteries now. The device is connected to grid power using its output connector (which will become an input in emergency mode). Anker told me NOT to connect the inverter input/emergency output to grid power; it might work but has no limiter in front of it, expecting that input can't exceed 800W.

[thomluther]

@noseshimself, if you send me your AC system account credentials to previous mail I can start looking into some Api queries.
At least the backup power mode is something I'd like to add for the next release.

[thomluther]

@noseshimself, @yhammeke, @Vehekk,
Can you provide meaningful system data from the AC or give me access to your system so I can validate and monitor some API queries to make some progress.
Without your support, nothing can be enhanced since I have no system to test.

[noseshimself]

I already sent you the account credentials to [email protected]. if you did not receive them I can resend them.

[thomluther]

I already sent you the account credentials to [email protected]. if you did not receive them I can resend them.

That is weird, the email is correct but I have not received anything. Please resend it and you may also try to invite that email as member to your system. Then I also should receive an invite for shared access with my account, which I must test as well for possible monitoring capabilities without using owner account.

[noseshimself]

That is weird, the email is correct but

Gargle isn't. I can't fix it right now and refuse to jump through hoops for them. I used an alternative way to provide the credentials.

[thomluther]

That is weird, the email is correct but

Gargle isn't. I can't fix it right now and refuse to jump through hoops for them. I used an alternative way to provide the credentials.

I got your system invitation and your file share invitation. Forget the access request I sent you, it was with my other google account.

[thomluther]

Hi @noseshimself, I created now a Tarifplan on your system to see how I can get and modify such a plan via Api. The other unknown thing is the Use Time mode. This can only be enabled when a Smartmeter is in the system. Can you add your Smartmeter into the system? You may need to update firmware if this is not working yet. Request this from Support if not provided automatically.

[noseshimself]

Can you add your Smartmeter into the system?

I still can't. There is only sufficient space for one set of CTs and this has been filled by the Shelly 3EM. Which any other E1600 EXCEPT the AC can use. And there is no firmware yet (I'm annoying the Anker support about once a week).

[thomluther]

OK, To my knowledge, the 1.0.3.x FW will support same Smartmeters with the AC as with the other SB2 models.
I also figured out, that the tarif plan I have defined with the 'prices' settings of the system, is the one used in the schedule as 'use_time' plan. This has very complex structure, but will be used when you can enable the Usage Time mode (requires a smart meter).
But don't ask me how it will work.
There are 4 different tariffs, So eventually, AC charge will allways be done with surplus (grid export), but without surplus only at low tarifs (off_peek and other). Mid_peek is maybe neither used for charge nor discharge. Peek may be used for discharge when there is home demand?

I haven't seen good documentation from Anker about how to configure such a meaningful tarif plan for Usage Time mode...

Nevertheless, with the example plan I created on your system, I have now the structure and can translate all codes that are used in the plan.

What I still miss is the integer code for the activated Usage Time mode. 1-3 are already used for the other modes, so could be 4 but Anker is so inconsistent in the Api that it could also be 99

[thomluther]

BTW, the manual backup power is no separate usage mode, but seems to be an 'Option' only.
While the settings are also part of the schedule object as separate plan, it may get priority and 'overlay' any active usage mode while system date and time is in the defined backup time range.
Although the range is a list item in the object, and maybe in future you can define multiple backup ranges, for now there is just one.
I probably going to support that as separate entities, and will require also separate Solix service in HA. But entity support still struggles me, because HA datetime entities in the UI trigger value changes with each field change (date, hour, second etc). So that would trigger lots of Api calls for schedule changes with every partial entitiy change through the UI. Not sure yet how to prevent this and limit it to a single Api call with enablement of the Switch for the backup mode...

[AgentAndre]

Thx Thom for your effort!!!
I think for First step Implementing this use Case would be already great:
Once a day the dayahead price curve of next day is checked by HA eg from Tibber and one single Backup time period in the day is scheduled.

So Not so mamy API calls are needed.
What do you think?

[thomluther]

If I implement support for the very complex use time plan, I must support all possible options like for other schedule plan. That covers individual setting changes via entity for current interval (or create a valid default interval with defaults for all other required values not touched by the entity), and actions that allow to specify multiple fields at once, but also optionally.
This is pretty complex and must also be tested carefully for valid structures in various use cases.
That is nothing that will be supported soon.

If Anker thinks a manual Plan is a useful implementation to support dynamic tariffs, I'm not going to improve that.
You should open a ticket with Anker to provide an interface that allows feeding dynamic tariffs.
Their current plan implementation is absolutely useless, so I don't see why I should spend any time to improve that for Anker...

[thomluther]

What I still miss is the integer code for the activated Usage Time mode. 1-3 are already used for the other modes, so could be 4 but Anker is so inconsistent in the Api that it could also be 99

I finally got it, and actually it is different as expected.
5 is the magic code for activating usage mode of the use_time plan. So 4 is currently skipped in the usage modes and I wonder what that will become?!?
But further testing has shown, that manual backup power option is really NOT related to any usage mode. It is simply prioritized over any active mode when the system is in the defined backup interval (the active usage code remains),
And testing has shown that an active backup mode is only reflected in the mobile App for a system owner, but NOT for a system member. This is something that everyone of you should address to Anker support if interested in that capability!

While a member can see the 'normal' active mode (because the usage code is given in the scene_info Api response), this code does not change when backup interval starts...The member just can see the active mode, e.g. Smart Meter mode, but the solarbank may do AC charge from Grid with 1200 W because backup mode is used!!!
I don't know if and how Anker will fix that, but they would have to extract more of the schedule data into the scene_info response. If active backup mode does not get an extra field, it would need to get an extra usage mode code to make that visible to members as well.
There is no way to work around that limitation, since a member account cannot read the schedule, so never knows whether backup interval is even defined or active. You could recognize that only when you see max charge, including charge from grid.

Another general App limitation is during the use_time mode: You cannot recognize easily which tariff is actually in use without going into the plan looking at current time definition.
This is something that could be extracted as separate system sensors by the library/integration to indicate the active use_time plan tariff and price...

[thomluther]

I ran into other issues when trying to modify the usage code or something in the plan. The new schedule was accepted via Api, but was not applied (remained unchanged). When I went back to App as owner, I always got the message that previous setup was not completed, and I had to confirm again the usage mode setting to complete it.
I assume either the system is in a weird condition, or when a use_time plan is defined, a change of settings in any part of the schedule may require additional Api calls than just applying the changed plan via set_device_parm.
I think so, because with a defined use_time plan (which includes different prices per period), in the App you can toggle the System Price mode between fixed price and use_time price. This toggle has no influence about active usage mode, but it could be that switching from/to use_time mode requires also to toggle the system price mode. But I have no clue how that would be done via Api, since there is no endpoint to my knowledge which covers this.

In other words, support for use time plan in the AC model is not going to come any time soon...
Not before anyone can test and document reliable modifications via the Api for such a system.

[thomluther]

And testing has shown that an active backup mode is only reflected in the mobile App for a system owner, but NOT for a system member. This is something that everyone of you should address to Anker support if interested in that capability!

Actually this statement may be wrong. Review of some exports shows a scene_mode number in scene info response. That seems to reflect the active usage mode number set in the schedule. But this also seems to show the missing 4 when the backup mode is running. For whatever reason this mode is not temporarily reflected in the schedule object...

So why did I not see the active backup mode in the App as member?
Maybe I did not wait at least 5 min to ensure that the SB2 sends actual data to the cloud...
So maybe the mode reflection is no issue at all, just delayed like all other values for members.

[thomluther]

More testing showed that backup mode can be enabled and disabled via Api. The caveat is that it may take up to 5 minutes until the change is reflected in the Api response. However, the system itself reacts in few seconds if the backup mode is activated.
The active mode is reliably reflected in scene info for any user, although it may have 5 min delay like other SB2 value changes.
I also found an error in the battery power calculation which did not reflect the AC charge power yet.
Other new fields in scene info for inverter power don't seem to be used yet.
I will add some new entities for those fields anyway, maybe one day they show something.

[thomluther]

To control backup mode with single Api call but multiple entities I plan to do following:

• When changing datetime entity, the changes are done in Api Cache only. One datetime entity change via UI may already trigger 3 updates (date, hour, minute)
• Any datetime change will always disable the backup mode switch
• To apply the new datetimes the switch must be activated, which is the only trigger for the Api call. The datetimes will be taken from the cache.

The only limitation with this approach is that background device detail run updates may reset the datetime changes. But that should be rare since only every 10 minutes by default, or when other schedule services are used by automations.
For convenience I will add an immediate backup range if end time is in the past, maybe for next hour. This should allow to charge about 1-1.2 kWh for emergency backup, just by enabling the backup switch for immediate use.

[tmb80c]

I ran into other issues when trying to modify the usage code or something in the plan. The new schedule was accepted via Api, but was not applied (remained unchanged). When I went back to App as owner, I always got the message that previous setup was not completed, and I had to confirm again the usage mode setting to complete it.

I have seen this user interface bug in the APP too, whenever I switch from member to admin account.

[thomluther]

I have seen this user interface bug in the APP too, whenever I switch from member to admin account.

So it is Not independent of doing schedule changes via Api?
Anyway, I could not modify the output either when running in manual mode which seems to work on other models. Nor sure if that depends on an existing use time plan or not...

[thomluther]

I noticed that the App toggles the site price to use_plan automatically when Use Time mode is activated.
I implemented it the same way into the Api.
However, that might not be everything that is being toggled on the AC with this new mode.

The 2.5.0 beta is available in the main branch.
You can update via the Action install update and selecting the Anker Solix update entity. For the version you need to specify 'main' as tag for the main branch.
Note: After installation and restart, HA will continue to report a repair action since it believes the available release version is newer than the installed 'main' version. Simple ignore that until the 2.5.0 has been released.
If you have any findings with the beta, please let me know. I don't plan code changes anymore, only documentation updates prior release next week.

Please report if the output power changes are accepted in your AC devices when manual power mode is active. Maybe there is still more investigation required by the community on what Api calls are done by the App when changing the AC usage modes...

For convenience, the intergration allows to enable the backup mode immediately when switching to this mode or when enabling the backup switch entity...It will start now and run for an hour, which is typically enough to charge 1 battery by ~60%.
Users can increase the end time if desired, which will deactivate the switch entity to prevent each entity change is triggering an Api call. Only enabling the backup switch will trigger the Api call to apply to modified datetime entities. So while it may appear the mode was disabled with the datetime change, the active mode remains unchanged until you trigger the Api call with enabling the backup switch. But there is no other way to reflect this otherwise in the various entities, since they are updated from the Api cache and that must be updated at least when any entity changes the backup plan value...

If it is more convenient, the 1 hour backup duration could be increased to 2 hours per default, which should be sufficient to fully charge one battery from 10% to 100%. Let me know what better fits to the usage behavior and how longer backup windows behave with the following:

• Can someone confirm, whether backup mode automatically turns off when SOC is 100% but interval still active? In that case, will the backup switch being disabled once 100% SOC is reached?
• And if so, assuming the house demand is requiring a discharge while the backup interval still active, will it toggle back again to recharge to 100%? I assume not, but user would need to reactivate the switch to enable another backup charge?

[thomluther]

For discussions on the new AC fields / entities, please refer to issue 198
I may have to rename those new entities (at least the translation name) to make their purpose more clear once the purpose is understood.

[Vehekk]

Can someone confirm, whether backup mode automatically turns off when SOC is 100% but interval still active? In that case, will the backup switch being disabled once 100% SOC is reached?

I can confirm this. It automatically disables the backup mode once reaching 100%.

And if so, assuming the house demand is requiring a discharge while the backup interval still active, will it toggle back again to recharge to 100%? I assume not, but user would need to reactivate the switch to enable another backup charge?

The backup interval overrides other plans. So while backup is active, it is always active till 100% or until the time is up. Doesnt matter if the house is using power. And yes, you have to manually re-enable backup mode. There is no pause and auto-start.
Altough it is possible to interrupt the charge e.g. with a smart plug (disconnect the power). If you power on the smart plug, it will resume the backup-charge, assuming the interval is still ongoing.

[thomluther]

The backup interval overrides other plans. So while backup is active, it is always active till 100% or until the time is up. Doesnt matter if the house is using power. And yes, you have to manually re-enable backup mode. There is no pause and auto-start.
Altough it is possible to interrupt the charge e.g. with a smart plug (disconnect the power). If you power on the smart plug, it will resume the backup-charge, assuming the interval is still ongoing.

OK. So what it probably does is simply deactivating the backup switch once it reached 100%. Therefore no automatic reenabling.
You can also interrupt the charge by deactivating the switch, no need for a smart plug.
This is possible with HA, e.g. when a certain SOC is reached.

So what is the impression for a meaningful default duration when the backup mode is enabled in HA without manual adjustment of the backup times?

• 1 hour => 1000-1200 Wh => 0,6-0,7 batteries
• 2 hours => 2000-2400 Wh => 1,2-1,4 batteries
• 3 hours => 3000-3600 Wh => 1,8-2 batteries
• 5 hours => 5000-6000 Wh => enough to fill 3 batteries

If it switches off automatically, it should not matter to default for a longer interval. I also assume >95 % SOC it will charge slower...