EcoFlow Stream Ultra + Home Assistant via BLE – impressive control and flexibility

[christianrainerschmid-cell]

Hi everyone,

I just wanted to share my experience with the EcoFlow Stream Ultra using the BLE integration from this project:
https://github.com/rabits/ha-ef-ble

First of all: huge thanks for this work.
This BLE interface completely changes what is possible with the system.

I’m currently running a Home Assistant setup where I control the battery dynamically based on real-time conditions:

• PV production
• grid import/export
• house consumption
• EV charging

Using BLE, I can directly control:

• charging power limits
• base load (discharge power)
• backup reserve
• operation modes

And that opens the door to something much more advanced than the standard EcoFlow app:
👉 a fully automated, self-optimizing energy system

What I implemented so far:

• near zero-import behavior (grid stays around 0 W)
• dynamic charging based on PV surplus
• fine-grained discharge control (10 W steps)
• EV priority mode (optional 800 W battery discharge while charging)
• smooth ramp-up/down logic instead of aggressive jumps

What I really like:

• BLE control is surprisingly stable
• reaction time is good enough for real automation
• full local control (no cloud dependency)

What could be improved (if possible):

• slightly faster update cycle (to reduce control lag)
• finer control for charging (similar to discharge resolution)

Overall:
This integration turns the EcoFlow system from a “consumer product” into a real energy control system.

Thanks again for building and sharing this – it’s seriously impressive.

[GnoX]

Thanks for sharing.

Adressing improvements:

slightly faster update cycle (to reduce control lag)

Did you notice that there is an option update period in device options? Default is 10 seconds, but you can set it to 0 which makes it update as soon as the message is received which is around 1 second with a tradeoff that it will will make your database a lot larger.

finer control for charging (similar to discharge resolution)

What control are you referring to here? If it's Charging Power Limit and you're on v0.8.4, update to the latest version v0.8.5 that changed the resolution to 1W.

[christianrainerschmid-cell]

Hi @GnoX,

thanks a lot for the quick reply and the great work on this!

I didn’t notice the update period option – setting it to 0 and getting ~1s updates is exactly what I was looking for. That should significantly improve the control loop 👍

Also good to know about v0.8.5 – I just updated and the 1W resolution for charging power is a big improvement. That removes one of the last limitations I had.

Really impressive how fast this project is evolving.
This BLE integration already enables very precise real-time control.

Thanks again for your work!

[christianrainerschmid-cell]

Setup

• Battery: EcoFlow STREAM Ultra X (Firmware v1.0.2.1)
• Integration: Unofficial EcoFlow BLE Home Assistant integration (v0.8.5)
• Home Assistant (automation-based control)

What the BLE interface enables

With this integration I can directly control:

• number.ef_XXXX_charging_power_limit
• number.ef_XXXX_base_load_power
• select.ef_XXXX_energy_strategy
• number.ef_XXXX_backup_reserve

This is exactly what is needed to build a real control loop.

Switching between charge and discharge
The key is switching modes cleanly and deterministic.

Switch to CHARGE

• service: number.set_value
  target:
  entity_id: number.ef_XXXX_base_load_power
  data:
  value: 0

• service: select.select_option
  target:
  entity_id: select.ef_XXXX_energy_strategy
  data:
  option: "scheduled"

Then set charging power:

• service: number.set_value
  target:
  entity_id: number.ef_XXXX_charging_power_limit
  data:
  value: 600

Switch to DISCHARGE

• service: number.set_value
  target:
  entity_id: number.ef_XXXX_charging_power_limit
  data:
  value: 0

• service: select.select_option
  target:
  entity_id: select.ef_XXXX_energy_strategy
  data:
  option: "self_powered"

• service: number.set_value
  target:
  entity_id: number.ef_XXXX_backup_reserve
  data:
  value: 20

Then set discharge power:

• service: number.set_value
  target:
  entity_id: number.ef_XXXX_base_load_power
  data:
  value: 400

Dynamic control approach
Instead of fixed values, I use step-based ramping depending on grid conditions.

Charging (coarse ramp-up)
{% if grid <= -600 %}
+100 W
{% elif grid <= -300 %}
+50 W
{% elif grid <= -100 %}
+20 W
{% elif grid <= -50 %}
+10 W
{% endif %}

Discharging (fine control)
{% if grid >= 100 %}
+50 W
{% elif grid >= 20 %}
+10 W
{% elif grid <= -20 %}
-10 W
{% endif %}

Why this works well with BLE

• BLE update cycle (~1–10s) requires smoothing
• step-based control avoids oscillation
• no direct setpoints → stable behavior
• ramping reacts naturally to changing PV / load

Result

• stable operation around ~0 W grid import/export
• smooth charge/discharge transitions
• no ping-pong behavior
• full local control without cloud dependency

Conclusion
This BLE interface makes the STREAM Ultra behave like a fully controllable energy component in Home Assistant.
That was not possible before.

[christianrainerschmid-cell]

Update: Moving from Step-Based Control to PI Control (BLE, local, sub-second capable)

After getting a stable setup with step-based control (ramping + hysteresis), I’ve now taken the next step:
--> Switching to a real PI controller (Proportional + Integral)

Why this now works

The key enabler is the BLE interface:

• fully local control (no cloud latency)
• reaction time in the seconds range
• deterministic feedback

