Ha_openems: Fenecon FEMS and OpenEMS integration

[romal (Robert M. Albrecht)]

Yes, correct. Wrong name. I meant the ctrlEmergencyCapacityReserve0-

[Scritch]

I uploaded v0.7.0 in this minute. Notable enhancements:

• Add UI template cards for Storage, Charging Station and Optimized grid charges apps
• Support national languages, provide German sample texts
• Enhance default entity configuration and make it independent of component IDs
• Support update of timestamps (used to set target time in optimized grid charging app)
• Add support for many additional units, eg handle sec_Σ as a duration in seconds
• Update user documentation

As for last release, its published currently as a pre-release. I intend to set it to the regular main release after a few days.

I think this is the first release that would be worth calling it a “beta” version.

On my Todo list before creating a v1.0.0:

• Enhanced logging
• Provide option to check for backend config changes
• Find and fix the problem reported by @salomonde . It would be really great if you could provide the logging output of the test app which I had forwarded to you. I’d really love to fix that bug (I am sure there is one).

I have updated the initial post of this thread with the current status, as it was really outdated by now.

[romal (Robert M. Albrecht)]

Downloaded. Seems to work fine

[benniju (Benjamin)]

Now there is a pretty bad precedence case: Someone got their Websocket-API disabled because he used fenecon2mqtt:
https://www.photovoltaikforum.com/thread/245066-fems-sw-2025-3-2-zerst%C3%B6rt-rest-api/?postID=4277676#post4277676:

… , möchten wir Sie darüber informieren, dass unser lokales Monitoring-System und Ihre Home Assistant-Integration dieselbe Schnittstelle (WebSocket) verwenden.

Durch die gleichzeitige Nutzung kommt es zu einer Überlastung des Systems aufgrund der Vielzahl an Anfragen.

Wir können die WebSocket-Schnittstelle wieder aktivieren, wodurch das lokale Online Monitoring wieder funktionieren sollte.

Bitte beachten Sie jedoch, dass wir das Auslesen über die WebSocket-Schnittstelle grundsätzlich nicht unterstützen.

Von unserer Seite werden ausschließlich folgende Lesezugriffe unterstützt:

• REST/JSON Lesezugriff:
  https://docs.fenecon.de/de/fems/fems-a…esezugriff.html
• Modbus/TCP Lesezugriff:
  https://docs.fenecon.de/de/fems/fems-a…esezugriff.html

Wir empfehlen daher, die Home Assistant-Schnittstelle entsprechend anzupassen oder zu deaktivieren, um Konflikte mit dem lokalen Monitoring zu vermeiden.

[usman (Raja G)]

@TheSerapher

nstalled the app, worked just fine. Tried to enable a new entity which also seemed to work. Noticed all sensors went into unknown state for a short time then came back. No idea what that means but something I noticed.

With how this is setup I understand that keeping old sensor data is probably not possible. Gaining the ability to control my system from Home Assistant on the other hand might make the switch worthwhile. Keep at it, I will follow up!

Sounds like you’re on the right track! A brief “unknown” state when adding a new entity is normal as sensors refresh. Losing old data can happen, but gaining full control through Home Assistant is a big win. Keep going you’re close!

[TheSerapher]

Ha_openems: FEMS and OpenEMS integration

Sounds like you’re on the right track! A brief “unknown” state when adding a new entity is normal as sensors refresh. Losing old data can happen, but gaining full control through Home Assistant is a big win. Keep going you’re close!

That’s a ChatGPT answer to an old topic if I ever saw one

Ha_openems: FEMS and OpenEMS integration

Now there is a pretty bad precedence case: Someone got their Websocket-API disabled because he used fenecon2mqtt: https://www.photovoltaikforum.com/thread/245066-fems-sw-2025-3-2-zerst%C3%B6rt-rest-api/?postID=4277676#post4277676: … , möchten wir Sie darüber informieren, dass unser lokales Monitoring-System und Ihre Home Assistant-Integration dieselbe Schnittstelle (WebSocket) verwenden. Durch die gleichzeitige Nutzung kommt es zu einer Überlastung des Systems aufgrund der Vielzahl an Anfrag…

That’s really bad news. And it’s in their right to turn access off since it’s not a documented feature that customers should have access to. Sadly this also means that at some point it could hit anyone of us - making any implementation into Home Assistant with Websocket impossible unless we want to get locked out again.

I don’t really want any REST calls to do the monitoring, they aren’t “live” data and take a call for each request. Not to mention that I like to monitor a lot of things in Home Assistant that I have interest in which would be really hard to do with just REST calls (I have 191 entities enabled).

