I've just switched back to Octopus Go for the winter and need to redo all my automation.
I think I've sorted all the SMARTTARGET stuff in GivTCP but it is still showing 100%. Is there a certain time it calculates the target? Can I force it to do the calculation in some way?
naltsta it does it 10 minutes before off peak rate starts I think. As the forecast should be more accurate the closer you get to it.
naltsta note that the default configuration has October as a winter month so it will always charge to 100%. Check your settings.
SmartTarget runs just before your off-peak period starts.
My standalone version of PALM runs a second time an hour before the end of the cheap period in case the weather has changed, that improvement hasn't made it into the HA integration yet. The standalone version can be run immediately and also works with Cosy and Intelligent Octopus.
stevelewis Thanks - I'd made October a shoulder month but will check to see if it adjusted in the morning. Thanks
stevelewis success this morning! Thanks
Pretty impressed with the calculation too - only exported a tiny bit this afternoon.
Next question - can I turn off SMARTTARGET on the weekend when I'm likely to use more power? Don't think the GivTCP settings are accessible to automate...
naltsta no, but you can weight the consumption calculations to favour the same day a week ago.
stevelewis 1,1,1,1,1,1,5 coming up
Quick question for you stevelewis, is it possible to configure SMARTTARGET to work with the Octopus Cosy tariff that has two off-peak periods per 24hrs? (4-7am and 1-4pm offpeak, with 4-7pm at a higher peak and the rest of the day at standard rate). In GivTCP there are only a single start/end time you can configure, is there a way to get SMARTTARGET to work with two?
Barns The simple answer is yes, it's being used with Cosy. The longer answer is:
The SmartTarget feature in GivTCP uses a version of my PALM code that runs once at the start of the overnight charge period to set the target Soc for the coming day. As most of the generation occurs before 4pm, adding a fixed second charge in GivTCP works fine. Any excess charge gets used overnight, for example on water heating.
The standalone version of PALM (www.github.com/salewis38/palm) also supports Cosy and has improvements that haven't yet made it into GivTCP. One of these is to run the simulation twice: at the start of the overnight off-peak period and also an hour before the end to adjust for any changes in generation forecast due to the weather. The afternoon charge period varies according to the season. It's also fairly easy to edit the code if you want it to do something slightly different.
stevelewis This sounds great and more importantly for me, very geeky and something to tinker with for hours 🙂 Can you run the standalone version via Home Assistant in some way? Still getting up to speed with what is (elegantly) possible and not.
Barns not within HA, but certainly on the same device. The standalone version runs best as a service in Linux.
Barns have a look at the “speak to the geek” YouTube video on solar predictors
I’ve personally adopted predbat which runs every 5 minutes so continually updates the forecast and charge/discharge actions based on soc, house load, actual PV etc. It will work fine with the multiple cosy periods.
It does however have quite a learning curve to it, it’s easy enough to get going but it did take me several days to tweak the settings to the point that I was happy with its actions.
Palm inside givtcp is much simpler
geoffreycoan I'd seen mention of predbat but it had seemed a bit overkill, at least until I've just recently actually started thinking more about the solar prediction problem myself. Now it sounds like I might have to investigate that also. Just in time for lack of appreciable solar for months!
Barns the prediction method in both PALM and Predbat is very similar and the savings achieved will be much the same.
The main difference is that Predbat is generic and works with Agile, whereas I've focused on fixed-time tariffs and a simpler configuration. At the last count, Predbat had about 3x the lines of code.
Barns I was similarly motivated. I’d been fine up to now but the shorter days mean on cloudy days the batteries don’t see me through on solar charging alone.
I had my own scripts to manage the flux peak discharge but didn’t want to have to roll my own calculator for the overnight charging. Only been live on predbat for about a week.
Gives you something to do on the darker evenings !
stevelewis I would think predbat is going to give better savings as it runs every 5 minutes to adjust the charge and discharge plan. Particularly useful if you’ve used more electricity from the battery than expected (so smaller flux export required) or more solar than predicted was generated. Either predbat or palm is a well supported option
stevelewis next question! What does the solcast weighting factor do? My solcast predictions are pretty accurate - should I turn this up from the default 35?
geoffreycoan Not so. Predbat's 5-minute cycle time isn't of any benefit for off-peak tariffs: the generation forecast doesn't change that quickly and once the off-peak period is over, no action can be taken to improve the overnight battery charge. The second-pass calculation in PALM an hour before the end of the off-peak period typically corrects the SoC target by <10% over the single-pas currently in HA.
naltsta The solar generation forecast is a probability curve and the Solcast website supplies three sets of estimates: a worst-case (P10), typical (P50) and best-case (P90). The 35% weighting applies a combination of the P10 and P50 estimates (it's not really P35, but it's close enough). On a cloudless, still, summer's day, the three estimates will be almost on top of each other but it's a very different story with changeable weather. Two examples from my setup over the past month: 18/25/26 and 4/8/16. Increasing the weighting factor equates to taking a greater risk of generation falling short of the prediction. You want the odds to be stacked in your favour to avoid unnecessary import and 35% seems to be a good number.
stevelewis when I’m importing at 9p/kWh and exporting at 8p/kWh I’m half tempted to just set it back to 100%.
If I set a smart target I can make tiny gains with a risk of losing big!
naltsta with those rates and conversion losses, you're right to set at 100% and leave alone. I'm on an old FIT arrangement with deemed export so the sums are not the same.
stevelewis I thought when comparing various methods you were better off charging from solar as DC to DC had smaller losses?
Still only talking about pennies per day I could save though
stevelewis geoffreycoan Not so. Predbat's 5-minute cycle time isn't of any benefit for off-peak tariffs: the generation forecast doesn't change that quickly and once the off-peak period is over, no action can be taken to improve the overnight battery charge
Fair point. I’m on flux and am still getting more than enough solar to run me through a day and to the overnight cheap period. I’m also still doing peak rate exports to minimise my electricity bill. So in my case the more frequent predbat runs to optimise the export are worthwhile IMHO.
