Implement OpenDTU meter

[sthhs]

This component implements an OpenDTU single phase meter. It sends http requests to an OpenDTU and evaluates power, voltage and current from the response.

[codecov]

Codecov Report

❌ Patch coverage is 67.90123% with 26 lines in your changes missing coverage. Please review.

Additional details and impacted files

@@              Coverage Diff              @@
##             develop    #3562      +/-   ##
=============================================
+ Coverage      59.35%   59.42%   +0.07%     
  Complexity       105      105              
=============================================
  Files           3069     3071       +2     
  Lines         133076   133157      +81     
  Branches        9815     9820       +5     
=============================================
+ Hits           78979    79116     +137     
+ Misses         51125    51054      -71     
- Partials        2972     2987      +15     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Sn0w3y]

Thank you! Generally solide! I still had some Comments.

Please see my PR (outdatet) - we already tried to implement it a longer Time ago - @DerWahreKlinki and me. Our implementation also supported Setting Power Limits (required in some cases).

Maybe we should consider to take the "best of two Worlds" and merge our Codes or join Forces and Improve both :)

[Sn0w3y]

@sthhs what do you think of my suggestion?

[sthhs]

@sthhs what do you think of my suggestion?

When should the limit be set? Only once at the first connection? Or should it be regularly requested and set if the received value doesn't match the target in OpenEMS?

My point of view with this component is:

• Keep it as simple as possible. If someone uses an OpenDTU, he should be able to configure the inverter from there. The limit may not be changed very frequently.
• If the API changes, this doesn't affect the OpenEMS component.
• Without the ability of writing values to an OpenDTU there is no need for storing credentials and therefore no possible security risk, even if this would be very low.

[Sn0w3y]

IMHO every time it changes (see other Components) as in Germany (as you know) there is a 800W Limit for Balcony Solar and many of the Customers want to set it. Would be nice if OpenEMS could do so aswell.

The limit can and should be changed frequently (see Dynamic Limit in OpenDTU) - also because of Zero-Feed-in use case where ine wants to use 100% (lets say 1000W) of his Balcony Solar but not Feed into Grid as this would again not be allowed.

Well if we see it from an API perspective - we have many many Components which depend on APIs/Registers and so on - why should we make an Exception on the OpenDTU?

We handle Security pretty well in OpenEMS (Backend Communication, Api-Keys, etc.) since the communication is local i do not see any problems in that tbh

[ChristianSill]

As far as I know, a reversible software-side throttling of the WR to 800 W does not fall into the balcony solar category. If you want to operate it in accordance with the rules. On the other hand, a factory throttling by the manufacturer is permissible. But I like to be taught a better one.

[Sn0w3y]

As far as I know, a reversible software-side throttling of the WR to 800 W does not fall into the balcony solar category. If you want to operate it in accordance with the rules. On the other hand, a factory throttling by the manufacturer is permissible. But I like to be taught a better one.

I still believe it absolutely makes sense to include the dynamic limit feature in this component.

OpenEMS is an Energy Management System, not just a passive monitoring layer. If we only read values from OpenDTU, we reduce this integration to a pure meter adapter. One of the core purposes of OpenEMS is to actively control and optimize energy flows — and dynamic power limiting is a fundamental EMS use case (zero-feed-in, self-consumption optimization, grid constraint handling, etc.).

Regarding the 800 W balcony solar discussion: the regulatory requirement is that no more than 800 W AC are fed into the grid. A dynamic EMS-based limit fully respects that physical constraint. In practice, many installations already rely on software-based caps or dynamic limiting (especially for zero-feed-in scenarios). This is not an exotic edge case but a real-world requirement.

Technically, dynamic limiting is superior to static manufacturer throttling because it allows full self-consumption while preventing grid feed-in. A fixed 800 W factory limit wastes potential if local load is higher. With EMS control, we can adapt in real time — which is exactly what OpenEMS is built for.

Security-wise, this does not introduce a new risk class. We already store credentials and write to APIs/Modbus devices in many components. Communication is local, and write access can be made optional via configuration. Read-only mode can remain the default to keep things simple.

So this is not about overengineering — it’s about enabling proper EMS functionality. We can keep the implementation clean and optional, but removing write capability would unnecessarily limit the integration and contradict the overall design philosophy of OpenEMS.

[sthhs]

How ist this solved for other PV inverters? I've been searching for the corresponding code in the controllers of Fronius or Kostal inverters and they only seem to request data from them, but don't send anything for setting the power limit. Maybe I haven't found it, or does it not exist?
Sending a Post request to the OpenDTU is quite simple, but there seems to be done much more for giving OpenEMS the possibility to set the limit dynamically dependant on the current feed strategy.

[Sn0w3y]

Another thought of mine:

• We should check, if there is a way to Implement it, so multiple Inverters can be fetched at once with one call as the DTU is running on an ESP32 it should not be fetched 5 times per second (1000ms Cycle).
• There is an Endpoint http:///api/livedata/status which gives us the Info of all connected Inverters to the DTU so we do not need 5 Components if there are 5 Inverters connected

TBD: We should also check, if there is a possibility to then still see 5 Components in the UI (@sfeilmeier is this possible, if there is only one Component activated?)

JFYI: My Implementation of the DTU is running smoothly aswell with the Feature of the Limit Setting - but i discovered Issues after some Runtime because of the multiple Requests made from OpenEMS'es side (i have 5 Inverters).

[sfeilmeier]

TBD: We should also check, if there is a possibility to then still see 5 Components in the UI (@sfeilmeier is this possible, if there is only one Component activated?)

I did not read through everything - but no, the current UI strictly expects separate Components. This is also required to use standard Channel-IDs like "ActivePower" per component