@WillCodeForCats My setup has been working beautifully for months. I have recently got an EV car and chose an Autel charger so that I can adjust the charge amps to send ‘export’ generation to the car instead of the grid. This is proving to be more challenging than it should be but an app called EVCC seems to do exactly what’s required. It does how ever want to have modus connection to my SE inverter and only one connection can be made simultaneously. I have to disable the HA Solaredge Modbus connection. The EVCC (https://evcc.io) app does seem to have a Modbus relay feature, I have not tried this as I have got EVCC working on a separate Raspberry Pi and I’d rather not have a system between fully working HA/Modbus and Solaredge. EVCC do have a HACS app for Home Assistant but this doesn’t seem to work/run.
Could your modbus module (or does it) have a relay function to make all SE values received available to EVCC or other app? Perhaps Modbus to MQTT or is there another way I should be looking at this?
I’d be interested to hear how others are solving this.
The Autel Maxi charger (or Evolo badged) doesnt seem to feature the charge rate adjustment via OCPP and their support channel has not responded to numerous queries in over 2 weeks so I may be returning this soon for a charger that does do what I need from a firm that does care about its customers.
Thanks.
Cheers to @Remko for this awesome work!
I would handle the setup but I am running into some small problems.
- I don’t see the Battery discharging values. The modes integrations shows values for this. The sensor solar_battery_to_house_w stays at 0 …
- The graph which shows the state of battery charge is reloading every couple of seconds, so the pointer is moving all the time.
General questions:
- Where do the “Solar production” and “Energy usage” boards get their data from? They are empty at moment.
- In energy_recorder.yaml, is this a global recorder file? So does it impact the recording of other entities in my setup like power plugs?
No, it does not have a proxy function and I would not add one since there is at least one modbus proxy addons available that can do it. I don’t use any proxy personally so I can’t remember the name of the proxy addon I’ve seen before.
The solaredge-modbus-multi integration can coexist with other things that access an inverter over modbus as long as the following conditions are met:
- The modbus connection is not held open by any other program accessing the inverter.
- The integration polling time is greater than 10 seconds.
- The “keep connection open” integration option is disabled.
When I’m doing development work I usually have 3 copies of solaredge-modbus-multi accessing the same inverter (1 on my home system and 2 virtual machines for dev/test work) and they coexist with minimal connection collisions which it handles with retries. But it’s the first condition that other programs fail since they take over the connection and don’t release it between polling cycles. When configured with a polling interval greater than 10 seconds and the keep connection open option disabled, solaredge-modbus-multi will release the modbus connection every time it finishes a polling cycle.
OK, i figured out, that I have to use the default “Energy” Dashboard too.
So are these the correct values?
How can I hide the default Energy Dashboard from the menu?
First of all: Thank you @WillCodeForCats and @Remko for your excellent work!
I’ve been running this setup for a few months now and it is really making life easier 
However, I’ve been experiencing an unusual behavior of the sensor “solar_exported_power_yearly” recently: On Sept. 30 at 12:00 am (beginning of day), the sensor dropped to zero. The “weekly” and “monthly” sensors stayed at their expected levels.
Is this intended behavior or a bug?
Thanks and keep up the good work!
Utility Meter helper does have a reset cycle option, so that can happen if it’s set to do that.
I just checked the configuration and the reset cycle option is not set.
It’s not a bifgdeal and I’ll try to investigate further once I have time for it.
I just wanted to check if anyone else is experiencing similar issues.
Hi shoei600,
I have the same setup as you and I’m using the modbus-proxy Addon and it works perfectly.
The modbus-proxy connects to the SE inverter and both, Home Assistant and EVCC, connect to the modbus-proxy.
Here is a thread, that discusses this solution (although in German):
Good advice, thank you. I’ll try some things.
Is there a method to change the target IP address for SolarEdge Modbus to the new proxy without deleting and reinstalling please? I have searched the file directory and can’t seem to find any files with current IP address. It’s been working so well I’m reluctant to delete and reinstall in case the variables change or do not match as the same afterwards. when I hit ‘configure’ it skips the step for the IP address.
Thanks.
The integration will raise a repair issue asking you to verify connection settings if it can’t connect.
If you want to do this proactively, break the network connection to your inverter (unplug its network or turn it off) and wait for the repair issue to appear.
Hi @uhae, I had the same issue at the same time and I just figured out why: there is a cron in the file energy_utilities.yaml
# Electricity Export
solar_exported_power_yearly:
source: sensor.solar_exported_power_kwh
name: Solar Exported Power Yearly
cron: "0 0 30 9 *"
Hello you all,
Winter is coming and my battery storage (BYD) will probably very often not charge that much during the day (due to my heatpump). So I’m asking myself if there might be a configure the setup, so the battery doesn’t discharge below 30 or 40%. Because otherwise it will always charge a little and discharge a few minutes later back to the minimum (10%). This can’t be good for the battery.
Is there a way to change this?
And is there a way to reduce the maximum discharge permanently (or at least longer than for an hour)?
I don’t know if the storage modes are the same for BYD batteries, but if they are, an automation that triggers when the numeric state of the battery is below 40 (or 30 if you prefer) then sets the storage mode to solar only, effectively turning off the battery, would achieve what you want. For an hour long time period, the same numeric state trigger could also start a 1 hour timer. When that timer ends, that triggers the storage mode back to MSC.
Something like:
trigger:
- platform: numeric_state
entity_id: sensor.your_battery_state_of_charge
below: 40
id: Stop
- platform: event
event_type: timer.finished
event_data:
entity_id: timer.your_one_hour_timer
id: Go
condition: []
action:
- choose:
- conditions:
- condition: trigger
id: Stop
sequence:
- service: timer.start
data: {}
target:
entity_id: timer.your_one_hour_timer
- service: select.select_option
data:
option: Solar Power Only (Off)
target:
entity_id: select.solaredge_i1_storage_command_mode
- conditions:
- condition: trigger
id: Go
sequence:
- service: select.select_option
data:
option: Maximize Self Consumption
target:
entity_id: select.solaredge_i1_storage_command_mode
You’ll also need to:
A: Make sure you put your own entity_ids in the relevant places.
B: Create a timer helper for the one hour countdown. Whatever you call that helper is the entity_id you put in the timer.your_one_hour_timer
If you want to turn the battery off for longer than one hour just set the timer helper for a longer period.
You might also want to consider preventing this automation from running under certain conditions etc.
I’ll leave that to you to determine.
One final thing to consider is the storage_command_timeout value. It defaults to 3600 secs, or 1 hour. So if your storage_default_mode is MSC and this automation changes the storage_command_mode to Solar Power Only (Off), after 3600 secs, or 1 hour, it will revert back to MSC no matter how long you set the timer for. So if you want to turn the battery off for longer than 1 hour, you would either have to also set the storage_command_timeout value to a higher number, or instead of changing the storage_command_mode change the storage_default_mode to Solar Power Only (Off).
Hope that makes sense.
THANK you very much! You made me thinking and I did the following:
I created a helper called “Winter-Mode”
And I created two automations:
alias: Wintermodus Batterie - Timeout auf 24h
description: ""
trigger:
- platform: time_pattern
hours: /1
condition:
- condition: state
entity_id: input_boolean.wintermodus_batterie
state: "on"
action:
- service: script.solaredge_timeout_24h
data: {}
mode: single
That runs a script that sets the timeout to 24h, if winter mode is on.
And I created a second automation:
alias: Wintermodus Batterie - Moduswechsel
description: ""
trigger:
- platform: time_pattern
minutes: /1
condition:
- condition: state
entity_id: input_boolean.wintermodus_batterie
state: "on"
for:
hours: 0
minutes: 0
seconds: 0
- condition: state
entity_id: select.solaredge_i1_storage_control_mode
state: Remote Control
action:
- if:
- condition: numeric_state
entity_id: sensor.power_solar_generation
above: sensor.power_consumption
- condition: state
entity_id: select.solaredge_i1_storage_command_mode
state: Solar Power Only (Off)
for:
hours: 0
minutes: 0
seconds: 0
then:
- device_id: REMOVED
domain: select
entity_id: REMOVED
type: select_option
option: Maximize Self Consumption
- if:
- condition: numeric_state
entity_id: sensor.power_solar_generation
below: sensor.power_consumption
- condition: state
entity_id: select.solaredge_i1_storage_command_mode
state: Maximize Self Consumption
for:
hours: 0
minutes: 0
seconds: 0
- condition: numeric_state
entity_id: sensor.solaredge_b1_state_of_energy
below: 40
then:
- device_id: REMOVED
domain: select
entity_id: REMOVED
type: select_option
option: Solar Power Only (Off)
mode: single
This does the following:
EVERY minute it checks the following:
- Condition: Winter Mode is On
- Condition: SolarEdge Storage Control is in Remote Control Mode
ACTION:
IF
the solar panels produce more energy than the house consumpts
AND
the Storage Command Mode is currently in “Solar Power Only (Off)” mode
THEN
switch to “Maximize Self Consumption Mode”
but
IF
the solar panels produce less then the house consumes
AND
the Storage Mode is currently set to Maximize Self Consumption
AND
the State of Energy of the Battery is below 40%
THEN
The Storage Command Mode is set to “Solar Power Only (Off)”
I think this should work, right?
I’m just working though that first automation:
So every hour, if “Winter Mode” is on, run a script that sets the timeout value to 24h?
Why every hour? You only need to set the timeout once before you change the storage command mode for it to work. Resetting it every hour may cause issues. In my experience, the system doesn’t like it and will do some weird things. It’s almost like the system wants or needs the timeout to return to the default regularly.
So in it’s current form, here’s what will happen: -
Every time your second automation changes the storage command mode, and that could be every minute, the system will start the timeout counting down from whatever value it is set at, in this case, 24hrs. My understanding of the system is that the timeout value is set in one register and held there. The actual countdown involves the transfer of the value in the timeout register into a counter that counts down. That happens when the storage command mode changes. The fact that the timeout value is held in a separate register allows the system to always be able to check what the value is set to before it starts the countdown. It doesn’t continue from where it left off last time it ran.
Remember, that’s my understanding of how it works. I’m an electrical/electronics engineer, but I didn’t design the SE system. There are probably many ways of running a countdown system that I haven’t even heard of.
Anyway, if we go on the premis that my understanding is correct, I would set the timeout to max once every day and then check the history after a couple of days to see what it’s actually doing. You might have to adjust the frequency to every 12 hours if it starts acting strangely, but once every 24 hours should do it. I know at least one other SE system user who holds his system’s timeout at 24 hours. I’m not sure how he does it, or how often he changes his system’s storage command mode, but it works for him.
In your second automation:
The condition to check the storage control mode is “Remote Control” is probably not needed. I leave my system in “Remote Control” all the time and it never changes. Why would you need to check it?
Additionally, you could potentially have the storage command mode changing every minute if conditions are such that supply and consumption levels flip every minute when the battery is below 40%. In my opinion, that’s probably not good for your system and could be problematic.
That said, you’ve created quite an adventurous automation. I’d be interested to see how/if it works as expected. My guess is that the timeout may be an issue and the storage command mode potentially flipping every minute might also be an issue.
I think all you can do is run it and see how it goes.
First of all - THANK YOU very much, for thinking my automations through and for your valuable hints and advice.
I changed the first script to every 12 hours. But are you certain, that running the script really resets the countdown? Because regularly is set to 24h before and it’s still 24h after. So I assumed it doesn’t change. I also built the following automation to have a viewable timer (countdown) and it doesn’t get reset, when the script is being launched, when the timeout was already set to 24h before:
alias: Set Timeout Timer
description: ""
trigger:
- platform: state
entity_id:
- number.solaredge_i1_storage_command_timeout
- platform: state
entity_id:
- number.solaredge_i1_storage_discharge_limit
- platform: state
entity_id:
- select.solaredge_i1_storage_command_mode
- platform: state
entity_id:
- number.solaredge_i1_storage_charge_limit
condition: []
action:
- service: timer.start
data:
duration: "{{states('number.solaredge_i1_storage_command_timeout') }}"
target:
entity_id: timer.solaredge_timeout_timer
mode: single
But I changed it to 12h anyway, because the only reason I set it to 1h was, so that when I activate Winter Mode, the timeout is being set to 24h more quickly. But of course you could also achieve that by simply making another automation, that sets it to 24h the moment you activate Winter Mode, right?
Now to the second automation:
The reason I have “Remote Control” as a condition is due to my Energy Dashboard:
When winter mode is off, you can manually change the timeout and see a timer:
In Auto-Mode the System is set to the Default Mode, in Manual Mode to Remote Control. You can only activate Winter Mode in the Manual Setting. However, the helper of course could be active even though you can’t see the switch. By making it necessary, that Remote Control is active, I make sure, that nothing runs in the background when it’s set to “Auto-Mode”. At least that was my thinking. On the other hand, when the system is not set to Remote Control, all the other things (changing timeout, changing storage command mode) wouldn’t work anyway. But it doesn’t do any harm, doing it this way, right?
About the switching every minunte:
YES - that is what was actually happening this morning. What do you think could happen?
And do you have ANY other idea, how to achieve what I want? The easiest way would be an option in the SolarEdge system, to set the minimum battery level up from 10% to 30 or 40%. Some other systems seem to offer this option.
Okay, perhaps I wasn’t clear. Running the script every hour doesn’t reset the countdown itself. It resets the timeout value, ie the value the countdown will start from. As far as I’m aware, we can’t actually see the value of the internal SE countdown as it’s counting down. Creating a timer is of course a great way of monitoring it for yourself. Just be sure to make sure your own countdown timer resets every time the storage command mode changes. That way, your countdown will mirror the internal SE countdown timer.
Right.
Excellent. I’d expect it to do exactly that, I’m just not sure what sort of strain, if any, it might put on your system to have it switch modes so frequently. I might be doing SE a huge disservice in that their system might be robust enough to handle that. Time will tell I guess.
Brilliant work on the dashboard BTW. I like your flip style countdown timer 
Thanks again for your reply. I changed automation 1 to running every 23 hours. This way, I still make sure, that it get’s checked before the 24h are over. And I made another automation that activates the “set timeout to 24h script” when the winter mode button is being activated (for at least one minute).
I will give a feedback in a few weeks/months how it’s been working for me.
And thank your for the feedback to the dashboard. I’m really happy with it! 