-
-
Notifications
You must be signed in to change notification settings - Fork 514
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Home Assistant Integration not displaying the same limit % as the website when over 100% #2511
Comments
That might be a HomeAssistent issue. If Thomas has a hard time debugging this, I will gladly take a look.
Are you aware of the daughter project, which has the Dynamic Power Limiter? |
Please take a look at the raw values on the mqtt broker (e..g. using mqtt explorer) to see whether it's HA specific or if the values on the broker are already wrong. Second, you cannot set percentage values > 100%. The command does not allow this. It's also disabled here: OpenDTU/lib/Hoymiles/src/inverters/HM_Abstract.cpp Lines 127 to 129 in 653efb4
But you can set absolut values which are higher then your max inverter value. It will be sent to the inverter (and updated via mqtt immediatly). But after a certain amount of time, the value is fetched from the inverter again and you can see what the inverter made with your command. |
Yes I already saw it and already updated the |
No, much more the type of sensor : it is defined as percentage, so cannot be more than that. It is not defined as a number. But I think that the question to answer is much more: should percentages more than 100% be allowed ? If yes, then in HA it has to be a number, not a percentage. If no, then OpenDTU needs to be fixed, but in that case, what is happening when a limit is set with a value more than the detected power of the inverter, like I do ? I saw that OpenDTU will detect the power value of the inverter, but does it use it also as a maximum limit ? Or we can actually send to inverters a limit higher than the detected value ?
yes I can do tomorrow! I completely forgot lol!
I will look! For now, I set a persistent limit, and the value of 450W is still kept both in HA and in OpenDTU. This is the night.
I know about OpenDTU-OnBattery, but since it has a focus on battery usage and I don't / will not have batteries, I was wondering whether it would fit my need... What I would need is to integrate OpenDTU with an MQTT topic to read the grid voltage, or, even better, with a JSY-163-T for example (https://github.com/mathieucarbou/MycilaJSY) which will read the grid power (in and out), and then, have a setting in OpenDTU that lets me chose the excess / import I wan to allow: 0 to simulate a zero-inject profile, etc.. And if I have a solar diverter (I designed some), we could set for example this number to -300W to allow some excess that will be redirected to the water heater by the solar diverter. If diverting, then opendtu would see that the grid is at 0, it will, if possible update the limit to let another 400W flow, etc. That's really the flow that I would need to make, either integrated within OpenDTU or on the side. I am really not good at UX design, but this is definitely something I could contribute to OpenDTU: JSY support (in my library, I also support a remote mode with UDP in order to have multiple clients reading the grid metrics), coupled with some settings to control the on persistent limit of inverters based on a target. Typically, this would be implemented like a PID algorithm, like I did for my solar diverters, to make sure the target can be reached better, since computing a difference (tested with my inverters today) does not exactly lead to 0 excess for example and limiting to for example 200W also does lead to more than 200W produced. There are always about 10, 20W more than the limit that is produced. So this PID could then control the adjustment of the limits depending in the grid power read and the target (setpoint in PID terms). |
Meh, that's not true, despite the name. We explicitly support (possibly multiple) solar-powered inverters as well.
✅
Possibly supported. I guess this is speaking SML? If not, integrating a new power meter interface should be straight-forward for you 😉
✅
Hm, yeah, this is where OpenDTU-OnBattery might fall short on your requirements... I am no good at stuff like this so I did not even attempt something yet. This is my grid power response when enabling and disabling a water heater from yesterday. You are probably turned off by the significant feed into the grid when the heater is disabled. I am curious how you could do much better. Know that you will have trouble speeding this up since communication to the inverter is inherently slow. The situation becomes worse when multiple inverters have to adjust their limit to achieve a particular target grid consumption value. Thomas, please excuse all this advertisement for the daughter project and the off-topic discussion. Mathieu, if you are interested in discussing this further, maybe start a discussion over at OpenDTU-OnBattery 😊 |
Ahah !! Good to know !! I was searching in the doc but it really focuses on battery integration. I will have a look once everything will be in place. For the PID, its use does not relate to the required accuracy, or to speedup the limit. It more relates to ability to react more properly to an inaccurate correction. For example, if I set a target excess to -300W, and I need to set the limit to 300W on 10 inverters to arrive to this target, in reality, one inverter will produce 280W, one 330W, one will be under some shade, etc. So the PID will be able to auto-correct such inaccurate adjustment by recalculating a new correction to apply, until the next measurement comes. A PID would also be more tolerant and able to correct the uneven production of inverters, caused by shade, difference of power, orientation, etc. without PID, if you simply correct by computing a difference and spreading the new limit on inverters, the reality is that the real correction won't be as expected by the calculation because of too many unpredictable factors. But I am pretty sure that in your code, to do that, you are using some kind of PID, but just more specific, with the Kp term only (which is a correction done based on a percentage of the error == target - current measurement). The graph that you have is very good I think! The Kp Ki Kd terms of a PID allows also to tweak its responsiveness. |
What happened?
I am playing with Hoymiles HM and limits.
Currently, my inverters are configured like this: HM400 with 400Wp solar panel.
I have set a limit of 450W because in winter an inverter can output more than its nominal power (there is a tolerance usually of about 10% if I remember the HM specs)
When doing that, OpenDTU displays 112.5% but Home Assistant 25%:
Restarting OpenDTU seems also to have cleaned the persistent unit.
I am playing with limitation right now to test a future setup where I will have to limit the grid excess, so I will have to update the limits frequently based on the home consumption. And I saw this weird thing regarding the percentages, also disappearing after a reboot of OpenDTU.
Thanks a lot for your advices @tbnobody 👍
Also, FYI, I don't know if you saw the announcement: ESP32Async/ESPAsyncWebServer#1
Discord: https://discord.gg/7MythzfGDp
To Reproduce Bug
N/A
Expected Behavior
N/A
Install Method
Pre-Compiled binary from GitHub releases
What git-hash/version of OpenDTU?
v24.11.7
What firmware variant (PIO Environment) are you using?
esp32dev
Relevant log/trace output
Anything else?
No response
Please confirm the following
The text was updated successfully, but these errors were encountered: