Move scheduling to the new API and end-of-life the legacy charge/discharge endpoints

[phill65]

Summary

I am testing the newer six-period AlphaESS OpenAPI schedule endpoints:

• POST /api/setTimeChargeBySn
• GET /api/getTimeChargeBySn

The POST returns success and the new schedule is immediately returned by the GET endpoint. However, the inverter does not act on the schedule until I open the same period in the AlphaESS mobile app (or website) and press Save, without changing anything.

System

• Inverter: SMILE-G3-S5-INV
• Battery: SMILE-G3-BAT-10.1P
• alphaessopenapi: 0.0.19

The API request is made directly against the official AlphaESS OpenAPI. It is not made through the Home Assistant charge service.

Use case

I want to prevent the house battery from discharging while an EV is charging.

A low grid-charge power period puts the inverter into grid-charge mode. The house and EV are then supplied from the grid, while any surplus solar can still charge the battery.

API test

The controller added this daily charge period while preserving the existing charge and discharge periods:

{
  "beginTime": "10:04",
  "endTime": "11:00",
  "chargePower": 1,
  "chargeLimit": 100,
  "weeks": [1, 2, 3, 4, 5, 6, 7]
}

[Poshy163]

it appears that getTimeChargeBySn is a completely new endpoint, ill look into implementing it now. thanks for that!

one questions @phill65 are you based in australia by chance?

[phill65]

@Poshy163 - Hi Josh - thanks for looking into this, and no UK based :)

[strickersuk]

I think something similar is happening to me, this is a B3 system with 3 charge slots in the app. I have an automation that sets the battery to charge when my car starts charging, the times are being sent over but the battery continues to discharge. Also UK based.

[Poshy163]

Alright, just going over implementation now,

i think initially, to get this resolved and back to working ASAP, ill set executeCycleType to 0, which means it should repeat the set periodic charge/discharge to how it is now (daily).

as for the future, im not quite sure how i can implement the "only on certain days" options, it seems quite out of scope for what can be offered within the "overview" of a device, but can be extended within automations, which i might look into migrating to.

curious to hear what you think @phill65 @strickersuk for your feedback on how it should be approached in the future

[strickersuk]

It's tricky isn't because different systems have different numbers of time slots, I think that would be impossible to keep track of? For me, all I want to be able to do is set the battery to charge when the car starts and stop when it finishes. Then to reset the charge times to be able to take advantage of the low rate off-peak energy. I can do that quite easily with an automation as long as the Alpha API is acting on the information sent.

[phill65]

@Poshy163 - I'd do the same, just get it working daily - I use it similar to others for setting the battery charge when EV charging so daily is fine for me too.

[DavidqStokes]

For what it's worth, I agree that specific use cases other than simply setting charge / discharge times should be handled by user specific automations.
The integration should only provide the ability to set times, not the logic of working those times out.