Home Assistant Integration not displaying the same limit % as the website when over 100% #2511
Comments
|
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: 
In HA: 
|
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). |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@tbnobody : I can confirm that OpenDTU sends the right % amount to MQTT: 
But HA is stuck at 100%: 
I will try modify something and raise a PR it it works... An idea could be to remove this The problem is that the discovery topic is sent with a min set to 0-100%. So this is not the fault of HA, but how OpenDTU sets the limits for the slider 
What I do not understand is : if (type == PowerLimitControlType::RelativNonPersistent || type == PowerLimitControlType::RelativPersistent) {
limit = min<float>(100, limit);
}If we have the code above... IS the code above right, or wrong ?
|
The inverter will Never Return a value >100%. The percentage value has nothing to do with any value detected by opendtu. The value ist just sent to the inverter and it applies it in some way. You can send values > 100% but the inverter will never apply them and return something else if it is fetched the next time. |
|
Ah! And there is another confusion: publishInverterNumber(inv, "Limit NonPersistent Relative", "status/limit_relative", "cmd/limit_nonpersistent_relative", 0, 100, 0.1, "%", "mdi:speedometer", STATE_CLS_NONE, CATEGORY_CONFIG);
publishInverterNumber(inv, "Limit Persistent Relative", "status/limit_relative", "cmd/limit_persistent_relative", 0, 100, 0.1, "%", "mdi:speedometer", STATE_CLS_NONE, CATEGORY_CONFIG);
publishInverterNumber(inv, "Limit NonPersistent Absolute", "status/limit_absolute", "cmd/limit_nonpersistent_absolute", 0, MAX_INVERTER_LIMIT, 1, "W", "mdi:speedometer", STATE_CLS_NONE, CATEGORY_CONFIG);
publishInverterNumber(inv, "Limit Persistent Absolute", "status/limit_absolute", "cmd/limit_persistent_absolute", 0, MAX_INVERTER_LIMIT, 1, "W", "mdi:speedometer", STATE_CLS_NONE, CATEGORY_CONFIG);The UI made me understand that there are 2 different limits:
This is only true when setting a value.
absolute value is computed: uint16_t maxpower = inv->DevInfo()->getMaxPower();
if (maxpower > 0) {
MqttSettings.publish(subtopic + "/status/limit_absolute", String(inv->SystemConfigPara()->getLimitPercent() * maxpower / 100));
}So when I send an absolute value to the inverter, the inverter allows it, and returns a limitPercent() > 100%, which displays a correct value. But when using % the code with the min prevents setting a % higher than 100. Why ? I don't know since it seems to be supported in the inverter I have (Hm400). Is this constrain there to support inverters that do not allow > 100% ? |
That is not my understanding of the code:
when publishing to MQTT, the code publishing the absolute value is: uint16_t maxpower = inv->DevInfo()->getMaxPower();
if (maxpower > 0) {
MqttSettings.publish(subtopic + "/status/limit_absolute", String(inv->SystemConfigPara()->getLimitPercent() * maxpower / 100));
}which means that the inverter took in consideration the absolute limit > nominal power and returned 112.5%. |
That's not right. We are sending a new limit to the inverter and assume it applied it. After ~4-5min the current limit is polled from the inverter (its not possible earlier otherwise it would generate nasty errors in the event log) |
No in my HM400: I set a hard limit to 450W yesterday, it remained and was there this morning... The UI read 450W and 112.5% in the stats (front page). And this is totally fine technically to accept an upper limit for an inverter otherwise it will limit itself to its nominal power and won't output for than its nominal power when it can: there is usually a small tolerence above the nominal power, eben if not in the datasheet. I am monitoring the AC production of each, plus the total with a Shelly EM. And in winter, especially 2022 and 2023, I had power spikes at more than 415, even 420W AC for output. |
|
I tested 2 patches. First one for HA Discovery: diff --git a/src/MqttHandleHass.cpp b/src/MqttHandleHass.cpp
index c39485dd..c0481fab 100644
--- a/src/MqttHandleHass.cpp
+++ b/src/MqttHandleHass.cpp
@@ -83,8 +83,8 @@ void MqttHandleHassClass::publishConfig()
publishInverterButton(inv, "Restart Inverter", "cmd/restart", "1", "", DEVICE_CLS_RESTART, STATE_CLS_NONE, CATEGORY_CONFIG);
publishInverterButton(inv, "Reset Radio Statistics", "cmd/reset_rf_stats", "1", "", DEVICE_CLS_NONE, STATE_CLS_NONE, CATEGORY_CONFIG);
- publishInverterNumber(inv, "Limit NonPersistent Relative", "status/limit_relative", "cmd/limit_nonpersistent_relative", 0, 100, 0.1, "%", "mdi:speedometer", STATE_CLS_NONE, CATEGORY_CONFIG);
- publishInverterNumber(inv, "Limit Persistent Relative", "status/limit_relative", "cmd/limit_persistent_relative", 0, 100, 0.1, "%", "mdi:speedometer", STATE_CLS_NONE, CATEGORY_CONFIG);
+ publishInverterNumber(inv, "Limit NonPersistent Relative", "status/limit_relative", "cmd/limit_nonpersistent_relative", 0, 200, 0.1, "%", "mdi:speedometer", STATE_CLS_NONE, CATEGORY_CONFIG);
+ publishInverterNumber(inv, "Limit Persistent Relative", "status/limit_relative", "cmd/limit_persistent_relative", 0, 200, 0.1, "%", "mdi:speedometer", STATE_CLS_NONE, CATEGORY_CONFIG);
publishInverterNumber(inv, "Limit NonPersistent Absolute", "status/limit_absolute", "cmd/limit_nonpersistent_absolute", 0, MAX_INVERTER_LIMIT, 1, "W", "mdi:speedometer", STATE_CLS_NONE, CATEGORY_CONFIG);
publishInverterNumber(inv, "Limit Persistent Absolute", "status/limit_absolute", "cmd/limit_persistent_absolute", 0, MAX_INVERTER_LIMIT, 1, "W", "mdi:speedometer", STATE_CLS_NONE, CATEGORY_CONFIG);
@@ -232,6 +232,9 @@ void MqttHandleHassClass::publishInverterNumber(
root["min"] = min;
root["max"] = max;
root["step"] = step;
+ if (max > 100 && unit_of_measure == "%") {
+ root["mode"] = "box"; // do not show a slider for possible % going more than 100%
+ }
publish(configTopic, root);
}Which is basically saying: if we define a number where we have to enter a % and its max allowed value is more than 100%, then switch to a box, not a slider. And it works. After the DTU is flashed and once the radio got the inverters limit, I have some consistent values in HA: 
Then, I did another patch to test your theory about the % value sent to inverters: diff --git a/lib/Hoymiles/src/inverters/HM_Abstract.cpp b/lib/Hoymiles/src/inverters/HM_Abstract.cpp
index d58324da..f77689cb 100644
--- a/lib/Hoymiles/src/inverters/HM_Abstract.cpp
+++ b/lib/Hoymiles/src/inverters/HM_Abstract.cpp
@@ -124,9 +124,9 @@ bool HM_Abstract::sendActivePowerControlRequest(float limit, const PowerLimitCon
return false;
}
- if (type == PowerLimitControlType::RelativNonPersistent || type == PowerLimitControlType::RelativPersistent) {
- limit = min<float>(100, limit);
- }
+ // if (type == PowerLimitControlType::RelativNonPersistent || type == PowerLimitControlType::RelativPersistent) {
+ // limit = min<float>(100, limit);
+ // }
_activePowerControlLimit = limit;
_activePowerControlType = type;So from what I observe of all my HM400, I can set a persistent absolute value of 450W, and it will stay in the inverters, and the inverters will return 112.5% for the % ( So with this patch, I am now testing if I can send 115% to the inverter. So I am entering 115% in the HA box: 
And the inverter switches to 115% / 460W 
and both limits (absolute and relative) are displayed in MQTT: 
So even if I agree with your sentence that the inverter could correct the input user value, I don't see any reason why OpenDTU should clamp the percentage (and weirdly, only the percentage) to 100%, when it could just let go all values and reads back the corrected one after. If some inverters are not OK with % greater than 100%, then this is not up to OpenDTU to manage that, but more up to the users. And If clamping to 100%, then why the absolute power also is not clamped to the detected nominal power for consistency ? |
|
@schlimmchen : FYI. |
|
I've opened PR #2513 |
|
Here is the board I am testing with in HA, with my current PnP installation, before going to a 5.5 kW rooftop one. 
So what's important for me is to be able to globally and manually set a persistent absolute power limit for all inverters, which I do with the number at the top, which automatically updates in a few seconds the inverters and the stats on the left (% and absolute power) are updated in consequence. That is the base of the panel I will use to monitor the auto adjustment of the inverters power limit based on the grid power excess / home consumption read from a JSY (local or remote - do not know yet but both are easy to support), to always let some little excess going out as a buffer. |
I will give you the shallow answer for now: I was not aware that the inverter would accept a limit higher than 100% of its nominal output power. @AndreasBoehm probably also is not aware of this. I just tried something:
The inverters don't actually produce more than their nominal power. However, I am confused that the limit value is shown as it is, because I know specifically that the value shown there is read from the inverter's answer to the limit command. That would mean the inverter receives a new absolute limit higher than its capabilities and does not answer with the value capped to its nominal power, but with the value it received, like in an echo. What I don't know is that other command which Thomas mentioned that is only "allowed" every four minutes or something, which would apparently update the limit shown by OpenDTU to the one actually in effect? I guess I need to restart OpenDTU to see that in action, as it seems the limit shown is not updated. So I initiated a reboot. The limit reads "0" now, as the limit is not known. Okay, so I did not send any new limit to the inverters, but both show the previous non-persistent limit I set earlier. That should mean that the inverter has internalized the actual value I sent, which is higher than its nominal power. I set 2222W as the persistent limit of my HM-1500: After restarting the inverter, it produces at 100% of its nominal power: After restarting OpenDTU, the limit is unknown: I shut down the inverter and wait for OpenDTU to fetch the current limit value: So... What I make of this: The inverters accept and even save a limit higher than their nominal power, because they obviously just don't check the value for sanity. The part of the inverter that consumes the limit value, however, obviously is not tricked into trying to produce more than the nominal power. I guess we should therefor try harder to avoid that the user ever sees a limit value greater than 100%, i.e., cap the limit value to the (eventually) known power output capability. That's the opposite direction of what Mathieu is suggesting in his PR 🤷♂
Are you asking me how to do this in OpenDTU-OnBattery? Publish to MQTT topic |
|
@schlimmchen an inverter can output more than the nominal power, there is a tolerance it seems. especially in winter, with good sun and low temp, It happened to me to produce 420W AC with an HM400 (400W nominal power). So I think the inverter accepts any limit, but will just make sure to clamp the production to this limit. But for what is worth, at any rate, these spikes only happen for a few seconds since a rated inverter of 400W is not supposed to output more than that on the long run. I was just talking about the tolerance and the possibility to have more, and the fact that the % do not match the absolute value in HA. Why would an absolute value be allowed to be set (and kept) with a value being more than the detected power, if the percentage is clamped to 100%.
I also agree with that approach, because these spikes of production are not important and just last a few seconds. So they are irrelevant. This ticket is much more about bringing consistency across the values.
thanks! |
|
I don't doubt that the inverter is able to produce these spikes of AC output power. Not even spikes: When fed from a battery the inverters produce slightly more power even for extended periods of time. Notice that the output power in my screenshots above is also slightly higher than the nominal power. However, that is also the case for a limit of exactly 100%:
That is to say: IMHO there is no need to be able to set a limit higher than the nominal power rating. |
Nope. The limit command only returns whether it was successful received. It does not return the currently set value. The SystemConfigPara command is used to fetch the the percentage value from the inverter (reading the absolute limit is not possible) |
|
So what should be the conclusion ?
|
Ha... Thanks! I re-read the code with that in mind and I can see it now. Once the command succeeded, the value that was transported to the inverter using that command is then set in the inverter's SystemConfigPara.
I prefer that option. There is a catch: The inverter's max power is not known right from the start, it has to be fetched first. In the DPL, inverters are not eligible for use until their max power is known. We'd have to do something similar when processing requests to set absolute limit values... |
No, we can let them go as now, It is just the displayed value and the one sent to mqtt that will be corrected. Anyone, even another system that opendtu could set a value more than the nominal power or a greater percebtage. But right now, opendtu has different behavior in the display of both information. it clamps the setting of %, but does not clamp the reading. |
--- a/lib/Hoymiles/src/parser/SystemConfigParaParser.cpp
+++ b/lib/Hoymiles/src/parser/SystemConfigParaParser.cpp
@@ -47,7 +47,11 @@ float SystemConfigParaParser::getLimitPercent() const
HOY_SEMAPHORE_TAKE();
const float ret = ((static_cast<uint16_t>(_payload[2]) << 8) | _payload[3]) / 10.0;
HOY_SEMAPHORE_GIVE();
- return ret;
+
+ // don't pretend the inverter could produce more than its rated power,
+ // even though it does process, accept, and even save limit values beyond
+ // its rated power.
+ return min(100, ret);
}
void SystemConfigParaParser::setLimitPercent(const float value)This should do it? |
|
|
|
min(100, 42) = 42 => as expected I assume you have the typical brain fuck when using min/max functions? You limit some value to a known max by using the min function. |
ahah! yeah exactly ;-) So should I update my PR or you raise another one ? |
|
Updated #2513 |
|
I confirm it works! I have 125% set in my inverters. After a few minutes, I get 100% 400W. I also tested my automation to set the a limit on all inverters and switch back to 350W, which displays 100% 400W. 
|
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 (415W-425W for spikes)
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: