Prevent Discharge?

[C00K50N]

@nathanmarlor I was wondering if it's possible - either from my end or with a tweak to the code - to prevent the battery discharging during the cheap period?

If you look at my statistics graphs below for the last 48hrs, you can see the first force charge this integration initiated was just before 06:00 yesterday [1]. Prior to that, the battery was prevented from discharging to cover the overnight load [2], which you can see from the SoC flat line [3] (ignore the SoC drop for now; that's a separate issue though a concerning one). However, when it had finished I noticed the schedules on my Fox app had reset to no longer prevent discharging.

So, our overnight load last night [4] was covered almost entirely by the battery rather than the grid. This quickly discharged the battery down to the set minimum of 10% before this integration successfully initiated the charge [5] from 04:50. Given the lower forecast generation today, the Capacity: Charge Needed last night said 14.04 kWh, so I was expecting it to have charged nearly to full last night. But it only charged to around 57% which I'm not sure will be enough for today.

Maybe it's OK allowing the battery to discharge fully then charging a bit, but when setting schedules manually I figured it was better to hold the existing charge, and use the grid for the load rather than discharging and recharging back to a similar level.

[nathanmarlor]

Thanks @C00K50N - really clear write up.

I've had similar thoughts regarding holding the battery SoC as soon as the off-peak period begins, however I came to the conclusion that the less we interact with Fox Cloud the better :) I'll probably look to implement this once we can write charge start/stop/hold commands via modbus. I imagine it can only have a positive effect on battery life. In the mean time I've been allowing the battery to discharge fully during the off-peak period and allowing the integration to charge back to the calculated level.

I think I understand what's going on here.. internally the integration creates a model of house load, forecast and battery state. This allows it to retrieve the expected battery capacity from any time in the future - i.e. capacity now is 10kw * 25% = 2.5kw, with an average house load of 16w/minute (~1kWh) in two hours time the capacity should be at 0.5kw. The final charge calculation (% target and start time) is performed at the start of the off-peak period (01:30 in your case) given all the information it has available at the time. If your usage is greater than usual once the % target and start time have been set, the actual SoC at charge time will be lower than it calculated and it won't be able to reach the target %. I guess a work around to this could be charging to the target % at the start of the off-peak window, then holding SoC until the window ends - needs some more thought :)

Could you add 'charge needed' to the screenshot above please?

[C00K50N]

That's great, many thanks for the detailed reply @nathanmarlor. That's what I suspected - the calculation is done at the start of the cheap period, but not performed until the end. So in the case of last night, I think it calculated we'd need to charge to full (it said 14.04 kWh needed), but because of the usage from 01:30 it didn't charge to full. I like your idea of charge to target % at the start of the period then hold the charge until the start of the peak period. That's how I was doing it manually. Or I guess have it the other way around - hold at the start of the period then charge at the end?

Or rather than do the final calculation at the start of the cheap period, can it continue to check throughout, so that if the % drops it's able to recalculate and start charging sooner?

Screenshots below - phone app from last night, then PC browser now...

[nathanmarlor]

The numbers from your screenshot at 23:00 look really odd... dawn time in 2 hours?

Can you screenshot history for all the calculated parameters?

[C00K50N]

Yeah, I spotted that but since I didn't really know what it was doing in the background I wasn't sure if it was OK or not. Here are some screenshots, if you can make sense of them! These are the main ones I guess could be useful, but let me know if you need any others...

[nathanmarlor]

Looks like the same behaviour I saw last night - the averages update at midnight for the previous two days, however a bug meant they were much lower than they should be, hence the drop in charge needed (as your expected load is now lower).

This should now be fixed.

[nathanmarlor]

@C00K50N - also worth mentioning that if you're using the Aux power fields, I fixed a bug this morning which was causing lower than expected house average calculations. This may be also be a factor. Worth updating to v1.0.2.

[C00K50N]

Thanks. Is that the +1kWh and Boost buttons? I hadn't been using them yet, but I'll update anyway.

[C00K50N]

Scratch that! I realise it's if we're ignoring devices from the total load, which I did with our Zappi. Hopefully all good after the update.

[nathanmarlor]

@C00K50N had a quick look at this today and knocked out a new build on develop (you should see 1.2.0 printed in the logs if you're feeling brave). The logic is as follows:

• at eco_start minus 5m: calculate the target % for the next day
• if current capacity is less than the totals, initiate a force charge at eco_start
  • otherwise allow the battery to discharge normally (minimises unnecessary grid usage)
• track the SoC until it reaches the target %
• hold the target %
• at eco_end release the hold and reset to min_soc as entered in the config

I'll test it tonight and see how it behaves :)

[C00K50N]

That logic sounds great! I'll not update at this end until you've tested it at your end, but this definitely sounds to me like it should work.

[nathanmarlor]

For reference, (and so I don't forget by tomorrow...!) the sensor purposes have changed slightly... Previously they'd be agnostic of any charging, but I've now updated them to account for the planned charge (or the forecasted values if a charge isn't needed). For my 10.4kw battery, given tomorrow's awful solar forecast it's planning a full charge (but still won't cover base load + all the buffer :( - 9.36 charge + 3.77 solar = 13.13 vs 12.02 peak + 2 buffer = 14.02)

[C00K50N]

Sounds like you've got it all worked out. Thank you! I can't quite get my head around all the numbers / sensors yet, but I'm sure I will.

For now, I have manually set it to prevent discharge for my whole cheap period (though it will have dropped to 10% by then anyway), and have hit your Full Charge button. Hopefully it will do the same as it did two nights ago, and not overwrite my manual settings until it's ready to charge. And I'm hoping it will charge to full since our forecast for tomorrow is also really poor.

[C00K50N]

Looks like the charge worked as intended last night - a full charge towards the end of the charge period. Next Dawn Time is still a bit odd - the below screenshots are just now. Perhaps it's getting confused because the rain and mist here is preventing the sun from being visible at all!

[nathanmarlor]

Perfect! The dawn time is calculated as the first moment in the day where the solar output is greater than the house load - i.e. the house is no longer being supported by the battery. Given the awful output today mine is also ~1pm... :(

The charge and hold worked well last night. I've tidied a few things up this morning and plan to release as v1.1.0 tomorrow morning.

[C00K50N]

Wonderful! I'll look out for the update.

[nathanmarlor]

@C00K50N really happy with how the integration performed last night so have released as v1.1.0 this morning -> https://github.com/nathanmarlor/foxess_em/releases/tag/v1.1.0 Let me know if it's better for you!

[C00K50N]

Wonderful! Thank you, I'll update at my end today.

[C00K50N]

@nathanmarlor looks like charge and hold worked perfectly last night for me. And the forecast is reasonable for me today, so it didn't charge too much. Happy days!

Thank you so much for your efforts putting this integration together! I don't know how long I would have spent muddling something together that no doubt wouldn't work anywhere near as well! I am very grateful, thank you.

[nathanmarlor]

@C00K50N really happy it's working out for you! Let me know if you experience any weirdness or have any ideas for new features :)