helgeerbe / OpenDTU-OnBattery

Software for ESP32 to talk to Hoymiles Inverters and Victrons MPPT battery chargers (Ve.Direct)
GNU General Public License v2.0
290 stars 62 forks source link

Power limiter without battery stops inverter #237

Closed spcqike closed 6 months ago

spcqike commented 1 year ago

What happened?

If you use dynamic power limiter without battery it stops the inverter after a few seconds. You can manually restart the inverter but it gets stops shortly after.

To Reproduce Bug

Setup Dynamic power limiting without connected battery

Expected Behavior

Ignore or opt out battery to limit power that gets feed in to the grid.

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

1c7b7d3

Relevant log/trace output

No response

Anything else?

I use MQTT topic to get the power of the grid tied meter. Lower inverter limit to 150 and upper to 600, allowed grid meter to -50, hysteresis to 10.

It starts with something 50W above my actual consumption, which is fine. Shortly after it limits to lowest limit (150) and than stops the inverter completely.

edit: today i tested again. this time i set all battery values to zero (SoC start and stop, DC voltage start and stop) and it looks like it is working. so, i guess, one could change the label from bug to enhancement, to maybe create a toggle switch to opt-out (or opt-in) a battery at all. (or maybe move dynamic power limit settings to power meter tab as it could be used, regardless of whether a battery is used or not)

Xenon-s commented 1 year ago

Unfortunately, I can confirm this. Even if you set everything to 0 for the battery, the inverter no longer responds.

helgeerbe commented 1 year ago

Is my understanding correct, that we don't need any code changes for that? Is it good enough to introduce a switch in PowerLimter "No Battery support", that will set default values and make the corresponding UI fields unchangeable?

What are the right settings, and does it fit for all scenarios when power limiter is used without battery?

spcqike commented 1 year ago

i guess we don't need code changes, if we have a switch that, if enabled (or disabled) pre-sets some values to let it work.

but, as also a switch is a code change, wouldn't it be easier to use this switch and not pre-set the existing fields, but change the PL logic to skip certain calculations accordingly? because, that what it is. without battery one can skip all ve.direct and solar pastrough related things. no stop if battery voltage is to low and threshold check to re-start the inverter.

