Pretty sure they are indeed fixed values.
OK, I will start a short experiment 
I am using the older āSolarEdge_Modbusā integration - and for now, I havenāt really seen the requirement to change the setup (especially, since this would require to redo the whole energy dashboard, etc.)
But I do get regular errors in my logs about an invalid state - probably, when the inverter resets (as I read further above)ā¦
2024-01-07 17:49:47.639 ERROR (SyncWorker_6) [custom_components.solaredge_modbus] Error reading modbus data
Traceback (most recent call last):
File "/config/custom_components/solaredge_modbus/__init__.py", line 240, in _refresh_modbus_data
update_result = self.read_modbus_data()
^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/solaredge_modbus/__init__.py", line 316, in read_modbus_data
and self.read_modbus_data_meter1()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/solaredge_modbus/__init__.py", line 326, in read_modbus_data_meter1
return self.read_modbus_data_meter("m1_", 40190)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/solaredge_modbus/__init__.py", line 475, in read_modbus_data_meter
exported = validate(self.calculate_value(exported, energywsf), ">", 0)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/solaredge_modbus/__init__.py", line 158, in validate
raise ValueError(f"Value {value} failed validation ({comparison}{against})")
ValueError: Value 0 failed validation (>0)
Since I am using a Modbus Proxy for the connection between HomeAssistant and my Inverter (The inverter does only accept one connection - and I need other devices read from the inverter directly) - this setup should allow me to use both integrations (Modbus multi) and my older one in parallel.
I know, a connection issue on HA side should affect both integrations, but also Inverter related disconnects.
This test should just show, if there are issues related to one of the integrations itself
Which proxy are you using?
this one
I havenāt done any development with a proxy in mind, but if there are any proxy-specific problems let me know. As a direct connect itās very stable and error-free at this point (after 162 releases and counting).
I donāt know how a proxy will work with the connection backoff and retry logic built in to the integration, but it can be adjusted in const.py in the RetrySettings class. Debug logs will show the details. Defaults were based on what works with my installation and tuned from feedback and observations.
Thereās Not much behind this.
Running it since mid 2022 without any issues to overcome the limitation on Solar Edge that only one Connection can be established.
Does anyone have the idea why the Energy Distribution does not work?
I was trying to manually set the values under the āEnergyā tab but the entities which should be used are not shown there.
If I am not wrong those entities should be used there?
sensor.solar_imported_power_kwh:
device_class: energy
sensor.solar_exported_power_kwh:
device_class: energy
sensor.solar_panel_production_kwh:
device_class: energy
sensor.solar_panel_to_house_kwh:
device_class: energy
sensor.solar_house_consumption_kwh:
device_class: energy
For those experiencing issues with their inverters resetting at random intervals, and thus reverting any changes to the default settings, may I suggest my solution of adding a āwatchdogā automation to protect against these events.
Essentially, you want to add changes, to your desired setting(s), as triggers for your automation and then assess their state. If their state is not what you want it to be at that time/under those conditions, then reset it to what it should be. What will happen, in case of a reset, is that your setting will become āunavailableā, your watchdog automation will try to reset it, and fail. Then, when the inverter comes back to life, the state will change again, to the default values. Your watchdog will trigger again, and this time it will be successful at setting your desired values. This should only cost you a second or two of default operation, before your settings are restored.
As an example, this is my watchdog to ensure that my battery remains in grid charge mode throughout the cheap overnight period of my tariff.
alias: Battery Go Watchdog
description: ""
trigger:
- platform: state
entity_id:
- select.solaredge_i1_storage_command_mode
condition:
- condition: and
conditions:
- condition: time
after: "00:30:00"
before: "04:29:00"
- condition: not
conditions:
- condition: state
entity_id: select.solaredge_i1_storage_command_mode
state: Charge from Solar Power and Grid
action:
- device_id: ************************
domain: select
entity_id: ************************
type: select_option
option: Charge from Solar Power and Grid
mode: single
It is also possible to roll this functionality into the main automation, by adding changes of the desired setting as an additional trigger, and using the trigger ID functionality to discern which path to take.
I took a slightly different approach and added a trigger that fires when the inverter has reset.
- platform: state
entity_id:
- switch.solaredge_i1_grid_control
from: unavailable
to: "on"
id: Inverter Reset
The corresponding choose option is:
- conditions:
- condition: trigger
id:
- Inverter Reset
- condition: state
entity_id: input_boolean.grid_charge_home_battery
state: "on"
- condition: state
entity_id: >-
binary_sensor.octopus_energy_target_intermittent_best_rates_3_hours_overnight
state: "on"
sequence:
- service: script.grid_charge_battery
data: {}
This specifically catches the reset that happens overnight, with conditions that check if the home battery should be charging. It can be adapted for any other situation, for example,if Iām charging the EV battery when the home battery is not charging, I shut down the battery output limit to prevent the EV draining the battery. If the inverter resets during this time, it will reset the battery output limit to max and drain the battery into the EV battery. My EV charging automation has th same trigger, with a different set of condtitions to check if the EV battery is charging at the time of reset.
This works every single time. Iām on an Agile tariff, so my charge window is not fixed.
Hello,
nice work.
Maybe I can suggest for the power flow to use a Sankey chart that is really expressive.
KR,
If you happen to have 3 batteries, itās been reported that modbus now supports this.
Please try Release v2.4.9-pre.2 if you have a third battery.
Report your inverter firmware version too if it works.
Starting with Release v2.4.10-pre.2 Iāve added some new controls for Reactive Power Mode and Commit Power Settings.
Hereās an example card with these new entities:
Card YAML:
type: entities
entities:
- entity: select.solaredge_i1_reactive_power_mode
name: Reactive Power Mode
- entity: button.solaredge_i1_commit_power_settings
name: Commit Power Settings
- entity: sensor.solaredge_i1_commit_power_settings
name: Commit Power Settings
- entity: button.solaredge_i1_default_power_settings
name: Default Power Settings
- entity: sensor.solaredge_i1_default_power_settings
name: Default Power Settings
title: I1 Power Settings
The Default Power Settings button entity is disabled by default to avoid accidentally using it. All others are enabled by default.
Button entities send the command and the matching sensor entities show the inverterās response to the command. A value of 0 is success. Other values mean errors (which will be added to the attributes if itās a value that was in the specs).
According to the SolarEdge documentation, youāre supposed to use the ācommitā function to save changes made to most of the controls. I donāt have an inverter that supports controls, so someone with the resetting problem will need to try it and report back.
1 Like
Dave, Many thanks for this very helpful input. I set up a trigger based on this to catch the overnight reset and the evening reset (the overnight one seems to be exactly 10 hours after the evening one). Overall, this has worked, but I have found that on a few occasions, values are being reset without being captured by the trigger.
This is the log extract from this morning:
Have you seen this happen at all ?. I do wonder if my 15sec data capture interval on the modbus configuration is too long so that sometimes I miss all the changes.
Any thoughts would be very helpful.
William
Hi William
I never see any of that in my logbook when the inverter resets. Iām currently running v2.4.10 pre.3 of the modbus-multi integration and all I see over a reset is this when it goes off:
and this when it comes back on:
I donāt see the status of any other related entities reported in my logs, but that could just be the way my recorder is set up 
As long as it works I tend not to bother with the logbook.
Hi Dave.
Many Thanks. For the last few days, I changed my trigger to use
Solaredge B1 Status changes from B_STATUS_OFF
This seems to have worked so far. I am running V 2.4.7 so will maybe update this.
My next task will be to get a better front end to set the daily schedule for overnight charging, preventing discharge during the day then maximise self consumption in the expensive 4:00pm onwards period. I will need to hold all of the values of the battery schedule (command mode, discharge rate etc) in entities so that I can check/reset all of the values when the inverter resets twice a day. Currently using scheduler and the automation trigger to catch the inverter resets. I am also on Octopus Agile, so my ultimate aim will be to have some sort of automation to handle this. I am new to HA so still learning how best to do things !
nothing changed I still have the problem
Also I notice the SolarEdge modbus integration is updating very slowly. Despite I have selected 15 seconds refresh. it takes 3-4 minutes to update the current at every change.
I checked also the inverter connection which is on Wi-Fi next to the AP. From the SolarEdge app I can see the current updating in realtime
Any ideas ?
Prior to opening a bug report on GutHub: On the current prerelease of SolarEdge Modbus Multi plugin, I get a notification about faulty modbus config on every reboot or restart of HA. Was never before. Started a few days ago. When I hit ārepairā everything is ok, and everything works fine.
(I use the modbus proxy addon, always did so. Maybe an issue of startup sequence/wait times)?
Did anything change about that, @willcodeforcats ?
The proxy needs to start before Home Assistant core to avoid connection errors. Iām not aware of any way to force that.
1 Like
Me neither. Just interesting that this never happened before and now it does. Might be that it started with the latest update of either your plugin or HA itself, I cannot say for sure.
Can we have a startup polling delay to bypass this problem?