[Bug] Yield Day is not being resettet each night, although the option is checked

[BerziOnline]

Platform

ESP32

Assembly

the DTU was already assembled

nRF24L01+ Module

nRF24L01+ plus

Antenna

external antenna

Power Stabilization

Elko (~100uF)

Connection picture

• [ ] I will attach/upload an Image of my wiring

Version

0.7.36

Github Hash

ba218ed

Build & Flash Method

was already installed

Setup

Inverter: Interval [s] = 3 Max retries per Payload = 1 Reset values and YieldDay at midnight = checked Reset values when inverter polling pauses at sunset = unchecked Reset values when inverter status is 'not available' = unchecked

NTP: = Router (time is synced correctly)

Sunrise & Sunset: Pause polling inverters during night = unchecked

MqTT: Server added, Interval = 0

Debug Serial Log output

No response

Error description

The option "Reset values and YieldDay at midnight" takes no effect, the Yield Day counts every day on and on in my setup. I have to say that the inverter (hoymiles hm 1500) stays always online 24/7 - maybe this is a relevant information.

These are my settings:

Activating/Deactivating the option "reset values and YieldDay at midnight" showed up in the logs by doing a http://[IP]/debug after each change, that this is enlisted in my case by "mid2" OR "midNi".

After activating the option as shown I am getting a new entry "midNi": (it goes away after deactivating the option)

I did that a few days ago and had a look now in the logs before(!) starting this issue here and now the entry is named "mid2" after at least one night went over: (but the first screenshot here was from before these nights, preparing this issue here!)

After deactivating the option right now once again, this entry disappears. After activating again I have the entry "midNi" in the debug again as I had it the days before after activating as well, not the "mid2" anymore. (I did not play around with other options)

I replicated this behaviour again yesterday. Activating the option "new" leads to "midNi". One night later its "mid2". Maybe it's just a normal behaviour, but I just wanted to mention that in inspecting the bug on my own as a curious fact relating to the option what is not working in my setup.

In none of my cases an entry "midRe" showed up, as I read in other issues about, when they talked about this option sometimes.

So my YieldDay counts on day by day without a reset :-) I cannot figure out why.

[MetaChuh]

@BerziOnline

I have to say that the inverter (hoymiles hm 1500) stays always online 24/7 - maybe this is a relevant information.

yes, this is very relevant. thank you for mentioning this.

the option reset values and yieldday at midnight can not clear the values of the inverter, it only clears the last values within the dtu. if the values are resetted at midnight, and the inverter is still powered by dc (e.g. by battery), the same yieldday values will be re-read at the next inverter data update.

to counter this within eg. my control software, i save all yieldday values as offsets at 00:00h, and substract them until the next end of day.

greetings, metachuh

[BerziOnline]

@MetaChuh

Thanks for that. This is a fact I didn't know, but it makes sense and helps to understand why this is happening. So yes, of course - I can clear that in my smarthome software by correction calculations.

But wouldn't it be a worthwhile goal to have the values calculated correctly in the DTU itself? When we already know the problem occurs when the inverter is running 24/7 maybe an offset-option for this would be helpful? Something like "inverter stays online 24/7" and the DTU knows, that if the reset option for the daily yield values is also wanted it needs to calculated this with offset values depending on the last boot/midnights? Problem solved at the source of the problem, wouldn't it?

Or maybe a quick solution would be an option to reboot the inverter itself at night as well, but this would be the uncleanest solution of course.

To be honest: I thought the option "Reset values and YieldDay at midnight" is exaclty there for people having their inverter online 24/7 :-) Otherwise, when the values are resettet by an inverter-reboot anyway, what is this option for then? In what situation is it needed, if not for inverters staying online?

[Solarteur]

The option "Reboot Ahoy at midnight" already exists:

[BerziOnline]

The option "Reboot Ahoy at midnight" already exists:

@Solarteur restarting the Ahoy is something different and doesn't help here

[MetaChuh]

@BerziOnline

But wouldn't it be a worthwhile goal to have the values calculated correctly in the DTU itself?

this would cause eg following issues:

if the offsets are saved in memory, they are gone after a dtu reboot (changing settings, memory low, etc) during the day.

if the offsets are saved in flash, it will degrade the esp life time.

