Feature to put the inverter in backup mode for a number of hours to protect battery SoC whilst EV charging.

[punkymuzzle]

Is your feature request related to a problem? Please describe. I want to be able to set the inverter to set to Backup mode for a number of hours (either a single or multiple slots) when I put my EV on charge, so the battery does bot drain to charge the car. When charging my Electric car overnight, some of this load will be provided by my batteries. I don't want this to happen as then I need to charge the batteries again before any price increase in the half hourly tariff rates. So a way to let the inverter know what times the car is charging (so it can not provide battery power to charge the car) would be ideal.

Describe the solution you'd like

1. What Would be great is a dashboard option to set PV-Opt into "EV Charge" mode and assign time slots & durations for this to happen.
2. PV-Opt would then set the inverter to not discharge the battery during these times
3. if the time slots selected coincided with the PV-Opt charging schedule, the battery would also charge as per the schedule (but not discharge)
4. Once the last EV charging slot had completed, PV-Opt would revert back to its calculated schedule.

I know that other automations (cough - Predbat - cough) have the ability to integrate car charging into the schedule, but that is dependent on a car charger that can be controlled. This is more of a process to protect the battery from discharging whilst EV charging is occurring when controlled via a separate app - i.e my ProjectEV app for my charger.

Describe alternatives you've considered If the hourly rates slots overnight are relatively cheap then I place PV-Opt in read only and manually set the inverter to Backup mode to prevent the battery from discharging to charge the EV. Then reset everything in the morning. However the process is not particularly easy:

1. Sometimes PV-Opt takes numerous cycles for the read only selection to "stick" so the inverter keeps resetting back to its schedule.
2. Sometimes PV-Opt resets the read only toggle back to "off", effectively ignoring my request for read only and so ends up powering the EV charge.
3. In the event of the above I sometimes have to stop AppDaemon to force PV-Opt to stop running. This is sometimes a problem as if I forget to reset things in the morning, PV-Opt does not resume running and I am usually left with an empty battery and consuming expensive electricity.
4. I can't do any of the above if the overnight price fluctuates and I want to charge my EV at certain time blocks, unless I stay up overnight to keep configuring PV-Opt.

Additional context More than willing to test this via beta versions if needed. My Inverter is a Solax X1AC.

Thanks very much in advance

[punkymuzzle]

Changed the value to 120 so there is now a pause between it optimising, which seems to have calmed it down. However, still problems

1. The 1W charge disappeared from the schedule again (assuming this is as per your earlier messages).
2. As the SoC dropped to 10% my inverter hibernated, meaning that HA cannot update it any further. This issue was overcome by @fboundy adding some code to make PV-Opt write the charging schedule to my inverter when it got to 13%. So I had to use my (SolaX) app to communicate with the inverter and manually reset chargiing times to effectively bring it to life.
3. I've had to put PV-Opt in read only mode now as my battery is flat so I need to charge it before my expensive peak time (16:00 - 19:00) so I have a full battery. However, when I put PV-Opt in Read only mode, it resets back to "Active" mode. So now there is some power back in the battery and the inverter is not in hibernate, PV-Opt keeps overwriting my manual charging settings I have had to setup as above. I seem to have this issue a lot but can't pin down what the problem is. So now I've had to actually stop AppDaemon so PV-Opt does not run at all.

Do we need a rethink on how this works? or do you think we are still on the right track? Also, I noticed there is an update to PV-Opt (to 3.18.2). Assuming that if I update to this version it will overwrite the beta files. Is it worth me updating first and then re-adding the files from your beta?

Thanks

[stevebuk1]

Do we need a rethink on how this works? or do you think we are still on the right track?

From the log you posted today everything actually appears to be working, its just long delays between each optimiser run and lags of whats done where that makes it look like it isn't. We just need to solve the 300/360 seconds delay, which is an issue from the original Solax integration development that hadn't affected things too much up to now but certainly does now. For reference my delay is 15 seconds, so a full optimiser run from idle through to idle takes a minute or so. We need to achieve the same, otheriwse, any method of preventing discharge is going to result in more inverter writes and certainly needing 10 minutes for each one will going to cause issues for anything more than the most basic charge window.

