[APP][Pro] HomeFlux EMS – Your energy, managed differently

[Davy_Bert]

HomeFlux EMS is a hardware-independent energy management system for Homey Pro.

It brings your home’s energy together in one system and decides when to charge or use your home battery, when to make the most of solar production, and when flexible loads such as EV charging, heating, cooling or hot water can run most efficiently.

HomeFlux supports both dynamic energy contracts and fixed contracts with different tariff periods, while taking solar forecasts, battery reserves and grid limits into account. Peak Guard always keeps priority to help avoid unwanted consumption peaks.

Because HomeFlux uses Homey Flow cards for its integrations, it is not tied to one specific battery, inverter, EV charger or HVAC brand. This makes it possible to combine different brands and devices in one energy strategy.

This topic can be used for:

• questions about setup and configuration;
• sharing supported hardware combinations;
• reporting unexpected behaviour;
• suggestions for improvements and new features.

HomeFlux EMS is available here:

HomeFlux EMS | Homey

For bug reports and technical issues you can also use:

Issues · DavyBert/HomeFlux-EMS

HomeFlux EMS — Your energy, arranged differently.

[smarthomesven]

@Davy_Bert

HomeFlux EMS is available here:

https://homey.app/en-nl/app/com.homeflux.ems/HomeFlux-EMS/

You forgot to add /test to the end of the URL

[Davy_Bert]

This is how the app receive info and control devices.

Data input

Output flow

Hvac control

hvac input

More cards are available to override the behaviour of the controller.
The controller can be added as a device.

[Jurgen_Schoorlemmer]

Hi,

I recently started looking seriously at HomeFlux as the EMS layer for my Homey setup. What I like is the idea of having one central energy logic layer instead of building everything in separate Advanced Flows.

My setup is roughly:

• Homey Pro
• dynamic electricity contract
• SMA hybrid inverter + BYD battery
• Zappi EV charger
• Renault EV
• Nibe heat pump
• PV around 13.5 kWp
• home battery around 10 kWh

For now I’m mainly using HomeFlux as the basis for monitoring and planning. I want to move towards coordinated control of EV, battery and later the heat pump, but with native device safety/fallbacks staying in place.

What I noticed is that the HomeFlux community is still fairly quiet compared with some other Homey energy apps. That’s a pity, because I think there is a lot of potential here, especially for people who want something more structured than a large collection of individual flows.

A few things I’d be interested in:

1. More visibility into decisions
   It would be useful to see not only what HomeFlux wants to do, but also why. For example:

• EV waiting because next cheap quarter starts at 13:15
• battery holding because cheap EV charging is coming up
• charging battery from PV surplus
• no action because price difference is too small

A simple current-state / reason view would already help a lot when validating an EMS.

2. Clear separation between strategy and device control
   For battery and EV control I would prefer HomeFlux to determine the intent, while the actual device integration handles vendor-specific behaviour. For example:

• Battery: AUTO / HOLD / CHARGE / DISCHARGE
• EV: WAIT / SMART CHARGE / CHARGE NOW / SOLAR CHARGE

That would make it easier to use different brands without putting brand-specific logic into the main EMS.

3. 15-minute pricing as a first-class input
   In NL we are moving towards quarter-hour prices, so complete 15-minute price data for today/tomorrow, freshness and fallback behaviour are important. Especially around publication time, it would be nice if the EMS can distinguish between “tomorrow not published yet” and “price source failed”.
4. Coordination between EV and battery
   One thing I’m particularly interested in is preventing situations where the EV starts charging in a cheap period while the home battery simultaneously discharges into the EV. Ideally the EMS can temporarily hold the battery if that makes economic sense.
5. Dashboard / state output
   Having compact status output that can be used in Homey Dashboards would be very useful:

• current strategy
• next action
• reason
• data freshness / fallback only when something is wrong

I’m still in the validation phase and not yet allowing automatic battery/EV control, so I’m also interested in how others test HomeFlux before giving it real control.

Are there more people here using HomeFlux with a similar setup? And are any of the points above already planned?

