Boffinboy commented 1 year ago

Hi there, I am considering switching to Cosy - though I have A2A not A2W - and was wondering how the second charge slot works? I remember you said it is no longer dependent on CO2 figures. My goal is to charge overnight, then also recharge in the second slot, to effectively ensure I am constantly using low rate.

salewis38 commented 1 year ago

Hi, the code is still there for the second slot, but I've never used it myself (I thought about Cosy, but moved to IO instead). It's easy enough for me to tweak the code to do most things. Maybe separate % SoC targets for the afternoon periods in shoulder and winter months and disable in the summer?

Boffinboy commented 1 year ago

Thank you. We had been discussing but I didn’t get a chance to test as I never needed to through the summer! Sometime in mid September, definitely by October, I will switch tariff. Having a second charge slot that could be modified threshold wise etc would be great. What triggers the second charge period currently?

At the moment I run different tariffs May-Aug where I get more solar than usage (Flux, as I am on SEG not FIT) and the rest of the year where I use more than I generate (E7, or may try Cosy if they accept my A2A). Rather than have it all in one settings file I just created two versions (as I run in Docker), but would be good to have the functionality you describe.

Technically on Flux it’s helpful to “pause” the battery during the peak export rate period, so all solar goes to the grid, but I can do that on Home Assistant once I get that setup.

salewis38 commented 1 year ago

Simply putting the start and finish times in the palm_settings.py file will cause the boost to run every day during the winter months with a SoC target of 100%. That's all there is to it.

You can use PALM to pause the battery by adding your own lines into palm.py. It would be very similar logic to the afternoon boost, just replace "charge_now" with "pause" and "set_soc_winter" with "resume".

Boffinboy commented 1 year ago

Thank you. How hard would it be to modify the % setting for the boost (whether in general, or by season)?

I will take a look and see if I can figure out the pause. I’m not very experienced, takes a lot of trial and error! I would actually want to do something slightly more complex as I would want the battery to supply load, but not charge (ie just pause charging, not fully pause all battery functions), I assume this requires different settings on the inverter.

springfall2008 commented 1 year ago

If you disabled charging then the solar would be used or exported

but why not force export during the period, this is what predbat will do if it pays to do so?

Boffinboy commented 1 year ago

If you disabled charging then the solar would be used or exported

but why not force export during the period, this is what predbat will do if it pays to do so?

I have looked at doing this, but as a high user and with a SSE orientated solar array I have very little I can force export in that period without then using standard rate electricity, which cancels out the benefit. Pausing battery charging would be a happy medium.

salewis38 commented 1 year ago

A few minutes of cut & paste later...

To pause only charge or discharge, change the "pause" command to "pause_charge" or "pause_discharge".
Setting the boost to a variable involves replacing "charge_now" with "charge_now_soc" after setting the variable inverter.tgt_soc to the desired value.

Boffinboy commented 1 year ago

A few minutes of cut & paste later...

To pause only charge or discharge, change the "pause" command to "pause_charge" or "pause_discharge".

Setting the boost to a variable involves replacing "charge_now" with "charge_now_soc" after setting the variable inverter.tgt_soc to the desired value.

Thank you so much! You are amazing! Can I buy you a coffee?! I will take a look and see how to set a variable. Presumably it would be possible to add this as a variable in the settings file? Never done anything in python before or even programming / scripting for about 25 years, so figuring it out by looking at your code!

If I have time this weekend I may try forking and creating three scenarios for summer (pause charge), shoulder (charge up to X%), winter (charge up to 100%)

salewis38 commented 1 year ago

Cosy mode now charges as proposed: off in summer, X = the shoulder overnight SoC depth in palm_settings.py and 100% in winter.

See line 593 onwards in palm.py for the detail and enjoy your weekend ;-)

Boffinboy commented 1 year ago

Thank you so much! Crazy week at work but hopefully I’ll have time to build a new container 👍

Boffinboy commented 12 months ago

Hiya, was just looking at the code to convert to a pause of charging whilst I am still on the Flux tariff for a few more days.

Noticed a couple of things that I wondered may not be quite right. 1) in the series of “ifs” starting line 595 in palm.py the final if assumes it should always be reset to set_soc_winter - as I read it that will happen even if you are in a shoulder month. Should that be the case? 2) in the next block of code it looks like there is some duplicated code for the boost, which presumably is no longer needed?

salewis38 commented 12 months ago

Hi, Thanks for the feedback.

