[Request] Add support for Eltek Flatpack2 AC Charger Network or virtual AC Charger via HTTP Post

[SintraDD]

Is your feature request related to a problem? Please describe.

Hi everyone! I am a big fan of the OpenDTU-OnBattery project.

I'm currently running a setup with 3x Eltek Flatpack2 AC chargers.
While it is technically possible to control the chargers via Home Assistant as an intermediary, this creates an overly complex 'chain' of systems between OpenDTU and the hardware. Relying on an intermediate layer introduces unnecessary latency and points of failure. A direct integration within OpenDTU-OnBattery would be significantly more robust, provide much faster and more reliable communication for the power control loop, and drastically reduce the dependency on external automation platforms.
It would be ideal if this could be implemented following the pattern of the existing Huawei grid charger or the MeanWell integration provided by skippermeister, ensuring a consistent and native way to handle AC charging directly within the firmware.

Thank you for your work, it´s great
Jan

Describe the solution you'd like

I see great potential in adding support for these chargers to enable dynamic AC charging (similar to how MeanWell units are supported). I found an existing ESP32/CAN implementation here: (https://github.com/taHC81/Eltek-Flatpack2-ESPhome).

Is there a developer interested in adopting this into the main branch or as a modular plugin? I have the hardware (3 Eltek units, ESP32, CAN transceiver) ready to go and I am very happy to act as a beta-tester for any implementation that is developed. I am looking for a stable way to integrate these chargers into the ZeroExport logic.

Describe alternatives you've considered

OR

Instead of talking to a specific hardware protocol (like MeanWell), OpenDTU on Battery could offer a configuration to send the calculated charging setpoints (Voltage/Current) as an HTTP POST request to a specific IP address in the local network.

Why this is beneficial:

Flexibility: This allows users to handle the specific hardware control (like CAN-bus communication via Tasmota or ESPHome) externally.

Load Balancing: I can handle the power distribution across my three Eltek modules via an external script or Tasmota, without overloading the OpenDTU firmware with low-level CAN timing.

Reduced Complexity: It keeps the OpenDTU core stable and allows users to adapt any custom hardware (Eltek, Victron, etc.) just by receiving a JSON payload containing the current setpoints.

The request:
Could you add an option to the 'AC Charger' or 'Battery' settings to push the target charging values to a configurable local HTTP endpoint (e.g., POST /set_power { "voltage": 54.0, "current": 20.0 })?

This would make the OpenDTU much more versatile for custom setups and save´s the MQTT Way for other purposes.

Additional context

Thank you for your work, it´s great
Jan

[SintraDD]

I have been thinking further about the integration architecture, and I would like to propose a potentially cleaner alternative to the HTTP push approach: extending the existing GridCharger API.

Currently, the GridCharger module and its API are effectively 'idle' unless a physical charger is actively grid-charging. I believe we could leverage this by implementing a 'virtual' or 'abstract' charger profile.

The Proposal:
Instead of externalizing the control logic, we could use the GridCharger interface as a native container for the target charging parameters (Voltage and Current setpoints).

Why this is more robust:

Direct Integration: By utilizing the existing GridCharger framework, the internal Dynamic Power Limiter could communicate its requirements directly. This removes the need for an intermediate automation layer and prevents the latency issues inherent in external control loops.

Deterministic Control: Rather than relying on external scripts to 'hunt' for the right current in 1A increments, the OpenDTU firmware could provide precise, real-time setpoints directly to the charger driver.

Architectural Consistency: This approach keeps the control logic centralized within the firmware. The GridCharger module would act as an interface where the logic (what power is needed) is separated from the driver (how it is communicated via CAN, Modbus, etc.).

Would it be feasible to abstract the GridCharger module so that it can hold and expose these setpoints even when no hardware-specific grid charger is detected? This would allow users to bridge custom hardware (like my Eltek setup) into the native control loop without bloating the system with external webhooks.

I am happy to test any implementation or help document the interface requirements for such a virtual charger.

[SintraDD]

Zero-Export Control Logic for Battery Chargers (Input for Virtual Power Supply / Intelligent Limiter API Feature)

I have a running setup where I dynamically control a 3-phase Flatpack2 rectifier array to charge my battery storage based on OpenDTU live data.
My goal is absolute Zero-Export (Nulleinspeisung). Since OpenDTU already has all the data (Solar Power, Grid Meter, Inverter Limits), I am currently fetching the JSON via API every 45 seconds to calculate the perfect DC charging current.
To support the idea of a "Virtual Power Supply" / "Smart Grid Brake" feature directly inside OpenDTU (which calculates and exposes the optimal target current/power via API), I want to share my control loop logic.
It solves a major problem: handling inverter latency and preventing control loop oscillations (hunting). Core Logic PhilosophyThe algorithm operates on four distinct grid states to balance speed and stability:
Hard Grid Draw (> 150W): Immediate, aggressive reduction of charging power to protect the grid/pockets.
Soft Grid Draw (40W to 150W): Gradual, smooth braking to fine-tune without causing counter-oscillations.
True Surplus / 0A Trigger: Activates a safe "Start-Ramp" at 5.25A, but crucially checks if the inverters have already reached their limits ($P_{Solar} / P_{Limit} \ge 65%$) before increasing further.
This prevents ramp-up during inverter latency phases.
Micro-Stepping Window (-15W to 40W): Ultra-small steps ($\pm 0.05\text{A}$) to perfectly hover around the zero-line.

Why this is perfect for an internal OpenDTU implementation:
Inverter Latency Aware (The Ratio Check): The conditional check (total_solar_power / sum_limit) < 0.65 is the magic bullet. It actively stops the loop from blindly increasing the charging current while the Hoymiles inverters are still processing their last grid-limiter step.

Separation of Concerns: OpenDTU wouldn't need to know what hardware is connected (Flatpack, Eltek, MeanWell). It just needs to calculate the ideal Target_Chg_Power (W) or Target_Chg_Current (A) based on this state machine and serve it via an API endpoint (e.g., /api/powerlimiter/virtual_psu).

Hardware Friendly: It implements startup-ramps (5.25A) and handles the zero-line with absolute micro-steps, minimizing thermal stress on rectifiers and preserving battery health.

Would love to hear your thoughts on integrating a virtual PSU calculation engine into the powerlimiter core!

Thanks a lot
Jan

Code is in Tasmota Berry (similiar to py)

▶ Click to expand the control loop code (Berry Script)

# ----------------------------------------------------------------------------
# CORE REGULATION LOOP (Executed every 45 seconds to handle inverter latency)
# ----------------------------------------------------------------------------
def control_charge_efficiency(v_akku, p_meter, total_solar_power, sum_limit)
    # v_akku            : Battery Voltage (V)
    # p_meter           : Grid Meter Power (W) -> Positive = Import, Negative = Export
    # total_solar_power : Current Solar Production (W)
    # sum_limit         : Sum of current absolute limits set on producing PV inverters (W)

    if v_akku > 40.0
        # Dynamic target voltage setup (keeps CV phase tracking the battery)
        var target_v = v_akku + 1.0
        if target_v > 56.8 target_v = 56.8 end
        self.set_v = target_v
        
        var current_i = self.set_i

        # --------------------------------------------------------------------
        # STATE 1: HEAVY GRID DRAW (> 150W) -> Fast & Aggressive Back-off
        # --------------------------------------------------------------------
        if p_meter > 150.0
            var excess_watt = p_meter - 150.0
            var reduce_amp = excess_watt / v_akku
            if reduce_amp < 0.5 reduce_amp = 0.5 end 
            
            current_i = self.set_i - reduce_amp
            
            # Hardware specific minimum load cut-off (Flatpack threshold)
            if current_i < 5.25 
                current_i = 0.0 
                self.regler_status_text = "Shutdown: High grid import, below minimum hardware load."
            else
                self.regler_status_text = "Aggressive reduction due to grid load spike."
            end
            self.set_i = current_i

        # --------------------------------------------------------------------
        # STATE 2: MODERATE GRID DRAW (40W to 150W) -> Smooth Fine-Braking
        # --------------------------------------------------------------------
        elif p_meter > 40.0
            if self.set_i >= 5.25
                var fine_reduction = 0.12 # Small steps to prevent counter-oscillations
                current_i = self.set_i - fine_reduction
                
                if current_i < 5.25 
                    current_i = 0.0 
                    self.regler_status_text = "Shutdown via fine-tuning: Fell below 5.25A."
                else
                    self.regler_status_text = "Soft braking due to minor grid import."
                end
                self.set_i = current_i
            else
                self.regler_status_text = "Holding 0.00A: Grid import present, charging not possible."
            end

        # --------------------------------------------------------------------
        # STATE 3: TRUE SOLAR SURPLUS OR INITIAL 0A TRIGGER
        # --------------------------------------------------------------------
        elif p_meter < -15.0 || (self.set_i == 0.0 && p_meter <= 35.0)
            var allowed_to_ramp_up = true
            
            if sum_limit <= 0.0
                allowed_to_ramp_up = false
                self.regler_status_text = "Lock: No active solar inverters producing (Night/Offline)."
            else
                # CRITICAL: Anti-Hunting Check! 
                # If current production hasn't caught up to 65% of the allocated limit yet,
                # the inverter is still ramping up (latency). Do NOT increase charger load yet.
                if (total_solar_power / sum_limit) < 0.65
                    allowed_to_ramp_up = false
                    self.regler_status_text = "Holding load: Waiting for Inverters to catch up to limits."
                end
            end
            
            if allowed_to_ramp_up
                # If charger is completely off, start with the safe hardware minimum step
                if self.set_i < 5.25
                    current_i = 5.25 
                    self.regler_status_text = "Start-Ramp triggered: Solar reserve available."
                else
                    # Step up safely to approach the absolute maximum surplus
                    current_i = self.set_i + 0.25
                    self.regler_status_text = "Increasing charge current: True export detected."
                end
                
                # Safety Margin: Never request more current than the current solar array can physically supply + 3A buffer
                var max_feasible_i = (total_solar_power / v_akku) + 3.0
                if current_i > max_feasible_i current_i = max_feasible_i end
                if current_i > 80.0 current_i = 80.0 end  # Global hardware safety ceiling
                
                self.set_i = current_i
            else
                # Status text set by the anti-hunting logic above
                print(self.regler_status_text)
            end

        # --------------------------------------------------------------------
        # STATE 4: THE ZERO-LINE DEADZONE (-15W to 40W) -> Micro-Adjustments
        # --------------------------------------------------------------------
        else
            if self.set_i >= 5.25
                if p_meter < 0.0
                    self.set_i = self.set_i + 0.05 # Micro-step up if still slightly exporting
                    self.regler_status_text = "Micro-step +0.05A (Hovering around zero-line)"
                elif p_meter > 10.0
                    self.set_i = self.set_i - 0.05 # Micro-step down if slightly importing
                    self.regler_status_text = "Micro-step -0.05A (Hovering around zero-line)"
                else
                    self.regler_status_text = "Perfect equilibrium achieved."
                end
                if self.set_i > 80.0 self.set_i = 80.0 end
            else
                self.regler_status_text = "Waiting for surplus trigger to break minimum load threshold."
            end
        end
    end
end