Happy to share findings from my setup as I go along.

Regards Jurgen

[Davy_Bert]

Thanks Jurgen, this is exactly the kind of feedback I was hoping to get from people who are actually validating HomeFlux in a real setup.

Your general view matches the architecture I’m aiming for: HomeFlux should decide what should happen and why, while the actual Homey device integrations remain responsible for vendor-specific commands, safety behaviour and fallbacks.

A few of the things you mention are already partly present today:

• HomeFlux already works hardware-independently through Homey Flow inputs/outputs rather than talking directly to a specific battery or charger brand.
• Battery control can already be split into charge/discharge mode and power outputs, so integrations can translate that into the commands required by SMA, Huawei, Marstek, etc.
• EV control is also separated per charger, with modes such as normal/smart behaviour, PV charging and session overrides.
• Peak Guard always remains the hard upper limit, regardless of what the planning wants to do.
• There is already a Live status page and a Planning simulation page, which are useful while validating the EMS before allowing it to control anything.
• HomeFlux can currently be used purely as an observer/planner. You don’t have to give it actual control immediately.

I particularly agree with your first and fifth points. At the moment HomeFlux can show quite a lot of state, but the next useful step would be to expose the decision context more clearly:

• Current strategy
• Current requested action
• Why that action was chosen
• Next expected action
• Data freshness / fallback state only when relevant

A compact controller/status widget for Homey Dashboards would fit this very well. That is a good suggestion and I’ll add it to the roadmap.

Your point about EV/battery coordination is also important. HomeFlux already coordinates several loads through the same planning and Peak Guard logic, but I agree that this should become more explicit. A state such as:

EV charging cheaply → hold home battery

is much clearer than having that emerge indirectly from several separate rules.

Quarter-hour pricing is another area I’m looking at closely. HomeFlux already supports dynamic pricing, but I agree that 15-minute prices should eventually be treated as proper planning data rather than merely a shorter tariff interval. In particular, the distinction between:

• tomorrow’s prices are not published yet
• price data is stale
• price source actually failed

is important for safe planning.

For validation, what you are doing is also what I would recommend: first let HomeFlux observe and plan, compare the Live status and Planning simulation with what you would have done manually, and only then enable individual outputs one by one. Battery and EV control do not have to be enabled at the same time.

Your SMA/BYD + Zappi + Nibe setup is also a very interesting test case because it is quite different from the systems I’m currently testing myself. So please do share what you find — especially cases where the planned action is correct but the reason is not obvious.

The main goal is exactly what you described: avoiding a huge collection of Advanced Flows and having one place that understands the complete energy situation.

HomeFlux is also already growing beyond battery/EV planning. The same controller can coordinate PV limiting, up to four EV chargers, multiple HVAC devices, a boiler, battery reserves, tariff-based planning and savings/cost tracking. The idea is that these all compete for the same available energy instead of each device making an isolated decision.

A small note for context: HomeFlux is still very new in the Homey App Store and I originally published it mainly as a test, with some uncertainty about how much interest there would be. The initial motivation was very much my own use case: managing energy intelligently with a three-period electricity tariff. Since then, the scope has grown considerably.

At the moment I’m personally testing HomeFlux on three different setups. One of those uses a Huawei LUNA2000, which is also a good example of why HomeFlux keeps the control layer hardware-independent: that setup does not allow a single control mode where positive and negative power setpoints can simply be used interchangeably, so separate charge/discharge control is required.

There are still only very few installs at this stage, so feedback from real-world setups is especially useful.

For EV charging, Peak Guard always remains the hard upper limit. There is, however, now an optional setting that allows the home battery to support EV charging up to the configured battery limit when desired. One example is Emergency Charge: this can be triggered through a Flow card for a single charging session. During that session HomeFlux can allow battery support if enabled, while still respecting Peak Guard. Once the EV disconnects and the session ends, HomeFlux automatically returns to the user’s normal EV mode and settings.

[Davy_Bert]

Thanks for taking the time to test the app and share feedback.

