Ha_openems: Fenecon FEMS and OpenEMS integration

Scritch · March 27, 2026, 7:34pm

Instead of using the gas option, I recommend to configure your heatpumps energy as an individual electrical device in the home assistant energy dashboard:

This way, its energy is included in the total energy. And the data distribution is visualized in the electricity tab:

HorizonKane · April 24, 2026, 10:00am

Hi there,

I now got a heatpump and I want to be able to exclude it from the battery (prevent it from discharging it). The reason is, that the energy for the heatpump will be significantly cheaper for me than the “normal” one for the house - so I want to sepnd the battery on that of course.

Fenecon offers an App for that (Power-to-heat) which offers the option - but I don’t want to buy it.

Is here anybody who realised such a function?

I found this entitiy:

However it is quite dynamic and I don’t know where the value comes from and if it has dependencies or if it is ok to change it?

I thought I could use it like when excess charging but in reverse: AllowedDischargePower = Total consumption - heatpump

Any thoughts?

romal · April 24, 2026, 8:02pm

You can also set the emergency reserve to whatever your SOC currently is, then the battery will also not discharge. I used this for a while for exactly that use case.

cbeckstein · May 7, 2026, 4:46pm

I found a likely bug in ha-openems regarding the documented REST Write service openems.update_value.

In my setup, openems.update_value did not work for the write-only sensor entity sensor.fems82773_ess0_setactivepowerequals (ess0/SetActivePowerEquals). Calls with timeout and update_cycle were rejected as extra keys, and calls with only value returned 200 OK but logged that the referenced sensor entity was missing or not currently available.

After code inspection, the likely cause is a service-name collision: both sensor.py and binary_sensor.py register an entity service named update_value, but with different schemas. Renaming the binary-sensor service locally to update_binary_value made the documented openems.update_value service work for the sensor entity. After that, a test call with value: -800, timeout: 75, update_cycle: 10 correctly resulted in about -795 W ESS active power on my FENECON/FEMS system.

I opened a detailed GitHub issue here:

github.com/Lamarqe/ha_openems

Service collision: openems.update_value is registered by both sensor.py and binary_sensor.py and breaks REST Write for sensor entities

opened 03:36PM - 07 May 26 UTC

cbeckstein

bug

## Summary `openems.update_value` appears to be registered twice with different… schemas and different entity platforms. In my setup this breaks the documented REST Write workflow for write-only sensor channels such as: `sensor.femsXXXXX_ess0_setactivepowerequals` This sensor maps to the OpenEMS/FEMS channel: `femsXXXXX/0/ess0/SetActivePowerEquals` ## Environment - Home Assistant Core: `2026.5.0` - ha-openems installed via HACS - HACS offered/downloaded release: `v1.5.0` - Installed `manifest.json` still reports: `"version": "1.4.1"` - FENECON/FEMS system with REST/JSON Write App installed - Target channel: `ess0/SetActivePowerEquals` - Target Home Assistant entity: `sensor.femsXXXXX_ess0_setactivepowerequals` Entity attributes after enabling and restarting Home Assistant: ```json { "entity_id": "sensor.femsXXXXX_ess0_setactivepowerequals", "state": "unknown", "attributes": { "accessMode": "WO", "id": "SetActivePowerEquals", "type": "INTEGER", "unit": "W", "unit_of_measurement": "W", "text": "Write command for a charge power (-) or discharge power (+). Range e.g. [-5000 to 5000]" } } ``` ## Observed problem Calling the documented service against the write-only sensor entity failed or did not reach the sensor entity reliably. When calling the service with `timeout` and `update_cycle`, Home Assistant rejected the extra fields: ```text extra keys not allowed @ data['timeout'] extra keys not allowed @ data['update_cycle'] ``` When calling the service with only `value`, Home Assistant returned `200 OK`, but logged: ```text Referenced entities sensor.femsXXXXX_ess0_setactivepowerequals are missing or not currently available ``` No effective REST Write happened in that state. ## Code inspection In `custom_components/openems/sensor.py`, `update_value` is registered as: ```python platform.async_register_entity_service( name="update_value", schema={ vol.Required(ATTR_VALUE): vol.Coerce(float), vol.Optional(ATTR_UPDATE_CYCLE, default=30): vol.Coerce(int), vol.Optional(ATTR_TIMEOUT, default=0): vol.Coerce(int), }, func="update_value", ) ``` In `custom_components/openems/binary_sensor.py`, `update_value` is also registered as: ```python platform.async_register_entity_service( name="update_value", schema={vol.Required(ATTR_VALUE): vol.Coerce(bool)}, func="update_value", ) ``` This looks like a service-name collision. In my installation the binary-sensor registration appears to interfere with the sensor registration. There may also be a copy/paste issue in `binary_sensor.py`: ```python entry.runtime_data.add_component_callbacks[Platform.SENSOR.value] = ( _create_sensor_entities ) ``` Since this is in `binary_sensor.py`, I would have expected something related to `Platform.BINARY_SENSOR.value`. ## Local workaround As a local test only, I changed the binary-sensor service name from: ```python name="update_value", ``` to: ```python name="update_binary_value", ``` in: `/config/custom_components/openems/binary_sensor.py` After restarting Home Assistant, the documented sensor service started working. ## Verification after workaround After the workaround, this service call worked: ```yaml action: openems.update_value target: entity_id: sensor.femsXXXXX_ess0_setactivepowerequals data: value: -800 timeout: 75 update_cycle: 10 ``` The FEMS system reacted correctly. Before: ```text sensor.femsXXXXX_sum_essactivepower = 78 W sensor.femsXXXXX_sum_gridactivepower = -16 W ``` During the active `-800 W` command: ```text sensor.femsXXXXX_sum_essactivepower = -795 W sensor.femsXXXXX_sum_gridactivepower = 892 W sensor.femsXXXXX_sum_productionactivepower = 814 W ``` The value stayed close to the requested value for the expected duration. ## Expected behavior `openems.update_value` should be callable for writeable sensor entities such as: `sensor.femsXXXXX_ess0_setactivepowerequals` with the documented fields: ```yaml value: timeout: update_cycle: ``` It should not be shadowed or overridden by the binary-sensor service registration. ## Actual behavior Without the local workaround: - `timeout` and `update_cycle` may be rejected as extra keys. - Calls with only `value` may return `200 OK` but log that the referenced sensor entity is missing or not currently available. - No effective REST Write happens. ## Additional observation: release/version mismatch HACS offered/downloaded `v1.5.0`, but the installed `manifest.json` still reports: ```json "version": "1.4.1" ``` This may be a separate release packaging/versioning issue.

cbeckstein · May 9, 2026, 7:55am

Bug(s) fixed in the new official release 1.5.1 of ha-openems.

Thanks to the author!

HorizonKane · May 13, 2026, 4:03pm

Had that idea. However i domt want to buy power from the network. The house should consume from the battery - just not the heat pump. Only way I see to realize this is to limit the battery to what I currently consume minus the heatpump.

Scritch · May 17, 2026, 9:15am

Hi everone,

Primarily because FEMS sent zero (or even negative) values for the energy counters right after its runup, I am working on a behavior change to drop decreasing channel values for sensor which represent sum value (like _sum/productionactiveenergy and _sum/consumptionactiveenergy).

While testing this change, I see a weird behavior of the _sum/consumptionactiveenergy channel. This is how it looks to me:

Can somebody confirm this behavior?

With my current change, behavior would instead look like this:

I still think this change would make sense. and would aim at rolling it out with a potential v1.6 of the integration.

romal · May 17, 2026, 3:59pm

Very strange numbers.

Scritch · May 17, 2026, 6:02pm

That's even more unexplainable than my system.
First chart looks similar to my system, with a super large dip when fems restarts. This is the main reason for me to add the change I explained above.

Regarding the 2nd chart: never seen a long time negative energy counter before. Does not happen for my system.

Xfinden · May 23, 2026, 7:28pm

Dear all,

FEMS is nice, as is HA, and I have been using this project/integration Fenecon FEMS & OpenEMS (1.5.1) for some time.

All my systems, apps and …. are updated to the latest versions – all the time.