Item 1 is fine. It resets the start and finish times and 100% SoC target in anticipation of the subsequent overnight period. The actual % then gets calculated just before the start of the period. Good shout on Item 2, now removed.

On Sat, 9 Sept 2023 at 15:45, Boffinboy @.***> wrote:

Hiya, was just looking at the code to convert to a pause of charging whilst I am still on the Flux tariff for a few more days.

Noticed a couple of things that I wondered may not be quite right. 1) in the series of “ifs” starting line 595 in palm.py the final if assumes it should always be reset to set_soc_winter - as I read it that will happen even if you are in a shoulder month. Should that be the case? 2) in the next block of code it looks like there is some duplicated code for the boost, which presumably is no longer needed?

— Reply to this email directly, view it on GitHub https://github.com/salewis38/palm/issues/14#issuecomment-1712528471, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALAPCY6GTATDMS4X4MJRZ5LXZR6HXANCNFSM6AAAAAA4JEC3QM . You are receiving this because you modified the open/close state.Message ID: @.***>

Boffinboy commented 12 months ago

Sorry to keep asking questions, but your advice is so helpful! I am looking at modifying the behaviour in the charge periods (both boost and overnight) to pause battery discharge. I want to avoid using stored battery charge when electricity is at cheap rate, saving it for when normal rate resumes. This is only an issue if the battery starts the charge periods above the target SoC, which can happen on sunny days, where it then runs down to the target SoC.

I assume I could do this by adding a charge pause and charge resume within the boost section, but am less certain how to add this in the main SoC charge period.

On another note, am testing my flux hold charge modification today.... have made it dependent on a "flux month" variable in settings - let's see if I got my coding right! Haha

salewis38 commented 12 months ago

Quick answer: read the current SoC and set the target to the max of either the computed SoC or the actual.

On Sun, 10 Sep 2023, 10:01 Boffinboy, @.***> wrote:

Sorry to keep asking questions, but your advice is so helpful! I am looking at modifying the behaviour in the charge periods (both boost and overnight) to pause battery discharge. I want to avoid using stored battery charge when electricity is at cheap rate, saving it for when normal rate resumes. This is only an issue if the battery starts the charge periods above the target SoC, which can happen on sunny days, where it then runs down to the target SoC.

I assume I could do this by adding a charge pause and charge resume within the boost section, but am less certain how to add this in the main SoC charge period.

On another note, am testing my flux hold charge modification today.... have made it dependent on a "flux month" variable in settings - let's see if I got my coding right! Haha

— Reply to this email directly, view it on GitHub https://github.com/salewis38/palm/issues/14#issuecomment-1712758063, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALAPCY5JCY553CWYDO5OJVDXZV6WNANCNFSM6AAAAAA4JEC3QM . You are receiving this because you modified the open/close state.Message ID: @.***>

springfall2008 commented 12 months ago

FYI in predbat I just added a pause mode where it sets the battery charge rate to 0 to export, it’s a step before forced export

salewis38 commented 12 months ago

PALM also has a Pause mode. For overnight cheap rates, I wouldn't recommend using a pause as the battery may recalibrate and end the night with a SoC that's below target. setting SoC to the current reading avoids waking up to a flat battery :-)

On Sun, 10 Sept 2023 at 13:08, Trefor Southwell @.***> wrote:

FYI in predbat I just added a pause mode where it sets the battery charge rate to 0 to export, it’s a step before forced export

— Reply to this email directly, view it on GitHub https://github.com/salewis38/palm/issues/14#issuecomment-1712797036, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALAPCY6YZZGO57BHDOLI5XLXZWUVBANCNFSM6AAAAAA4JEC3QM . You are receiving this because you modified the open/close state.Message ID: @.***>

Boffinboy commented 12 months ago

Quick answer: read the current SoC and set the target to the max of either the computed SoC or the actual.

Ah, an elegant solution! I was thinking about pausing discharge, and resuming, but no need to do that! Will see if I can figure it out next weekend for the cheap and boost periods. Have run out of time this weekend after seeing if my pause charging has worked (first attempt I made a typo in the code) - and it all has a fairly steep learning curve doing it for the first time.

FYI in predbat I just added a pause mode where it sets the battery charge rate to 0 to export, it’s a step before forced export

Thank you. I took a look at predbat and it looked comprehensive, but would require a number of additional steps for me to get setup on my Synology. Given how good PALM is I am happy with making tweaks here or there if I have time, and salewis38 has been very generous in making useful updates frequently.

salewis38 commented 12 months ago

Try something like this. It's not the most elegant solution, but it avoids editing the common palm_utils.py library.

palm.py, current line 558:

inverter.set_mode(inverter.compute_tgt_soc(pv_forecast,

stgs.Solcast.weight, True))

Replace with

inv_cmd = inverter.compute_tgt_soc(pv_forecast, stgs.Solcast.weight,

True)

if inv_cmd == “set_soc”:

    inverter.tgt_soc = str(max(int(inverter.soc),

int(inverter.tgt_soc)))

inverter.set_mode(inv_cmd))

On Sun, 10 Sept 2023 at 16:33, Boffinboy @.***> wrote:

Quick answer: read the current SoC and set the target to the max of either the computed SoC or the actual.

Ah, an elegant solution! I was thinking about pausing discharge, and resuming, but no need to do that! Will see if I can figure it out next weekend for the cheap and boost periods. Have run out of time this weekend after seeing if my pause charging has worked (first attempt I made a typo in the code) - and it all has a fairly steep learning curve doing it for the first time.

FYI in predbat I just added a pause mode where it sets the battery charge rate to 0 to export, it’s a step before forced export

Thank you. I took a look at predbat and it looked comprehensive, but would require a number of additional steps for me to get setup on my Synology. Given how good PALM is I am happy with making tweaks here or there if I have time, and salewis38 has been very generous in making useful updates frequently.

— Reply to this email directly, view it on GitHub https://github.com/salewis38/palm/issues/14#issuecomment-1712844253, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALAPCY2I7FLPAEEVUI35IKTXZXMU7ANCNFSM6AAAAAA4JEC3QM . You are receiving this because you modified the open/close state.Message ID: @.***>

Boffinboy commented 12 months ago

Thank you. Will see if I can test next weekend - though I guess low likelihood of being able to test with the reducing sun! I could manually charge up to fill in the day to then test it overnight I suppose, but at the moment I imagine the SoC will want to charge to fill pretty regularly (unless I change solcast threshold)

Boffinboy commented 12 months ago

Just one question, is there an extra closing bracket at the end of the new code intentionally? Or is that an error? Counting them up it looks to be unneeded?

salewis38 commented 12 months ago

Brackets should always match

On Mon, 11 Sep 2023, 12:27 Boffinboy, @.***> wrote:

Just one question, is there an extra closing bracket at the end of the new code intentionally? Or is that an error? Counting them up it looks to be unneeded?

— Reply to this email directly, view it on GitHub https://github.com/salewis38/palm/issues/14#issuecomment-1713690998, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALAPCYZNIMO2STWKV4QDXELXZ3YTFANCNFSM6AAAAAA4JEC3QM . You are receiving this because you modified the open/close state.Message ID: @.***>

Boffinboy commented 11 months ago

Hi Steve - finally switched to cosy and testing this out. Last night overmorrow protection triggered, and then I got an error "unable to set SOC". Could I have done something wrong with the code you shared that would break the standard setting routine? PALM appears to be communicating with the inverter fine as the other registers eg charge times, have been written OK earlier in the day when I first ran it. I have forked your build - is there a way I can show you where I made the edit? I'm slightly worried I got the syntax wrong. Ps don't know why I said Steve! Hopefully that's right...

Boffinboy commented 11 months ago

this is the code I have, based on the above suggestion you made. Presumably I must have made an error, and therefore it's triggering an exception


                try:
                    inverter.get_load_hist()
                    logger.info("Forecast weighting: "+ str(stgs.Solcast.weight))
                    inv_cmd = inverter.compute_tgt_soc(pv_forecast, stgs.Solcast.weight,True)
                    if inv_cmd == "set_soc":
                       inverter.tgt_soc = str(max(int(inverter.soc), int(inverter.tgt_soc)))
                    inverter.set_mode(inv_cmd)
                except Exception:
                    logger.error("Warning; unable to set SoC")

salewis38 commented 11 months ago

Hi, I've seen the same here twice recently, so it's not something you're doing wrong. It's highly intermittent and I've been unable to replicate it. Not much happens between the overmorrow message and the end of the routine to set the SoC target so I'll update the code to display the exception.

Boffinboy commented 11 months ago

Thank you. I am terrible at using GitHub so I have re-forked and will also try making these edits. I am using the web interface and having never used it before couldn’t figure out how to selectively merge commits. I have also gone into the palm utils and added settings to pause discharge during the boost period. Going to try again and see if this weeks.

Boffinboy commented 11 months ago

Will see if hopefully it works OK tonight and if not then the new code will give more insight.

I noticed a potential bug as well, with the coding around set_soc_winter at the end of the boost period, it does not reset the end time if the current month is not a winter month. This can leave the boost running. In my fork I made a few edits:

added a new line that sets the end time in set_soc_winter even if current month is not in winter, which addresses the above bug
changed the boost settings to pull the timings from settings, rather than hard-coding times (means if for some reason it doesn’t reset to default then the timings are still set at a low rate period)
added a line to charge_now and charge_now SoC to pause battery discharge - on the assumption that one doesn’t want to use the battery but use the low rate electricity (this could be made conditional on a setting, in case you thought it was useful to go in your main version); added a line to set_soc_winter that restore discharge to 3000

salewis38 commented 11 months ago

Good catch on set_soc_winter!

I can see what you're thinking for the second item, I want to keep the generic commands in palm_utils as this file gets used by multiple programs... could create a separate entry for "charge_now_boost" or be clever by parsing optional parameters.

The idea behind "charge_now_soc" was to replicate the functionality of the overnight charge and aim for a target soc, whether higher or lower than the current. To avoid discharge, I'd avoid touching the power registers and instead amend line 608 in palm.py: From: inverter.tgt_soc = str(stgs.GE.max_soc_target) To: inverter.tgt_soc = str(max(stgs.GE.max_soc_target, inverter.soc))

Boffinboy commented 11 months ago

That makes a lot of sense to want to keep things clean and clear in the shared palm_utils.

Re: the alternative approach, I should have thought about that! I am always time limited when I get a chance to tinker, and don’t know python, so I go with what I can figure out quickly based on your existing code. I am hopeful with the latest edits it will now see me through to summer and switching back to Flux, with any changes or updates becoming “nice to have”.

I will see tonight whether the updates charge code you provided works OK. I had never had that error before, but it could of course be coincidence. I also don’t think I’ve ever had the overmorrow triggered before (whilst on Flux I used the p10 forecast as I wasn’t worried about overcharging)

Boffinboy commented 11 months ago

Well, the calculation and write seems to have worked but I got a different error related to the AC3 fix. Could the new code to chose the higher of current or target soc cause this?

salewis38 commented 11 months ago

Yes, there's an error in the new code.

"inverter.tgt_soc = str(stgs.GE.max_soc_target)" should be "inverter.tgt_soc = int(stgs.GE.max_soc_target)"

The joys of python's on-the-fly type changes! I've added a hard definition of integer for tgt_soc in palm_utils.py and corrected in my repo.

Boffinboy commented 11 months ago

Thanks! I wondered if it might be that. Will carry over that edit

Boffinboy commented 11 months ago

I made the edit to palm.py but forgot to do palm_utils and last night it failed again, with a different error “unsupported operand types(s) for -: ‘int’ and ‘str. I will edit palm_utils ans well and check again tonight.

Sorry for another naive question, but should other instances of soc be changed as well to be integers. E.g. in palm_utils things like set_inverter_register("77", str(self.tgt_soc))? I don’t think this should matter for the new logic, but I wanted to check.

Boffinboy commented 11 months ago

To be clear, this is happening when setting the SoC right before the off peak, and 1 hour before the end of the off peak. I edited the lines you suggested: ` try: inverter.get_load_hist() logger.info("Forecast weighting: "+ str(stgs.Solcast.weight))

inverter.set_mode(inverter.compute_tgt_soc(pv_forecast, stgs.Solcast.weight, True))

                inv_cmd = inverter.compute_tgt_soc(pv_forecast, stgs.Solcast.weight, True)
                if inv_cmd == "set_soc":
                    inverter.tgt_soc = int(max(int(inverter.soc), int(inverter.tgt_soc)))
                inverter.set_mode(inv_cmd) `

I have left the original line in there, but commented out

salewis38 commented 11 months ago

No, that's correct as its converting the integer to a string to write it to the inverter.

On Tue, 26 Sep 2023, 08:48 Boffinboy, @.***> wrote:

I made the edit to palm.py but forgot to do palm_utils and last night it failed again, with a different error “unsupported operand types(s) for -: ‘int’ and ‘str. I will edit palm_utils ans well and check again tonight.

Sorry for another naive question, but should other instances of soc be changed as well to be integers. E.g. in palm_utils things like set_inverter_register("77", str(self.tgt_soc))? I don’t think this should matter for the new logic, but I wanted to check.

— Reply to this email directly, view it on GitHub https://github.com/salewis38/palm/issues/14#issuecomment-1735009710, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALAPCY6GZZSOUXC4RSPFOBTX4KCFXANCNFSM6AAAAAA4JEC3QM . You are receiving this because you modified the open/close state.Message ID: @.***>

Boffinboy commented 11 months ago

Thank you. Hopefully it will work tonight with the edits to palm_utils

salewis38 commented 11 months ago

Can you run it in test mode now with the -t option on your setup. It would spare you the waiting.

Boffinboy commented 11 months ago

So, odd behaviour overnight today. The first SoC calculation gave the same type error. The second SoC calculation 1 hour before the period worked and wrote to the inverter OK. Does that one use a different part of the script? Am I just doing something silly? I have carried over the edits you had made, and was using the code pasted above

salewis38 commented 11 months ago

It sounds like it's initialising a variable as an incorrect type and then dynamically changing it later on to the correct type so the problem gets fixed. Do you have a line number in the error message? Check your palm_settings.py file for integers with quotation marks.

On Wed, 27 Sep 2023, 06:36 Boffinboy, @.***> wrote:

So, odd behaviour overnight today. The first SoC calculation gave the same type error. The second SoC calculation 1 hour before the period worked and wrote to the inverter OK. Does that one use a different part of the script? Am I just doing something silly? I have carried over the edits you had made, and was using the code pasted above

— Reply to this email directly, view it on GitHub https://github.com/salewis38/palm/issues/14#issuecomment-1736732829, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALAPCYZSSIZOUMGXELZVM5TX4O3ODANCNFSM6AAAAAA4JEC3QM . You are receiving this because you modified the open/close state.Message ID: @.***>

Boffinboy commented 11 months ago

Thank you. No integers in quotation marks in the settings file. The only bit that's changed that could cause this error is the new code snippet comparing current soc to target soc, and I've adjusted to "int" in there. Could current soc be read as a string or something? This is a bit over my head! I note the "if" looks at the string "set_soc"?

salewis38 commented 11 months ago

I'm away on business at present so will take a look when I get home. Using a string in an if statement is fine, comparing a string with an integer or trying to do maths on them as a pair that would be an issue.

On Wed, 27 Sep 2023, 09:16 Boffinboy, @.***> wrote:

Thank you. No integers in quotation marks in the settings file. The only bit that's changed that could cause this error is the new code snippet comparing current soc to target soc, and I've adjusted to "int" in there. Could current soc be read as a string or something? This is a bit over my head! I note the "if" looks at the string "set_soc"?

— Reply to this email directly, view it on GitHub https://github.com/salewis38/palm/issues/14#issuecomment-1736920371, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALAPCY3ULT4OJWYZJZ6LAXLX4POE7ANCNFSM6AAAAAA4JEC3QM . You are receiving this because you modified the open/close state.Message ID: @.***>

Boffinboy commented 11 months ago

No problem. The issue appears to have resolved itself last night. My assumption is on the first run it was stored as a string, corrected to an integer by the code, and now remains stored as an integer. So long as it continues to work it's not an issue - even if it bugs me to not understand where it's coming from! Will see if it works again tonight. Thanks as ever for your help.

salewis38 commented 11 months ago

I think I've fixed the issue in the updated palm_utils.py

Boffinboy commented 11 months ago

Thanks. Were there additional changes beyond what you made previously? It seems to be running fine now, and I carried over the previous, so I'm reluctant to fiddle further!

salewis38 commented 11 months ago

It's just today's change in the chart data generation code that fixed the issue.

On Mon, 2 Oct 2023, 22:06 Boffinboy, @.***> wrote:

Thanks. Were there additional changes beyond what you made previously? It seems to be running fine now, and I carried over the previous, so I'm reluctant to fiddle further!

— Reply to this email directly, view it on GitHub https://github.com/salewis38/palm/issues/14#issuecomment-1743765855, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALAPCY45JXTGC5J3A5ZOC2DX5MUFHAVCNFSM6AAAAAA4JEC3QOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBTG43DKOBVGU . You are receiving this because you modified the open/close state.Message ID: @.***>

Boffinboy commented 11 months ago

Ah, thank you! I will incorporate it into my fork at the weekend. Interesting to see you adding the intelligent octopus support. No EV here, but hopefully will have one in future.

salewis38 / palm

Second charge slot (for cosy) #14

inverter.set_mode(inverter.compute_tgt_soc(pv_forecast, stgs.Solcast.weight, True))