Also, I noticed there is an update to PV-Opt (to 3.18.2). Assuming that if I update to this version it will overwrite the beta files. Is it worth me updating first and then re-adding the files from your beta?

No need - the files you have already include the changes made to 3.18.2. I merge production changes into the development code as soon as they are released.

Changed the value to 120 so there is now a pause between it optimising, which seems to have calmed it down. However, still problems

I really do need a Pv_opt.log from you with every post that describes a behaviour. I really can't do anything without them......

[punkymuzzle]

OK thanks for this. Understood the point with the logs, will ensure I upload one for each post.

I realised I was having some problems with my inverter / battery charging rate. I ended up speaking with the installer who has helped in hopefully resolving this. So i ended up updating to the latest version of PV-Opt in order to rule out that my inverter issue wasn't related.

Now it's (hopefully) been resolved I will reinstall the beta and start charging / testing again (with the refresh time down to 60 seconds) and we'll see how it goes.

Please bear with me whilst I do this. Many thanks for your support and patience with this, it's really appreciated.

[stevebuk1]

For now its probably best that you revert to the production release of Pv_opt and make sure you have stable operation with an inverter delay of 60seconds and see if that resolves the issue you raised . If you think its working a pv_opt.log and main.log would be very useful to see if this solves the issues within #299. I'll also put a similar response in #299. We'll leave this open and come back to it once #299 is resolved.

[punkymuzzle]

Fantastic, thank you very much. To confirm, now I have reverted back to 3.18.2 and set the optimiser time to 120 seconds (as 60 seconds was causing issues with the dashboard showing various states of optimisation). I will drop this to 60 seconds as requested and leave overnight to see if this is still OK. If it is I will then re-download the bera files and start to test the "prevent discharge" option again.

Many thanks

[stevebuk1]

The recommendation for 60secs was entirely arbitrary. If 120s is reliable we can stick with that. That means everything completes in 5 minutes which is less than the optimiser scheduled time of 10 minutes.

Can I just confirm that the value of 60 (or 120) is regarding the value of id_cycle_seconds in config yaml? You referred to it as optimiser time and I can't see this needing to be set any lower than 10 minutes.

On Tue, 19 Nov 2024, 22:59 punkymuzzle, @.***> wrote:

Fantastic, thank you very much. To confirm, now I have reverted back to 3.18.2 and set the optimiser time to 120 seconds (as 60 seconds was causing issues with the dashboard showing various states of optimisation). I will drop this to 60 seconds as requested and leave overnight to see if this is still OK. If it is I will then re-download the bera files and start to test the "prevent discharge" option again.

Many thanks

— Reply to this email directly, view it on GitHub https://github.com/fboundy/pv_opt/issues/284#issuecomment-2486920814, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASVRJMFVX5HJASPUV46YQHL2BO7EFAVCNFSM6AAAAABRMJ6GR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBWHEZDAOBRGQ . You are receiving this because you were assigned.Message ID: @.***>

[punkymuzzle]

This is the setting I am referring to (in the config.yaml)

update_cycle_seconds: 60

This is set towards the end of the .yaml file under the section:

=============================================================================================================== Brand / Integration Specific Config: SOLAX_X1:

These are the default entities used with the Solax X1integration. You can change them here and over-ride the defaults

Set it to 60 seconds and no adverse behaviour yet.

Is this the wrong setting?

I don't have the id_cycle_seconds in my .yaml file

[stevebuk1]

Yep that's the one!

On Tue, 19 Nov 2024, 23:17 punkymuzzle, @.***> wrote:

This is the setting I am referring to (in the config.yaml)

update_cycle_seconds: 60

This is set towards the end of the .yaml file under the section:

=============================================================================================================== Brand / Integration Specific Config: SOLAX_X1:

=============================================================================================================== These are the default entities used with the Solax X1integration. You can change them here and over-ride the defaults

Set it to 60 seconds and no adverse behaviour yet.

Is this the wrong setting?

