Manual Charge Control Override

[AGLAISTER]

Is your feature request related to a problem? Please describe. On odd occasions due to unexpected high load use there are times where I'd like to boost the battery charge However to do this I have to put batpred in to read only then select charge through the givenergy app Likewise there are other times where batpred choose to charge that I'd like to be able to override

Describe the solution you'd like Addition of a manual charge controls that will override the batpred plan during the current 30 minute slot Controls would be "manual charge" & "manual idle" or something similar

[springfall2008]

I've implemented a manual charge and manual discharge option on 'main' now (will report as v7.15.0), can you please give it a try?

Use: select.predbat_manual_charge and select.predbat_manual_discharge drop down menu. Select a 30 minute time slot in the next 12 hours you want to charge or discharge. You can select more than one and they will be added to the list. They will show in the HTML plan with an upside down F (for force). You can disable them again by selecting the time again (now in square brackets).

I could do one for manual idle also if you like the concept, it's very easy to scale this code.

[gcoan]

I have upgraded to main, see the new controls, but on trying to set up a manual charge at 23:30, it doesn't seem to be working

No charge appears at 23:30. I was interested to see what the extra charge did to the rest of the plan, whether it planned more discharging as a result for example, but the charge isn't added:

In the log the manual override charge is set at 15:04 and is then logged in the subsequent predbat runs at 15:-5. 15:10 and 15:15 appdaemon (14).log

[springfall2008]

Please update again I think I have fixed it now (and added manual idle mode)

[gcoan]

Thanks, this seems to work now:

and turning the manual discharge off:

the plan gets correctly recomputed each time

This might be useful for ensuring that the DFS session always does a discharge #630 and I had thought it could be useful for the Octopus power up events to save having to manually edit apps.yaml and put the zero rate in, but not sure about how practical this will be as every time a select.predbatmanual... is set you have to wait for predbat to recalculate the plan before adding the next manual time command.
I have the power up start/end and date already in helper entities as I have other automations running off them, so could do the same to automate predbat for the session, but not sure its worth it.

One other feedback, If I am going to use this for scheduling power up charges, then 18 hours ahead would be more useful than 12.

Thanks

[springfall2008]

I'll change it to 18 hours, no issue there. It's not 24 hours so that old values are removed without it being time critical.

I'm adding a saving session scaling feature which will allow you to assume a reduction in energy during the session, this can also be done manually in the rates override settings (load_scaling).

[springfall2008]

Released in: https://github.com/springfall2008/batpred/releases/tag/v7.15.0

[gcoan]

thanks the saving session load should give me what I need to ensure that I always get a force discharge during the saving session.

Probably will stick with editing apps.yaml for now for the power up events. Might try to be adventurous and append the extra power up timing entries via a script.

BTW the version description for 7.15.0 looks messed up:

[springfall2008]

Thanks I fixed the title now

power ups don’t have an API as far as I know hence the need to enter in apps.yaml?

[springfall2008]

I forgot to say you can do load scaling in the apps.yaml also now

[gcoan]

Thanks I fixed the title now

power ups don’t have an API as far as I know hence the need to enter in apps.yaml?

yep, new title fixed now

there isn't an API for powerups so it has to be manually configured each time.

I have 3 entities in HA for start time, end time and date, so have to set these and edit apps.yaml, was just trying to think of a way of tying it all together to edit just one thing once. Hence why I may try to automate appending the power up rate override onto apps.yaml from the HA entities. Or may just continue as I am.

Another power up tomorrow evening, 7-11pm. Today's was 1-4:30pm. Wish they were every day !

[springfall2008]

What do you use the HA entities for, could you not get that data from predbat?

[gcoan]

The entities were originally when I was managing the charging outside of predbat. Now they are used to turn some heaters on and swap between the day and free tariff on the import tariff selector so I get the right pricing in the energy dashboard On 20 Jan 2024 at 17:36 +0000, Trefor Southwell @.***>, wrote:

What do you use the HA entities for, could you not get that data from predbat? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[AGLAISTER]

Hi Trefor,

Been playing around with it and its looking pretty good - thanks.

If you could at the idle feature as I could see me using this to override the hold charge (hopefully)

Thanks

On Sat, 20 Jan 2024 at 11:59, Trefor Southwell @.***> wrote:

I've implemented a manual charge and manual discharge option on 'main' now (will report as v7.15.0), can you please give it a try?

Use: select.predbat_manual_charge and select.predbat_manual_discharge drop down menu. Select a 30 minute time slot in the next 12 hours you want to charge or discharge. You can select more than one and they will be added to the list. They will show in the HTML plan with an upside down F (for force). You can disable them again by selecting the time again (now in square brackets).

I could do one for manual idle also if you like the concept, it's very easy to scale this code.

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/634#issuecomment-1902076174, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBXYY325GWHJMUXWA4XLVDLYPOWRLAVCNFSM6AAAAABCCODDNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBSGA3TMMJXGQ . You are receiving this because you authored the thread.Message ID: @.***>

[springfall2008]

Way ahead of you the idle is there already