Now, today I have run into a problem: I can't do a automatic/manual backup anymore because the home-assistant_v2.db-file is too big. The system tried to write the backup-data, but couldn't verify the file for some reason (and, as I saw, wiped the even written data from the storage (512 GB SSD).

I had to purge the database, and then the backup worked again as before! (the file has only ~ one third of the size as before).

When i did some audits in my HA-system using H.A.C.A (also nice project!!) because of that, I got this information:

H.A.C.A Konfigurationsbericht :

...

Leistungs-Probleme (55)

--> noisy entity

[MEDIUM] sensor.fems123456789_sum_consumptionactivepower

Laute Entität: 81256 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_sum_essactivepower

Laute Entität: 71401 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_meter0_activepower

Laute Entität: 70542 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_sum_gridactivepower

Laute Entität: 70542 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_ctrlgridoptimizedcharge0_selltogridlimitminimumcharg

Laute Entität: 56952 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_sum_productionactivepower

Laute Entität: 51920 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_sum_productiondcactualpower

Laute Entität: 48123 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_charger0_actualpower

Laute Entität: 41868 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_charger1_actualpower

Laute Entität: 40894 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_sum_gridsellactiveenergy

Laute Entität: 38634 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_sum_gridsellactiveenergy_compensation

Laute Entität: 38634 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_sum_productionactiveenergy

Laute Entität: 38389 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_sum_productionacactivepower

Laute Entität: 38282 Statusänderungen in 24h

[MEDIUM] sensor.1_og_summe

Laute Entität: 37329 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_ess0_dcdischargepower

Laute Entität: 36747 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_sum_essdischargepower

Laute Entität: 36747 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_charger2_actualpower

Laute Entität: 35834 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_meter2_activepower

Laute Entität: 32387 Statusänderungen in 24h

[MEDIUM] sensor.fems123456789_charger0_- actualenergy

....... and so on.....

There is a verry big amount of data - each day - filling the database

!

It seems to me, that there are stored 1 "data-point" each second (may be at dayligth - ~ 10 h/d --> =~ 36.000) for each entity ??

-- ((sorry I am a beginner - in HA, in english and in IT-language.... ;-)) --

Is it only a problem of me with the database ?

What could/should I do?

Based on the information regarding my integration—which apparently comprises " 1 Gerät • 11 Dienste • 295 Entitäten” // 1 Device • 11 Services • 295 Entities—do I need to disable many of these entities or services?

And if so, which ones exactly?

I would be happy for any help!

benniju · May 23, 2026, 7:43pm

Yes, because of the very frequent updates of many FEMS Sensors if have excluded it form the database.. (Or rather I have a whitelist for recorded sensors.)
You can also lower the purge time.

I think it would be great if the was a way have for example configureable average intervals directly in the Integration, but this might be tricky to implement. Otherwise you can just blacklist the sensors an only allow the important ones, or add filter sensors.

Edit: On the others hand this would break the best thing of this integration, which are instant updates, just like in the Fems Portal. This Problem is really a generic issue with Home Assistant an it has been annoying me for years...

Scritch · May 23, 2026, 7:44pm

The amount of data stored due to live updates is static, as the recorder duration is fixed (default: 10 days). You can fine tune eg by setting purge_keep_days or auto_purge. See the recorder integration docu.

The long term statistics contain only 5(?) minute values. No matter how often the entity was updated initially.

Xfinden · May 23, 2026, 9:16pm

OK, THANKS—so I'm not alone in this!
It's just that I hadn't read anything about this database issue in any previous posts.
That's why I went into a bit more detail in my explanation.

But which of the 11 services • 295 entities can I actually disable now without breaking something that I still need?

Could someone publish a proven/tested blacklist or whitelist for this?
I think starting with a heavily stripped-down version would be helpful for many people.

Thanks a lot - to the very, very helpful community,

Xaver

Scritch · June 3, 2026, 4:29pm

v1.6.0 allows to reduce the frequency of data updates.

There is now an option which allows you to define the interval in which the data shall be updated in HA.

benniju · June 3, 2026, 5:03pm

Thank you so much for maintaining this great integration and updates!