Correct - and I agree. That makes it very limited. You can find any writable variables by fetching all channels and looking for RW or WO. It’s still a bit more than some other vendors and I did manage to make use of it 
RETIRED Add-On Fenecon2Mqtt - Connect Fenecon Home (OpenEMS) energy storage systems to Homeassistant
@benniju @TheSerapher
Thank you very much for this information.
I asked now a question to [email protected]
Here my usecase:
I would like to use the Octopus Heat electricity tariff. There is no suitable FEMS app from fenecon. For a few weeks now, fenecon has allowed the emergency power reserve to be topped up from the grid. Now I would like to increase the emergency power reserve when the price is low and reduce the emergency power reserve when the price rises.
1 Like
Since you can’t control the power reserve setting via API this probably would need quite some tinkering with the existing write api (e.g. continuously adjust discharge power at high price times to the consumption of your setup?). Personally I’d rather not use my storage cycles for low/high price situations that save me a couple cents per kWh and purely use it for solar. But that’s just me 
With the “Octopus Go” tariff, for which you don’t need an electric car, it’s still 10 cents.
I wrote to Fenecon on Friday afternoon and got a call on Monday morning. I didn’t expect it to happen so quickly.
Unfortunately, I was not pleased with the answer:
There is no interface and none is being planned to manage the emergency power reserve.
TheSerapher has already written about this.
An app is planned for the provider octopusenergy.de. It was not known whether this will only map the dynamicOctopus tariff or also the octopus heat tariff. This question was passed on.
Thanks for asking and posting the answer.
You could probably prevent the System from discharging by writing 0 into the power and make it charge by writing a positive/negative value. It should be possible to make these modbus writes with the modbus integration and an automation. Then you would basically have control.over the State of charge.
Hello,
thank you for the information and the tip to solve the problem via the supported values of the FEMS apps. Which of the two apps (REST/JSON or Modbus) is recommended?
Which interface is more stable?
Which can write more values (I could compare this myself if necessary)?
So far, I have connected my Fenecon system for reading via the three interfaces “Fenecon2Mqtt”, “JSON/REST” and “Modbus/TCP”. If many values are read, not all of them are always filled via the JSON/REST interface.
Best regards
nam-AH
Hi Benjamin,
Do you know how it is possible to set up write access to values that are accessible via the web frontend anyway (and can be controlled from there - just manually - without buying the additional app)? I am currently looking for a way to integrate the value of the “Notstromreserve” (and possibly the switch “Erhalten der Notstromreserve aus dem Netz aktivieren”) into the HA.
Have you found a way to do this yet?
My target is to build an automation to prevent a long time low load of the battrey in the dark winter season.
Greetings Thomas
Hey ThoBec,
This is not possible - you can’t write into any of the hard settings of the device and they have no intentions to add this as far as I could gather information from support. There is just not enough people asking for it 
The only option, and in my opinion the better option anyway, you have is to dynamically adjust the power distribution of the system. I have made a post regarding this setup here but it is in German (should be easy enough to translate):
With that in mind, I have added the exact same thing in my HA to prevent the battery to be used if consumption exceeds a certain power limit, here is the automation for that that builds on top of the Write REST/API. It also sets a boolean switch that will enable a timer to indicate when the limitation is expected to be disabled again (60 second timeout in the FEMS system) just to make it more visible. You can adjust the automation to check that a certain limit is exceeded for a certain time period which would match exactly your intent.
alias: "Trigger: Disable Battery on High Power"
description: ""
triggers:
- trigger: numeric_state
entity_id:
- sensor.battery_inverter_fems_sum_consumptionactivepower
above: 10000
for:
hours: 0
minutes: 0
seconds: 0
conditions:
- condition: template
value_template: >-
{{ not is_state('sensor.battery_inverter_fems_evcs0_chargestate',
'Charging') }}
alias: Car not charging
- alias: Battery Below 65%
condition: numeric_state
entity_id: sensor.battery_inverter_fems_sum_esssoc
below: 65
- condition: numeric_state
entity_id: sensor.battery_inverter_fems_sum_esssoc
above: 0
actions:
- repeat:
sequence:
- action: rest_command.fenecon_battery_power
metadata: {}
data:
power: >-
{{
states('sensor.battery_inverter_fems_sum_productionactivepower') |
int(0) }}
alias: Set battery power to solar production
enabled: true
- action: input_boolean.turn_on
metadata: {}
data: {}
target:
entity_id: input_boolean.fems_battery_limiter_active
- delay:
hours: 0
minutes: 0
seconds: 1
enabled: true
while:
- condition: and
conditions:
- condition: template
value_template: >-
{{ not
is_state('sensor.battery_inverter_fems_evcs0_chargestate',
'Charging') }}
- condition: numeric_state
entity_id: sensor.battery_inverter_fems_sum_consumptionactivepower
above: 10000
- action: input_boolean.turn_off
metadata: {}
data: {}
target:
entity_id: input_boolean.fems_battery_limiter_active
mode: single
I went with the REST/API Write Access when implementing my own change since I didn’t feel like digging into Modbus at all. REST was easy to add to Home Assistant as well, so I didn’t bother looking into Modbus. It might be worth comparing the two, I do have a feeling there won’t be any difference in how many settings you can control. They are very protective about that setup to ensure nothing that could break the system can be set by a user.
In my mind, their reasoning for not adding backup battery settings is probably that they wouldn’t be great to apply a timeout to. If I changed that setting, I would expect it to stick even though I am not writing it every 60 seconds. The current API will reset settings after that timeframe, maybe it’s just not implemented in any other way.
As for your specific setup, SetActivePower could still be used since a negative value sent to the system tells it to charge the battery. Combine that with a HA automation that checks for prices you could still accomplish a charged battery when the price is low. Or you wait for a proper implementation in FEMS (which apparently they work on as you said). If that fits your need 100% I don’t know, but there are ways around.
Since the weather is finally better in my region I decided to finally post a screenshot of my dashboard with all the data I care about when taking a glance at my Solar system. It may not be totally on topic but it took me a long time to design something I am happy with so maybe it inspires others to get some good ideas too
Things I have added to make this work (HACS):
- ApexCharts - replacing all those boring HA ones
- Plotly Graphs - for more advanced heat maps not covered by ApexCharts
- Sun2 Integration for the sun graph
- Azimuth Heatmap to see the power production throughout the day
- Consumption Heatmap to see when power was consumed
- Lots of template sensors to fill missing information (like battery charge duration and target time)
Hopefully someone can get some information out of this and get their own dashboard on track
Edit: And I just noticed, that red bar on Total power at the beginning is the result of the “high power stop battery” automation and 60 second timeout - sending power to the grid until the setting is revoked. So that works too!
1 Like
This statement is wrong. Its even public API to do so. Everything that the WebUI does is actually public API.
I have started implementing a FEMS & OpenEMS integration. In its current state its possible to read all values same as Fenecon2Mqtt. However, its not yet a robust implementation. For example I am not yet handling connection losses and re-connects between HomeAssistant and Fenecon. Also I have not yet done proper documentation.
The integration can be installed via HACS by adding the following repo: GitHub - Lamarqe/ha_openems: Home Assistant Integration for FEMS and OpenEMS
I intend to implement controlling of component properties (like charge mode and battery reserve) as one of the next steps.
Well if it really is a public API, then there should be some kind of documentation. There once was a website about the Websocket API in the Documentation, but it always said “todo” and was later removed.
Just one remark: I saw in your code, that you use port 80. You could also use the port 8085 (or at best make it configurable) which is the extra port for the Websocket API. (I think you also need to remove the websocket from the ws:// URL, so maybe you could make that configurable) You can see this on the “Controller API Websocket” Configuration. And if the port exists like that and can be used you could of course argue that it is supposed to be a public API.
Thanks for the integration, I will try it out later.
Maybe we should create a new thread for the integration?
Agreed. Lets move here
Hey, I have the problem that FEMS is no longer sending me any data. I have installed HA from a micro SD card to an SSD. Do I have to set anything else?
Log:
2025-03-15 11:20:33,516 - on_disconnect-MqttClient - paho-mqtt-client-Fenecon2Hassio_mqttClient_0 - WARNING - Unexpected MQTT disconnection code=Unspecified error. Will auto-reconnect in 5 seconds.
Seems like there is an issue with your MQTT Broker. Is MQTT working with other devices?
0.4.0
-
switched to threaded message handling process
-
added more sensor names in translations
-
refactor code
-
addes value mappings for evcs charge states and charge from grid allowed state
-
modified standalone script
-
upgrade rel package
The Azimuth Heatmap is cool. Thanks, I included it in my installation too.
Sorry for being shamefully late with feedback, but better now than never. I remembered the project and tried again and it works now! Incredible, thank you so much for your help! I could not image that this was possible and went on without a solution, so I did not check up since then. Amazing, that you could integrate even such a minor side issue into the project!
1 Like