MalteSchm / OpenDTU-OnBattery-Controller

Variable energy price control for OpenDTU-OnBattery
6 stars 0 forks source link

More sophisticated charging/discharging algorithm #1

Open gitisgreat2023 opened 3 months ago

gitisgreat2023 commented 3 months ago

Currently the battery is charged when the electricity price drops below a certain threshold. If there's not enough solar energy available, it would be better to charge during the low cost hours and discharge during the highest cost hours and regularly use the grid during the other hours.

Did you consider to enable to be using this victron-tibber-ess-control code?

MalteSchm commented 3 months ago

Thanks for this hint.

I do see value in a more sophisticated approach but mostly on the discharge side. I have not found a way to deal with the unpredictable consumption however. Without knowing this in advance optimization can not really be done.

Charging has, in my experience, little room for optimization... At least in my scenario. During summer the battery is charged using solar. Energy prices are low when there is sunshine, but I don't need to AC charge / optimize this case. During winter energy prices are low when there is a lots of wind. I have fond this to be a long lasting scenario and I recall the batt frequently sitting fully charged for 1-2 weeks. There was no point using the battery at all during this time considering energy prices, losses and battery degradation

gitisgreat2023 commented 2 months ago

On the summer yes I agree. On winter: do I understand you correctly the differences in prices over the day are so small, that assuming a 15% round-trip loss on the battery it doesn't pay off to charge the battery during low prices (2-4 in the night) and discharge during peak hours (typically morning 6-9 and evening 19-21)?

MalteSchm commented 2 months ago

You also need to add about 5ct / kwh to account for battery wear. I used Pylontechs 6000 cycle promise here (which is probably optimistic) That and your other points -> Yes that is what I observed.

I pay about 19ct / kwh when the EPEX price is 0ct due to taxes and other costs. Using your 15% losses this starts to hit break even at 27.3ct. So it only makes sense if you see peak prices of lets say 30ct. You don't get this situation often.

When I did the math I calculated with 20% losses and 6ct / kwh. This makes this even less attractive.

gitisgreat2023 commented 2 months ago

Okay you add in the wear of the battery. I don't do that. I have about 250 cycles a year with solar only (yeah I utilize the battery quite well, it's a little too small for my energy consumption and profile). That implies with 6000 cycles lifetime 24 years of usage, which is longer than than I expect it will last. So extra cycles in winter don't cost me extra, the marginal costs are 0. With 19 cents and 15% loss my break-even is thus 22.4 cents. The 15% I measured myself and I only achieved thanks to you, enabling using OpenDTU-OnBattery with Huawei chargers.

MalteSchm commented 2 months ago

Understood. There will be also aging over time. The truth is probably in the middle. Charging will have some effect but it may not be the only factor to consider here.

gitisgreat2023 commented 3 weeks ago

Agree. One question on how to configure the flows: I don't have an MPPT and no Car Charger either (yet ;-)). I'm not sure how I have to configure the DPL flow. Above the "DPL active from" it uses the battery to discharge, if necessary, right? Below that price, say 9.5ct, it doesn't discharge the battery anymore but instead uses the (cheap) grid power. But the charger still works, if there is a solar surplus, is that right? Now that leaves me with the "Solar PT to car from" value. How should I set that? I still want that surplus solar power is used to charge the battery under all circumstances.

MalteSchm commented 3 weeks ago

Agree. One question on how to configure the flows: I don't have an MPPT and no Car Charger either (yet ;-)). I'm not sure how I have to configure the DPL flow. Above the "DPL active from" it uses the battery to discharge, if necessary, right? Below that price, say 9.5ct, it doesn't discharge the battery anymore but instead uses the (cheap) grid power. But the charger still works, if there is a solar surplus, is that right? Now that leaves me with the "Solar PT to car from" value. How should I set that? I still want that surplus solar power is used to charge the battery under all circumstances.

This is all correct. The Solar PT (pass-through) to the car handles the case when the car is charging. If this case is detected and the price is over the configured value then the inverter is steered based on the energy reported from the MPPT. The whole system works like an regular inverter in this case. This is done because the car will use the AC energy for charging. Without a car you can set this value to a very high value.

gitisgreat2023 commented 3 weeks ago

Yesterday at a SoC of 67% the flows apparently stopped the Huawei Charger. Till now I don't understand why that happened. I thought the charger itself had an issue, after an hour or so I thought the scripts caused it, because the Status of the Huawei in the dashboard said inaktiv. Stopping the scripts started the charger again, I was happy because it was a sw failure not hw... :-)

My settings: DPL Aktiv ab -40 cent, Solar PT 1000 cent. Huawei charger Voll aktiv ab -20 cent, Batterie voll bei 100%, 4800Wh.

I just looked at the Transform function in Huawei Netzteil: line 58-69

//node.warn("Expected: " + expected_energy);
if (expected_energy * 0.7 < (battery_capacity * (100 - soc) / 100)) {
    msg.payload = 3;  // Use auto power in this case
    msg.current = 0;  
    msg.text = "Automatisch";
    return msg;
}

msg.payload = 2;  // Let openDTU disable the PSU ...
msg.current = 0;  // ... as we set current to 0A here
msg.text = "Inaktiv";
return msg;

I think this caused the PSU to stop charger. Probably because the expected energy for the day was enough to charge the battery... it stopped the charger?!

Wait... is that because you have a MPPT charger, and the Huawei is only used to charge additionally the battery (using a surplus from other PV modules, not connected to the MPPT charger)? Then I understand the logic... With a safety margin of 30% the battery is fully charged using the Garage modules connected to the MPPT.

Apart from that: how do I actually stop the flows being active? I had to completely stop the Red Node instance to get the charger working again.

MalteSchm commented 3 weeks ago

Wait... is that because you have a MPPT charger, and the Huawei is only used to charge additionally the battery (using a surplus from other PV modules, not connected to the MPPT charger)? Then I understand the logic... With a safety margin of 30% the battery is fully charged using the Garage modules connected to the MPPT.

That is exactly the point. If you don't want this you can change the code or use an inject node to inject a high number for the expected energy.

Why you had to start the Red Node instance is not clear to me. It might be important to understand that flows are generally triggered by something. This can be input messages or a timer. In the case of OpenDTU control the flows generate a control message every minute or so. So every time you make a change on the UI it will take some time for the system to respond.

It may also be important to re-iterate that I considered this controller as a starting point for an own Node Red flow. The setups differ and most people have different wishes.

gitisgreat2023 commented 2 weeks ago

Thanks! Don't get me wrong, please. I'm very happy you share the code, it's an excellent starting point! I was just puzzled and couldn't get my head around it. Now I got it... I solved it, it works now!