Or maybe a quick solution would be an option to reboot the inverter itself at night as well, but this would be the uncleanest solution of course.

for now, this can only be done by disconnecting/turning off all inverter dc inputs externally. the dtu option to restart the inverter can not reboot and reset the inverter.

at least for now, no one (public) knows if the hm accepts such command, and what to send to the inverter, if it does.

In what situation is it needed, if not for inverters staying online?

only to clear the last history values of offline inverters, to e.g. have a 0 value on the display from 00:00h on, instead of yesterday‘s value, until at least one of the inverters comes online again in the morning.

greetings, metachuh

[BerziOnline]

@MetaChuh Thanks for your explanations.

if the offsets are saved in memory, they are gone after a dtu reboot (changing settings, memory low, etc) during the day.

But it would improve the situation in nearly all cases. Right now the value is always wrong. With that the value would be just wrong when the DTU restarts. Don't forget, we're talking about environments having the problem because there is always power delivery. So the DTU wouldn't reboot as well each night. And just saying that when the DTU is being rebooted by the user for another reason would lead to wrong values: Yeah, the values are wrong right now all the time. Here it's just when the user steps in and want to have this reboot. So in my eyes a clear improvement, if there would be such an option, wouldn't it?

And yes, we can all re-calculate that in our smarthome logics - but as I said a post before: I think it's a valuable goal for the DTU itself showing the values as correct as possible to the given setup. With such an option it would be possible in most cases.

if the offsets are saved in flash, it will degrade the esp life time.

I see that point. But we're talking about 365 write operations per year. I am not sure, if this is reducing the lifetime very hardly. But I am not confirm enough what kind of flash technology is inside the ESPs, if you're saying this damages the ESPs flash I have to believe that.

the dtu option to restart the inverter can not reboot and reset the inverter.

Ohhh okay, I see! Just saw that option in the command section and thought it could be a valuable solution.

Thank you for your time, @MetaChuh

[lumapu]

don't know how many users are affected by this problem. Maybe we collect this information before I implement this feature for one user only.

[BerziOnline]

I would say at least everybody who is using the inverter together with a battery.

[MetaChuh]

@BerziOnline

on newer versions, you can restart the inverter at midnight using following post request to reset the yield day within this specific inverter:

i've tested this successfully on v0.7.45 won't work on e.g. v0.6.9 i didn't test any versions in between

curl --header "Content-Type:application/json" --request POST --data '{"id": 1, "cmd": "restart"}' "http://1.2.3.4/api/ctrl"

the json response should be:

{"success":true}

notes: this is a curl example for immediate quick testing from any terminal, without changing your control code.

id: your battery inverter id, 0 is the first at the dtu settings, 1 the second, etc. ip 1.2.3.4: please replace this with your ahoy dtu ip

the inverter restart takes about 10 seconds in this time the relay will be disconnected shortly and no power will be produced for this hearable (relay clicks) and very short period

the restart button within the dtu gui still does not do anything though (v0.7.45)

---

edit update and a little hack for v0.6.9:

the inverter reset via rest api didn't work as expected on older versions, due to a typo within RestApi.h:

before:

556    else if(F("restart") == jsonIn[F("restart")])
557                   accepted = iv->setDevControlRequest(Restart);

instead of:

else if(F("restart") == jsonIn[F("cmd")])
                accepted = iv->setDevControlRequest(Restart);

so if someone would like to reset the inverter on eg. 0.6.9, you can use this hack to do so:

curl --header "Content-Type:application/json" --request POST --data '{"id": 1, "restart": "restart"}' "http://1.2.3.4/api/ctrl"

greetings, metachuh

[BerziOnline]

@MetaChuh Thank you. A nightly restart resets the YieldDay - it's also possible about an MQTT command in the ctrl/restart tree. It's a workaround so long. Thank you.

[MetaChuh]

@BerziOnline

thank you for your feedback, much appreciated

note: all thanks regarding the reset topic via rest api go to @sri-elgora, who pointed this out and fixed it.

greetings, metachuh

[BerziOnline]

Hey @lumapu

you marked this topic as solved, thank you very much.

But I didn't see any changes in the described problem:

If the inverter has power (by a battery storage) all the time, the values are not being resetted each night. This was the problem here about, and this hasn't been fixed - or am I wrong?

