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
@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.
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!