[Request] Make 'Night' configurable

[ButterBetzi]

Is your feature request related to a problem? Please describe.

No response

Describe the solution you'd like

Hi,

currently 'empty at night' and the corresponding 'night-state' solely depends on the current wattage (<20 W) from the solar panels.

1. I would like to be able to adapt the 20 W default value.
2. I would like to also set a timeframe, so that in the winter when a big cloud results only in 19 W solar panel power i can restrict it to not recognize this as 'night'. My idea would be to define e.g. 10pm-8am as time range where solar power below 20 W can result in 'night'. But not outside of my configured time range.

Describe alternatives you've considered

No response

Additional context

No response

[schlimmchen]

As far as I remember, OpenDTU already has everything we need to determine sunrise and sunset. Do you agree that this is far superior to setting a fixed time frame, which is either completely off in the summer or completely off in the winter?

About the 20W threshold: Do you really think it is important to be able to set this to a custom value? How about setting this to 1% of max(max_power_yesterday, max_power_today)?

[spcqike]

which is either completely off in the summer or completely off in the winter?

Not to forget DST (daylight saving time). Another clock / timer to adjust twice a year? :)

You are right. Opendtu comes with the power saving oled feature. We already can choose one out of three day/night cycles

[schlimmchen]

You are mixing three different things:

Not to forget DST (daylight saving time). Another clock / timer to adjust twice a year? :)

NTP will configure the clock correctly, so there is no need to adjust OpenDTU's clock. However, there is the issue that sunrise and sunset change by a full hour once DST is enabled/disabled. That's why a fixed time frame also makes little sense.

You are right. Opendtu comes with the power saving oled feature.

That is actually implemented like this: Turn the screen off after two minutes after the last inverter went offline. That does not even happen if at least one inverter is battery-powered. It has nothing to do with sunrise or sunset.

We already can choose one out of three day/night cycles

This is what I meant: There is a setting to select the type of sunset, and since the software is there, we can ask it when sunset and sunrise are.

[ButterBetzi]

OpenDTU already has everything we need to determine sunrise and sunset. Do you agree that this is far superior to setting a fixed time frame, which is either completely off in the summer or completely off in the winter?

i honestly dont get it. What is "everything" and how can I edit/use it?
My main problem is, that i dont want my battery to drain during the day (even when the panels have low input power). Can I fix this with those 'functionalities(?)' ?

How about setting this to 1% of max(max_power_yesterday, max_power_today)?

this sounds good to me

[schlimmchen]

Sorry, that's a misunderstanding between a developer and a user. I was talking about the fact that the software has mostly everything that is needed to make an informed decision about whether or not it's day or night, i.e., it already knows when there is sunrise and sunset. We still have to use that information in the DPL so that it behaves as you requested. Which is a very reasonable request.

[ButterBetzi]

ahhh, ok. That explains my confusion :D
Sounds good to me :)

[DDvO]

As far as I remember, OpenDTU already has everything we need to determine sunrise and sunset. Do you agree that this is far superior to setting a fixed time frame, which is either completely off in the summer or completely off in the winter?

Sure using the actual sunrise and sunset time (ideally with a configurable offset) would be best.
For instance Home Assistant supports this, and I hope this can be done with limited effort based on OpenDTU as well.

About the 20W threshold: Do you really think it is important to be able to set this to a custom value? How about setting this to 1% of max(max_power_yesterday, max_power_today)?

Why not allow the threshold be configurable (like, e.g., the TargetPowerConsumption offset is) - would that take much effort?

[schlimmchen]

Why not allow the threshold be configurable (like, e.g., the TargetPowerConsumption offset is) - would that take much effort?

The DPL is complex enough as it is. More settings are usually not helpful. Please explain why it is important to most users to configure this? What value would you chose and why? How do you suggest I come up with a value for my setup? Are you willing to document all of this?

What do you think about my suggestion of using 1% of max(max_power_yesterday, max_power_today)?

(ideally with a configurable offset)

Why?

[DDvO]

Why not allow the threshold be configurable (like, e.g., the TargetPowerConsumption offset is) - would that take much effort?

The DPL is complex enough as it is.

Yeah, unfortunately, an efficient charge&discharge control is inherently complex.
I did this myself based on Home Assistant, which was quite a pain,
in part due to their terrible programming environment and due to Hoymiles bitchiness.

More settings are usually not helpful. Please explain why it is important to most users to configure this? What value would you chose and why? How do you suggest I come up with a value for my setup? Are you willing to document all of this?

Well, most users likely would not care nor understand the implications.
I would be willing to take care of the documentation.

The point is that there is a trade-off how to spend low PV power best -
charging the battery should generally be avoided as long as the power can be used directly,
yet with low power, inverters are particularly inefficient.
The break-even depends on the type (and rated power etc.) of the inverter.
For instance, for my HM-300 I use a minimum limit of 25 W because with lower power its actual efficiency (not the one wrongly reported by the device via OpenDTU) is below 90%, which I deem too little.

What do you think about my suggestion of using 1% of max(max_power_yesterday, max_power_today)?

This would not fit with the background that I explained above why I would adapt the threshold.

(ideally with a configurable offset)

Why?

Sorry, that part of my comment was in the wrong context.
What I actually meant is that when supporting the option for making the charge/discharge decision depend on the sunrise/sunset times,
would be nice to be able to configure an offset, e.g., such that charging only starts an hour after sunrise and ends an hour before sunset, or even better: start with a given angle of the sun above the horizon and end with some given (potentially different) angle.
This should be helpful because radiation is too low around sunrise and sunset times,
and depending on shadowing, for instance by a nearby building, no fixed value could be generally optimal here.

[DDvO]

I would like to be able to adapt the 20 W default value.

At least, the 20 should not be a (essentially undocumented) "magic number" buried somewhere in the PowerLimiter.cpp code.
Even if it does not become configurable at UI level, it should be replaced by a named constant suitably defined in a header file such as PowerLimiter.h or Configuration.h-
If/when it becomes configurable, this named constant would serve as the default value.

[AndreasBoehm]

Will be fixed when #1126 gets merged

[github-actions]

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.