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.
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.
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.
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.
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:
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 !
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
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)?
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?
I am also seeing this repair notification a lot more than I used to and I was looking at another Home Assistant instance and they commented that they were also seeing this repair a lot more often as well.
The repair used to check on a polling basis the failure condition and self correct if connectivity was restored. It feels like this polling check isn’t occuring so the repair never self repairs it seems to always waits until the user manually presses the repair button.
If you are using a proxy and the proxy doesn’t start before HA starts, the repair issue will be raised when integration set up/start up fails becasue it can’t communicate.
Any start up communications failure will raise the repair issue. I haven’t seen this personally and there have been no changes to how repair issues are handled.
For info - mine isn’t running through a proxy, but in the last few days it’s been unable to connect. Seems to be after recent updates, but difficult to pin down which.
I’m getting the following in the logs:
2024-02-10 19:21:45.806 ERROR (MainThread) [custom_components.solaredge_modbus_multi] Timeout fetching SolarEdge Coordinator data
2024-02-10 19:21:45.807 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 8.403 seconds (success: False)
2024-02-10 19:22:15.405 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] coordinator timeout is 8.4
2024-02-10 19:22:18.684 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Registers received requested : 40 40
2024-02-10 19:22:21.742 DEBUG (MainThread) [custom_components.solaredge_modbus_multi.hub] Registers received requested : 4 4
2024-02-10 19:22:23.807 DEBUG (MainThread) [custom_components.solaredge_modbus_multi] Finished fetching SolarEdge Coordinator data in 8.402 seconds (success: False)
Had been fine until late on 8th Feb, which appears to be when I updated to core_2024.1.6. Currently running ver 2.4.10-pre.4 of the integration.