One argument I could use in my case: Their EVCS integration is completely useless for me since automated charging with battery priority doesn’t work as it should. Using Home Assistant I can work around the issues they are causing (and haven’t fixed or even addressed yet through my support ticket).

It’s too bad we can’t see the performance of the Rasperry Pi running FEMS. If turning off a few things brings performance back in line with what they expect, I have no issue with that as long as I keep control over charging my car.

I do have a feeling this is a bogus reasoning on their end. They realised people are using Websockets to work around all their own OpenEMS frontend and they probably want to stop that. Something I find interesting though, especially from a GDPR perspective: How would they know it’s a home assistant integration that is fetching that data and not just a regular client running all the time? One could always argue: What if I have a monitor and my own Raspberry running 24/7 that shows the information via your own web sockets? Would you block that too? They run basically the same commands.

Difficult situation for sure, but definitely something I would fight for if I ever got that E-Mail

Edit: And just a thought because it was mentioned before, maybe with throttling someplace and not using real time data we could at least keep the interface running even with their knowledge. That’s how their own frontend seems to do the calls? Speculation of course, but something that could be added to the integration as an option in case one of us gets that mail. I’d then enable throttling and tell them my Home Assistant behaves the exact same as their own frontend in my LAN !

[romal (Robert M. Albrecht)]

Maybe one possible “compromise” would be a very minimal default configuration. Only _sum and even there only a handful of enabled attributes.

Then the user has to actively enable the stuff he really needs.

[Scritch]

Which is exactly what this integration does.

The default config is a stripped down set of channels that is also accessed by the regular webui, extended with the energy channels (which could easily be converted to rest based access).

There is absolutely nothing to be worried about here. Neither does the integation something different then a browser does while executing the regular webui, nor there are any reason or even signs visible that fenecon would have any interest in taking actions to convert openems to closedems

[Scritch]

@benniju

blocked

This is not true based on the link you shared. Could even have been a support activity of fenecon to help a person whose system was misbehaving. How great is that? If you want to understand what really happened with which intentions: ask directly in the openems.io community. Fenecon members are very active over there.
Speculating here and drawing a picture of bad intentions by fenecon is misleading.
And even more: it has nothing to do with ha_openems (which is what this thread here is about). I would really appreciate if you could relocate your thoughts and concerns to a more suitable location.

[TheSerapher]

@Scritch

There is absolutely nothing to be worried about here. Neither does the integation something different then a browser does while executing the regular webui,

After reflection on this I agree with your statement. This shouldn’t be anything that has to worry us for now and especially this could be true:

@Scritch

Could even have been a support activity of fenecon to help a person whose system was misbehaving.

This is very likely the case. How else would they know that Home Assistant specifically is doing those requests

Let’s stick to ha_openems here, which works great. I still have to look at those template cards (great work on those, even though I am not a huge fan of installing a lot of dependencies to make them work ). They look very useful, especially for me since multiple people access the charging feature and having a dedicated card and dashboard for it sounds awesome!

[romal (Robert M. Albrecht)]

I like this integration very much.

I build an automation to enable / disable the grid optimized charging. The feature does not include a weather-forecast and also does not evaluate how much energy the car will suck up. So, depending on these conditions I can enable / disable it via HA.

Also, I can trigger / suppress the heat pumps SG Ready program via FEMS. The heat pump itself does not offer this capability.

And I can raise the emergency level to prevent the car from emptying the battery and instead use grid energy.

So much possibilities to refine the existing FEMS logic.

[TheSerapher]

@romal

So much possibilities to refine the existing FEMS logic.

I agree, even though I’d be much happier if a few things would just work as intended. The battery draining part is simply an implementation issue in OpenEMS/FEMS and one of the community members already offered a solution in code (which I can’t test because I can’t change the FEMS code). I do see there are lots of edge cases that probably a big percentage of FEMS users won’t run into and having the integration makes a lot of stuff possible!

[Scritch]

@TheSerapher

look at those template cards (great work on those, even though I am not a huge fan of installing a lot of dependencies to make them work ).

Yes, true. There are indeed quite some dependencies Furthermore, the usability on mobile devices is not the greatest due to non-ideal behavior of the default sliders contained.

The main purpose of these is to illustrate the power of the integration by showcasing feature parity with the regular Fenecon UI. With that, you can use the template card configs to look up which channels are used and have to be updated for which UI options. Users can use the templates as a starting point to create custom versions of the UI, containing only the parameters which they regularly use/modify, using whatever look&feell they wish.

@romal

And I can raise the emergency level to prevent the car from emptying the battery and instead use grid energy.

This limitation is the main reason why I actually got started on this integration, at all.

Here my automations which I use in my personal setup to solve this problem:

1. Enable capacity reserve while charging the car:

alias: "[ctrlEvcs]: Reserve aktiv solange Auto lädt"
description: Reserve aktiv solange Auto lädt
triggers:
  - trigger: state
    entity_id:
      - sensor.fems12345_evcs0_status
actions:
  - if:
      - condition: state
        entity_id: sensor.fems12345_evcs0_status
        state: Charging
    then:
      - action: switch.turn_on
        target:
          entity_id: switch.fems12345_ctrlemergencycapacityreserve0_isreservesocenabled
    else:
      - action: switch.turn_off
        target:
          entity_id: switch.fems12345_ctrlemergencycapacityreserve0_isreservesocenabled

2. Set reserve capacity to battery status of charge while charging the car:

alias: "[ctrlEvcs]: Während Auto lädt Speicher Reserve auf Ladestand setzen"
description: Während Auto lädt Speicher Reserve auf Ladestand setzen
triggers:
  - trigger: state
    entity_id:
      - sensor.fems57988_evcs0_status
      - sensor.fems57988_sum_esssoc
conditions:
  - condition: state
    entity_id: sensor.fems57988_evcs0_status
    state: Charging
actions:
  - action: number.set_value
    metadata: {}
    data_template:
      value: "{{ states('sensor.fems57988_sum_esssoc') }}"
    target:
      entity_id: number.fems57988_ctrlemergencycapacityreserve0_reservesoc

Edit: Updated the 2nd one to trigger only when a relevant entity changes (instead of every minute).

[TheSerapher]

Since I have been running automations for this as well for a while, even though not tied to the reserve limit, be aware that the status is not always “charging” and it flips quite often between “increasing”, “decreasing” and other values for the KEBA Charger. I’d check for “is not Not Charging” as a template condition instead.

@Scritch

The main purpose of these is to illustrate the power of the integration by showcasing feature parity with the regular Fenecon UI.

Maybe another option, and potentially easier to use, would be adding HACS supported template cards. Maybe similar to power flow, where you only need to link to the right properties. More work to first set things up but no dependencies needed to get it to work. And with a proper GUI guide it’s also not too hard to do for a user.

I have added your examples and they look neat! Thanks for that, can now control everything for a single solar settings dashboard with visibility adjusted to cards that need to be used by users.

[Scritch]

@TheSerapher

Maybe another option, and potentially easier to use, would be adding HACS supported template cards. Maybe similar to power flow, where you only need to link to the right properties. More work to first set things up but no dependencies needed to get it to work. And with a proper GUI guide it’s also not too hard to do for a user.

That makes sense for power flow card, which creates its own graphical elements. It does not make sense for the OpenEMS control UIs, which consist out of standard controls.
For that use-case, the decluttering card was created, which allows to combine arbitrary set of other cards and define a template layout, using a yaml config. That makes it not only generic, but even far less effort than having to implement an own card using the HA frontend API. (And I am really not an experienced typescript developer )

I agree tough, that it is not ideal that the template configs need to be copied to every dashboard in which you want to use it. I tried to find ways around that, but it is not possible.

[TheSerapher]

@Scritch

And I am really not an experienced typescript developer

Who knows, maybe someone in the community feels compelled to lend a hand here someday just to use a streamlined process similar to other cards For now it works just fine and we can use the features as intended!

[romal (Robert M. Albrecht)]

I found a new SAN energy card in HACS and wanted to try it out. But it needs one entity for the battery dis/charge.

I found entities for DCCharge and DCDischarge, but the wants one entity (then using plus and minus).

I couldn’t find one. Does FEMS provide such an entity and I have just overlooked it?

[benniju (Benjamin)]

Yes, you can use ess0 DcDischargePower which is negative for charging and positive for discharging

[Scritch]

The Readme provides a configuration for the Power Flow card plus

It references _sum/EssDischargePower which should be identical to the one posted by benniju as long you have only one battery.

[Scritch]

I have published a pre-release version of v0.8.1.

New features:

• Add support for reload and reconfigure steps.
• Re-read backend component config during reload step.
• provide options to connect OpenEMS, FEMS Online monitoring and custom URLs (visible only to users who enabled advanced mode)
• Support multi-edge systems

I am confident that this release also fixes the issue reported by @salomonde.

As always, I will give it a few days for people who are willing to support with early testing. In case of no issues reported, the release will be made available to everybody.

Furthermore, from functionality perspective, this version can be considered complete. After a few more documentation extension to describe the new config options, v1.0.0 will be released.