Skip to content
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

Open
4 tasks done
mathieucarbou opened this issue Jan 23, 2025 · 7 comments
Open
4 tasks done
Labels
bug Something isn't working

Comments

@mathieucarbou
Copy link

mathieucarbou commented Jan 23, 2025

What happened?

I am playing with Hoymiles HM and limits.

Currently, my inverters are configured like this: HM400 with 400Wp solar panel.

Image Image

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%:

Image

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

  • I believe this issue is a bug that affects all users of OpenDTU, not something specific to my installation.
  • I have already searched for relevant existing issues and discussions before opening this report.
  • I have updated the title field above with a concise description.
  • I have double checked that my inverter does not contain a W in the model name (like HMS-xxxW) as they are not supported.
@mathieucarbou mathieucarbou added the bug Something isn't working label Jan 23, 2025
@mathieucarbou
Copy link
Author

I found that after updating the hard limit, the % does not move. So I changed the hard limit back and forth to 450W:

In OpenDTU:

Image

In HA:

Image

@schlimmchen
Copy link
Contributor

When doing that, OpenDTU displays 112.5% but Home Assistant 25%:

That might be a HomeAssistent issue. If Thomas has a hard time debugging this, I will gladly take a look.

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.

Are you aware of the daughter project, which has the Dynamic Power Limiter?

@tbnobody
Copy link
Owner

When doing that, OpenDTU displays 112.5% but Home Assistant 25%:

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:

if (type == PowerLimitControlType::RelativNonPersistent || type == PowerLimitControlType::RelativPersistent) {
limit = min<float>(100, limit);
}

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.

@tbnobody
Copy link
Owner

Also, FYI, I don't know if you saw the announcement: ESP32Async/ESPAsyncWebServer#1

Yes I already saw it and already updated the platformio.ini :-)

@mathieucarbou
Copy link
Author

That might be a HomeAssistent issue. If Thomas has a hard time debugging this, I will gladly take a look.

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 ?

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.

yes I can do tomorrow! I completely forgot lol!

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.

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.

Image

Are you aware of the daughter project, which has the Dynamic Power Limiter?

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

@schlimmchen
Copy link
Contributor

since it has a focus on battery usage

Meh, that's not true, despite the name. We explicitly support (possibly multiple) solar-powered inverters as well.

What I would need is to integrate OpenDTU with an MQTT topic to read the grid voltage

even better, with a JSY-163-T for example

Possibly supported. I guess this is speaking SML? If not, integrating a new power meter interface should be straight-forward for you 😉

have a setting in OpenDTU that lets me chose the excess / import I wan to allow

Typically, this would be implemented like a PID algorithm

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.

Image

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 😊

@mathieucarbou
Copy link
Author

mathieucarbou commented Jan 23, 2025

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!
I know that it takes a few seconds for inverters to adhere to a new limit. So doing that in 5 seconds is nice!

The Kp Ki Kd terms of a PID allows also to tweak its responsiveness.
In your graph example, you seem to have quite stable home consumption after the boiler is disabled.
But imagine that you had someone cooking in the kitchen ;-) You would get a lot of on/off with different appliances. So a PID is also able to "slowdown" to reach a target by smoothing its corrections to avoid these sort of abrupt correction (coming a few seconds later in effect) in the case of a sequence of lot of high / low consumptions. It does that thanks to his integral term and summations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants