Ha_openems: Fenecon FEMS and OpenEMS integration

[austrogaucho]

@Scritch: how could I limit the charge power, while I recharge my batterie from the grid overnight?
I am using the “number.femsxxx_ctrlemergencycapacityreserve0_reservesoc_2” and set it to the desired SOC-value e.g. 95% at midnight and switch it back to 5% at 5:00 a.m.
By doing so the the batteryinverter will charge the battery with full power - in my case with 4,5kW.

Now I would like to limit the charge power down to 2kW or so, since my battery has only 8.8kW and I could you use the whole 5 hours of my cheap-grid-night-tariff to charge the battery.

Is there a way to implement that?

[benniju (Benjamin)]

As far as I know you can’t control that without buying the Write Access App. With that you should be able to control the power (charge and discharge) freely. (I’m not sure how well it works with ha_openems though)

Also you should consider that the system probably charges more efficiently with a higher power anyways.

Btw, the charge power for the emergency reserve is not the max power, it’s half of the Inverter Power. So if you have the Home 10 then it’s 5 kW. But in your case the battery limits that.

[Scritch]

Personally, I have no experience in this, as I do not (yet) have a dynamic electricity tariff.

Generally speaking, thats primarily a question about the capabilities of FEMS / OpenEMS. Once its clear how this can be achieved, we should also be able to convert it to an automation in home assistant.

I recommend you to first ask the question in the OpenEMS Community.

[marathonfrank]

WattWise - Energy forecasting and battery control for dynamic energy tariffs like Tibber

Hi, first of all, thank you for your great Appdaemon app. I’ve been looking for a long time for an easy way to load my Fenecon storage with some “intelligence”. I first tried it with little success with EMHass. I’ve been running Wattwise for about 4 weeks now and I’m very happy with it. To be able to charge the Fenecon Home storage externally, either the Modbus Write or the Rest Write app is required. I use the Rest-Write application. For this, a corresponding command must be executed …

[romal (Robert M. Albrecht)]

FEMS has this logic build in (APP zeitvariable Netzentgelte and similar):

to reduce battery load, the charging is limited, so that at the end of the time-window the intended soc is reached.

[Scritch]

Based on that response, sending setpoints to ess0/SetActivePowerEquals
using the REST/Write App seems to do the trick.

That is currently not yet supported by the integration.
If there is somebody around who purchased this app and would take care of testing, I offer to implement it.

[romal (Robert M. Albrecht)]

I have purchased the Rest Write app and could test it.

[Scritch]

Sounds good. I will try to work on it during the next weeks.

My idea is to provide a service call, probably called openems.update_value which takes the following parameter types and default values:

entity_id: str
value: str | int
timeout: int | None = 0
update_cycle: int = 30

[Scritch]

@romal : Can you please send me the contents of your config entry via PM?

I would like to see which properties are getting exposed by the REST write application component.

Ideally, I can read properties like availability and communication port directly from backend instead of asking the user to configure it. This would save some implementation effort (the config dialogue is already sufficiently complex) and it would be less error-prone as no extra configuration will be required.

[distante]

Hi a question,

I have seen in HACS an update marked with b1: v1.3.0b1. I asumme this is a Beta?

I am not sure if we should update it because as I remember, there was a problem some weeks ago about a non-stable version getting offered by HACS.

[Scritch]

I had created a 2nd beta for 1.3.0 (containing only documentation enhancements) a few days ago. At that point, I removed the beta label from the first beta. As I didn’t set it as the current main release, I expected HACS would ignore it.

However as it turns out. HACS actively promoted it as a new default release. Sorry for the small confusion.
As by now nearly 50% of all users migrated to the first beta, I decided to clean this up and set beta2 to the new main release, and removed the beta label from it.

Bottom line: Now we have v1.3.0 officially released, using the previous beta2 tag, which differs only in small documentation enhancements from beta1, that many people are using as of now.

[distante]

Sorry I got no notification from this, thanks!

[distante]

Hi all, I am not sure what I have setup wrongly but in HA, the Now tab in the Energy Dashboard shows the Production as the same as the Consumption value

In my Fenecon Dashboard it looks like this:

I think I have correctly setup the inputs

Does someone knows what did I did wrong here?

Thanks in advance!

[Scritch]

Configuration looks almost the same as mine. No issues for me. Normally, the power sources graph should show also grid and battery values.

I have personally no idea what might be causing that these done show up for you.

[distante]

So I found I my problem thanks to github, like always it was a layer 8 problem.

I didn’t configured the Power Sensors, I just got the Energy ones.

I added Fenecon Home 10 Sum GridActivePower as Grid Power Sensor and EssDischargePower as The Battery Power Sensor and now looks correct (I think).

[hhjung (Lars)]

Hi all,

I’m currently trying to integrate a FENECON (FEMS / OpenEMS) system into the Home Assistant Energy Dashboard and I’m running into a consistency issue that I can’t fully resolve.

⸻

Setup:

I’m using the following sensors from the integration:
• *_sum ProductionActiveEnergy (PV production)
• *_sum GridBuyActiveEnergy (grid import)
• *_sum GridSellActiveEnergy (grid export)
• *_sum EssDcChargeEnergy (battery charge)
• *_sum EssDcDischargeEnergy (battery discharge)

All sensors appear stable and match the values shown in the FENECON portal.

⸻

Problem:
• During the day, values in Home Assistant and FENECON are very close.
• However, towards the evening, the Home Assistant Energy Dashboard starts to drift.
• The calculated home consumption becomes significantly higher than expected.

Example (same day):
• FENECON:
• Production: ~23.4 kWh
• Consumption: ~26.6 kWh
• Grid import: ~10.5 kWh
• Home Assistant:
• PV: ~22.4 kWh
• Grid: ~9.5 kWh
• Home consumption: ~38 kWh

So individual values look correct, but the overall energy balance is off.

⸻

What I suspect:

It looks like the _sum sensors:
• are already aggregated values
• may not be fully independent from each other
• could mix AC and DC domains (especially battery vs grid)

Since the Home Assistant Energy Dashboard expects independent, monotonic energy counters, this might lead to incorrect internal calculations (double counting or drift).

⸻

Questions:
• Has anyone managed to get a 1:1 match between FENECON and HA Energy Dashboard?
• Are you using the _sum sensors, or different ones?
• Did you exclude battery from the Energy Dashboard?
• Are you using template or utility_meter sensors to “normalize” the data?

⸻

Goal:

I’d like to achieve a consistent energy balance in Home Assistant similar to FENECON, without drift over time.

⸻

Any insights or best practices would be highly appreciated
:::

[Scritch]

Looking at your screenshots (eg taking the one of March 26th), I am surprised about the discrepancy in the PV production.

• FEMS: 36.9 kWh
• HA: 68.9 kWh

How does the chart of the *_sum ProductionActiveEnergy entity look like for that day in HA?

[hhjung (Lars)]

That might actually be related.

On March 25th I did not receive any data from the system, and the values seem to have been updated only on March 26th.

However, I had already checked the raw sensor values before and at that time they appeared consistent with the FENECON portal.

What I’m seeing now is:
• The individual sensor values look plausible
• The curves are smooth (no visible resets or spikes)
• But the total energy for the day (especially PV production) ends up significantly higher in Home Assistant

This makes me wonder if delayed or backfilled data could be affecting how Home Assistant interprets the total_increasing sensors.

If a larger increment is applied after a period without updates, it might be assigned entirely to the current day, which could explain the discrepancy.

Would the integration or underlying system ever “catch up” missing values in this way?

I will also take a closer look at the sensor history around the day boundary to see if there is a noticeable jump.

Happy to provide additional charts if that helps.

[Scritch]

So basically you received the energy of 2.5 days Friday very late. This is the reason why the values do not match.

So we can only use the data of today for meaningful evaluation.

For todays values: Is it possible that the 38 kW consumption is exactly the sum of the consumption visible in FEMS (26.6) + the gas consumption (11)?

What do you expect? Do you say that the 11 should actually be included in the 26.6?

[hhjung (Lars)]

Thanks – this helped clarify things a lot.

I checked the values again for today and they actually match very well:

• FENECON:
  • Consumption: ~46.8 kWh
• Home Assistant:
  • Home: ~47 kWh

So the total electrical consumption is consistent.

The confusion came from the fact that in Home Assistant I also have a separate “gas” entity (~12 kWh), which in my case represents the heat pump.

However:

• The heat pump is fully electric
• Its consumption is already included in the total “home” consumption
• The “gas” value is just a separate visualization, not an additional energy source

So there is no double counting – just a different way of presenting the same data.

Also, the earlier discrepancy (almost doubled PV values) was likely caused by delayed/missing data from the previous day being applied to the next day.

For today’s data, everything seems consistent.

Thanks for guiding me in the right direction!