HomeFlux actually started from a fairly practical problem in my own setup. I had accumulated a lot of Advanced Flows that were constantly checking things like Peak Guard, whether the battery should charge, whether grid power should be used instead of charging/discharging the battery, and when to switch into a battery-saving strategy.

That worked, but over time the amount of logic running in separate flows became quite large. Even after upgrading my Homey Pro 2023 to 4 GB RAM, I occasionally noticed slowdowns when a lot of Zigbee devices were reporting at the same time. Because Homey does not really give you a clear view of how much CPU individual flows are using, it became difficult to know where the bottleneck was.

So I decided to move all that energy logic into one app and handle it in a more coordinated and efficient way instead of having many separate flows continuously doing the same checks.

That is essentially how HomeFlux was born.

[Jurgen_Schoorlemmer]

Thanks Davy, really appreciate the detailed response. Good to hear that several of these ideas fit the direction you already have in mind.

A bit of background from my side: I moved from Home Assistant to a Homey Pro (2026) a few months ago. Since then I’ve been rebuilding the setup step by step, with quite a strong focus on keeping the energy management understandable rather than ending up with an ever-growing collection of separate flows.

I’m doing much of that exploration together with ChatGPT: breaking the problem into small steps, first inspecting and validating what is actually happening, then testing the logic in observer/planner mode, and only afterwards considering real control. That has also made me quite focused on things like explicit states, reasons, fallbacks and clear separation between EMS decisions and device-specific control.

Your response makes me quite positive about continuing with HomeFlux as the basis for that. Especially if HomeFlux can become the central place that decides what should happen, while Homey/device integrations remain responsible for the actual execution and safety behaviour.

I’ll keep testing it against my real setup and am happy to report back where the planned behaviour, status information or reasoning could be made clearer.

I’ve attached a screenshot of my current Homey dashboard for some context. It’s still very much work in progress, but it probably shows why I’m interested in having a compact, understandable EMS state on the dashboard as well.

[Davy_Bert]