-->This is exactly what you need for proper control theory.

With MQTT/cloud-based setups, this was not feasible in a stable way.

Core idea

Target remains:

Grid Power ≈ 0 W (slightly negative preferred)

Control loop:

error = grid - target

P = kp * error
I = I + (ki * error)

output = output + P + I

What changed compared to the previous approach

Before (step-based logic):

• fixed steps (+10 / +50 / +100 W)
• thresholds
• intentionally conservative
• some “ping-pong” near boundaries

Now (PI control):

• continuous adjustment
• no discrete jumps
• automatic fine-tuning
• much smoother behavior
• Observed behavior

--> large error → fast reaction (P)
--> small persistent error → gradually eliminated (I)

Result:

• stable around 0 W
• near-zero grid import
• no visible oscillation
• smooth charge/discharge transitions
• Practical considerations

To keep it stable:

• deadband (e.g. −40 to +20 W)
• integral clamping (anti-windup)
• max step per cycle (e.g. ±50 W)
• 10 W quantization (EcoFlow limitation)
• Charge ↔ Discharge handling

Still separated via:

• charging_power_limit
• base_load_power
• energy_strategy

--> PI controller runs inside the active mode
--> mode switching remains deterministic

A fully unified controller (no mode switching) would be ideal, but is currently limited by the EcoFlow API design.

Conclusion
With BLE control, the EcoFlow system effectively becomes:

--> from a “black box”
--> to a controllable energy component

The PI controller provides:

• improved stability
• reduced grid import
• smoother curves
• more “industrial-grade” behavior instead of basic smart home logic

---

If there’s interest, I can share the Home Assistant implementation (including I-state handling, clamping, etc.).

[Expalmi]

It would be nice if you post your ha implementation.

[joaster-git]

Interesting post and it would indeed be nice to post the ha implementation.

Use case here is to have 0 grid feed-in, rather use a bit more from te grid (so positive usage).

Requested EcoFlow to implement an offset on their zero on the meter P1 control (which now dips frequently in negatieve, effectively feeding back). Just got back it is accepted and in developement.

Lastly want to give a shout out to the BLE integration creators/maintainers, it works locally, fast and really well.

Solutions as posted here will make it even more usefull.

[christianrainerschmid-cell]

I have published the first experimental version here:

https://github.com/christianrainerschmid-cell/ha-ecoflow-stream-pi-controller

It is still beta and intended as a starting point for advanced Home Assistant users who want to test PI-based EcoFlow STREAM zero-grid control.

The package uses an adapter layer at the beginning of the YAML file, so users only need to map their own entities there. The controller logic then works with internal EFCTRL aliases.

The main idea is a unified target power model:

positive target power = battery discharge
negative target power = battery charge
zero target power = idle / deadband

[Expalmi]

@christianrainerschmid-cell what I tried to mention ist, the entities in ha are only usable and writable when i have a charging task within the ecoflow app, otherwise they are greyed.

[GnoX]

This integration does not support creating/configuring charging tasks yet (other than modyfing if using controls), it needs task that is pre-configured from the app. For use in HA, you would do it only once and create 24 hour tasks for charging and discharging.

[Expalmi]

@GnoX thank you for clarify

[deltamelter]

@christianrainerschmid-cell
Very interested in the PI controller, I have been vibe coding in that direction too.
My charging tries to be primarily from solar but also from grid when the solar forecast is is poor or when my wholesale tracked rates are low or even negative. I use a shelly pro3em in HA to track import and import but having to smooth the readings because it is quite jumpy and possibly too noisy. My grid meter is not realtime accessible and although there is a near realtime API, the rate limiting makes this 60s refresh time at best.
How close to zero are you able to get? My main automation is trying to self-consume solar on baseload and only leaving excess for charging. When the UltraX is full or excess solar is more than the charging can use enable a secondary battery charger connected to external rack batteries.
Grid charging is always 1200W for the moment. because I am usually trying to maximise charge during short periods.

[christianrainerschmid-cell]

Thanks, very interesting setup.

In my case the important part is the grid meter update rate. I use a near real-time smart meter value in Home Assistant and smooth it with a short moving average, currently around 10 seconds. The PI controller targets roughly zero grid exchange, with a small negative target to avoid accidental import.

In stable conditions I can usually keep it quite close to zero, roughly within ±50 to ±150 W most of the time. It is not perfect, of course. Fast clouds, kettle/oven spikes, EV charging changes, or EcoFlow response delays still cause short overshoots.

The EcoFlow limits are also important:
discharge control is quite usable, because it can be set in small steps
charging is much coarser, because charging power changes in larger steps
therefore the PI controller works better on discharge than on charge

With a 60 second grid meter refresh I would probably not run an aggressive PI loop. That would be too late and may oscillate. I would use a slower outer-loop approach instead: smooth the grid value heavily, apply a deadband, and only change the charge/discharge setpoint every 60–120 seconds.

My current idea is:
PI controller for live zero-grid control when the meter data is fast enough
forecast and electricity price logic as a higher-level planner
simple hard overrides for EV charging, low SOC, full battery, and cheap/negative grid prices

For grid charging I also see the value of using 1200 W during short cheap periods. For solar surplus charging I prefer smoother control, because otherwise it easily creates import/export oscillation.