Hello,
I am thinking about adding the following ev option:
In the ev tab you can select “only use ev consumption for battery management”
That would allow net import to the maximum power set for the ev in the tariff section. (New maximum power set when selecting “charge ev by default”
For example on low tariff you set 4500w (peak guard at 5000w) when you ev sends 3600w homeflux will allow 3600w net import so it would use the amount of the ev from te net.
Optionally: pause ev when high tariff occurs.
However, this one is tricky because an expensive night would not charge ev.
I just need a suitable solution for ev before going live.
When homeflux receives an ev disconnect, the input power is forced to 0 in case the ev power update was not send.
Just thinking…
Hi Davy,
I like the direction, but I would personally try to keep the user interaction as simple as possible.
For me, the most important EV inputs are not really power budgets, but two very simple questions:
When do I need the car?
How full does it need to be?
The EMS should then do the technical optimisation underneath.
On the user dashboard I would therefore prefer a few clear user choices instead of asking the user to enter exact charging times or power limits every time. For example:
- Fast / ASAP – charge as quickly as possible;
- Smart – no fixed deadline, optimise mainly for PV and attractive prices;
- Tomorrow morning – for example ready by 06:30;
- Tomorrow afternoon – ready by a predefined afternoon time;
- Tomorrow evening – ready by a predefined evening time.
You could still offer a custom time as an advanced option, but I would not make that the normal daily interaction.
For SoC I would use the same principle. In my case I would use 80% as the normal default target and have a simple Long trip option that changes the target to 100%. After the long trip, it should automatically return to the normal 80% target.
That gives the end user a very simple interface:
When do I need the car?
Normal trip or long trip?
From there HomeFlux can calculate when charging actually needs to start, taking into account current SoC, required energy, PV forecast, electricity prices, battery state and the available charging window.
This also solves the concern about expensive tariff periods in a more natural way. A high tariff should not simply mean “EV off”. If the car is not needed soon, HomeFlux can wait for PV or cheaper periods. But if the user has selected “Tomorrow morning” and the car needs more energy, the required SoC by that deadline must have priority.
I would therefore also avoid coupling battery management too directly to EV consumption. I see them as separate flexible assets:
EV: required SoC + when the car is needed + charging priority
Battery: reserve SoC + economic optimisation
HomeFlux: coordinates both using PV, tariff and household/grid constraints
So the battery does not automatically discharge just because the EV is charging. Sometimes that may be useful, but sometimes keeping that stored energy for later is economically better.
I think this approach also keeps the dashboard understandable for non-technical users. The user expresses the desired outcome, while HomeFlux decides the optimal technical strategy.
I do agree with your disconnect safeguard: setting EV power to 0 when the EV disconnects is important. I would additionally consider a timeout on the EV power measurement, so an old value cannot remain active if an update is missed. Just my 2ct’s.
I’ve added a few screenshots of my current Homey dashboard as context.
The EV controls show the type of interaction I mean: Smart, ASAP, Morning, Afternoon, Evening, plus a separate Long trip switch. The normal charging target is 80%; Long trip allows charging to 100%.
My preference is to keep this kind of user-facing logic simple and let the EMS translate it into the actual charging schedule based on PV, prices, battery state and the required departure time.
The screenshots also show the current HomeFlux observer/status view and the wider Homey dashboard setup. I’m still testing the integration, so the layout and some status data are not final yet.
You can already build most of that behaviour around HomeFlux today.
HomeFlux already lets you define during which tariffs the EV is allowed to charge from the grid, and separately when PV surplus may be used for EV charging. So the basic charging strategy can already remain tariff-based without requiring the user to enter detailed schedules every day.
For example, you could configure the EV to:
- charge from the grid during low or normal off-peak tariffs;
- avoid expensive tariff periods whenever possible;
- use available PV surplus independently of the grid-charging tariff rules.
Your Homey Flows can then handle the user-facing part such as Smart, ASAP, Morning, Afternoon or Evening.
For a “Tomorrow morning” profile, for example, HomeFlux could optimise normally for most of the available time. Then, during the final few hours before departure, your Flow could simply override the normal optimisation and allow charging regardless of tariff if the car still needs energy.
So conceptually:
Normal situation
→ HomeFlux follows the configured tariff and PV rules.
Approaching the departure deadline
→ the Flow can override those rules and make sure the car gets charged.
That keeps the daily interaction very simple while still allowing HomeFlux to handle the energy optimisation underneath.
The main thing HomeFlux still needs for this to work properly is the option to subtract the EV’s measured charging power from the grid measurement used by the EMS.
Without that, HomeFlux can see the EV charging as additional household consumption and may react by discharging the home battery to compensate for it. In many situations that is exactly what you do not want.
If HomeFlux knows that, for example, 7 kW of the current grid import belongs to the EV, it can treat that EV consumption separately from the normal household load. The battery can then continue following its own reserve and economic strategy instead of automatically trying to compensate for the car.
That is the separation I think is important:
EV: tariff/PV charging rules + user deadline
Battery: reserve and economic optimisation
HomeFlux: coordinates both, while knowing how much of the grid consumption belongs to the EV
Once the EV wattage can be excluded from the grid value used for battery regulation, most of the rest can already be built quite cleanly with the existing tariff settings and Homey Flows.
Thanks Davy, that makes sense and is actually very close to the architecture I had in mind.
I agree that HomeFlux should keep doing the normal tariff/PV optimisation, while the Homey Flow only provides the user intent and overrides the normal optimisation when a deadline can no longer safely be met.
One additional rule I use is a permanent mobility floor: regardless of the selected mode, the car should always be at least 30% by 07:00. So even in Smart mode, HomeFlux may wait for PV or cheaper tariffs, but the Flow should start charging once the last safe start time for reaching 30% is reached.
For the other modes the normal target would be 80%, or 100% with Long trip selected.
I also think your proposal to subtract the measured EV charging power from the grid value used for battery regulation is the cleaner solution. That would avoid having to force the battery into HOLD every time the EV charges and keeps EV and battery as two genuinely separate flexible assets.
So from my side the intended structure would be:
HomeFlux: tariff/PV optimisation
Homey Flow: Smart / ASAP / Morning / Afternoon / Evening + 30% morning guard + 80/100% target
Battery regulation: grid load excluding measured EV consumption
That looks like a good basis to build on.
Just a quick question, can your ev technically send soc to homeflux? (i think so)
Because not lot of chargers reports soc, onlly the direct integration with the car makes that possible.
Yes, technically I can send SoC to HomeFlux. I get it through the Renault integration rather than from the charger itself.
The only caveat is that the Renault app/integration is not fully reliable in practice, so I would not want the whole charging strategy to depend on that value being available all the time.
My preference would therefore be:
- use the live Renault SoC when it is available and fresh;
- if it is unavailable or stale, allow a manually entered current/start SoC as fallback;
- and still keep the hard mobility rule that the car must be at least 30% by 07:00.
So yes, HomeFlux can receive SoC, but I think it is important that the logic also works safely when the car API temporarily fails.
EV control in HomeFlux EMS 0.6.1 has been significantly improved to support more charger types and more real-world situations.
Because EV chargers behave very differently, HomeFlux now supports multiple control methods:
- Current / Hybrid: HomeFlux can reduce charging current to stay below Peak Guard.
- Mode-only: HomeFlux falls back from Standard → Smart → Stop.
- Estimated current values for Smart and Standard help HomeFlux predict the expected load before switching modes.
Peak Guard always remains the absolute limit.
Each EV now has its own tariff settings, PV charging rules, hysteresis, grid supplementation and deadline planning.
New EV Flow cards
You can now dynamically set charging targets from Flow:
- Reach X% SoC by HH:mm
- Require X kWh by HH:mm
Both support:
Target guaranteed: Yes / No
With No, HomeFlux prefers PV and selected tariffs and warns if the target becomes impossible.
With Yes, HomeFlux may use additional tariff periods if required to protect the deadline. Peak Guard still always has priority.
SoC targets set by Flow can persist until the dedicated Clear EV SoC target override card is used.
The kWh target is useful for chargers or cars that do not provide reliable SoC data.
SoC freshness
EV SoC can now have a configurable validity of 1–60 minutes.
If the value becomes stale, HomeFlux stops relying on it and falls back to normal PV/tariff-based charging. In that situation, using the “X kWh required by HH:mm” Flow card is recommended.
EV grid import
HomeFlux can deliberately allow EV consumption to remain as grid import instead of making the home battery compensate it.
However, the charger must still remain within Peak Guard.
If the preferred charging level is too high:
- Current/Hybrid can reduce the current.
- Mode-only can fall back from Standard to Smart.
- If even Smart does not fit, charging stops.
P1 remains the source of truth
HomeFlux never blindly assumes that a charger is consuming the commanded power.
The EV reports what it is doing → P1 confirms the real load → HomeFlux controls the system based on that reality.
This prevents false EV data from causing incorrect battery discharge or unwanted grid export.
Planning Simulation
EV charging is now also included in Planning Simulation, so you can test:
- EV load;
- SoC;
- charging current;
- Peak Guard;
- P1 impact;
- battery behaviour;
- allowed EV grid import.
In short, 0.6.1 gives HomeFlux much more control over when, how fast and under which conditions an EV may charge, while keeping Peak Guard and real P1 measurements as the final safety layer.
The available options should now be flexible enough to plan EV charging for most charger types and integration limitations.
I chose not to follow that approach, because once the car SoC becomes stale or unavailable, HomeFlux can no longer reliably plan toward a target such as 30% by 07:00.
For that reason, the tariffs configured in the EV section should always remain the primary charging windows and be used as much as possible. HomeFlux should continue charging according to those tariff rules even when SoC data is missing, instead of relying on an SoC-based deadline it can no longer verify.
In that situation, the recommended alternative is to use the “X kWh required by HH:mm” Flow card, because that target does not depend on vehicle SoC and can still be planned reliably.
Added Automatic Finetuning to help HomeFlux EMS adapt selected control parameters to the actual behaviour of your installation instead of relying only on generic defaults.
Finetuning reuses the P1, PV, battery and EV data HomeFlux already receives, so no additional polling loop is introduced. It looks for meaningful deviations in parameters such as control deadbands, reaction intervals, EV response behaviour and PV regulation. More importantly, it can learn from compact daily summaries to improve the settings that influence battery planning.
A major focus is the low-PV threshold and expected energy requirement. HomeFlux compares the full-day PV forecast with the SoC the battery actually reached and learns how much non-EV household energy is typically required. The aim is to gradually improve the planning throughout the seasons: leave enough battery capacity available for useful solar production, try to reach roughly 90–100% during the solar day, and avoid keeping unnecessary energy in the battery overnight or charging too much from the grid.
Recommendations are only shown when HomeFlux detects a meaningful reason to change something. You can:
- Apply this time to accept the recommendation once;
- allow HomeFlux to manage that parameter automatically;
- choose Do not check again when a recommendation is not relevant for your installation.
Parameters marked Do not check again are moved to a separate list at the bottom and can be enabled again later.
Hard limits and explicit user choices such as Peak Guard, minimum SoC, maximum charge/discharge power, tariffs and priorities are never automatically changed. Finetuning is intended to improve how HomeFlux reaches your goals, not to redefine those goals.
Hello,
I am a new user of the Homeflux app, and I think it’s a fantastic application.
In my case, I have only 600 Wc photovoltaic setup. I optimize my electricity self-consumption by diverting the surplus—beyond the home's consumption to a domestic hot water tank, and I measure the energy sent to that tank.
Would it be possible to add this option alongside the existing ones for home batteries and electric vehicles?
In the meantime (if possible), I am using your home battery solution in an unconventional way :)
Thank you in advance.
Sincerely,
C. BARRES
Hello,
This is already implemented.
Just set battery to zero and set boiler to activate when there is for example 500w room to heat.
It is not tested yet, but in homeflux nothing is mandatory. Well maybe you need pv 
.
I’m sorry, but I wasn’t talking about the Homeflux EMS app, but rather the slightly simpler Homeflux app.
.
I made homeflux to have an energy flow widget on the dashboard and Homeflux Ems because i needed an ems that can handle fixed energy hours. I would like to not want mix functionalities between the 2 apps.
Feel free to try Homeflux Ems.
Maybe i could add some dumpload devices later on.
Hi,
I’m currently setting up and testing battery control from HomeFlux towards my own external battery controller.
My setup consists of:
- SMA Sunny Tripower Smart Energy 10.0
- BYD Battery-Box, 10 kWh
- SMA Sunny Home Manager 2.0
- Homey Pro
- Battery control via Modbus
The integration is intentionally kept as thin as possible: HomeFlux determines the desired battery power, while my Homey-side adapter only translates that command into the Modbus control required by the SMA inverter.
The command chain itself now appears to be working correctly. I can see the battery commands generated by HomeFlux arriving at my controller, and the battery responds accordingly. For example, I have seen HomeFlux generate commands such as -244 W and -500 W, which were passed through and resulted in corresponding battery behaviour.
What I’m struggling with now is mainly the intended test and acceptance procedure within HomeFlux.
In the configurator, I can run “Start charge test” using the standard 100 W test power. I can perform this test as long as “EMS output active” is disabled. After that, I can mark the test as successful, which then allows me to enable “EMS output active.”
However, once “EMS output active” is enabled, I can no longer run the charge test.
So I can validate the charging direction, but I do not see a way in the configurator to deliberately generate a positive battery command / discharge command in order to perform a complete bidirectional end-to-end test.
My question is therefore: what is the intended official procedure for this?
Is the idea that I should:
- Run the charge test;
- Mark it as successful;
- Enable EMS output;
- Then wait until HomeFlux itself generates a positive battery command during normal operation, and use that to validate the discharge direction?
Or is there another supported way to temporarily generate a positive battery command for a full acceptance test?
I would prefer not to build any additional custom test logic if HomeFlux already has an intended workflow for this.
Thanks in advance for your clarification.
Hello,
The test function is mainly intended as a commissioning and safety check.
Its purpose is to verify that the HomeFlux battery output reaches your controller correctly and that the configured direction/sign is correct before allowing HomeFlux to take control of the battery.
So the intended workflow is:
- Keep EMS output active disabled.
- Run the charge test.
- Verify that the battery actually reacts in the expected direction.
- Mark the test as successful.
- Enable EMS output active.
Once that has been completed successfully, you normally do not need to use the test function again unless you change the battery integration, inverter configuration or command mapping.
At the moment there is no separate manual discharge test in the configurator. The discharge direction is therefore normally verified when HomeFlux generates a discharge command during normal operation.
Since your adapter is intentionally very thin and simply translates the HomeFlux power value into the corresponding SMA Modbus command, seeing values such as -244 W / -500 W correctly arrive and produce the expected battery behaviour already confirms that the command chain itself is working.
So yes: after the initial acceptance test, the test function can essentially be left alone. HomeFlux should then be allowed to control the battery normally.
A separate bidirectional commissioning test could certainly be added in the future, but it is not currently required for normal operation.
Hello Jurgen,
I have looked into you devices specs online.
You already have a descent sma ems. But this lacks peak protection when using tariff proces.
For your specific test case, but probably like many others the approach below might actually be useful.
My own test environments use Marstek and Luna battery systems. Those are perfectly suitable for testing direct battery control, planning and overrides, but they are not really the right systems to validate cooperation between HomeFlux EMS and a capable external EMS that already performs its own fast self-consumption regulation.
Your setup is therefore particularly useful for testing this type of hybrid control.
During normal self-consumption, it could make sense to let the external EMS handle the fast, real-time battery regulation, while HomeFlux EMS remains responsible for the higher-level energy strategy.
External EMS
Controls the battery locally in real time
Handles zero-import / zero-export regulation
Reacts quickly to rapid PV and load fluctuations
Is especially useful during changing cloud cover
Continuously determines the actual battery charge or discharge power during normal self-consumption
HomeFlux EMS
Handles planning, optimisation and energy strategy
Decides when normal self-consumption may be handled by the external EMS
Takes direct control when a strategic action is required
Manages scheduled charging, battery saving, EV charging, Peak Guard, minimum SoC targets, forced charging/discharging and other planned actions
When HomeFlux EMS does not require direct battery control, it could send an additional command such as:
Set external EMS to self-consumption mode
At that point, HomeFlux EMS stops sending continuous battery power setpoints and the external EMS takes over the real-time battery regulation.
When HomeFlux EMS needs to perform a planned action, it switches the external EMS out of self-consumption mode and takes direct control again.
To keep HomeFlux EMS informed while the external EMS is controlling the battery, an additional Homey Flow input card could be used to report the actual battery power back to HomeFlux EMS.
For example:
Report external EMS battery power
This input would contain the actual charge or discharge power commanded by the external EMS. HomeFlux EMS could then still estimate how much energy was charged or discharged, even though it did not generate those individual setpoints itself.
That would allow the cost, savings and energy calculations to remain approximately correct while the external EMS is in control.
In short:
External EMS = fast local self-consumption control
HomeFlux EMS = planning, optimisation and supervisory control
The important requirement is that only one system actively controls the battery at a time.
Would this feature suit your needs and are you willing to test that Function?
Hi Davy,
Thanks for taking the time to look into my specific setup. Yes, I think the approach you describe could suit my installation very well, and I would definitely be interested in testing it.
For some additional context, my battery setup consists of an SMA Sunny Tripower Smart Energy 10 hybrid inverter, a BYD battery of approximately 10 kWh and a Sunny Home Manager 2.0 (SHM).
The SHM is an important part of the setup. It measures the household energy flows and, together with the SMA inverter, already performs the native energy management. During normal self-consumption it is very good at continuously balancing PV production, household consumption, grid exchange and battery power. It reacts much faster to changing household load and PV production than I would want to reproduce through Homey.
That is why I like your proposed hybrid approach.
When no strategic intervention is required, I would prefer to let SMA/SHM remain responsible for this fast local self-consumption regulation. HomeFlux could then act as the higher-level supervisory and economic controller and only take direct control of the battery when there is a reason to do so.
I would, however, deliberately not make SMA/SHM the overall economic strategy owner.
I already use dynamic Zonneplan import prices in the SHM. SMA allows me to configure dynamic import prices independently of the energy supplier. The limitation is on the other side: I cannot configure my dynamic export/feed-in prices in the same way. For export, SMA currently only lets me enter a fixed value, for which I use €0.05/kWh.
There are also combinations of functions that SMA cannot currently optimise together, such as dynamic tariffs and peak protection and taken into accout the charging of the EV. And, more generally, I would prefer not to make my energy strategy dependent on possible future SMA premium/subscription functions or designated energy suppliers.
So for my installation I see the division roughly as:
- SMA/SHM: fast local self-consumption regulation and real-time balancing.
- HomeFlux: higher-level planning and economic optimisation, including dynamic import and export strategy, Peak Guard, battery saving, minimum SoC/targets, planned or forced charging/discharging and coordination with EV charging.
I already have a technical route available to let HomeFlux temporarily take control without making HomeFlux SMA-specific.
I use a thin Homey/OpenHEMS adapter between HomeFlux and the SMA inverter. The adapter communicates with the inverter over Modbus. I have already successfully tested the relevant SMA external-control functions: the adapter can switch the inverter to external control (802), after which a requested battery power can be translated into the SMA active-power setpoint. I have tested HOLD (0 W), controlled charging and controlled discharging. Sending 803 releases external control again and returns the battery to the native SMA/SHM regulation.
So in practice I imagine the hybrid ownership model something like:
HomeFlux requires a strategic battery action
→ HomeFlux requests direct control
→ my adapter performs the SMA/Modbus 802 takeover
→ HomeFlux power request is translated into the SMA setpoint
HomeFlux no longer requires a strategic intervention
→ HomeFlux releases control
→ my adapter sends 803
→ SMA/SHM resumes native self-consumption regulation
I like this because HomeFlux can remain vendor-independent. It only needs to express whether it requires direct battery control and what the strategic battery request is. My thin adapter can remain responsible for translating that into the SMA-specific Modbus commands.
I also like your suggestion to feed the battery power back to HomeFlux while the external EMS is in control. In my case I would prefer to report the actual measured battery power rather than trying to reproduce the internal SMA commanded setpoint. That keeps the distinction between command and actual behaviour clear, while still allowing HomeFlux to estimate the energy charged/discharged and keep its cost and savings calculations meaningful.
For me, one important architectural requirement would be that only one controller actively owns the battery at any moment. I would therefore prefer an explicit handover between HomeFlux and SMA/SHM. If HomeFlux/Homey control disappears unexpectedly, I would also prefer native SMA/SHM control to be the safe fallback rather than leaving the inverter indefinitely under external control.
I think my installation could therefore be an interesting test case for this function: it combines a capable local EMS with a battery/inverter that can also be taken over externally when the higher-level strategy requires it.
One other piece of feedback: I recently discovered that HomeFlux already has two dashboard widgets that I had completely missed earlier — the cost/savings widget and the extensive status widget.
I have now added both to my Homey Energy dashboard and I really like them. The status widget in particular gives me a very useful overview of what HomeFlux is currently deciding and why, including tariff information, battery target, next charging window, Peak Guard, PV planning and EV status. The cost/savings widget is also useful because it shows me the result of the optimisation rather than only what the EMS is doing at that moment.
That is definitely meant as a compliment. It is also perhaps a small usability observation: I had actually started looking at building some of this visibility myself because I simply had not realised these widgets were already available. Now that I have found them, I can keep my own OpenHEMS dashboard focused much more on household-specific information instead of duplicating functionality that HomeFlux already provides. So I think the functionality is excellent; perhaps these widgets just deserve a little more visibility in the documentation or onboarding.
I am leaving for about 1.5 weeks of holiday today. During that period I will only have limited possibilities for live testing, although I can probably do some remote/read-only checks. I am always very interested in testing new HomeFlux functionality, so once I am back I would be very happy to do proper controlled testing of this hybrid function.
I also have one separate EV requirement/question about guaranteeing a minimum vehicle SoC by a fixed time in the morning, regardless of the normal optimisation mode. I will send that separately, because I think that is a different design question and I don’t want to mix it into this battery-control discussion.
So yes — if you implement this hybrid function, I would very much like to test it.
Thanks again for looking into this. I think this could be a very good fit for my setup.
Best regards,
Jurgen
Hi Davy,
I have one separate question about EV planning in HomeFlux.
Besides the normal charging modes and deadlines, I have one basic availability requirement for my car:
Every morning at 06:30 I want the EV to have at least 30% SoC, regardless of the selected charging strategy.
The idea is not to normally charge the car to 30% at 06:30. It is really a minimum safety/availability floor: I want to know that I can always take the car unexpectedly in the morning and have a reasonable amount of range available.
Above that 30%, I would like HomeFlux to optimise normally.
For example, if I select an 80% target for 07:00, that target obviously takes precedence and the 30% requirement has no additional effect. But if I am using Smart mode and prices are unattractive, I would still want HomeFlux to make sure the car does not remain below 30% at 06:30 simply because waiting would be economically optimal.
In other words, I see two different concepts:
- the normal charging target/deadline, such as 80% by 07:00, 12:00 or 18:00;
- a permanent minimum availability reserve, in my case 30% by 06:30 every morning.
Once that minimum has been secured, HomeFlux can continue with the normal selected strategy and optimise the remaining charging as usual.
I deliberately haven’t built an extra OpenHEMS/Homey guard around this yet, because I first wanted to ask how you see this fitting into HomeFlux. It feels like something that belongs in the planner rather than being implemented as an external override, especially because HomeFlux already knows the current SoC, charging target, deadline and planned charging windows.
Is there already a good way to configure this with the current HomeFlux functionality that I have overlooked?
And if not, would something like a recurring minimum SoC / availability deadline make sense as a native HomeFlux requirement? Ideally it would act as a lower boundary underneath the normal EV strategy, rather than as another charging mode.
I am mainly interested in how you think this should best be modelled. If there is a cleaner way to achieve the same requirement with the existing planner, I would prefer that over adding another function.
Best regards,
Jurgen
Hello,
I’ve addressed the two EV planning points.
The Set SoC requirement can now be marked as guaranteed. When enabled, HomeFlux treats that SoC as a hard lower boundary and may use all available tariffs if necessary to make sure it is reached in time.
If the same requirement is received with guaranteed = no, HomeFlux keeps optimising normally and will continue charging only during the favourable tariff/PV windows.
One important note regarding the hybrid EMS setup: if HomeFlux stops working completely and control needs to be returned to the native EMS, I would recommend handling that fallback through an external Homey Flow/watchdog. If HomeFlux itself is unavailable, it obviously cannot reliably perform that handover anymore.
Davy