[lumapu]

which version did you test at least? There was recently an update which could affect this issue. I'll reopen this issue, maybe I was too fast by closing this.

[BerziOnline]

I have used the last dev version the last months. I updated also to you latest release today. But from yesterday to today I had the 0.8.82, where it did not reset as well:

You see, that the Yield Day is very unrealistic (I have about 2-6kw per day), because it is not resetted since the last time without any energy source.

These are my settings:

[MetaChuh]

@BerziOnline

please restart your battery inverter at midnight, as recommended, with the above api call. this is the only recommended way at all dtu projects, including OpenDTU-OnBattery.

if you don't, and you update your dtu, which reboots it, you will get your 61kwh yield day battery back, regardles of implementations inside the dtu.

if you need further explanations please ask, and please re-read all from above within this issue.

thx

[MetaChuh]

@lumapu

There was recently an update which could affect this issue.

no, this commit does not affect this issue.

half off topic: @fsck-block thanks for your pull request https://github.com/lumapu/ahoy/pull/1431. nice to see some reading and understanding given diffs at issues 🙏👍 one day more, and i'd made my own "monk like" pull request about this 😉

[BerziOnline]

@MetaChuh I tested this of course in past, but in my environment it didn't work out sometimes.

I do know why now:

1. MQTT-Behaviour The restart object for the inverter just restarts the inverter, if the value is different than before. So for example always setting the value of "1" takes no effect, when the value from last time has been as well "1". You have to make a change, that the inverter will restart. So in my case, if the last sent value for /ctr/restart/0 has been "1" I need to send a "0", the next time a "1" again. So the restart in that object is just triggering, if you have a value-change in my eyes. The value itself but has no meaning. (so a "0" is also triggering a restart, as long the last value has been something different)

2. DTU doesn't take the new Yield Day unless it is rebooted itself as well This is the reason why my troubleshooting testing lead to the opinion it is still not working. So I restarted the inverter, but the Yield Day kept the old value, so I thought it didn't work. But the reason is, that after a restart of the inverter, what resets the real values, you need to reboot the DTU as well.

So these both are the reasons, why the workaround in practise didn't work. Fixing the first thing with the MQTT changing value is doable. But what do I have to do that the DTU itself can be restartet remotly then? I don't have a MQTT object to trigger this in night, do I? Or is there a setting what helps me doing that?

So in general the solution is:

• at midnight restarting the inverter
• at midnight (after restart of the inverter) reset the Yield Day in the DTU (if possible without a restart? If not, then there has to be a restart as well)

Is this doable?

[MetaChuh]

So in general the solution is: at midnight restarting the inverter at midnight (after restart of the inverter) reset the Yield Day in the DTU (if possible without a restart? If not, then there has to be a restart as well)

yes correct. with the premise that with ahoy dtus you have to restart the inverter before midnight, at e.g.: 23:59h otherwise the reboot will be finished after the ahoy offset reset, so ahoy will create another offset, as the inverter itself is not yet zeroed exactly at midnight (ahoy takes the value of last successful communication)

Is this doable?

yes, but currently not with ahoy dtu alone

you can either try different, mostly stand-alone dtu project's firmware, like OpenDTU-OnBattery or apply the external workaround mentioned here or at HoymilesZeroExport

[BerziOnline]

@MetaChuh I am really not sure if we're talking about the exact same thing, when I have a look at your links as a solution. These projects are for a zero feed solution controlling the inverter directly with values from the bms of a battery storage itself. Cool thing, but it's another topic, solving another problem?! It's about maximum efficiency for your consumption using original values directlry from the bms. Just because it's a DTU-project for a battery storage system it is not related to this issue here just because of there is a battery in use as well. We are going from a very simple issue to a solution for a very complex issue.

The restart of the inverter is possible by the DTU. First problem solved. The only reason I mentioned that before, because maybe it's interesting for every person out there as well (also for non-battery-users of the ahoy dtu), that the MQTT topic just reacts for a restart, when the value have changed - no matter what value you're sending. Because without knowing that, all the resets won't have any effect.

