Open schlimmchen opened 1 month ago
Läuft seit heute im Produktivsystem meines Vaters mit 2x hm-600, aufgefallen ist mir auf die schnelle, das sich die regel gschwindigkeit der DTU addiert, was aber irgedwie logisch ist. 1 sek = 2 sek pro wechselrichter.
Ansonsten läuft es bestechend gut, bei leistungen ab 300w sind die wechselrichter nahe bei einander 155w/145w o.ä.
Bei kleineren leistungen hab ich auch schon 45w/93w geshen. Das eingestellte Limit wird jedoch tadellos getroffen.
Ansonsten ist mir soweit nichts negatives aufgefallen 😁
Da das Sytem leider nicht bei mir steht, kann ich leider nur alle paar Tage draufschauen. Laut Shelly ist der Verbrauch aber da wo er sein sollte.
Vielen Dank @schlimmchen für deinen betriebenen Aufwand. Funktioniert grossartig bis jetzt 👍
Soll ich bei Gelegenheit irgend etwas speziell testen? Lg
@DonJohnLong Vielen Dank fürs mutige Testen und deine Rückmeldung!
aufgefallen ist mir auf die schnelle, das sich die regel gschwindigkeit der DTU addiert, was aber irgedwie logisch ist. 1 sek = 2 sek pro wechselrichter.
Naja, nachregeln sollte eigentlich so schnell sein wie zuvor, denn es sollte in aller Regel ja weiterhin nur ein Inverter ein Update erhalten müssen, um den neuen Haushaltsverbrauch zu kontern. Wenn du allerdings vorher nur einen WR an je einer OpenDTU hattest, dann dauert es natürlich etwas länger als zuvor. Da möchte ich noch dran schrauben, aber bisher sind wir da auf 1s zwischen den WR und 1s Pause zwischen den Runden beschränkt.
Dass die Leistungen der Inverter nahe beieinander sind ist nur ein Bonbon und kann nicht garantiert werden. Es kommt drauf an, wie der Haushaltsverbrauch schwankt und wie die Hysterese eingestellt ist, etc. Aber in der Tat, wenn die Hysterese klein ist und die Inverter gleiche maximale Ausgangsleistung haben und die PowerMeter Schwankungen eher klein sind, aber größer als die Hysterese, dann nähern sich die Leistungen über die Zeit an.
Soll ich bei Gelegenheit irgend etwas speziell testen? Lg
Lieb, dass du fragst, aber ich finds schon total super, dass du hilfst zu testen und Rückmeldung gibst, ob dir etwas negativ auffällt, das ist erstmal mehr als ausreichend :muscle:
Nice work @schlimmchen !
I will try to provide the solar powered inverter implementation until sunday :)
After installing the new build the start voltage threshold changed to a weird value that can't be saved anymore.
Even if i change it to 52,1
it will return back to the shown value.
If i enter 52,3
and save it i end up with this:
installed the build today and apart from not seeing the power limits in the webapp it seems to do its job so far. Thank you very much for implementing this, I will monitor the behavior closely and report if I stumble upon anything out of the ordinary👍
edit: small correction - I can see the power limits now (was "0" before for both already working inverters)
I will try to provide the solar powered inverter implementation until sunday :)
No worries and no rush. Let's do a maintenance release soon to fix issues users reported, then take a couple of weeks to finalize and merge this as well as other features/PRs (which there are quite a lot all of a sudden).
Even if i change it to 52,1 it will return back to the shown value.
Yes. This drives drove me nuts. See #1225.
Quick feedback: looks good to me so far
Rainy day completely ruins the otherwise awesome stats I normally achieve using this excellent project xD
PS: dont trust todays values, "heute eingespeist" only counts one inverter, I forgot to reboot-proof the 2nd one
Quick feedback: looks good to me so far
Fancy dashboard.
So what you haven't observed, obviously, is that one inverter might be off for a longer period of time simply because it is not needed. This night, my inverters were shut off as the battery was depleted. After solar power was available again, one started producing power (the bigger one with 2kW output, as that is sorted to the front of the queue). Since then, there was no situation where the first one produced at least 500W such that the second one (1.5kW output) would have been sorted to the front of the list as more power was needed.
I don't like that. I anticipated that this could happen while writing the code, and I think I am going to sort inverters in shutdown to the front of the list when an increase is needed. This still requires a jump of at least the lower power limit of that inverter such that it will turn on, but I guess that happens rather frequently, even if it's not a busy day.
Also I want to find a way to decide when to sort the list by a different metric, i.e., such that the output power of both inverters align (in absolute output or relative output?!). Probably it's a good idea to so that every time any inverter can take the update to achieve the new total output.
I thought that we want to keep the number of active inverters low to prevent that we are running them on low limits which results in the output not being what we set as the limit (HMS-2000 below 15%) and because every extra MPPT brings more voltage variance in to the system. Please correct me if i misunderstood something.
Hm. Good point. Do you have suggestions on how to implement it? Right now I did the implementation with the opposite assumption in mind. In particular, an inverter will not be turned off unless it has to be. I need to think about that a little.
And if we do it like this, I really think that there needs to be some kind of load balancing to spread the aging across the inverters somewhat evenly. Maybe we keep the inverter running which, proportional to its max output, has produced less energy? However, it would also be very nice if we switch inverters based on their temperatures, so that we allow them to run cooler?
You opened a can of worms :wink:
I would like to test this once i am back home and can flash my devices. I currently run two on battery instances to control two HMS-2000 inverters. As from my experience with two inverters in general so far, i would definitly try to use only as much inverters at the same time as needed. Which should also have the benefit of more speed as long as only one inverter is active, which should be most of the time i guess. HMS Devices also come down to a nice stand by consumption of 1,2W only if they are not needed.
I would like to test this once i am back home and can flash my devices.
Nice!
Which should also have the benefit of more speed
No, why do you think so? The answer is no because the current implementation sorts the inverters by the amount they can increase or decrease their output, and the one with the biggest difference is at the front This means only one inverter is updated at a time.
i would definitly try to use only as much inverters at the same time as needed.
Are there other reasons from your perspective other than the speed argument, which I think is not a concern?
Efficiency and Simplicity
If one inverter is enough to cover the household, it should be more efficient as two running at low load. If two are running, you still need to get power ratings for both of them. If one is disabled this can be skipped.
thank you, I can see your points, very good arguments! let me skip waiting for inverter data if the inverter is currently not in use to speed up the DPL loop, possibly considerably. and let me change the "algorithm" to use as little inverters as possible. I still need to think about it, though. any ideas from you guys?
To be honest i dont think its as easy to say that the minimum number of inverters is the best way to go.
If we are close to the limit of the first inverter we will have issues to react to increased power requirements quickly. Because it takes before production starts and because we need to reach the minimum limit of the second inverter.
what about setting an upper limit of, i dont know, maybe 75% and then we start a second inverter to be able to quickly increase the output?
I also think it’s better if all inverters run in a low but stable level.
I’m not to sure if efficiency is a real problem. A inverter at 70% load may be more efficient than on 15%. But losses across the cables will be lower when using two inverters, as you reduce the current for each pair of cable and so you basically double the wire diameter.
And I think two inverters at 30% are cooler than one at 60%. Low temperatures are better for the hardware in the long run
I don’t know if the inverters need to reach their lowest limit where they can hold the desired power (like ~15% for the HMS-2000) or if it’s enough when the first one runs stable (10-15W per MPPT, so no communication errors but also not reaching the target limit) and the second produces the missing power to hold your overall power target. case A would be tricky as you need 300W for a HMS-2000 to hold its target limit. But B would be more complex to calculate or slower to settle in, somehow.
Because it takes before production starts
is that true? I thought it doesn’t matter if the inverter is stopped or does produce, as long as it’s not disconnected from the grid or restarts. The first start takes time for grid Synchronisation, but after that it is quite fast, I thought.
I read this and I am not confident that we can reach a common ground in this. Maybe we don't need to. It is understandable that ine strategy does not fit all use cases or setups.
Using different sorting of the inverters, I think we can quite easily implement very different strategies.
Towards the extremes, all inverters should be on or off in any case. So I dont' think that changing the implementation design to iterate the sorted inverters and call the respective increase or decrease method is required.
It is also easy to drop an inverter from the sorted list, if the sorting strategy decides that it does not want an inverter to be considered in the current round. The algorithm could also cap the increase or decrease for the current round. Adding methods for that to the DPLinverter class is straightforward.
The implementation of these strategies can go into their own class each, implementing a particular interface, which is simple to read and maintain.
I had this in mind before, that's why I was very happy with the approach to sort inverters, as I realized that this could easily be adapted. We can make this even more flexible as described above.
I moved from a HM-600 to a HMS-2000 on my secondary system and noticed that the limit and the inverter output was fluctuating a lot.
Something is going wild, trying to set a crazy limit
sending limit of 3276.7 % (65534 W respectively)
You can find a log below, if you need more log lines or anything else, let me know.
@AndreasBoehm There are two problems here:
Also, I continue to get headaches thinking about how to tweak the methods that calculate the possible reduction/increase as well as those applying them, because they need to deal with solar-powered inverters as welll as battery-powered inverters. I think I want to split PowerLimiterInverter into PowerLimiterSolarInverter and PowerLimiterBatteryInverter (with PowerLimiterInverter being an abstract base class). Unfortunately, we then have to organize the instances using pointers to the base class... However, since I already use a deque, those objects already "float around" in the heap.
- The reason you triggered this bug is because your lower limit is far to little. 20W may have worked for an HM-600, but an HMS-2000 with 4 inputs shall have a lower power mit of at least 60W (maybe 40W works as well). The logs tells you ecatly that: The limit is already at 8W, but the inverter produces 47W. The inverters don't do well with such low limits.
With the 'old' DPL this works fine, i know that the lower limit is super low for an HMS-2000, right now its set to 25W and the average required limit is ~35W. While the heatpump is running it will go to 2000W, while its idling it consumes ~35 W.
It does not make sense that the limit should be 8W, maybe thats also a problem of the new DPL implementation?
In the two screenshots you can see that a limit between 30W and 50W is needed for the consumption while the heatpump is idle. And this works fine with both the HM-600 and HMS-2000 using the old DPL. (You can also see when i switched back to the old DPL build at ~13:40)
Also, I continue to get headaches thinking about how to tweak the methods that calculate the possible reduction/increase as well as those applying them, because they need to deal with solar-powered inverters as welll as battery-powered inverters. I think I want to split PowerLimiterInverter into PowerLimiterSolarInverter and PowerLimiterBatteryInverter (with PowerLimiterInverter being an abstract base class). Unfortunately, we then have to organize the instances using pointers to the base class... However, since I already use a deque, those objects already "float around" in the heap.
Sounds like a good solution to have multiple classes with less code.
It does not make sense that the limit should be 8W, maybe thats also a problem of the new DPL implementation?
Yes, of course. I did not want to suggest that you are at fault, I just wanted to point out how you managed to trigger this issue. Good job :wink:
However, I still maintain that your lower limit is too low, given the joint experience we shared in this project. Did you not notice that the inverter is shutting itself off at these low limits? Is the DPL restarting the inverter because of that (check the logs). Maybe your specific inverter is not prone to shutting itself down due to oscillations...
Got it!
I checked the logs and the inverter ist not shutting itself off with the limits that the DPL applied (as low as 28W). Maybe this issue got fixed at some point?
I have two HMS-2000, both manufactured 0/2024 with firmware version 1.0.27 (thats what openDTU shows me)
I have observed the oscillations until the inverter shuts off with my HM-1500. My HMS-2000 never had very low limits set. Mine is week 31 of 2023 and has firmware 1.0.16. My das has one such model as well, and one the same as yours. Maybe I will torture them with very low limits and see how they behave -- some day.
There is another stupid mistake, another underflow: It occurs if some non-DPL-managed inverter or completely other power source makes the power meter value go "too negative". The DPL will consider the DPL-manged inverters' output, but if the result is still negative, we (I...) interpret this value as an uint16_t
, which is garbage, of course :man_facepalming: If we already feed into the grid, the power request to the inverters shall be zero.
Kudos to @AndreasBoehm for showing us that collapsible sections are available in Github comments. :heart:
Aaaand another stupid mistake... This is definitely not as robust as I had hoped :disappointed: At least not yet...
My HM-1500 is not turned off even though the battery stop threshold is reached. That's because it has a limit of 49W set (guess that's a rounding error), whereas the lower power limit is 50W, so the PowerLimitInverter
class assumes the inverter cannot reduce the power output...
Just a Heads up
For the little System with 2 identical hm-600 i can only confirm that it runs absolutely flawless. None of the Problems above did show up with 2 identical small inverters.
@DonJohnLong Thank you very much for your feedback! I am now running the newly build firmware based on the current state of the PR. That Github action run is linked in the first comment of the PR.
rebased onto current development branch, which includes upstream changes in particular.
WOW - sieht fürs erste nach einen riesen Schritt aus und ich freu mich total aufs ausprobieren! @schlimmchen danke !!!!
Habe das ganze gerade seit 2 Tagen a laufen leider ist es meistens zu bewölkt um zuverlässige werte zu erfassen. Da mein Setup mit 2 durchgeschleiften "hornbach" Akkus , an mehreren wechselrichtern und somit nicht immer alle Panels an allen wechselrichtern zur Verfügung stehhen muss ich wohl hier einiges bei den neuen einstellungen berücksichtigen... ich glaube wenn ich dazu mehr fragen habe wäre es besser im diskussions bereich zu fragen hierzu zu eröffnen - oder?
Eine offene Frage powerlimiteradmin.TotalUpperPowerLimit Das ist quasi die gesamt leistung auf alle WR die nicht überschriutten werden soll?
@schlimmchen danke !!!!
Freut mich, dass du es gebrauchen kannst und ausprobieren möchtest.
ich glaube wenn ich dazu mehr fragen habe wäre es beser im diskussions bereich zu fragen oder?
Ja, das wäre gar keine schlechte Idee! Eine allgemeine Diskussion bezogen auf diesen PR, er ist ja doch sehr umfangreich.
Eine offene Frage powerlimiteradmin.TotalUpperPowerLimit Das ist quasi die gesamt leistung auf alle WR die nicht überschriutten werden soll?
So ist es. Aber diese Einstellung wird noch nicht berücksichtigt, so steht es auch oben. Vielleicht schaffe ich das heute noch.
I am delighted to share this changeset with all of you: This implements my approach to support multiple inverters by the DPL.
Design
Very shortly (to be explained in the docs in detail):
Status
Definitely work in progress, but usable. My setup is running this implementation and from what I see it does what it is supposed to do.
The WebApp has glitches.webapp should work as expected.yarn linting fails, I know why, but I learned just now only, and this will be solved another time.the linters are happy.PowerLimiterInverter::isValid()
and integrate intoPowerLimiterInverter::create()
.Preliminary Results
These logs are now outdated, as the implementation progressed since they were recorded.
Breakfast: The power meter reading is not very impressive :disappointed: I hope that it is okay since the issue of stoves using power in intervals is well known. The resolution of the power meter graph is only 10s. I don't know why, it should be 1s, I never bothered to check.
Testing
As stated above, this is usable, at least for systems with multiple battery-powered inverters, and I deployed it to my productive system with one HMS-2000 and one HM-1500. I would be very happy to receive your feedback on this. Firmware can be downloaded from the respective PR build run.
Please do not open issues but answer to this PR when giving feedback.
Related
Closes #230. Closes #1032. Closes #1071.