— Reply to this email directly, view it on GitHub https://github.com/fboundy/pv_opt/issues/284#issuecomment-2486948128, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASVRJMHBBXJDO3LELUD4P532BPBJBAVCNFSM6AAAAABRMJ6GR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBWHE2DQMJSHA . You are receiving this because you were assigned.Message ID: @.***>

[punkymuzzle]

OK so I just went for it last night and tried it out end to end:

1. Installed the latest beta files from the earlier post - Worked OK
2. My charging schedule calculated OK with no issues. It had several charging slots allocated overnight. I wanted to charge my car overnight for approx 4 hours, which overlapped the charging slots. - Worked OK
3. Used the Automations and helpers I created (mentioned in earlier post ) to set the "prevent discharge" to switch on just before my car started charging, and to switch off just after my car stopped charging. Worked OK

I watched the 1W charging slot be inserted into the schedule just before the car charger started - Worked OK I watched as the original charging schedule kicked in at the right time (and the battery charged successfully) - Worked OK I watched as the next 1W charging slot was inserted into the schedule - Worked OK

In the morning I came down to a car that was fully charged as well as a battery that was charged as per the PV-Opt schedule, which is fantastic. Looking at the charging graph for my battery it showed that there was no discharge, as planned. So I reckon that it`s all working correctly.

Attached logs if you need them: main.log pv_opt.log error.log

my only two comments are:

1. When the charging slot completed and the next 1W slot was configured, there is a slight delay in applying the config to the inverter. This is obviously due to the update cycle, and is expected. So the way to minimise this delay is to make the update cycle as small as possible, which results in HA constantly recalculating. So there is a balance to be decided upon.
2. Regarding the automations and helpers I created, I will look to add some more, so we have more charging slots. I also want to look at how the times that are entered can be reset once used, to avoid them recurring at the same time if left as they are. Once I get this all up and running I will upload the yaml for the automations, helpers and dashboard so they can be included in the PV-Opt dashboard if you want.

Once again, huge thanks for working on this. Hopefully this can be added into the production version of PV-Opt, but please let me know if you need anything from me.

Thanks

[stevebuk1]

Pleased it all now seems to be working.

Regarding your observations:

• When the charging slot completed and the next 1W slot was configured, there is a slight delay in applying the config to the inverter. This is obviously due to the update cycle, and is expected. So the way to minimise this delay is to make the update cycle as small as possible, which results in HA constantly recalculating. So there is a balance to be decided upon.

Yes that's it. In general, the optimiser runs every 10 minutes. If it doesn't need to do anything with the inverter, it takes a minute or two complete. If if does need to do anything with the inverter, there is an additional 2 minutes (2 lots of "update cycle_seconds")

However, when you toggle Prevent_discharge, the optimiser will be triggered to run immediately, so its about 4 minutes for the toggle to take effect. This is a minimum though, this will be longer if done midway through a scheduled optimise, as it has to wait for that one to finish first. Not so convienient for your use case of preventing discharge if someone wants a shower.

The delays are unfortunately unavoidable as Pv_opt is reading the status of Prevent_discharge live. The ideal (long term) is that the particular 1/2 hour slots are all setup in advance, then there would be no delays because Pv_opt does the inverter loading 10 minutes before the slot starts. This functionality is mostly incorporated already as PV_opt can read the Intelligent Octopus Go car charging schedule and load all the prevent slots for the night, but thats a very bespoke format that the Octopus Energy Integration generates and it would be quite hard to generate that from a dashboard that has a number of start and end time pairs. I think the way forward on this is to simply have 48 slots in a some sort of drop down list (24 hours of 1/2 hour slots) and one simply sets each slot individually for whether discharge is presented? Or do you think say 3 pairs of start/end times would be sufficient?

• Regarding the automations and helpers I created, I will look to add some more, so we have more charging slots. I also want to look at how the times that are entered can be reset once used, to avoid them recurring at the same time if left as they are. Once I get this all up and running I will upload the yaml for the automations, helpers and dashboard so they can be included in the PV-Opt dashboard if you want.

Yes please, I'll add them into the repo and documentation.

Hopefully this can be added into the production version of PV-Opt, but please let me know if you need anything from me.

Theres a few things to iron out in the dev version (unrelated to this) but yes, the intention is to incorporate all of this into the production version.