no yield per day after sunset with HMS-Series, HM is ok

[kr0815]

What happened?

I have 2 OpenDTU-Installations

• one with 4 HM-1200 Inverters
• the other one with 3 HMS-2000 Inverters

After sunset, i see on the HM-1200 inverters the yield by day
In the HMS-Installation, YPD shows zero after sunset

To Reproduce Bug

what shall i say :-)

Expected Behavior

see YPD for both installations

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

v23.9.18

Relevant log/trace output

No response

Anything else?

No response

[AloisKlingler]

since I disabled the "poll inverter at night" this did not occur any more for me.
see #979

[kr0815]

thanks, i will give it a try :-)

I don´t understand - how to even poll the inverters at night - they don´t send anything when there is no input?

[huste511]

I also have several HMS here and have never been able to see the daily yield after sunset.

I also deactivated nighttime polling.

Since OpenDTU can determine the day itself, smaller values ​​from the same inverter should be ignored - it would be even better to cumulate them if necessary.

[kr0815]

I changed the settings for "poll inverter at night" - still strange , now another of the 3 HMS shows a yield per day, the others zero - musst be really a bug?

The HM-Inverters show all as expected

[huste511]

Not really a bug in openDTU but an area where improvements could be made.

The HMS switches off at some point at dusk. If it gets a little brighter at some point, it starts again, usually doesn't provide any energy, but for it it's still a "new day" and it and delivers 0 values...

[tbnobody]

I am currently bad out of order. But please change the eventlog. Is it possible that your hms inverters reboot at evening? In this case the daily counter is resettet. Happens when e.g. at the evening the wether is cloudy and at the end the sun still comes out a bit to power the inverter again. Hm and hms might react differently here.

[kr0815]

--> tbnobody - get well soon :-)

What do you mean with changing the event log?

You are right, it could definetly be possible they reboot, show zero because of that event

[tbnobody]

I mean, have look at the event log. Sry. Brain is mud.

In the event log should see the last startup time of the inverter.

[kr0815]

sorry if it sounds stupid, but where to see the event log? :-)

info - console?

[tbnobody]

Ne. It's in the live view. I top of each in inverter are several buttons. One is for the event log

[kr0815]

strange:

Inverter 1 - YPD 0 - inverter start 19:17
Inverter 2 - YPD 0 - inverter start 07:09
Inverter 3 - YPD 11,9 kWh - inverter start 07:09

The HM all say Inverter Start around 7:14

[tbnobody]

Maybe hm require less power to keep them operational. But there is already a first walkaroumd for this issue. Will have a detailed look and modify maybe the on or other thing. Bit this feature will come in if I am back.

[kr0815]

Take your time :-)

It´s fascianting, - what i observe, HM are generally better regarding output
not much, but it´s noticible

[broth-itk]

Duplicate of #1268 ?

I proposed a fix to cache the YieldDay values.

The problem can be observed when the interver restarts

• in the evening
• if panel is covered and disconnected for maintenance
• intentionally on interter restart

[kr0815]

i guess there is another problem / bug:

See the red Message on the HM-1200, letzte Aktualisierung
With the HMS-2000 it is not red

[tbnobody]

Grey means that you've disabled polling at night. And that it is currently night.

[Lineflyer]

I am currently bad out of order. But please change the eventlog. Is it possible that your hms inverters reboot at evening? In this case the daily counter is resettet. Happens when e.g. at the evening the wether is cloudy and at the end the sun still comes out a bit to power the inverter again. Hm and hms might react differently here.

I do also have this exact issue with my HMS.
I thought the "Zero daily yield at midnight" feature was the foreseen fix/workaround for this problem...but seems not. What is the benefit of this feature then?

For my understanding:
Is this value provided by the HMS or calculated within the DTU?
If its calculated in the DTU it should be an easy fix, if the value comes from the HMS it would need to be buffered and added within one day by the DTU.

[pimisen]

Same issue here. 2 HM. No issues. One HMS YPD gone after sunset

[GM-Jokemaster]

Same here HMS800 T2. (Newest Version) v23.11.16
Reset to 0 on the same Day. At Power lost at the OpenDTU (Reset at Midnight is active)
Also a Friend of mine same HMS same result.
Please try to Store the yield per Day and if NTC Time tells same Day = Add the new (now low) vlaue to the Last before "Power lost"?
TY !!

[fred777]

IMO, the difference between HM and HMS is, that the HMS will start to communicate much earlier than the HM.

The electronics of both inverters are powered by solar and as soon as there is enough power, they will start feeding to AC.

For the HM this will be also the time when it starts communicating.

But not so with the HMS. It will already communicate as soon as there is enough DC power.

Attached are two images from a HM700 with 2 panels and HMS2000 with 3 panels on a winter's day with solar panels covered with snow.

The purple line is AC power, the other lines are DC power from the solar panels.

[Lineflyer]

Yes, its basically that the chance of the HMS to stop transmitting due to sunset and then getting alive again for a few seconds short after seems significantly higher than with the HM series.
This effect IMHO causes the YTD reset....and that is why I asked for clarification how the "reset ad midnight" works. I thought it should exactly prevent this problem. Otherwise it should be enhanced to cover this problem of multiple "restarts" of transmission during a day.

[broth-itk]

Yes, its basically that the chance of the HMS to stop transmitting due to sunset and then getting alive again for a few seconds short after seems significantly higher than with the HM series. This effect IMHO causes the YTD reset....and that is why I asked for clarification how the "reset ad midnight" works. I thought it should exactly prevent this problem. Otherwise it should be enhanced to cover this problem of multiple "restarts" of transmission during a day.

Agree, I noted this problem long ago.
This is why I implemented caching of the YTD value (see above comment from Oct 5 and pull request).

At daychange the offset value needs to get resetted. Due to new implementations this could maybe done elsewhere.
Haven't looked at the code since then.

[tbnobody]

It's already in my dev branch. But I am currently out of order. Therefor. Please keep patient.

[broth-itk]

@tbnobody: Patience is not a problem for me. Thanks for your great work!

Gute Besserung!

[pimisen]

@tbnobody Gute Besserung!
Maybe that is of use for anybody: HMS and HM seem to be different (But i guess you know that already ;-) )
Home Assistant Yield curves look kinda different:

[Lineflyer]

It's already in my dev branch. But I am currently out of order. Therefor. Please keep patient.

Thanks for the update and all the best!

[Lineflyer]

@pimisen
Yes, this visualization shows the "bug". The production is reset to zero on the HMS while it just stays stable on the HM and only resets on the following sunrise. The proposed fix should make your HMS curve look like the others.

[tbnobody]

This should be fixed with 1de3b48

You can enable this feature per inverter.

[chris299]

@tbnobody I just flashed the firmware.zip. I'll report how it will work today afternoon if the inverter restarts....

[fred777]

But wait - why do you keep setting _lastYieldDay[static_cast<uint8_t>(c)] = 0; in StatisticsParser::endAppendFragment() ?

Because the offset is applied in the line above.

Yes, but is that cumulative? To me it looks like the offset is just stored and when _lastYieldDay is then being reset to 0 on the next line, then on next call of endAppendFragment this code path will not be hit anymore and _lastYieldDay will be updated with current (much lower or even zero) yield value from the inverter in the else-path which is not what we want I guess.

[tbnobody]

Yes, but is that cumulative?

Yes kind off.... The offset is applied in the getChannelFieldValue function. Therefor the _lastYieldDay contains the current raw value from the inverter + the current offset.

[broth-itk]

@chris299 You can just restart the inverter from GUI. This will have the same effect.

[tbnobody]

you can just restart the inverter from GUI.

Great idea!! I've just tested it.... and it seems to work as expected.

[fred777]

Yes, but is that cumulative?

Yes kind off.... The offset is applied in the getChannelFieldValue function. Therefor the _lastYieldDay contains the current raw value from the inverter + the current offset.

Ah, I see. Good - the day hasn't ended yet, so I'll revert my change now and see what happens after inverter restart.

[chris299]

@chris299 You can just restart the inverter from GUI. This will have the same effect.

@tbnobody just restarted the inverter and it seems to work :-)

[fred777]

I did not restart my inverter but waited for the sunset instead so that the inverter would restart by itself.

=> seems to work too 👍

[tbnobody]

The fix is included in todays version: https://github.com/tbnobody/OpenDTU/releases/tag/v23.12.18

I am going to close this issue. Please feel free to open it again if there are still issues.

[chris299]

@tbnobody looks like something else went wrong now:
the yield was not reset at midnight, although configured and it shows a dot instead of a comma.
looks like it was set to 65535-yield of yesterday....
(I'm still on the testing version from yesterday, not the 23.12.18 yet)

[tbnobody]

If you compile yourself, you could try this one:

diff --git a/lib/Hoymiles/src/Hoymiles.cpp b/lib/Hoymiles/src/Hoymiles.cpp
index 4cd3ef0..e7b3d26 100644
--- a/lib/Hoymiles/src/Hoymiles.cpp
+++ b/lib/Hoymiles/src/Hoymiles.cpp
@@ -133,10 +133,12 @@ void HoymilesClass::loop()
             if (currentWeekDay != lastWeekDay) {

                 for (auto& inv : _inverters) {
+                    // Have to reset the offets first, otherwise it will
+                    // Substract the offset from zero which leads to a high value
+                    inv->Statistics()->resetYieldDayCorrection();
                     if (inv->getZeroYieldDayOnMidnight()) {
                         inv->Statistics()->zeroDailyData();
                     }
-                    inv->Statistics()->resetYieldDayCorrection();
                 }

                 lastWeekDay = currentWeekDay;

[chris299]

If you compile yourself, you could try this one:

@tbnobody unfortunately I'm not able to compile it myself....

BTW: Thank you very much for your effort and commitment! 👍 🙏

[tbnobody]

I am pretty sure that fixes the issue. will be included in todays release.

[broth-itk]

I'm running the latest version. A smaller inverter had 15Wh daily yield. After manual restart, it value drops to zero:

My understanding is that the day yield should be 15Wh (from cache, offset) + new Wh value from freshly restarted inverter.
Can I provide more information?

[tbnobody]

Can I provide more information?

Please tell me your version number. "latest" is not enough.
Please also provide the inverter config of this specific inverter.

[broth-itk]

@tbnobody: OpenDTU v23.12.18

I've just noticed a new setting "Tagesertragskorrektur", wasn't aware about that.

As far as I was concerned, the code looks to work as designed - thanks!

[stefan123t]

@kr0815 @chris299 @Lineflyer could you test again with OpenDTU v23.12.18/19 ?
According to @broth-itk the code has been fixed and this issue could probably be closed if you report back too.

[fred777]

I just tested with the patch from #1397 (comment) applied to v23.12.18 and built from source.

Daily yield was perfectly reset to zero in the morning and started to grow on sunrise.

[chris299]

23.12.19 worked fine for me so far @stefan123t

[kr0815]

i tried with V19 - rebootet the inverter twice - looks like it works :-)

[stefan123t]

@tbnobody suggest to close this issue as fixed in 23.12.18/19.

[Lineflyer]

Yes, it also works with my HMS-1600 without further issues now!

Thanks @tbnobody

[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.