Issue with non-edited fields in new Service Calls

[DavidqStokes]

I've been trying out the new service calls. This looks good and I'll be looking to update my automations*

However, when using the UI via the Developer Tools Service Tab or as an Action in an automation, the service request fails if any field is not edited or updated. Comparing the UI to the YAML, the data is only included in the YAML if the data field has been entered or updated. This means that any unchanged value in the UI causes to service call to fail.

This means that of you don't want to set e.g. Charge Period 2, you have to enter some values for CP2 via the UI, then change then back to e.g. 00:00 and 00:00

As a workaround the service data can be entered via the YAML, but ideally the YAML should contain all necessary data, whether or not the field was changed / edited

• At the moment I have an automation which sends me a notification each evening, to tell be to charge the battery, allow the battery to discharge or do nothing (i.e. use grid power) during off-peak prices, based in the state of charge and the PV solar forecast for the next day

[Spookster]

Yes, the data needs to be populated with defaults. From the service call in UI , the yaml is populated by changed settings

However to call the service it needs all of the defaults:

You would probably also want to default the data to 00:00 so there are no unintended changes

[DavidqStokes]

On a positive note, I have been making progress with automations and have been able to successfully make the service call using calculated (templated) values for charge / discharge times.

This is looking very promising.

I will share / document my code if/when I get things working, but these are very dependent upon the overarching business rules.

[matt-oneill]

I think that’s a ‘feature’ in home assistant that it doesn’t populate the default values in the ui until you change it. I’ll look into it at some point. Ive had mine running calculations overnight and charging up at cheap times only if needed based on battery SOC, solar forecast & average daily consumption. I have noticed that I had a step to maintain the battery to 25% if it didn’t need charging just so it lasted until the solar started, but that stops it from discharging below whatever it’s currently on so I have a separate automation to set the discharge cutoff to 25 if it’s going to drop below that in the cheap period

[DavidqStokes]

I've got my 'maths' sorted out to consider how much the AlphaESS need to charge (considering tomorrow's PV and SOC), but have also done the same for the EV.

However, although some night I would be happy for the AlphaESS to 'spill' (discharge overnight if there is a good solar PV forecast tomorrow), but have realised that I can't allow the AlphaESS to 'spill' if the EV needs charging.

The 'business rules' are quite complex, even once the 'maths' has been worked out, but I'm getting there.

This would of course only be possible with the brilliant work of yourself and Charles, so thank you both once again for all the work reverse engineering the ever changing API.

[matt-oneill]

New changes again next weekend, doesn’t mention the dreaded anti-crawling mechanisms on the changes this time so 🤞

I guess the easy change to the service (and ui) would be to have the fields as optional and if they are null in the api use the current value and just overwrite what’s sent.

[mikeew]

@DavidqStokes Would you be willing to share your automation YAML?

[DavidqStokes]

I absolutely will, when I get that far. I've figured out how to do all the maths based on battery capacity, SOC and expected PV generation, and call a templated value into the action call i.e. an actual time e.g. "01:30". This of course needs to respect the AlphaESS requirement that time values can only be in increments of 15 minutes.

I've just got to the stage where I've working out workflow for the business rules e.g. I need HA to calculate whether the EV needs charging or not, and whether or not it's plugged in.

The actual automations will be very specific to my use cases, but when it's all done I'll share the code for the templated (calculated) variables in such a way as people can replace e.g. battery capacity and charge rate with their own. I'll also share my workflows and the automation YAML. It will take a while yet, but I'm getting there.

[matt-oneill]

@DavidqStokes do you get any options to change the EV settings in Alpha Cloud? I only did the battery charge/discharge services because that's all I needed, as I don't have an EV charger I don't see the options.

You can send any time via the api and it will appear as that in the alpha app, I just don't know if it would start at that time so would only recommend setting values alpha would allow

[DavidqStokes]

Yes - I'm only planning on sending values on the quarter hour. One of my templates uses an if-elseif-endif structure to calculate and set the AlphaESS end time based on a fixed start time (00:30) which is when my cheap grid power starts. So if I need e.g 49 minutes of grid charge to top the battery up to 100% (also allowing for the solar PV charging the next day), it would round 49 minutes down to 45 minutes and calculate the end time to be be (00:30 + 45 minutes = ) 01:15

I should have been clear about the EV - I'm using a separate MyEnergi Zappi charge point. You can't sent it start/stop times like the AlphaESS via the HA integration (although I guess that API could be further reverse engineered to do that because the MyEnergi app allows scheduling), but you can start and stop fast charge mode via the API and Home Assistant integration . What I'll do there is start charging at 00:30, by enabling fast charge mode, run a HA timer for the correct number of minutes and then end fast charging by switching to Stopped mode.

The beauty of Home Assistant is that we can integrate the automation of these two separate systems into one solution.

I already use an automation to put the charge point into Eco++ mode if/when the AlphaESS reaches 100% on sunny day and there is still solar to use.

[matt-oneill]

I didn't think of doing it like that. I just calculate how much energy would be required and charge the battery up to {{calculate charge cutoff}}% from 00:30-04:30. if it gets to the required percentage before 04:30 it just maintains it until it switches off. Your idea sounds better!

I forgot there would be other chargers integrating with this in HA. It would be interesting to see if anyone has the alpha one and options are available

[DavidqStokes]

I think that charging / discharging to a specific SOC is a simpler and therefore preferred method (the coding / templating is simpler), but I have noticed that my AlphaESS SMILE B3 has previously charged over my 95% limit, and has discharged below my 10% discharge limit, which I'd like to try and avoid. I don't mind slow charging to 100% on solar PV (which is occasional and generally a slower charge) but am trying to avoid this on a regular basis over the winter with grid charging.