Hello,
Glad to see HomeFLux dash as well.
At this point i have pushed a version with a widget that can display the most important data you want. (and so do i )
And, allso a savings overview if you want. But this is new and needs a full day to be correct. You can an input card every 5 minutes to push the current daily imported energy (just in case the measurement by the app is not in sync witch the metered dongle. This is not mandatory but helps to calibrate.
I have home assistant linked to homey for… for example a custom dreame air FP10 that cannot be controlled by homey.
I ever started with hass, but after 8h of searching and editing yaml files… i could turn on a light
So now i use homey and i do like very much and i end up again late in the night.. building an app. hehe
But i think, i do already cover the most important functions. For now, my batterij charges when needed.
Last weekend, thunder ended my solar inverter… so i bumped pv value to 100 and minimum soc to 100, now my batterij charges in low tariff and stays in stand-by and discharges when in high tariff.

I do hope, HomeFLux can simplify your time working in flows. but is have an override input card..
you could use this to switch modes when you flow decides that… homeflux will regain control at the next tariff change… (allso an option that can be enabled)

Now i am going to sleep.. and let the energy flow
En nu ik het zie… je homey staat in het nederlands

[Davy_Bert]

Just one little remark, when homeflux does not have control, decisions will not occur because you real flows are allway sending to achieve 0 consumption.
you could try to edit you flow that actually sends the power to the batteries by adding a virtual mode let’s say HomeFlux On and when homeflux is off send to the batteries using you flows/
when homeflux is on create a flow that sends the values of homeflux to the batteries.
That way.. you can switch by the flip of a switch.

but again, that is just how i did it… i do not want to delete 1.5 year of advanced flow adjustments..
For now, and only now is have deleted the flow cards ev hvac without a number. you must use 1-4 (if you used them allready (and EV one has the most priority)

Davy

[Jurgen_Schoorlemmer]

Hi Davy,

Thanks for the additional explanation. It makes clear that HomeFlux is developing into quite a bit more than just an energy-flow dashboard, especially with the EMS modes, override options, savings calculation and EV/HVAC priorities.

At the moment I’m using HomeFlux v0.8.62. I don’t yet see the new HomeFlux Flow cards there, so I assume these are part of a test or upcoming version.

In parallel I’m building OpenHEMS for my own Homey setup. It combines 15-minute dynamic prices, solar forecast, battery state, EV state and user intent to determine when charging or discharging is most sensible. The project is still very much focused on my own setup; I’m not currently planning to publish it as an app. I may however document the architecture and approach in more detail at some point.

Your new HomeFlux functionality is interesting in that context, especially the override mechanism, savings overview and external inputs. I’m curious to understand a bit better how you intend those to work in practice.

A few questions for when you have time:

• In which version are the new EMS / Savings / override Flow cards available?
• What exactly does the override card accept, and when does HomeFlux resume its own control?
• Can tariff data be supplied externally, for example as 15-minute prices for today and tomorrow?
• Are the EV/HVAC priorities mainly intended as indicators, or also for active control?
• What baseline do you currently use for the savings calculation?

HomeFlux is already one of the central widgets on my dashboard, so I’m definitely interested in how it develops further.

Best regards, Jurgen

[Davy_Bert]

Hello,

HomeFlux is the energy widget, you have to look at HomeFlux EMS (test version)
To override the mode, use then => homeflux ems (app list), select

You can install the ems controller as a device too.

Best Regard.

Davy

[Jurgen_Schoorlemmer]

Found it, yes that’s a completely different beast. Very impressive! I’m going to figure out how to apply this to my current architecture, but it seems to do a lot, even more than what I was working on.

[Jurgen_Schoorlemmer]

Hi Davy,

A quick first impression after spending quite a few hours testing HomeFlux EMS v0.4.17 with my SMA/BYD + Zappi + Nibe setup.

So far, I’m genuinely impressed with the direction of the app. The “observe first, enable outputs later” approach works very well for testing an EMS like this. I currently keep all EMS outputs disabled and use Live Status and Planning Simulation to understand the decisions first.

A few things that already work particularly well for me:

• Live Status is very useful. I now feed HomeFlux actual grid power, PV power, battery SoC, remaining PV forecast for today and PV forecast for tomorrow through Flow cards. All five inputs are accepted and shown as OK.
• The request-based input cards are a nice hardware-independent solution. They make it possible to use my existing SMA/Homey data without HomeFlux needing direct support for every device.
• Planning Simulation is probably the feature I like most at this stage. Being able to change SoC, target SoC, PV and time without publishing any real commands makes it much easier to validate the planning logic safely.
• Native 15-minute dynamic pricing is very relevant for the Dutch market. I also like that HomeFlux shows not only the selected action, but the reasoning around tariff, planning phase, forecast and target.
• The separation between planning and physical output is valuable. In my setup I want HomeFlux to become the generic planner, while a small OpenHEMS adapter layer can eventually handle device-specific safety, translation and fallback for SMA, Zappi and Nibe.
• Peak Guard and the possibility to activate battery/EV control separately also fit that phased approach very well.

The interface contains a lot of information, but after using it for a while the logic becomes quite transparent. Especially the explanatory text in Planning and Planning Simulation is helpful when checking why a certain decision was made and the extensive help documentation.

I am now building a small regression set with different SoC, PV and price scenarios before enabling any real output. I’ll share interesting results as we go.

Thanks for making such an open test version available — this is a very interesting project to evaluate on a somewhat more complex home energy setup.

Regards Jurgen

[Jurgen_Schoorlemmer]

Hi Davy,

One technical question that came up during our first Planning Simulation tests.

I have one 10 kWh battery configured with:

• Number of batteries: 1
• Total capacity: 10 kWh
• Minimum SoC: 10%
• Maximum SoC: 100%
• Max total charge: 0 W
• Max total discharge: 0 W
• Max charge per battery: 2300 W
• Max discharge per battery: 2400 W
• “Different power limits per battery”: disabled
• Battery Balance: disabled
• EMS output: disabled

Could you clarify the exact meaning of 0 W for Max total charge and Max total discharge?

Does 0 W mean:

1. no group/total limit, therefore use the per-battery limits, or
2. literally no charging/discharging allowed?

I’m asking because of the following simulation:

• Battery SoC: 20%
• Target SoC: 80%
• PV forecast: 0 kWh
• PV live: 5 W, so Day Planning is active
• Cheap charging window available: 12:15–15:15
• Planning goal: 17:00

HomeFlux correctly detects the cheap window and shows a target of 80%, but the result is still:

Battery saving → Rest → 0 W
“No grid charging needed in the remaining cheap charging windows.”

With a 10 kWh battery, going from 20% to 80% represents roughly 6 kWh, so I expected some grid charging to be planned in that window.

Is this caused by the Max total charge = 0 W setting, or is another planner condition intentionally deciding that no grid charging is required?

Everything is still running in simulation only; no EMS outputs are enabled.

[Davy_Bert]

@Jurgen_Schoorlemmer

• Max total charge: 0 W
• Max total discharge: 0 W

• Max total charge: 0 W

• Max total discharge: **0 W

  this must be set to the total amount of charge and discharge you want.
  If you have 2 batteries, one onely capable of discharging 800w and one that can discharge 5000w you can limit the total power 5000w if you want. that way HomeFlux knows the maximum of that battery. setting it to 0 means HomeFlux cannot send power.**

[Davy_Bert]

Actually the most important settings for planning are:

This is the amount of forecast pv when homeflux decides to pauze the battery (but keep peak guard active). HomeFlux saves too early? Raise this value, ther is no setting for all.
When the amount of PV was more than predicted. HomeFlux will revert a bad day in a good one and will start consuming. (Default settingis soc 95% and more than 60 minutes)
This is a fallback trigger to convert the battery save (we want to use pv power )

This setting is actually the power needed at least in the battery at the morning and at the evening.

These moment homeflux will work towards to charge or wait and capture PV.
Night plan calculates a soc level depending on power needed and pv forecast.
but at midnight, the new rest pv of today arrives and homeflux will adjust the soc till the morning.
For night plan the main goal is to aim for a soc as low as possible to consume as much as possible power. (and wil go in battery save till higher tarif)
During the day: homeflux will aim for ‘doelmoment dagplanning’ and aims for a full battery and wants to use all pv power, when no or very little sun is left, your battery should be full at this hour using low cost blocks. so no charge will be planned at this point when enough pv is left.

But.. in winter months pv is sometimes far off from expectations.

In these months, the minimum battery soc can be set to a minimum soc so when the need of power is more important to peak shave, that minimum soc is respected and will allway be the mimimum chosen. This is an override to prevent that the battery remains empty when pv forecast was perfect but the weather was blocking the sun. So 50% wil be ensured before 17pm

You have the same setting to choose that value for summer months (off by default)
And you can set to aim for those socs at night too. Maybe needed by someone…

But, if you want to control the mode and use HomeFlux only to coordinate the battery to start with.

unselect “batterty override resume on tariff change”

That way you are in control of choosing the when to charge while HomeFlux will keep you Peak Guard settings
Automatic: HomeFlux decides based on tariffs, PV forecast and planning.
Self consumption: Minimize grid exchange using the battery.
Battery save: Preserve battery energy for later.
Avoid grid import: Use the battery to prevent grid import where possible.
Forced charging: Charge the battery manually at the configured power.
Standby: Stop normal battery charging and discharging. ( not very usable but needed when you acutally need to pause)
Peak guard is active for all modes! Even in stanby

But when you play with the above hours, pv and power needed settings. HomeFlux wil take care.

About your EV. if you only connect your ev to see if its connected you could allow to set the current calculated by homeflux but only when using one mode, let me say smart mode.
The power send to the ev does not change a lot.. when HomeFlux sends 32A and nothing changes, the goal wil remain the same. But do it step by step. Keep you current apps to control the ev as they preserve.. preheat.. when needed and so on and let HomeFlux assist in current changes when selecting smart when no specific time is needed.