at least thats what i used in my local branch, with my other changes to the PL logic (over limiting if one module is shaded, but the other isn't). and, if this idea isn't canceld, as i thought @schlimmchen wanted to make some changes and send a proposal, i think i would start in this direction. like "plain production" without extras like VE.direct, CAN, Passtrough, ... only PowerMeter and a target power consumption with hysteresis.

but, as i said, to use DPL, i need to set all battery voltages to 0 (because that results in an always "enough battery voltage" condition", i need to activate solar passtrough and empty at night (but i guess this is unrelated, i never changed it, but i guess solarpasstrough and a "filled" battery is enough to trick the calculations)

schlimmchen commented 1 year ago

@spcqike I am still interested in providing an implementation that does what you want (but hopefully in a way that works for all inverters that are connected to solar panels rather than a battery). However, I have so many ideas in my head and also have my own issues that I want to address and only so little time (in comparison) to do it... I am sure you can understand. I am indeed busy making more contributions.

Regarding this particular issue, which is more about support for non-battery-systems rather than over-provisioning the inverter: I sill think that it would be a valuable feature to support systems without a battery. Having said that, I also think that supporting systems with some inverters connected to the (one and only) battery and others to solar panels is also a valuable feature (looking at myself in particular). This makes an important difference, because even though your idea of introducing a new mode of operation for the DPL to support your scenario makes a lot of sense, it would be even better if the DPL logic decides per inverter and per the inverter's settings what its power limit should be, so that the overall goal (regulating the household grid consumption) is achieved.

That's a long shot...

That's why I agree with @helgeerbe and argue that it would be best to introduce a global DPL switch "The inverter is connected to solar panels (and there is no battery)" that enforces reasonable settings for this scenario to work without touching the DPL logic, since you say that this is possible. This probably can be done in a few lines of code that are separate from everything else, which is easy to maintain.

In the future, I see that switch being inverter-specific: "This inverter is connected to solar panels rather than the battery". We can even upgrade from this setting gracefully: move the global switch mentioned above to the set of settings for the one inverter that will be auto-configured on upgrade from the existing settings.

@spcqike Can you reiterate a complete list of settings that must be applied to make this scenario work?

Ist that all?

bf4ed commented 1 year ago

One more. I have HM-1500 and dynamic limiter without battery. But when i lost connection to network and Shely 3EM for power metering, the inverter also shut down. No output. It would be nice to have a switch to enable fix output limiter (600W) when no power meter data, so that the inverter do not shut down.

schlimmchen commented 1 year ago

How about this: The "something is wrong, shut everything down" action considers the switch that was discussed earlier. If the switch is enabled, i.e., the inverter is attached to solar panels, the inverter is not shut down, but its limit is set to "Upper power limit" configured in DPL settings? It is my opinion that Introducing another setting for this failure scenario is quite a lot of work.

NevelSavage commented 1 year ago

I'm also trying this project out without batteries. Thresholds are set to zero, but it looks like that the calculated power limit is taked twice into account. Subsequently my export is too high. In the log I saw that the limit send to the inverter is 'newPowerLimit' multiplied by two.

20:27:13.992 > [PowerLimiterClass::loop] *** ENTER ** 20:27:13.992 > [PowerLimiterClass::loop] dcVoltage: 39.30 Voltage Start Threshold: 0.00 Voltage Stop Threshold: 0.00 inverter->isProducing(): 1 20:27:13.992 > [PowerLimiterClass::loop] newPowerLimit: 192 20:27:13.992 > [PowerLimiterClass::setNewPowerLimit] 4 channels total, 2 producing channels, scaling power limit 20:27:13.992 > [PowerLimiterClass::setNewPowerLimit] using new limit: 384 W, requested power limit: 192 20:27:13.992 > [PowerLimiterClass::loop] Status: SolarPT enabled 1, Drain [ 21688.582] DPL: waiting for a power limit command to complete

20:28:07.216 > [PowerLimiterClass::loop] dcVoltage: 38.90 Voltage Start Threshold: 0.00 Voltage Stop Threshold: 0.00 inverter->isProducing(): 1 20:28:07.216 > [PowerLimiterClass::loop] newPowerLimit: 185 20:28:07.216 > [PowerLimiterClass::setNewPowerLimit] 4 channels total, 2 producing channels, scaling power limit 20:28:07.216 > [PowerLimiterClass::setNewPowerLimit] reusing old limit: 370 W, diff: 0, hysteresis: 5

I don't know if this is a new issue or if my settings are incorrect. Thanks for the great work here!

schlimmchen commented 1 year ago

My guess is you have half of the inverter inputs hooked up to your battery.

20:27:13.992 > [PowerLimiterClass::setNewPowerLimit] 4 channels total, 2 producing channels, scaling power limit

There we go.

Selectively enabling the scaling is not implemented yet. Why have you not all channels connected to the battery?

NevelSavage commented 1 year ago

I'm currently testing the system without batteries, to see if the regulation is fast enough. After that I would spend money for expensive batteries. That means the inverter is powered by two solar panels, each on one mppt.

What I do not understand, the calculation is taking the DC power (when I understood the code correctly) and then it is multipied by two, because only two channels are producing. It seems that my HM-1500 DC power is the sum of all DC chanels, isn't it?

schlimmchen commented 1 year ago

to see if the regulation is fast enough.

In that case you will need to spend time optimizing the radio channel, i.e. the NRF24 module

It seems that my HM-1500 DC power is the sum of all DC chanels, isn't it?

Probably yes, I do not understand the question or why you ask. So maybe you want to rephrase your question?

NevelSavage commented 1 year ago

I try to specify my question. It looks like the new limit is calculated correctly (newPowerLimit = PowerMeter + InverterPower - TargetPowerConsumption ...). However, the double limit value is then sent to the inverter because only two channels are active? This is what I do not understand. If the calculated limit value would be sent directly, in my case everything would be fine.

schlimmchen commented 1 year ago

Okay, you are asking about the rationale. So, it is assumed that the inverter limits each of the n channels to 1/n of the total power limit (most of them do). Scaling the power limit up is useful for some people, so that the actual power output matches the expected output. See #241 for more.

This all falls apart for the HM1500, I noticed it already, too. I have a screenshot somewhere... The scaling will be made optional. And you will not have this problems once you connect all inputs of the inverter (since all channels will be producing and no scaling happens, even if the code ist still non-optional).

ves1820 commented 1 year ago

I tested DPL without a battery in all known ways - my inverter stops working shortly after i activate the modul.

on what version is

working ?

spcqike commented 1 year ago

this was on https://github.com/helgeerbe/OpenDTU-OnBattery/commit/1c7b7d3cdf38e65c79dffb094fb71006e785492c

but also now, on https://github.com/helgeerbe/OpenDTU-OnBattery/commit/84647d80e201cf99d3d9a983df1cde06458db862 its working for me.

grafik grafik grafik

grafik

ves1820 commented 1 year ago

i tested this morning - an it is kind of working. set the target power to 0W outgoing.

It works as long as the outgoing power is positive. If the power meter has a negative value - the inverter limit is set to minimum limit (30W) and gets the command to shut down.

After this, the power meter gets positive because the inverter is shut down (no producing). So the Inverter has to be started again and the new limit is set. After this all is working again (after some seconds) until the power meter has a negative value.

07:35:41.832 > PowerMeterClass: TotalPower: -2.70 07:35:41.832 > [DPL::loop] * ENTER ** 07:35:41.832 > [DPL::loop] battery interface disabled, SoC: 0 %, StartTH: 0 %, StopTH: 0 %, SoC age: 237743509 ms 07:35:41.832 > [DPL::loop] dcVoltage: 32.40 V, loadCorrectedVoltage: 32.40 V, StartTH: 0.00 V, StopTH: 0.00 V 07:35:41.832 > [DPL::loop] StartTH reached: no, StopTH reached: no, inverter is producing 07:35:41.832 > [DPL::loop] SolarPT enabled, Drain Strategy: 1, canUseDirectSolarPower: no 07:35:41.832 > [DPL::commitPowerLimit] Stopping inverter... 07:35:41.832 > SuccessSuccess ... 07:36:02.927 > PowerMeterClass: TotalPower: 280.40 07:36:02.927 > [DPL::loop] * ENTER ** 07:36:02.927 > [DPL::loop] battery interface disabled, SoC: 0 %, StartTH: 0 %, StopTH: 0 %, SoC age: 237764559 ms 07:36:02.927 > [DPL::loop] dcVoltage: 35.30 V, loadCorrectedVoltage: 35.30 V, StartTH: 0.00 V, StopTH: 0.00 V 07:36:02.927 > [DPL::loop] StartTH reached: no, StopTH reached: no, inverter is NOT producing 07:36:02.927 > [DPL::loop] SolarPT enabled, Drain Strategy: 1, canUseDirectSolarPower: no 07:36:02.927 > [DPL::commitPowerLimit] Starting up inverter...[ 237764.679] DPL: waiting for a power limit command to complete ... 07:36:13.373 > PowerMeterClass: TotalPower: -1.30 07:36:13.432 > [DPL::loop] *** ENTER ** 07:36:13.433 > [DPL::loop] battery interface disabled, SoC: 0 %, StartTH: 0 %, StopTH: 0 %, SoC age: 237775057 ms 07:36:13.433 > [DPL::loop] dcVoltage: 32.40 V, loadCorrectedVoltage: 32.40 V, StartTH: 0.00 V, StopTH: 0.00 V 07:36:13.433 > [DPL::loop] StartTH reached: no, StopTH reached: no, inverter is producing 07:36:13.433 > [DPL::loop] SolarPT enabled, Drain Strategy: 1, canUseDirectSolarPower: no 07:36:13.433 > [DPL::loop] battery discharging allowed, PowerMeter: -1 W, target consumption: 0 W 07:36:18.390 > [DPL::commitPowerLimit] Stopping inverter...

schlimmchen commented 1 year ago

Have you enabled "Inverter is behind Power meter" (DPL settings)?

ves1820 commented 1 year ago

no - i use the "volkszähler" from hichi - should i ?

spcqike commented 1 year ago

You should, as this tells the DTU that your produces energy is part of your consumption.

As you mentioned, you get a negative power reading. If the inverter is not behind your meter, DTU calculates that you don’t need the inverter right now, as you don’t have any demand anyway. But that’s not true as your demand is satisfied by your own production only.

Check „inverter is behind power meter“ and DTU calculates the correct values.

@schlimmchen do you know if there is any real use case where the DPL calculates a Limit based on a power meter, but the inverter is not behind that power meter?

schlimmchen commented 1 year ago

Nope, I dont understand why this switch exists. However, I am ignorant and there might be people out there who have a setup that makes sense and requires this switch to be off 🤷‍♂️

As far as I can tell this would require working on the cables between the the grid and the power meter, which are off-limits.

schlimmchen commented 1 year ago

@ves1820 Please close this issue if enabling said switch in the DPL settings solved your problem.

spcqike commented 1 year ago

@schlimmchen the issue was opened by me. I kept it open as you wanted to check if it’s possible to provide some functionality like a switch / toggle or something to, to use DPL without battery. So that the firmware ignores or not shows the battery specific input fields if it’s Solar only :)

schlimmchen commented 1 year ago

Oops. My bad. Yes, keep it open, this is an interesting feature.

pillepallepeng commented 11 months ago

Hi All,

I have the same "problem" that was described by ves1820 - Inverter is switched off when actual required power is below lower power limit.

„inverter is behind power meter“ is enabled.

I would appreciate if the DPL is not going below the defined lower power limit and/or is not switching of the inverter when required power is below the lower power limit. I don't want the inverter toggling between on & off too often (and it also takes a while switching the inverter on.) -do you think this would be possible?

just FYI: I have one non limited HM-400 connected to a solar panel and one HM-1500 connected to a battery with DPL enabled. Lower power limit is set to 50W to prevent the HM-1500 from switching off. (my HM-1500 is switching off, when limiting it to a value below ~45W)

In case the non limited HM-400 is generating enough power so that no power from HM-1500 is needed and thus required power from HM-1500 is below the lower power limit it gets switched off. I would accept for this rare situation in my setup that the battery is used even though it is not needed.

Does this somehow make sense to you? - do you have any suggestions?

spcqike commented 11 months ago

my suggestion would be to limit your HM-400 to like 370W or even 350W. so it can't produce "to much" so that the HM-1500 is always "needed" and can produce > 50W.

i dont see another solution for your problem. changing the behaviour of DPL logic for just one (your) specific use-case, can mess around with other settings.

one thing, i mentioned somewhere else, is the behaviour of lower-limit itself. i dont see a reason to say "if you would produce less than X, dont produce at all", instead i think it should be "produce at least X, regardless of everything else", but thats not how it works right now.

so if you don't mind using your battery, if its not needed, you could limit your HM-400 to always have enough production left for your HM-1500.

pillepallepeng commented 11 months ago

Thanks spcqike!

I agree to this:

one thing, i mentioned somewhere else, is the behaviour of lower-limit itself. i dont see a reason to say "if you would produce less than X, dont produce at all", instead i think it should be "produce at least X, regardless of everything else", but thats not how it works right now.

schlimmchen commented 11 months ago

"produce at least X, regardless of everything else"

I have to push back against this strongly: The battery will be depleted (until the BMS kicks in) if the discussed logic would be implemented. How is this acceptable? The BMS should really only be needed in case something went wrong, not to stop discharging on a regular basis. Also, one should want to keep the battery at some minimum state of charge (limit the Depth of Discarche, DoD) to preverse battery lifespan.

Or maybe you are only talking about the state where the battery is above the stop threshold?

I don't want the inverter toggling between on & off too often (and it also takes a while switching the inverter on.)

Well... Yes, it makes the whole system more sluggish. This makes me seriously consider your request.

How about a new state "standby", which the inverter is put into if it is not needed to offset household consumption? In that case we don't shut it down, but set the power limit to 5W (non-user-configurable). If the household consumption increases, we can set a new power limit with only one message to the inverter, rather than multiple (two I guess). That could indeed improve the responsiveness.

If the battery must not be used because its voltage/SoC is below the stop threshold, we would still shut the inverter down as before.

spcqike commented 11 months ago

Or maybe you are only talking about the state where the battery is above the stop threshold?

of course I mean only if it can produce. Like it is above stop voltage / SoC.

produce at least X, regardless of everything else

was more a „regardless of power limiter / power meter needs“.

spcqike commented 7 months ago

@schlimmchen

Nope, I dont understand why this switch exists. However, I am ignorant and there might be people out there who have a setup that makes sense and requires this switch to be off 🤷‍♂️

to bring this topic back, i can imagine one use-case. similar to zendures satellite plugs. if you can't monitor your overall household power consumption (no access to meter, no smartmeter at all?) you could monitor different devices on site. like your fridge, TV, electric heater, whatever. and only produce the energy needed for this devices.

the other topic

one thing, i mentioned somewhere else, is the behaviour of lower-limit itself. i dont see a reason to say "if you would produce less than X, dont produce at all", instead i think it should be "produce at least X, regardless of everything else", but thats not how it works right now.

was mentioned in #626 again. maybe one really could add such an option? like a toggle to let lower powerlimit be either a) the minimum power required to start up the inverter, as it is now, and b) the minimum power one wants to produce 24/7, as long as the battery voltage/SoC allows it.

as of how: one could store the values in the config and decide, while storing, whether config.PowerLimiter.LowerPowerLimit is 50 (or whatever value, if toggle is not switched) and config.PowerLimiter.LowestPowerLimit is 0, or if config.PowerLimiter.LowerPowerLimit is 0 and config.PowerLimiter.LowestPowerLimit is 50. (see Lower and Lowest, Lowest would be the new to be defined value)

so existing code should work, as https://github.com/helgeerbe/OpenDTU-OnBattery/blob/ebacc2f25ff6fb8ed64143d21dc631592694a143/src/PowerLimiter.cpp#L523

would evaluate to false, if one wants to produce "at least X W" (LowerPowerLimit would be 0)

one would need an additional check like

https://github.com/helgeerbe/OpenDTU-OnBattery/blob/ebacc2f25ff6fb8ed64143d21dc631592694a143/src/PowerLimiter.cpp#L530

but for "max", like

effPowerLimit = std::max(newPowerLimit, config.PowerLimiter.LowestPowerLimit);

do you think thats doable?

spcqike commented 7 months ago

@schlimmchen

Ich habe gestern deinen aktuellen PR der Anzeige des Netzbezugs installiert und teste diesen grade.

Nachdem wir in den vergangenen Tagen an mehreren Stellen über Solar-only und solar-passtrough geschrieben haben, hier meine aktuellen Erkenntnisse:

Ohne passtrough stoppt der DPL den Inverter früh am Morgen, und startet ihn bisher nicht von alleine

grafik grafik

08:37:04.118 > [DPL::loop] ******************* ENTER **********************
08:37:04.136 > [DPL::loop] battery interface disabled, SoC: 0 %, StartTH: 0 %, StopTH: 0 %, SoC age: 175 s
08:37:04.150 > [DPL::loop] dcVoltage: 42.80 V, loadCorrectedVoltage: 42.80 V, StartTH: 0.00 V, StopTH: 0.00 V
08:37:04.152 > [DPL::loop] StartTH reached: no, StopTH reached: no, inverter is NOT producing
08:37:04.152 > [DPL::loop] SolarPT disabled, Drain Strategy: 1, canUseDirectSolarPower: no
08:37:04.167 > [DPL::loop] battery discharging prevented, PowerMeter: 238 W, target consumption: -20 W
08:37:04.168 > [DPL::loop] ******************* Leaving PL, calculated limit: 0 W, requested limit: 0 W (kept last requested)

Ich hätte vermutet, dass eine Start- und Stoppspannung von 0V dazu führen, dass die Tresholds immer true werden. immerhin ist 42.8 > 0 😄

Hast du eine Idee, was man machen/ändern soll? Wenn wir solar-passthrough ohne erkanntem VE.Direct verstecken wollen, was durchaus sinnig ist, sollte es ja trotzdem irgendwie klappen :)

schlimmchen commented 7 months ago

Siehe https://github.com/helgeerbe/OpenDTU-OnBattery/issues/662#issuecomment-1945996194

Es ist möglich, dass ich die Überprüfung auf ">= 0" eingebaut habe (jedenfalls habe ich diese Funktion zum Überprüfen eines Thresholds umgebügelt) und dass es deshalb "erst" seit einigen Monaten so nicht mehr geht mit Schwellwerten, die Null sind.

schlimmchen commented 6 months ago

Wow! This is actually around 8 months old... Well, the switch I discussed 8 months ago is here with #733. So, @spcqike, I close this issue. If I overlooked something, let's reopen it or open another, more specific issue.

github-actions[bot] commented 5 months ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.