So the last simple question to solve this isseu from my side was, can the DTU be forced to reset it's Yield Day after the inverter has restarted? Either by a setting, what simply forces to reset the datapoint (because the inverter already would have done that, i. E. every night at 23:59 as you said <= not my question, we can go on as this will happen, the question is just about the dtu) at midnight or if you could just reboot the DTU at a given time. This was all I'm asking.

If in the end the answer to my question is: It's the setting "Reset values and YieldDay at midnight.", then I am happy to check this out this night. In past it didn't work - but maybe the reason was just the thing with the not working restart of the invertert because of the strange behaviour of the MQTT object. I can give feedback tomorrow, if it's working now.

[MetaChuh]

The restart of the inverter is possible by the DTU. First problem solved.

no, it is currently not possible to automatically restart the inverter from ahoy dtu. but you can open a new issue with feature request to restart specific inverters at 23:59h

So the last simple question to solve this isseu from my side was, can the DTU be forced to reset it's Yield Day after the inverter has restarted?

yes, but only if the inverter has been physically restarted before that.

If in the end the answer to my question is: It's the setting "Reset values and YieldDay at midnight.", then I am happy to check this out this night. In past it didn't work

no, as stated this will not work with your setup.

I am really not sure if we're talking about the exact same thing, when I have a look at your links as a solution. These projects are for a zero feed solution controlling the inverter directly with values from the bms of a battery storage itself.

yes, these links are to better understand the origins of the things you are experiencing. this is also to avoid, that devs implement what you think you need in good will, and with it, break the functionality for nearly all battery users of ahoy.

i'd personally only consent to a feature request from you called: "feature request to restart specific inverters at 23:59h" but note: ahoy does not allow "per inverter" settings as other firmwares do, so implementing such feature will possibly break other user's needs, as those commands would be sent to all inverters.

please read, albeit much information, all at this or other related projects, there's much to learn, much to reject, and much to accept.

[BerziOnline]

no, it is currently not possible to automatically restart the inverter from ahoy dtu. but you can open a new issue with feature request to restart specific inverters at 23:59h

Sure, this is possible by the MQTT-Object as I told before. This is not the problem anymore. I did it in practise. Right now before that post I tested it again. The only thing was, that the behaviour of the trigger was strange as already described. But if you know that, it's working fine.

yes, but only if the inverter has been physically restarted before that.

Great. This is what I need. The inverter-restart has been happend before, triggered by MQTT over the dtu.

no, as stated this will not work with your setup.

Why won't this work for me? This is what I didn't understand until here.

yes, these links are to better understand the origins of the things you are experiencing. this is also to avoid, that devs implement what you think you need in good will, and with it, break the functionality for nearly all battery users of ahoy.

i'd personally only consent to a feature request from you called: "feature request to restart specific inverters at 23:59h" but note: ahoy does not allow "per inverter" settings as other firmwares do, so implementing such feature will possibly break other user's needs, as those commands would be sent to all inverters.

please read, albeit much information, all at this or other related projects, there's much to learn, much to reject, and much to accept.

Believe me, we're talking about different things. It's because you're ignoring that I already told multiple times that a restart of the inverter can be triggered by the DTU easily over MQTT. So no implementation change necessary here - no one will be affected. If the setting of the reset for "Yield Day" is working fine after a few seconds before the inverter has been restarted, everything is fine :-) It's really just a cosmetic thing and it would cost less energy fixing it, when the option takes no effect, than trying to making it more complex than it is :-)

Anyway - I can give a report after that night, if it worked fine.

[BerziOnline]

Issue closed.

The problem was that the inverter has not restarted over MQTT each night before the "Yield Day Reset" in the DTU itself tried to reset it's values. Reason for that is that the MQTT-topic for the restart needs a changed value (as described in further posts), to trigger the restart. When this is ensured everything is functional.

I don't know if it's normal that the restart-trigger in the MQTT-topic behaves that way. If not, it's maybe worth to have an eye onto that to fix. But for this issue here it's fine for now. Maybe also helpful would be a note beside the Yield Day reset option in the DTU. Maybe a mouseover note behind an info-icon what give the information, that this option just takes effect, when the inverter has lost power before (normal setup without batteries) or when the inverter doesn't loose power over night it has to be restarted over another way (MQTT or API).

[theMPstig]

I am facing the same problem and do not really understand where/how to set the curl-command. Could someone please give me a header?