Mark Purcell

Continuing to be an issue, p_nom is 115200, but with an end_timestep constraint it allocates forecast power levels above p_nom. 

This issue only appears with the end_timestamp constraint. It seems to be it is trying to squeeze in additional power above p_nom in order to complete before the end_timestamp, but...

I'm not sure if it would be feasible it would be to set Constraints to ensure that _nominal_power_of_deferrable_loads_ & _minimum_power_of_deferrable_loads_ is honoured during each optimisation run. As a workaround it...

One interesting effect is text sensors are character limited to 255. If you have 48x intervals in Watt [12000, 13000, 14000, ...] each interval using 7 characters, 48x intervals requires...

> So are you suggesting this change is not viable due to the way that the array of load values is stored in an input_text? No suggesting quite the opposite....

This is not the expected outcome, I have seen similar results in the past which has usually been a consequence of incorrect input values. Can you update this issue with...

> - weight_battery_discharge: 0.5 > - weight_battery_charge: 0.5 Have you tried with lower weights? I generally find 0.05 or 0.1 creates my desired behaviour.

I have been setting discharge efficiency to 1.00 to workaround this issue.

> [@einarhauks](https://github.com/einarhauks) [@purcell-lab](https://github.com/purcell-lab) , can you assist pls? Thx. It has been working rock solid for me, I haven't done anything special with the setup. 

I have been doing some work using Riemann sum and utility meters to calculate the savings and cost benefits of both solar and battery. https://community.home-assistant.io/t/add-solar-cost-saving-option-to-native-energy-dashboard/376143/4?u=markpurcell